[Schema Consistency] Schema Consistency Check — 2026-02-23

[github-actions[bot]]

This report covers the seventeenth automated schema consistency run (day 54 → proven strategy). Strategy used: Network/Firewall/Engine Deep Dive + Runtime Typed Struct Audit (Strategy-12). Three parallel analysis agents examined network/firewall files, runtime typed structs, and safe-outputs/permissions schemas.

Summary

Metric	Value
New findings	13
Critical severity	6
Confirmed unfixed from previous runs	2
Strategy	Network/Firewall/Engine Deep Dive + Runtime Typed Struct Audit
Areas covered	Network/firewall engine support, domain sanitization logic, permissions schema, runtime typed structs, safe-outputs serialization
Workflow run	§22301210648

---

Critical Issues

1. Schema network.firewall Description Is Wrong — All 4 Engines Support Firewall

Files: pkg/parser/schemas/main_workflow_schema.json:2225, pkg/workflow/copilot_engine.go:45, pkg/workflow/claude_engine.go:32, pkg/workflow/codex_engine.go:44, pkg/workflow/gemini_engine.go:28

The schema network.firewall description reads:

"AWF (Agent Workflow Firewall) configuration for network egress control. Only supported for Copilot engine."

In reality all four engines have supportsFirewall: true in their engine definitions. This is a stale description that will mislead users of the Claude, Codex, and Gemini engines into thinking the firewall is unavailable to them.

2. Firewall log-level / log_level Key Name Mismatch Across Two Parse Paths

Files: pkg/workflow/engine.go:220, pkg/workflow/frontmatter_extraction_security.go:123

Two separate code paths parse firewall configuration from user YAML using different key names for the same field:

• engine.go:220 — reads firewallObj["log_level"] (underscore)
• frontmatter_extraction_security.go:123 — reads firewallObj["log-level"] (hyphen)

A user who writes network: firewall: { log-level: debug } gets the expected behavior via the security extraction path. A user who tries to set the log level in an engine.firewall: block must use log_level with an underscore — an inconsistency not documented anywhere. Neither the schema nor docs mention this divergence.

3. cleanup_script Field Parsed from engine.firewall but Absent from Schema

Files: pkg/workflow/engine.go:227, pkg/workflow/firewall.go:20, pkg/parser/schemas/main_workflow_schema.json

engine.go:227 silently reads firewallObj["cleanup_script"] from the user's YAML and stores it in FirewallConfig.CleanupScript. This field is entirely absent from the schema (which has additionalProperties: false on the engine config object properties) and from all documentation. It is a hidden/undiscoverable feature. The FirewallConfig struct comment notes the default is ./scripts/ci/cleanup.sh, suggesting it has real production significance.

4. hasNetworkRestrictions() Ignores Blocked Domain List

Files: pkg/workflow/engine_firewall_support.go:17-35

func hasNetworkRestrictions(networkPermissions *NetworkPermissions) bool {
    // ...only checks Allowed list...
    // Blocked list is never checked
}

A workflow specifying only network: blocked: ["tracker.example.com"] with no allowed: list returns false from this function, meaning checkNetworkSupport skips firewall validation entirely. Attempts to block specific domains without an explicit allowlist will silently pass compilation without the firewall being engaged.

5. computeAllowedDomainsForSanitization Missing gemini Case

Files: pkg/workflow/domains.go:695-706

switch engineID {
case "copilot": return GetCopilotAllowedDomains(...)
case "codex":   return GetCodexAllowedDomains(...)
case "claude":  return GetClaudeAllowedDomains(...)
default:        return GetAllowedDomains(...)  // ← Gemini falls here
}

Gemini falls into default, which calls GetAllowedDomains() — this does not include GeminiDefaultDomains. The function GetGeminiAllowedDomainsWithToolsAndRuntimes at domains.go:611 exists and correctly merges Gemini defaults but is not called from this sanitization path. Gemini workflows therefore receive an incomplete domain allowlist during sanitization.

6. permissions Schema Missing repository-projects and organization-projects Scopes

