You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Found 3 actionable inconsistencies across schema, compiler/parser, and documentation. Workflow usage was checked with bounded static scans. Strategy: cached schema spot checks plus targeted parser/doc/workflow verification (proven strategy; day 303 modulo 10 = 3). No source files changed or workflows executed.
Key Issues
High — refusal-labels is advertised as an available guard but is rejected and not emitted.docs/src/content/docs/reference/mcp-gateway.md:1617 describes label-based integrity downgrades and provides two configuration examples. The GitHub tool schema omits this property; parsing in pkg/workflow/tools_parser.go:306 handles blocked users, approval labels, and trusted users without refusal labels. Guard-policy serialization in pkg/workflow/mcp_github_config.go:459 likewise has no refusal-label mapping. The documented example fails schema validation. Users cannot configure the advertised restriction through this frontmatter. Either implement schema, parsing, validation, and serialization together with precedence tests, or clearly mark the documentation as a future contract and remove runnable examples until supported. No runtime bypass was tested or inferred.
Medium — documented allowed-repos: current shorthand is unsupported.docs/src/content/docs/reference/cross-repository.md:68 lists current and claims normalization to the current repository; the example at line 82 uses it. pkg/parser/schemas/main_workflow_schema.json:5087 accepts only all, public, the literal GitHub repository expression, or an array. pkg/workflow/tools_validation_github.go:222 special-cases those supported strings; current instead reaches repository-pattern validation. Replace the example with ${{ github.repository }}, or implement and test normalization alongside the schema addition.
Medium — FAQ places custom MCP servers under an invalid key.docs/src/content/docs/reference/faq.md:224 shows tools.mcp-servers.my-server, rejected because tools disallows the mcp-servers property. The supported top-level field is defined at pkg/parser/schemas/main_workflow_schema.json:4914. The FAQ also uses image, so moving the block alone is insufficient: rewrite the complete example using a supported HTTP or stdio/container server shape and validate it against the relevant definition. A top-level HTTP server control passes.
Validation, scope, and excluded leads
Started from /tmp/gh-aw/agent/schema-diff.json and the cached strategy database. The apparent docker-image-pull-policy and work-queue-policy gaps are false positives: both have RawFrontmatter consumers. The precomputed used-in-workflows comparison contains no unknown top-level keys.
Scanned reference YAML snippets as data, preserving YAML on keys and Boolean values. Reduced the three findings to inert Draft7 examples; each unsupported shape was rejected. Corresponding supported controls passed the selected property constraints. Required workflow-level fields were excluded for these partial fragments; this was not whole-workflow compilation.
Cross-checked compiler/parser consumers for the affected settings. No repository or workflow code was executed.
Scanned 497 workflow/shared Markdown files for literal allowed-repos: current and refusal-labels: in frontmatter; neither appeared. This is a targeted usage check, not a claim that all workflows and imported configurations are schema-valid. No workflow edits are recommended from this evidence.
Excluded issues already recorded in the strategy cache rather than repeating prior findings.
Updated the successful strategy record and findings in the strategy database.
Non-authoritative AWF Warning
The supplied AWF config comparison is degraded: canonical source retrieval failed for the config specification and schema sources. No authoritative AWF drift conclusion can be drawn. This warning does not fail a required check and does not justify a corrective PR or drift issue.
Next Actions
Resolve the refusal-labels implementation/documentation contract together.
Correct the current shorthand documentation or implement it consistently.
Replace the FAQ MCP example with a fully schema-valid server configuration.
Add focused documentation-example validation for these cases.
Strategy Performance
Findings: 3. Effectiveness: High. Reuse: Yes. Minimal rejected examples paired with passing controls separated real documentation mismatches from raw-map field false positives.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Overview
Found 3 actionable inconsistencies across schema, compiler/parser, and documentation. Workflow usage was checked with bounded static scans. Strategy: cached schema spot checks plus targeted parser/doc/workflow verification (proven strategy; day 303 modulo 10 = 3). No source files changed or workflows executed.
Key Issues
High —
refusal-labelsis advertised as an available guard but is rejected and not emitted.docs/src/content/docs/reference/mcp-gateway.md:1617describes label-based integrity downgrades and provides two configuration examples. The GitHub tool schema omits this property; parsing inpkg/workflow/tools_parser.go:306handles blocked users, approval labels, and trusted users without refusal labels. Guard-policy serialization inpkg/workflow/mcp_github_config.go:459likewise has no refusal-label mapping. The documented example fails schema validation. Users cannot configure the advertised restriction through this frontmatter. Either implement schema, parsing, validation, and serialization together with precedence tests, or clearly mark the documentation as a future contract and remove runnable examples until supported. No runtime bypass was tested or inferred.Medium — documented
allowed-repos: currentshorthand is unsupported.docs/src/content/docs/reference/cross-repository.md:68listscurrentand claims normalization to the current repository; the example at line 82 uses it.pkg/parser/schemas/main_workflow_schema.json:5087accepts onlyall,public, the literal GitHub repository expression, or an array.pkg/workflow/tools_validation_github.go:222special-cases those supported strings;currentinstead reaches repository-pattern validation. Replace the example with${{ github.repository }}, or implement and test normalization alongside the schema addition.Medium — FAQ places custom MCP servers under an invalid key.
docs/src/content/docs/reference/faq.md:224showstools.mcp-servers.my-server, rejected becausetoolsdisallows themcp-serversproperty. The supported top-level field is defined atpkg/parser/schemas/main_workflow_schema.json:4914. The FAQ also usesimage, so moving the block alone is insufficient: rewrite the complete example using a supported HTTP or stdio/container server shape and validate it against the relevant definition. A top-level HTTP server control passes.Validation, scope, and excluded leads
/tmp/gh-aw/agent/schema-diff.jsonand the cached strategy database. The apparentdocker-image-pull-policyandwork-queue-policygaps are false positives: both haveRawFrontmatterconsumers. The precomputed used-in-workflows comparison contains no unknown top-level keys.onkeys and Boolean values. Reduced the three findings to inert Draft7 examples; each unsupported shape was rejected. Corresponding supported controls passed the selected property constraints. Required workflow-level fields were excluded for these partial fragments; this was not whole-workflow compilation.allowed-repos: currentandrefusal-labels:in frontmatter; neither appeared. This is a targeted usage check, not a claim that all workflows and imported configurations are schema-valid. No workflow edits are recommended from this evidence.Non-authoritative AWF Warning
The supplied AWF config comparison is degraded: canonical source retrieval failed for the config specification and schema sources. No authoritative AWF drift conclusion can be drawn. This warning does not fail a required check and does not justify a corrective PR or drift issue.
Next Actions
refusal-labelsimplementation/documentation contract together.currentshorthand documentation or implement it consistently.Strategy Performance
Findings: 3. Effectiveness: High. Reuse: Yes. Minimal rejected examples paired with passing controls separated real documentation mismatches from raw-map field false positives.
References: §41008353798
All reactions