Z.ai Coding Agent Review

This PR replaces ts-json-schema-generator with a dual-interpreter approach: the same declarative loader schemas (GLOBALS_SCHEMA, VARIABLE_SCHEMA, CACHE_SCHEMA, SET_ARMS, layout grammar, etc.) now feed both the runtime validator (via parse facets) and the JSON Schema emitter (via json facets). This is a strong [LAW:one-source-of-truth] improvement — the old schema derived from dsl-types.ts and could drift from the loader (it was missing cells nodes, for example). The new approach closes that gap.

No must-change issues found. Observations for the author's attention:

1. [LAW:types-are-the-program] — JsonNode = Readonly<Record<string, unknown>> is very loose. The withConst function (validate-core.ts:604-616) and setArm (actions.ts:296) cast JsonNode to { properties, required } via as, trusting that objectJson always produces that shape. The type doesn't enforce it. A full JSON Schema AST would be impractically large, so this is a pragmatic choice — but if withConst ever receives a non-object node (e.g. an anyOf), it would silently produce garbage.

2. The input variable arm hand-authors its json (variables.ts:209-219) instead of deriving from objectJson(fieldMap). This is the one drift point where the schema shape is not mechanically derived from the field map. The comment explains why (cross-field invariant between type and default), and the hand-authored shape matches the parse, but adding a new field to input's parse would require remembering to update the hand-authored json too. Consider a note or assertion tying the two.

3. Schema size doubled (~673 → ~1393 lines) because CacheDecl is now inlined in every variable kind instead of $ref-shared. This is fine for editor validation but worth being aware of.

4. cells node kind is now correctly included in the LayoutNode schema definition — a real accuracy fix over the old schema. The existing config-schema.test.ts doesn't have a GOOD config that exercises cells through ajv; adding one would pin the new arm.

✅ Approved

Z.ai Coding Agent Review

This PR replaces ts-json-schema-generator with a hand-rolled schema emitter that derives JSON Schema from the same declarative loader schemas the runtime validator interprets. Each FieldSpec, PresentArm, and TaggedArm now carries a json facet alongside its parse function, and module-level *Json() functions compose these into the full editor-facing schema. This is a strong [LAW:one-source-of-truth] improvement — the schema and validator now read the same declarations.

Must-change: The input variable arm at src/config/loader/variables.ts:209-218 hand-authors its json object separately from its parse logic, while every other variable arm derives json from field specs via arm(). This creates a second source of truth for the input variable's shape that can drift from the parse logic. The fix is to define INPUT_FIELDS and use arm("input", INPUT_FIELDS) like all other kinds — a custom default field spec can handle the cross-field (default-matches-type) invariant since parse receives the full raw record.

Pre-existing / non-blocking observations:

• The committed schema artifact roughly doubled in size (~673 → ~1393 lines) because the shared CacheDecl definition is now inlined per-variable-kind rather than referenced via $ref. This is mechanically generated so not a LAW issue, but schema consumers now download a larger file. A future $ref extraction pass over the emitted tree could reduce this if it becomes a concern.
• The test in test/config-schema.test.ts provides good [LAW:verifiable-goals] coverage: it validates the committed artifact against Ajv, asserts the schema/loader boundary (structurally-bad configs fail both; semantically-bad configs pass schema but fail loader), and the check:schema guard prevents drift. The cells layout node kind (previously missing from the type-derived schema) is now correctly covered.

❌ Request Changes

Z.ai Coding Agent Review

The PR replaces ts-json-schema-generator with a custom schema emitter derived from the same declarative loader schemas (FieldSpec maps, TaggedUnionSchema, OneOfPresentSchema, RecordSchema) that the runtime validator interprets. Each FieldSpec now carries a json facet alongside parse, and emit helpers (objectJson, recordJson, withConst, taggedUnionJson, oneOfPresentJson) project those declarations into JSON Schema mechanically. The input variable arm was refactored from a hand-authored parse closure into a field map (INPUT_FIELDS) using inputDefaultSpec for its cross-field invariant — closing the last spot where parse and schema were authored independently. This is a genuine [LAW:one-source-of-truth] improvement: the old schema derived from TypeScript types (which knew structure but not exactly-one-present for cache/actions, and omitted cells sugar), while the new one derives from the actual validation declarations.

Must-change (1): The layout node schema regression — layoutNodeJson() emits arms with no required fields because layout field specs use required: false for parse-time error recovery. The parse functions always return fallback values (never undefined), so changing to required: true is safe and restores the schema's structural enforcement.

Pre-existing note: JsonNode = Readonly<Record<string, unknown>> is very loose — it admits any object, not just valid JSON Schema fragments. This is a pragmatic tradeoff (a full JSON Schema type would be extremely complex), and the check:schema guard + config-schema.test.ts catch structural drift, but the type doesn't enforce correctness at compile time. Not a regression; worth noting for future tightening.

❌ Request Changes

Z.ai Coding Agent Review

This PR replaces ts-json-schema-generator with a dual-interpreter pattern: each declaration (FieldSpec, PresentArm, TaggedArm) now carries both a parse facet (runtime validation) and a json facet (schema emission), composed by mechanical emit helpers (objectJson, recordJson, taggedUnionJson, oneOfPresentJson). This directly enforces [LAW:one-source-of-truth] — the editor-facing schema and the runtime validator now derive from the same declarations, closing real drift (the old type-derived schema missed the cells sugar and exactly-one-present constraints).

No must-change items found. The diff is clean:

• All FieldSpec/PresentArm/TaggedArm instances have json facets (enforced by TypeScript since the interfaces now require readonly json: JsonNode).
• The input arm was correctly refactored to use arm() with inputDefaultSpec() (reads sibling raw.type to resolve the cross-field default invariant), closing the last hand-authored parse/schema split.
• The required: false → true changes on layout fields (cellsSegmentsSpec, segmentNameSpec, directionSpec, childrenSpec, literalSpec) correctly reflect their semantic mandatory nature in the emitted schema — the parse recovers (so fields() treats required: true as a no-op), but the schema now correctly marks them required. The new test cases for bare container/segment nodes validate this.
• refine() correctly stays outside the schema path — it wraps ArmParse (not FieldSpec), and the schema derives from the field map directly. Cross-field refinements (min<max, by≠0) are correctly excluded from the schema as unexpressible.
• The cells node kind is now included in the LayoutNode definition, and the recursive $ref for children correctly mirrors the lazy thunk.

Observations (not must-change):

• The generated schema grew from 673 to 1406 lines because the cache anyOf is inlined per variable kind instead of shared via $ref. This is cosmetic — the source of truth is still CACHE_SCHEMA, and the output is auto-generated.
• JsonNode = Readonly<Record<string, unknown>> is deliberately loose to avoid a parallel typed AST. The tradeoff is documented.
• withConst uses type assertions (as Record<string, unknown>), which is fragile in principle but correct in practice since it's only called with objectJson output.

✅ Approved