Files: pkg/workflow/permissions.go:39-42, 83-84, 105-106, pkg/parser/schemas/main_workflow_schema.json

The permissions schema uses additionalProperties: false and lists 16 scopes, but two scopes fully implemented in Go code are absent:

• repository-projects (PermissionRepositoryProj — permissions.go:40)
• organization-projects (PermissionOrganizationProj — permissions.go:42)

Any workflow YAML that sets either of these scopes will fail schema validation even though the runtime handles them correctly. Additionally, the schema allows an all key (for all: read style permissions) that has no corresponding case "all" in convertStringToPermissionScope at permissions.go:28-47, so users setting permissions: all: write get a silent "Unknown permission scope key: all" log entry with no compilation error.

---

Documentation Gaps

7. docs/reference/network.md Understates Engine Coverage

File: docs/src/content/docs/reference/network.md:10,40,186

The docs state:

"Network permissions are currently supported by the Claude engine and the Copilot engine (when using the firewall feature)."

Codex and Gemini both have supportsFirewall: true and dedicated default domain lists (CodexDefaultDomains at domains.go:40, GeminiDefaultDomains at domains.go:95). The network.md "Implementation" section (line 186) only documents the Copilot engine. Claude, Codex, and Gemini engine subsections are absent.

8. Runtime Typed Struct RuntimeConfig Missing action-repo and action-version

Files: pkg/workflow/frontmatter_types.go:16-19, pkg/workflow/runtime_overrides.go:41-42, schema runtimes section, docs/src/content/docs/reference/frontmatter.md:148-150

RuntimeConfig struct:

type RuntimeConfig struct {
    Version string `json:"version,omitempty"`
    If      string `json:"if,omitempty"`
}

Both action-repo and action-version are documented, in the schema, and read from the raw map in runtime_overrides.go:41-42 — but absent from the typed struct. If any code path routes through RuntimesTyped instead of the raw Runtimes map, these fields would be silently dropped.

9. RuntimesConfig Typed Struct Missing 5 Supported Runtimes

Files: pkg/workflow/frontmatter_types.go:16-29, 301-315, pkg/workflow/runtime_definitions.go

RuntimesConfig only models: node, python, go, uv, bun, deno (6 runtimes).

knownRuntimes in runtime_definitions.go defines 11 runtimes: the same 6 plus dotnet, elixir, haskell, java, ruby. The parseRuntimesConfig switch statement at frontmatter_types.go:301-315 is also missing these 5 cases. All 11 are documented in frontmatter.md:156-165.

10. rust Runtime Silently Dropped for Serena Local Mode

Files: pkg/workflow/runtime_detection.go (Serena language map), pkg/workflow/runtime_definitions.go, pkg/parser/schemas/main_workflow_schema.json:3318

runtime_detection.go maps Serena language "rust" → runtime ID "rust" with the comment: // rust is not in knownRuntimes yet, but including for completeness. When a user configures Serena with rust in local mode, findRuntimeByID("rust") returns nil and logs "runtime 'rust' not found" — no setup step is generated, silently. The schema enum at line 3318 includes "rust" as a valid Serena language, so users following the schema believe this configuration is supported.

---

Schema Improvements Needed

Medium Issues: Schema/Struct Serialization Gaps

11. SafeOutputsConfig Plural YAML Tags vs Singular Schema Keys

Files: pkg/workflow/compiler_types.go:476-522, pkg/parser/schemas/main_workflow_schema.json

Seven struct fields use plural yaml tags that don't match the singular schema keys:

Go struct field	yaml tag (PLURAL)	Schema key (SINGULAR)
CreateIssues	create-issues	create-issue
CreateDiscussions	create-discussions	create-discussion
CloseDiscussions	close-discussions	close-discussion
AddComments	add-comments	add-comment
CreatePullRequests	create-pull-requests	create-pull-request
CreatePullRequestReviewComments	create-pull-request-review-comments	create-pull-request-review-comment
UpdateIssues	update-issues	update-issue

