[Schema Consistency] Schema Consistency Check - 2026-02-22

[github-actions[bot]]

Summary

• Inconsistencies Found: 4 (1 critical, 1 significant, 2 medium)
• Categories Analyzed: Schema ↔ Parser, Schema ↔ Implementation, Schema ↔ Documentation, Import System
• Strategy Used: Strategy-11 — Import Conflict Detection Gap Analysis (new strategy, extends Sub-Object Compilation Gap Analysis from runs 9-10)
• Day of Year: 053 (mod 10 = 3 → proven strategy path)

This run focused on two new analysis areas not previously covered: (1) hasSafeOutputType() switch statement coverage relative to the schema's operation list, and (2) tools.serena.languages schema restriction vs runtime support. Both produced actionable findings.

---

Critical Issues

1. tools.serena.languages — Schema Blocks 26+ Supported Languages

File: pkg/parser/schemas/main_workflow_schema.json → tools.serena.languages
Constants: pkg/constants/constants.go:435 (SerenaLanguageSupport)

The schema for tools.serena.languages has additionalProperties: false and only defines 6 language keys: go, typescript, python, java, rust, csharp.

However SerenaLanguageSupport in constants.go defines 30+ supported languages:

go, typescript, javascript, python, java, rust, csharp, cpp, c, ruby, php,
bash, swift, kotlin, scala, haskell, elixir, erlang, clojure, lua, perl, r,
dart, julia, fortran, nix, rego, terraform, yaml, markdown, zig, elm

Impact: Any user using the long-form object syntax to configure an unsupported language gets a schema validation error at compile time. For example:

# FAILS schema validation (schema blocks it):
tools:
  serena:
    languages:
      javascript: null   # ❌ additionalProperties: false
      ruby: null         # ❌ additionalProperties: false

# WORKS (array short-syntax has no enum restriction):
tools:
  serena: ["javascript", "ruby"]   # ✅ passes schema validation

This creates an inconsistency between short-syntax and long-syntax: the short array syntax accepts any language string, but the object languages: syntax rejects the same languages with a schema validation error.

Recommendation: Either add all supported languages as named properties to the schema, or change additionalProperties to true (or a permissive schema) so the object syntax can accept any language identifier that the runtime supports.

---

Significant Issues

2. hasSafeOutputType() Missing 11 Operations — Silent Import Conflict Pass-Through

File: pkg/workflow/imports.go:425 (hasSafeOutputType function)

hasSafeOutputType() is used by MergeSafeOutputs() to detect when both a main workflow and an imported workflow define the same safe-output operation type (which is a conflict). The function has a switch statement that maps schema operation keys to struct fields, but 11 operations present in both the schema and the struct are missing from the switch:

Missing Operation	Struct Field
assign-to-user	AssignToUser
unassign-from-user	UnassignFromUser
mark-pull-request-as-ready-for-review	MarkPullRequestAsReadyForReview
autofix-code-scanning-alert	AutofixCodeScanningAlert
link-sub-issue	LinkSubIssue
hide-comment	HideComment
dispatch-workflow	DispatchWorkflow
missing-data	MissingData
create-project	CreateProjects
create-project-status-update	CreateProjectStatusUpdates
update-discussion	UpdateDiscussions

Impact: When hasSafeOutputType(config, "assign-to-user") is called, it falls through to default: return false. This causes topDefinedTypes["assign-to-user"] to be false even when the main workflow HAS configured assign-to-user. An imported workflow can then also define assign-to-user without triggering a conflict error — the user never gets warned about the duplicate definition.

Note: The actual merge logic in mergeSafeOutputConfig (lines ~540–615) DOES handle all 11 operations correctly (first-wins semantics), so configurations don't get silently dropped. The bug is specifically in conflict detection — users aren't warned when they create potentially ambiguous configurations across imports.

Recommendation: Add the 11 missing cases to hasSafeOutputType() in pkg/workflow/imports.go.

View suggested additions to hasSafeOutputType()

