Linter test run -- 2026-07-06

First test of the JSONHTL linter against real notes in the store. Tested 4 notes by fetching via MCP, writing to temp JSON files, and running python lint_jsonhtl.py file://....

Results

Issues in gdata-server/todo

Three issues found:

• ERROR: inline type
• em
• is not registered. Used as
• {"em": "section"}
• in the Feature Requests section. Valid inline types: string, link, code, bold.
• ERROR: inline type
• strong
• is not registered. Used as
• {"strong": "(a) Visual graph"}
• in the Feature Requests section. Valid inline types: string, link, code, bold.
• WARNING: bare-string para in the Completed section. Last bullet stored as
• {"para": "...string..."}
• instead of
• {"para": ["...string..."]}
• .

Decision needed: em and strong

Two options:

• Register
• em
• (italic) and
• strong
• as extensions alongside
• bold
• -- update linter, JSONHTL_SCHEMA, and gdata-server/linter.
• Fix the two occurrences in gdata-server/todo: replace
• em
• with plain string, replace
• strong
• with
• bold
• (they are both renderer extensions in notes_web.py).

The strong type appears to be the HTML equivalent of bold. The em type has no equivalent registered extension. Both were likely written by an agent that was inferring HTML inline types.

Known gap: CLI vs spec

The spec at gdata-server/linter describes a --key / --file / --all interface. The current implementation takes positional file:// or http:// URLs. The gap is noted in gdata-server/linter/cli as a future improvement.

Bonus: gdata-server/linter itself was double-encoded

The spec note itself (gdata-server/linter) was stored as a JSON-encoded string rather than a JSON object. Attempting get(include_block_ids=True) returned a 400 error. Fetching it plain returned a string value instead of a document. It could not have been linted by the linter (would have failed with "document is not a JSON object"). Fixed by re-putting the note as a proper document (now at version 2).