Parsing is done via direct outputMap["create-issue"] key lookups so user-facing behavior is correct today. However, if SafeOutputsConfig is ever marshaled back to YAML (e.g., via trial_command.go:516 JSON marshal path), the plural yaml keys would fail additionalProperties: false schema validation — a latent round-trip bug.

12. activation-comments Parsed from Top-Level but Stored in Messages Sub-Struct

Files: pkg/workflow/safe_outputs_config.go:419-428, pkg/workflow/compiler_types.go:540, schema

The schema places activation-comments as a top-level property of safe-outputs. safe_outputs_config.go:423 correctly reads it from the top-level outputMap. However, compiler_types.go:540 puts the field inside SafeOutputMessagesConfig with yaml tag activation-comments. If the struct is marshaled to YAML, the field would appear under safe-outputs.messages.activation-comments — a path that does not exist in the schema and would fail additionalProperties: false on messages.

13. SafeOutputsConfig Meta Fields Not Merged from Imported Workflows (Confirmed from Strategy-11)

Files: pkg/workflow/imports.go:655-720

Still not fixed. Five meta fields are never merged from imported configs:

Field	Type
SafeOutputsConfig.Footer	*bool
AllowGitHubReferences	[]string
GroupReports	bool
MaxBotMentions	*string
Mentions	*MentionsConfig

Confirmed Unfixed from Previous Runs

These findings from previous strategy runs are confirmed still present:

Finding	First Found	Status
hasSafeOutputType() missing 11 operations causing silent import conflict pass-through	Strategy-11 (2026-02-22)	Still present — imports.go:422 switch statement unchanged
tools.serena.languages schema additionalProperties:false restricts to 6 languages but runtime supports 32	Strategy-11 (2026-02-22)	Still present — schema items.enum unchanged

---

Recommendations

1. Fix network.firewall schema description — remove "Only supported for Copilot engine"; all four engines support it (main_workflow_schema.json:2225).

2. Fix firewall key name inconsistency — standardize log_level to log-level in engine.go:220 to match the pattern used in frontmatter_extraction_security.go:123.

3. Add cleanup_script to schema — add it to the appropriate schema object (or move its parsing to the correct documented field if it is accidental).

4. Fix hasNetworkRestrictions() — add a check for len(networkPermissions.Blocked) > 0 to return true when only a blocked list is specified (engine_firewall_support.go:17-35).

5. Add gemini case to computeAllowedDomainsForSanitization — call GetGeminiAllowedDomainsWithToolsAndRuntimes for the "gemini" engine ID (domains.go:695).

6. Add repository-projects and organization-projects to permissions schema — with additionalProperties: false these valid scopes currently fail schema validation for users who set them.

7. Update network.md documentation — document Codex and Gemini engine support for network/firewall features; add engine-specific subsections.

8. Add action-repo and action-version to RuntimeConfig struct and add missing runtime IDs (dotnet, elixir, haskell, java, ruby) to RuntimesConfig and parseRuntimesConfig switch (frontmatter_types.go).

9. Add rust to knownRuntimes or document in the schema that rust Serena language support does not generate a runtime setup step.

10. Fix hasSafeOutputType() missing 11 cases (carry-over from Strategy-11) — add all missing operation type keys to imports.go:422.

11. Expand Serena language enum (carry-over from Strategy-11) — remove or expand the additionalProperties: false on serena.languages to match the 32 languages supported by SerenaLanguageSupport.

---

Strategy Performance

Metric	Value
Strategy	Network/Firewall/Engine Deep Dive + Runtime Typed Struct Audit
Approach	3 parallel agents: network/firewall subsystem, stop-after/github-token/runtime, safe-outputs/permissions
New findings	13
Effectiveness	HIGH — network/firewall subsystem had never been deeply analyzed; all agents found actionable issues
Should reuse	YES — parallel agent decomposition by subsystem is highly effective

References:

• §22301210648

AI generated by Schema Consistency Checker

• expires on Feb 24, 2026, 10:14 AM UTC

[pelikhan]

/plan

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-02-24T10:14:58.986Z.

Closed by Workflow