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

[github-actions[bot]]

Schema consistency analysis run on 2026-02-20 using Strategy 9: Struct-Schema Differential Field Audit (proven strategy, day 051 → 51 mod 10 = 1).

Summary

Metric	Value
Inconsistencies found	6
Critical bugs	2
Schema gaps	2
Documentation gaps	2
Strategy	Struct-Schema Differential Field Audit (new)
Run reference	§22219493995

---

Critical Issues

1. messages.detection-failure is silently ignored at runtime

Severity: Critical — user-configured values are silently dropped.

The messages.detection-failure field is correctly defined in the JSON schema and the SafeOutputMessagesConfig struct, and the JS runtime (messages_run_status.cjs) is ready to consume it. However, neither parseMessagesConfig nor mergeMessagesConfig extract this key from the raw YAML frontmatter map.

Layer	Status
pkg/parser/schemas/main_workflow_schema.json	✅ defined
compiler_types.go:539 (DetectionFailure field)	✅ defined
actions/setup/js/messages_run_status.cjs (JS consumer)	✅ implemented
safe_outputs_config_messages.go parseMessagesConfig()	❌ missing
imports.go mergeMessagesConfig()	❌ missing
Test coverage in Go	❌ none

Impact: A workflow author who sets messages.detection-failure: "custom message" will have their value silently ignored. The JS runtime will always fall back to the default message "⚠️ Security scanning failed for [{workflow_name}]({run_url})...".

Fix: Add handling to parseMessagesConfig() in pkg/workflow/safe_outputs_config_messages.go:

if detectionFailure, exists := messagesMap["detection-failure"]; exists {
    if detectionFailureStr, ok := detectionFailure.(string); ok {
        config.DetectionFailure = detectionFailureStr
    }
}

And mirror in mergeMessagesConfig() in pkg/workflow/imports.go:

if result.DetectionFailure == "" && imported.DetectionFailure != "" {
    result.DetectionFailure = imported.DetectionFailure
}

---

2. messages.agent-failure-issue and messages.agent-failure-comment are schema-blocked features

Severity: Critical — fields usable in JS runtime are completely blocked by additionalProperties: false.

The SafeOutputMessagesConfig struct defines two fields (agent-failure-issue, agent-failure-comment) that are consumed by the JS runtime in actions/setup/js/messages_footer.cjs:136-155. However:

• They are absent from the schema's messages.properties
• The schema sets additionalProperties: false — so schema validation will reject any workflow that uses these fields
• They are not handled in parseMessagesConfig() or mergeMessagesConfig()
• They are undocumented

Layer	Status
compiler_types.go:540-541 (struct fields)	✅ defined
actions/setup/js/messages_footer.cjs:136-155 (JS consumer)	✅ implemented
pkg/parser/schemas/main_workflow_schema.json messages schema	❌ absent (blocked by additionalProperties: false)
safe_outputs_config_messages.go parseMessagesConfig()	❌ missing
imports.go mergeMessagesConfig()	❌ missing
Documentation	❌ undocumented

Impact: The feature exists in the JS runtime but cannot be activated through frontmatter. Schema validation will reject attempts with an additionalProperties error before the Go parser even runs.

Fix: Add both fields to pkg/parser/schemas/main_workflow_schema.json under properties["safe-outputs"]["properties"]["messages"]["properties"], add parsing in parseMessagesConfig(), merging in mergeMessagesConfig(), and documentation.

---

Schema Gaps

3. MCP config proxy-args field missing from mcp_config_schema.json

The proxy-args field is fully implemented:

• mcp_config_custom.go:634-635 — extracted from frontmatter
• mcp_config_custom.go:451-471 — rendered to TOML and JSON formats
• mcp_config_comprehensive_test.go:891-892 — test coverage exists
• Listed in propertyOrder for both stdio and container MCP types

But proxy-args is absent from pkg/parser/schemas/mcp_config_schema.json (which has 14 properties: allowed, args, command, container, entrypoint, entrypointArgs, env, headers, mounts, network, registry, type, url, version).

