[Schema Consistency] 🔍 Schema Consistency Check - 2026-10-03

[github-actions[bot]]

Summary

• Inconsistencies Found: 4
• Categories Analyzed: Schema, Parser, Documentation, Workflows
• Strategy Used: Schema-def spot checks + targeted parser/doc/workflow verification
• New Strategy: NO

Critical Issues

1. Schema default mismatch for max-runs

   • Schema (pkg/parser/schemas/main_workflow_schema.json) declares top-level max-runs default as 500.
   • Documentation says default is 5 in docs/src/content/docs/reference/frontmatter.md:387 and docs/src/content/docs/reference/frontmatter-full.md:1761.
   • Impact: users/operators may tune policy based on incorrect expected run limits.

2. Schema default mismatch for check-for-updates

   • Schema default is true.
   • Documentation says default is false in docs/src/content/docs/reference/frontmatter.md:741, docs/src/content/docs/reference/frontmatter-full.md:2094, and docs/src/content/docs/reference/configuration.md:164.
   • Impact: update-check behavior differs from documented expectations.

Documentation Gaps

1. Workflow references runs-on-slim but primary run-configuration docs under-emphasize framework-job scope interactions
   • Parser/runtime support and precedence are implemented and tested (pkg/workflow/safe_outputs_runtime.go, pkg/workflow/runs_on_validation_test.go).
   • Workflows and references use this heavily, but readers starting from frontmatter-only sections can miss precedence details unless they jump to self-hosted runners reference.
   • Impact: configuration confusion in mixed runs-on, runs-on-slim, and safe-outputs.runs-on setups.

Schema Improvements Needed

1. Clarify defaults as canonical source in docs generation pipeline
   • Current doc examples appear stale against schema defaults for max-runs and check-for-updates.
   • Recommendation: derive rendered “Default” values directly from schema where possible.

Parser Updates Required

1. No parser/schema field drift detected at top-level in this run
   • schema_fields and frontmatter_fields match in /tmp/gh-aw/agent/schema-diff.json.
   • field_gaps.in_schema_not_frontmatter and field_gaps.in_frontmatter_not_schema are empty.

Workflow Violations

1. No top-level unknown frontmatter keys detected in repository workflows

   • field_gaps.in_used_not_schema is empty in /tmp/gh-aw/agent/schema-diff.json.

2. AWF config-source drift status degraded (non-authoritative warning)

   • /tmp/gh-aw/agent/awf-config-drift.json reports degraded: true and canonical source retrieval failures.
   • Per instructions, this is treated as informational only and not used for corrective PR/issue actions.

Recommendations

1. Align documentation defaults for max-runs and check-for-updates with schema defaults immediately.
2. Add CI/docs guardrail that compares frontmatter default callouts in docs to schema default fields.
3. Add a compact “runner precedence” note in the main frontmatter section pointing to the full self-hosted-runners precedence matrix.
4. Keep using precomputed schema diff as the first-pass detector; it correctly ruled out parser-field drift here.

Strategy Performance

• Strategy Used: Schema-def spot checks + targeted parser/doc/workflow verification
• Findings: 4
• Effectiveness: HIGH
• Should Reuse: YES

Next Steps

• Fix documentation default for max-runs
• Fix documentation default for check-for-updates
• Add schema↔docs default consistency check in CI/docs lint
• Add explicit frontmatter runner precedence cross-reference

Generated by ✅ Schema Consistency Checker · codex · gpt53codex · 8.14 AIC · ⌖ 4.02 AIC · ⊞ 22.2K · ◷

• expires on Oct 3, 2026, 9:42 PM UTC-08:00

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-10-04T05:42:57.073Z.

Closed by Workflow