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

[github-actions[bot]]

Overview

Found 3 actionable documentation inconsistencies against the local frontmatter schema and compiler contracts. No critical runtime bug was established. Reviewed schema, parser/compiler, documentation, and actual workflow/shared-component usage.

• Strategy: Schema-def spot checks + targeted parser/doc/workflow verification (cached strategy-2; new strategy: no). Day-of-year 302 modulo 10 = 2 selected a proven strategy.
• Validation: Three minimal inert configurations were rejected by Draft7 validation; all three corrected controls passed. No workflow code was executed.
• Workflow coverage: Targeted scan of 465 workflow/shared-component frontmatter mappings, including 10 dispatch configuration objects; no selected literal violations found. This was not a full compilation or import-resolution audit.

Key Issues / Documentation Gaps

1. Reusable-workflow worker example advertises unsupported input types. docs/src/content/docs/reference/safe-outputs.md:1508 shows on.workflow_call.inputs.environment.type: choice with options, and the following prose lists choice as supported. The schema at pkg/parser/schemas/main_workflow_schema.json:2251 permits only string, number, and boolean for workflow_call inputs and rejects options. Users copying the worker example cannot pass schema validation. Fix: use type: string, remove options, and document how the worker validates the allowed environment values. Keep choice examples scoped to workflow_dispatch.

2. Dispatch examples omit the required workflow allowlist and advertise an unsupported approval field. The FAQ example at docs/src/content/docs/reference/faq.md:186 contains only max: 1. The manual-review example at docs/src/content/docs/reference/rate-limiting-controls.md:105 contains only environment: production. The dispatch schema requires a nonempty workflows array (pkg/parser/schemas/main_workflow_schema.json:11763, :11859) and does not define environment. Compiler validation independently rejects an empty workflow list (pkg/workflow/dispatch_workflow_validation.go:29); the dispatch config struct has no environment field (pkg/workflow/dispatch_workflow.go:12). Fix: add an explicit allowlist such as workflows: [worker] to both examples; replace the manual-review advice with a documented GitHub Environment gate on the appropriate job. Merely adding workflows does not make the environment field valid.

3. Sandbox example uses the unsupported legacy network.firewall field. docs/src/content/docs/reference/sandbox.md:116 shows network.firewall: true. The network schema defines no firewall property and rejects additional properties (pkg/parser/schemas/main_workflow_schema.json:3927, :4020). The compiler lint rule explicitly diagnoses network.firewall as unsupported (pkg/workflow/lint/firewall_ssl_bump.go:27). Fix: remove the firewall line and retain sandbox.agent: awf with the existing network.allowed list. This is a local documentation/schema mismatch, not a conclusion about upstream AWF config drift.

Analysis details, exclusions, and limitations

Schema ↔ Parser Assessment

The precomputed root gaps were not missing implementations: docker-image-pull-policy is read through RawFrontmatter in pkg/workflow/docker.go:294; work-queue-policy has RawFrontmatter consumers in pkg/workflow/work_queue_policy.go:132. No schema expansion or parser change is recommended for these gaps.

The three validation controls changed only the disputed fields: workflow_call choice/options → string without options; dispatch max-only → max plus workflows; network.firewall → omitted legacy field with allowed retained. Each corrected configuration passed local schema validation.

Workflow Violations

No matching literal violations were found in the targeted scan. Existing workflow_dispatch choice inputs were not confused with workflow_call inputs. Shared fragments, runner-pod Kubernetes snippets, and GitHub Actions job snippets were not treated as complete gh-aw frontmatter. Previously cached findings were excluded from the new issue count.

Schema Improvements Needed / Parser Updates Required

None established by these findings. Preserve the current accepted contracts and correct the examples first. A useful follow-up is documentation-example validation that recognizes frontmatter fragments and excludes other YAML dialects.

AWF Canonical-Source Warning — Non-Authoritative

/tmp/gh-aw/agent/awf-config-drift.json reports degraded=true: canonical retrieval failed for docs/awf-config-spec.md, docs/awf-config.schema.json, and src/awf-config-schema.json. Upstream AWF drift cannot be assessed authoritatively. No required check failure, corrective PR, or drift issue is proposed from that incomplete comparison.

Strategy Performance

• Findings: 3; effectiveness: high; should reuse: yes.
• Updated strategy-2 in strategies.json with the date, successful controls, findings, and bounded workflow coverage.
• Repository source files were not modified. No runtime execution or full compiler test suite was needed for this read-only analysis.

Recommendations / Next Steps

• Correct the workflow_call worker example and supported-type claim.
• Add workflow allowlists to dispatch examples and correct the environment approval guidance.
• Remove network.firewall from the sandbox example.
• Add schema checks for documentation frontmatter examples with explicit snippet classification.
• Revisit AWF config-source drift only after canonical retrieval is restored.

References: §40823324864

Generated by ✅ Schema Consistency Checker · codex · gpt61 · ~22 AIC · ⌖ ~7 AIC · ⊞ 19.7K · ◷

• expires on Oct 29, 2026, 9:31 PM UTC-08:00

[github-actions[bot]]

This discussion has been marked as outdated by Schema Consistency Checker.

A newer discussion is available at Discussion #73115.