case "assign-to-user":
    return config.AssignToUser != nil
case "unassign-from-user":
    return config.UnassignFromUser != nil
case "mark-pull-request-as-ready-for-review":
    return config.MarkPullRequestAsReadyForReview != nil
case "autofix-code-scanning-alert":
    return config.AutofixCodeScanningAlert != nil
case "link-sub-issue":
    return config.LinkSubIssue != nil
case "hide-comment":
    return config.HideComment != nil
case "dispatch-workflow":
    return config.DispatchWorkflow != nil
case "missing-data":
    return config.MissingData != nil
case "create-project":
    return config.CreateProjects != nil
case "create-project-status-update":
    return config.CreateProjectStatusUpdates != nil
case "update-discussion":
    return config.UpdateDiscussions != nil

---

Documentation / Schema Gaps

3. safeOutputMetaFields Missing 4 Config Fields

File: pkg/parser/schema_compiler.go:85 (safeOutputMetaFields map)

GetSafeOutputTypeKeys() reads all keys from the schema's safe-outputs.properties and excludes those in safeOutputMetaFields. The current exclusion list covers 9 meta fields, but 4 configuration fields present in the schema are not excluded:

Field	Type in Struct	Present in Schema	In safeOutputMetaFields
footer	*bool	✅	❌
group-reports	bool	✅	❌
mentions	*MentionsConfig	✅	❌
allowed-github-references	[]string	✅	❌

Impact: GetSafeOutputTypeKeys() returns these 4 config fields as "safe output operation type keys". Callers that iterate over those keys (like hasSafeOutputType) will call hasSafeOutputType(config, "footer") which returns false (no case for it) — functionally harmless in the current conflict detection code, but conceptually incorrect and could cause subtle bugs if GetSafeOutputTypeKeys() is used for other purposes.

Recommendation: Add footer, group-reports, mentions, and allowed-github-references to safeOutputMetaFields.

4. mergeSafeOutputConfig Doesn't Merge 5 Meta Config Fields From Imports

File: pkg/workflow/imports.go:492 (mergeSafeOutputConfig function)

mergeSafeOutputConfig merges imported workflow safe-outputs configs into the main workflow. Several configuration fields are handled (AllowedDomains, Staged, Env, GitHubToken, MaximumPatchSize, RunsOn, Messages), but 5 configuration fields are not merged:

Field	Type	Effect of Missing Merge
Footer	*bool	If import sets footer: false, it's silently dropped
Mentions	*MentionsConfig	If import configures mention filtering, it's silently dropped
GroupReports	bool	If import enables group-reports, it's silently dropped
AllowGitHubReferences	[]string	If import whitelists GitHub refs, entries are silently dropped
App	*GitHubAppConfig	If import configures GitHub App credentials, they're silently dropped

Recommendation: Add merge logic for these 5 fields in mergeSafeOutputConfig, consistent with how other meta fields are handled (main workflow takes precedence, import fills in only when empty/nil).

---

Strategy Performance

• Strategy Used: Strategy-11 — Import Conflict Detection Gap Analysis (new)
• Findings: 4 findings across 2 major areas
• Effectiveness: HIGH (found real functional bug in conflict detection + schema validation bug blocking users)
• Should Reuse: YES — the pattern of auditing function switch statement coverage vs schema keys is highly effective for finding gaps

Next Steps

• Schema: Add 26 missing languages to tools.serena.languages.properties in main_workflow_schema.json, or change additionalProperties to accept any string key
• Parser: Add 11 missing cases to hasSafeOutputType() in pkg/workflow/imports.go
• Parser: Add footer, group-reports, mentions, allowed-github-references to safeOutputMetaFields in pkg/parser/schema_compiler.go
• Compiler: Add merge logic for Footer, Mentions, GroupReports, AllowGitHubReferences, App in mergeSafeOutputConfig in pkg/workflow/imports.go

References:

• §22274796614

AI generated by Schema Consistency Checker

• expires on Mar 1, 2026, 10:04 AM UTC