Repository navigation
[Schema Consistency] 🔍 Schema Consistency Check - 2026-10-31 #73429
Closed
Replies: 1 comment
|
This discussion has been marked as outdated by Schema Consistency Checker. A newer discussion is available at Discussion #73715. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Overview
Found 3 actionable documentation inconsistencies after comparing the schema, compiler, reference documentation, and repository workflows. No critical runtime bug was established. Analysis was static; no workflows or untrusted scripts were executed.
Key Issues
FAQ dispatch example omits the required workflow allowlist. faq.md:185 shows only
safe-outputs.dispatch-workflow.max: 1. The schema requiresworkflows(schema:11882), and dispatch_workflow_validation.go:29 explicitly rejects an empty workflow list. Impact: copying the advertised configuration fails validation. Fix: addworkflows: [worker-name]and explain that the named worker must exist and supportworkflow_dispatch. Adding that list passes the isolated schema check.Manual approval example nests
environmentat an unsupported location. rate-limiting-controls.md:104 placesenvironment: productioninsidedispatch-workflow. Even after adding the required workflow list, that nested property is rejected because the dispatch object disallows additional properties. dispatch_workflow.go:12 has no environment field; the supported environment override is extracted from the global safe-outputs map in safe_outputs_config_global.go:290. Impact: the documented manual-review configuration cannot compile. Fix: moveenvironment: productiontosafe-outputs.environment, alongside a dispatch configuration containingworkflows. That corrected shape passes the schema. Repository environment reviewers still need configuration as described in the docs.Reusable-worker input example advertises schema-invalid
choiceinputs. safe-outputs.md:1507 declareson.workflow_call.inputs.environment.type: choiceandoptions, then listschoiceas supported. The workflow_call schema permits onlystring,number, andbooleanand rejectsoptions(schema:2268). Impact: the documented worker fails frontmatter validation. Fix: usetype: stringfor reusable-workflow inputs and removeoptions; describe any application-level allowed-value validation separately. Align the typed-worker fixture in call_workflow_compilation_test.go:194, which also useschoice, and verify the complete worker through normal frontmatter validation. The string-only control passes. Generic choice-to-enum support in build_input_schema.go:48 does not establish that workflow_call accepts that declaration.Scope, false positives, and strategy performance
Schema and Parser Assessment
The precomputed top-level gaps
docker-image-pull-policyandwork-queue-policyare false positives from struct-tag enumeration: both have RawFrontmatter consumers, respectively inpkg/workflow/docker.go:294andpkg/workflow/work_queue_policy.go:184. No missing implementation is claimed. The confirmed issues require documentation corrections; no schema broadening or parser feature addition is recommended merely to accept the faulty examples.Workflow Violations
No selected literal patterns were found in the 471 parsed workflow/shared blocks. Imports and shared components were not treated as standalone complete workflows. Findings from earlier cached runs were excluded.
AWF Comparison Warning — Non-authoritative
/tmp/gh-aw/agent/awf-config-drift.jsonreportsdegraded: true: canonical source retrieval failed for the AWF specification and schemas. No authoritative AWF config-source drift conclusion is possible. This warning is separate from the three local documentation findings; no required-check failure, corrective PR, or drift issue is requested from that incomplete comparison.Strategy Performance
Next Actions
References: §41172406285
All reactions