[Schema Consistency] 🔍 Schema Consistency Check — 2026-06-16

[github-actions[bot]]

Summary

• Inconsistencies Found: 3 (1 high / 1 medium re-priority / 1 high re-confirmed)
• Categories Analyzed: Schema ↔ Parser ↔ Documentation ↔ Workflows
• Strategy Used: NEW — BaseSafeOutputConfig field coverage diff (strategy-27)
• New Strategy: YES (day-of-year mod 10 = 7 → "try a new approach")

This run introduced a new probe: the BaseSafeOutputConfig and per-type config structs are inlined onto every safe-output type via yaml:",inline". Diffing each struct's yaml-tagged fields against that type's schema oneOf object branch (all additionalProperties: false) surfaces fields the compiler consumes but the schema rejects under strict validation.

---

Critical Issues

1. normalize-closing-keywords is absent from the entire JSON schema (HIGH — new)

normalize-closing-keywords is a BaseSafeOutputConfig field, so it is inlined onto every safe-output type. It is actively consumed by the compiler and documented as a user-facing feature, but it appears 0 times in main_workflow_schema.json. Because every safe-output object branch is additionalProperties: false, any workflow that sets it fails schema validation despite being a fully working, documented feature.

Evidence

• Struct: pkg/workflow/compiler_types.go:640 — NormalizeClosingKeywords *bool \yaml:"normalize-closing-keywords,omitempty"``
• Consumed by handlers: pkg/workflow/safe_outputs_handler_registry.go:29 (create_issue), :49 (add_comment), :472 (create_pull_request) — each emits normalize_closing_keywords
• Documented: docs/src/content/docs/experimental/safe-outputs-samples.md:102 lists it alongside max:, github-token:, github-app: as a standard safe-output feature
• Schema: grep -c "normalize-closing-keywords" main_workflow_schema.json → 0

Net effect: a documented + implemented field is rejected by schema validation for create-issue, add-comment, and create-pull-request.

Fix: Add normalize-closing-keywords (boolean) to the schema object branches of create-issue, add-comment, and create-pull-request (or wherever the base config is meant to apply).

2. engine.extensions triple gap (HIGH — re-confirmed, still OPEN)

Re-confirmed from prior runs and still unresolved.

Evidence

• Parser reads it: pkg/workflow/engine.go:469 (engineObj["extensions"]), consumed into config.Extensions (Pi engine)
• Schema: extensions is absent from all engine/engine_config oneOf branches (all additionalProperties: false) → rejected under strict validation
• Docs: not present in docs/src/content/docs/reference/engines.md

Fix: Add extensions (array of strings) to the engine config schema branches and document it in engines.md.

---

Schema vs Parser Mismatches

3. create-discussion.required-category schema-rejected (MEDIUM — new)

CreateDiscussionsConfig reads required-category and the compiler emits it, but the schema only declares required-category under close-discussion, not create-discussion.

Evidence

• Struct: pkg/workflow/create_discussion.go:25 — RequiredCategory string \yaml:"required-category,omitempty"``
• Used: pkg/workflow/create_discussion.go:99 (close-older matching), emitted at pkg/workflow/safe_outputs_handler_registry.go:86 as required_category
• Schema: safe-outputs.create-discussion is oneOf:[object(additionalProperties:false), null]; the object branch has no required-category. The key exists in schema only under close-discussion (line ~5808).
• Docs: frontmatter-full.md:4013 documents required-category only under close-discussion.

Fix: Either add required-category to the create-discussion schema branch (it is meaningfully used when close-older-discussions is set) or remove it from CreateDiscussionsConfig if unintended.

---

Lower-confidence / secondary

• github-app partial schema coverage: github-app is a BaseSafeOutputConfig field (applies to all 73 safe-output types) but is declared in only 3 schema type branches (create-pull-request, create-check-run, push-to-pull-request-branch). May be intentional; flagged for review, not asserted as a defect.

Still-open low-priority (carried from prior runs)

• dispatch-repository dash alias accepted by parser but only dispatch_repository (underscore) is in schema (strategy-24).
• dispatch_repository is the sole snake_case key among kebab-case safe-output siblings (strategy-19).

---

Recommendations

1. Add normalize-closing-keywords to the schema branches of create-issue, add-comment, create-pull-request (highest impact: documented feature currently un-schemable).
2. Add engine.extensions to engine config schema branches + document in engines.md.
3. Add required-category to the create-discussion schema branch (or remove from the Go struct).
4. Decide whether github-app should be uniformly declared across safe-output schema branches or restricted; document the intent.

Strategy Performance

• Strategy Used: BaseSafeOutputConfig field coverage diff (new, strategy-27)
• Findings: 2 new (1 high, 1 medium) + 1 re-confirmed high
• Effectiveness: HIGH
• Should Reuse: YES — extend the struct-vs-schema-branch diff to all remaining safe-output types and to tools.* sub-objects next run.

Next Steps

• Add normalize-closing-keywords to relevant safe-output schema branches
• Add engine.extensions to schema + engines.md
• Reconcile create-discussion.required-category (schema or struct)
• Review github-app coverage consistency across safe-output types

References: §27600402542

Generated by ✅ Schema Consistency Checker · 152.8 AIC · ⌖ 31.6 AIC · ⊞ 5.8K · ◷

• expires on Jun 16, 2026, 11:14 PM UTC-08:00