Note: The MCP schema does not use additionalProperties: false, so this won't cause validation errors — but IDE autocompletion and schema-driven tooling won't suggest the field, and there's no schema-level type documentation.

Fix: Add to pkg/parser/schemas/mcp_config_schema.json:

"proxy-args": {
  "type": "array",
  "items": { "type": "string" },
  "description": "Additional proxy arguments passed to the MCP gateway proxy layer"
}

---

4. safe-outputs schema $comment lists 4 missing operations

The $comment field on the safe-outputs schema object serves as the authoritative list of supported operations, but it omits 4 valid operations that are fully defined in the schema properties:

Missing operation	Schema property	Documentation
assign-to-user	✅ defined	✅ documented in safe-outputs.md:1134
unassign-from-user	✅ defined	✅ documented in safe-outputs.md:1149
create-project	✅ defined	✅ documented in safe-outputs.md:435
missing-data	✅ defined	✅ documented in safe-outputs.md:890

This affects tooling and AI agents that read the $comment to understand available operations.

Fix: Update $comment in pkg/parser/schemas/main_workflow_schema.json to include the four missing operations.

---

Documentation Gaps

5. messages Templates list in safe-outputs.md is incomplete

docs/src/content/docs/reference/safe-outputs.md:1256 lists:

Templates: footer, footer-install, staged-title, staged-description, run-started, run-success, run-failure

Missing from this list (but defined in schema and struct):

• footer-workflow-recompile
• footer-workflow-recompile-comment
• detection-failure

And not yet documented at all:

• agent-failure-issue (pending fix #2 above)
• agent-failure-comment (pending fix #2 above)

Fix: Update the Templates list in safe-outputs.md to include all supported message template fields.

---

6. messages.detection-failure placeholder {operation} not listed in variables

The schema messages description says: Available placeholders: {workflow_name} (workflow name), {run_url} (GitHub Actions run URL), {triggering_number} (issue/PR/discussion number), {workflow_source} (owner/repo/path@ref), {workflow_source_url} (GitHub URL to source), {operation} (safe-output operation name for staged mode).

However, detection-failure specifically uses {workflow_name} and {run_url} (not {operation}). The docs at safe-outputs.md:1268 list {operation} as a variable but don't clarify which templates support which placeholders. The variable documentation could be more precise.

---

Recommendations

1. Immediate (bug fix): Add detection-failure parsing to parseMessagesConfig() and mergeMessagesConfig() — one-line fix each with no architectural change needed.

2. Immediate (schema fix): Add agent-failure-issue and agent-failure-comment to the messages schema properties to unblock these JS-runtime features. Also add parsing and merging in Go.

3. Quick wins:

   • Update $comment in safe-outputs schema to include assign-to-user, unassign-from-user, create-project, missing-data
   • Update safe-outputs.md templates list
   • Add proxy-args to mcp_config_schema.json

4. Process improvement: The pattern of adding fields to the Go struct and JS runtime without updating the schema and parser functions has appeared multiple times (detection-failure, agent-failure-*). Consider adding a linting check or PR template checklist item that verifies: when a field is added to SafeOutputMessagesConfig, it must also be added to (a) schema, (b) parseMessagesConfig, (c) mergeMessagesConfig, and (d) documentation.

---

Strategy Performance

• Strategy used: Struct-Schema Differential Field Audit (new — strategy-9)
• Approach: Extracted all struct fields from SafeOutputMessagesConfig, compared against schema properties, checked parseMessagesConfig/mergeMessagesConfig for completeness, cross-referenced JS runtime usage
• Findings: 6
• Effectiveness: HIGH — direct struct-to-schema comparison is very reliable for finding half-implemented features
• Should reuse: YES — especially effective after PRs that add new message customization fields

References:

• §22219493995

AI generated by Schema Consistency Checker

• expires on Feb 27, 2026, 10:08 AM UTC

[github-actions[bot]]

This discussion was automatically closed because it expired on 2026-02-27T10:08:12.667Z.

Closed by Workflow