[Schema Consistency] 🔍 Schema Consistency Check - 2026-06-30

[github-actions[bot]]

Summary

• Inconsistencies Found: 4
• Categories Analyzed: Schema, Parser, Documentation, Workflows
• Strategy Used: Engine sub-object key coverage + parser key-alias verification
• New Strategy: NO

Critical Issues

1. ** is documented but not present in the schema or parser key set**

   • Schema: has at line 12107, but no property.
   • Parser/compiler: reads only ; there is no parser read for .
   • Docs: and document as a supported field.
   • Impact: Users following the docs can write a field that schema validation should reject and the compiler/parser will ignore if validation is bypassed upstream.

2. Built-in engine catalog docs/schema omit despite runtime support and real workflow usage

   • Runtime/compiler: registers engine id ; tests also expect it in .
   • Workflow usage: uses .
   • Docs/schema-generated reference: lists built-ins as , omitting . available engines table also omits it.
   • Impact: Valid workflows look undocumented/invalid, and schema-generated examples under-advertise a supported engine.

Documentation Gaps

1. ** canonical key vs generated reference drift**

   • Parser/compiler: treats as canonical and only keeps as a deprecated alias.
   • Schema: both keys exist ( at , deprecated alias at ).
   • Docs: surfaces only in the example block.
   • Impact: The auto-generated reference nudges users toward the deprecated spelling rather than the canonical one the compiler logs about.

2. ** is implemented and documented in , but not visible in the main human-oriented frontmatter reference**

   • Parser/compiler: parses .
   • Schema: property exists at .
   • Docs: specialized doc exists at , but reduces to a one-line pointer/example and does not mention this engine-specific field family.
   • Impact: Users reading the primary frontmatter guide can miss a supported engine field that is available in schema and parser.

Schema Improvements Needed

1. Add an explicit schema decision for Copilot SDK driver naming:
   • either introduce in and map it in the parser, or
   • remove/replace all docs that advertise it and standardize on .
2. Add everywhere the built-in engine catalog is enumerated in schema descriptions/examples.
3. Prefer canonical in generated docs/examples; keep underscore alias clearly marked deprecated.

Parser Updates Required

1. Reconcile vs documented :
   • parser currently supports only (),
   • docs claim a separate key,
   • schema lacks that claimed key.
2. If backward compatibility is desired, parser could accept both keys and emit a deprecation warning for the losing form.

Workflow Violations

• No invalid in-repo workflow usage was confirmed in the sampled checks.
• Instead, the main workflow-side inconsistency is the opposite: uses a runtime-supported engine that the schema/docs examples do not advertise.

Recommendations

1. Fix the Copilot SDK driver field drift first because it is a direct schema ↔ parser ↔ docs contradiction.
2. Update engine catalog enumerations to include in schema descriptions and engine docs.
3. Regenerate after preferring canonical keys so appears instead of the deprecated underscore alias.
4. Expand the human-oriented frontmatter guide with a short pointer to engine-specific subfields such as , , , and .

Strategy Performance

• Strategy Used: Engine sub-object key coverage + parser key-alias verification
• Findings: 4
• Effectiveness: HIGH
• Should Reuse: YES

Next Steps

• Fix schema/docs/parser naming for Copilot SDK driver
• Add to built-in engine enumerations and examples
• Regenerate frontmatter reference to prefer canonical safe-output keys
• Improve frontmatter guide coverage for engine subfields

References:

• §28425422807

Generated by ✅ Schema Consistency Checker · 42.2 AIC · ⌖ 24.5 AIC · ⊞ 7.4K · ◷

• expires on Jun 30, 2026, 10:47 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-07-01T06:47:34.173Z.

Closed by Workflow