[Schema Consistency] Workflow-First Analysis: reaction Field Missing, Polymorphic Pattern Gaps

[github-actions[bot]]

This analysis took a radically different approach by starting with 150 production workflows and reverse-engineering their patterns to validate against schema, parser, and documentation. This "workflow-first" methodology discovered critical gaps where implementation and documentation exist but schema representation is missing or incomplete.

Summary

• Inconsistencies Found: 7 (3 critical, 2 moderate, 2 informational)
• Workflows Analyzed: 150 production workflows
• Categories: Schema gaps, polymorphic patterns, nested configurations
• Strategy: NEW - Strategy-021: Workflow-First Reverse Engineering
• Effectiveness: Very High - discovered unique issues missed by 20 previous strategies

Critical Issues Requiring Immediate Action

Critical Issues

1. reaction Field Missing from Schema ⚠️

Severity: Critical - Feature is fully implemented, tested, and documented but absent from JSON schema

Evidence:

• ✅ Documented: docs/src/content/docs/reference/frontmatter.md:34 lists reaction as trigger option
• ✅ Fully Documented: docs/src/content/docs/reference/frontmatter-full.md:578-589 provides complete specification
• ✅ Tested: 12 test files validate reaction functionality
  • pkg/workflow/activation_checkout_test.go:48-59
  • pkg/workflow/comment_env_vars_conditional_test.go:22-57
  • Multiple other test files reference and validate behavior
• ✅ Implemented: Runtime code handles reaction logic fully
• ❌ Schema: jq '.properties | has("reaction")' main_workflow_schema.json returns false

Supported Values (from documentation):

reaction: eyes      # Default for command workflows
reaction: rocket    # Custom emoji
reaction: +1        # String format
reaction: 1         # Numeric format (thumbs up)
reaction: none      # Disable reactions

Valid Reactions: +1, -1, laugh, confused, heart, hooray, rocket, eyes, none

Impact:

• External JSON Schema validators reject valid workflows
• IDE autocomplete and validation tools cannot suggest reaction field
• Documentation-schema gap causes user confusion
• Schema is incomplete representation of system capabilities

Recommended Fix:

"reaction": {
  "description": "Emoji reaction to add on triggering items (issues, PRs, comments). Use 'none' to disable. Defaults to 'eyes' for command workflows.",
  "oneOf": [
    {
      "type": "string",
      "enum": ["+1", "-1", "laugh", "confused", "heart", "hooray", "rocket", "eyes", "none"],
      "default": "eyes"
    },
    {
      "type": "integer",
      "enum": [1, -1],
      "description": "Numeric aliases: 1 for thumbs up, -1 for thumbs down"
    }
  ],
  "examples": ["eyes", "rocket", "+1", 1, "none"]
}

File to Update: pkg/parser/schemas/main_workflow_schema.json

---

2. cache-memory Polymorphic Patterns Incompletely Captured

Severity: Critical - Schema may not capture full complexity of production usage patterns

Pattern A - Simple Boolean (5+ workflows):

tools:
  cache-memory: true
  timeout: 300

• Used in: audit-workflows.md, ci-doctor.md, cli-version-checker.md

Pattern B - Array of Objects (10+ workflows):

tools:
  cache-memory:
    - id: metrics
      key: code-metrics-${{ github.workflow }}
    - id: token-metrics
      key: copilot-token-metrics-${{ github.workflow }}

• Used in: daily-code-metrics.md, daily-copilot-token-report.md, developer-docs-consolidator.md
• Supports GitHub Actions expression interpolation: ${{ github.workflow }}, ${{ github.run_id }}
• Multiple cache entries per workflow

Real-World Key Patterns Found:

• cloclo-memory-${{ github.workflow }}-${{ github.run_id }}
• code-metrics-${{ github.workflow }}
• copilot-token-metrics-${{ github.workflow }}
• developer-docs-cache
• mcp-response-analysis-${{ github.workflow }}
• poem-memory-${{ github.workflow }}-${{ github.run_id }}
• quality-focus-${{ github.workflow }}
• schema-consistency-cache-${{ github.workflow }}
• stale-repos-analysis-${{ github.workflow }}-${{ github.run_id }}

Schema Validation Needed:

1. Does schema capture boolean OR array of objects with id and key fields?
2. Is GitHub Actions expression syntax documented as valid in key field?
3. Are id and key both required in array pattern?
4. Is there a maximum array length?

Impact: If schema doesn't fully capture array pattern, external validators will reject 10+ production workflows.

Recommended Action: Audit cache-memory schema definition to ensure it captures:

{
  "oneOf": [
    {"type": "boolean"},
    {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": {"type": "string", "description": "Cache identifier"},
          "key": {"type": "string", "description": "Cache key (supports GitHub Actions expressions)"}
        },
        "required": ["id", "key"],
        "additionalProperties": false
      }
    }
  ]
}

---

3. Bash Command Allowlist Wildcard Patterns

Severity: Moderate-High - Undocumented pattern used in production

Found Pattern (5+ workflows):

tools:
  bash:
    - "date *"
    - "echo *"
    - "mktemp *"
    - "cat *"
    - "gh aw compile *"
    - "ls *"
    - "rm *"
    - "test *"

Workflows Using This Pattern:

• blog-auditor.md
• close-old-discussions.md
• poem-bot.md
• Others

Questions Requiring Answers:

1. Does schema explicitly support array of glob pattern strings for bash?
2. What wildcard syntax is supported? (*, **, ?, [...])
3. How are glob patterns validated at compile time?
4. How are they enforced at runtime?
5. Is this pattern documented in tools reference?

Current Schema Check: Verify tools.bash schema supports:

# Both patterns should be valid
bash: true                    # Unrestricted
bash: ["date *", "echo *"]   # Glob allowlist

Impact: If wildcard syntax not documented, users may:

• Use invalid patterns that fail at runtime
• Be unaware of security implications
• Not understand how to escape special characters

Recommended Action:

1. Verify schema captures array-of-strings with pattern/format constraints
2. Add documentation section on bash allowlist glob syntax
3. Add examples showing wildcard usage and security considerations

Moderate Issues and Documentation Gaps

Moderate Issues

4. safe-outputs.messages Template System

Finding: Production workflows use sophisticated message customization with template variables

Example from archie.md:

safe-outputs:
  add-comment:
    max: 1
  messages:
    footer: "> 📊 *Diagram rendered by [{workflow_name}]({run_url})*"
    run-started: "📐 Archie here! [{workflow_name}]({run_url}) is sketching the architecture on this {event_type}..."
    run-success: "🎨 Blueprint complete! [{workflow_name}]({run_url}) has visualized the connections. The architecture speaks for itself! ✅"
    run-failure: "📐 Drafting interrupted! [{workflow_name}]({run_url}) {status}. The diagram remains incomplete..."

Template Variables Discovered:

• {workflow_name} - Workflow display name
• {run_url} - GitHub Actions run URL
• {event_type} - Triggering event type (issue, pull_request, etc.)
• {status} - Workflow execution status

Schema Validation Needed:

1. Is messages object documented in safe-outputs schema?
2. Are four message types defined: footer, run-started, run-success, run-failure?
3. Are template variables documented with list of available placeholders?
4. Is Markdown formatting support documented?

Impact: Powerful customization feature may be underdocumented. Users unaware of capability.

Recommendation:

• Verify messages object in schema with four required string properties
• Document template variable syntax
• Add examples showing Markdown formatting and URL generation

---

5. safe-outputs.close-older-discussions Cleanup Pattern

Usage Statistics: 33 workflows (22% of total) use this pattern

Common Combination:

safe-outputs:
  create-discussion:
    category: "reports"
    max: 1
    close-older-discussions: true

Purpose: Automatically close older discussions in same category when creating new one. Prevents discussion proliferation in automated reporting workflows.

Related Pattern - title-prefix: 62 workflows (41%) use title prefixes

safe-outputs:
  create-discussion:
    title-prefix: "[audit] "
    category: "audits"

Schema Status: Likely in schema, but verify:

1. Is close-older-discussions boolean documented?
2. Is interaction with max field explained?
3. Is category scoping behavior documented?

Recommendation: Confirm schema completeness and add usage examples showing cleanup patterns.

---

6. GitHub toolsets Enum Completeness

Found 18+ Unique Toolset Combinations across 150 workflows:

Individual Toolsets:

• default - Most common (appears in 40+ workflows)
• all - Used in 5+ workflows
• repos - Repository operations
• issues - Issue management
• pull_requests - PR operations
• actions - Workflow/action queries
• discussions - Discussion management
• labels - Label operations
• code_security - Security scanning
• dependabot - Dependabot alerts
• context - Contextual metadata

Example Combinations:

toolsets: [default]
toolsets: [all]
toolsets: [default, issues]
toolsets: [default, pull_requests]
toolsets: [repos, issues, pull_requests]
toolsets: [context, repos, code_security, pull_requests]

Schema Audit Needed:

1. Are all 11 toolset values in schema enum?
2. Is all special value (expands to all toolsets)?
3. Is default a predefined collection (if so, what does it include)?
4. Are toolset combinations validated (any invalid combinations)?

Impact: If enum incomplete, valid workflows fail validation.

Recommendation:

1. Extract all toolset values from schema enum
2. Compare with 11 values found in production
3. Add missing values with descriptions
4. Document special values (all, default)

Positive Findings and Best Practices

Positive Findings

✓ Excellent Schema Field Coverage

All 18 major fields discovered in workflows are properly in schema:

Validated Fields:

• strict - Strict mode validation ✅
• tracker-id - Workflow tracking identifier ✅
• network - Network access control ✅
• imports - Shared configuration imports ✅
• sandbox - Sandbox runtime configuration ✅
• safe-inputs - Input validation ✅
• secret-masking - Secret redaction ✅
• concurrency - Concurrent execution control ✅
• features - Feature flags ✅
• roles - AI role configuration ✅
• post-steps - Post-execution steps ✅
• mcp-servers - MCP server configuration ✅
• source - Workflow source tracking ✅
• services - Container services ✅
• cache - Build cache configuration ✅
• name - Workflow display name ✅
• if - Conditional execution ✅
• jobs - Multi-job workflows ✅

Impact: Core schema coverage is excellent. Issues are edge cases and nested configurations.

---

✓ Complex command.events Pattern Correctly Captured

The sophisticated pattern from archie.md is properly supported in schema:

on:
  command:
    name: archie
    events: [issues, issue_comment, pull_request, pull_request_comment]

Schema Structure: Uses oneOf to support both string and object command formats:

• String format: command: "name" (conflicts with comment events)
• Object format: command: {name: "archie", events: [...]} (allows event combinations)

This hierarchical dependency pattern (Strategy-018 finding) is correctly captured.

---

✓ Network Configuration Well-Structured

Schema provides excellent examples for network access control:

network:
  allowed:
    - defaults       # Common domains
    - python         # Python ecosystem
    - node           # Node ecosystem
    - "*.example.com"  # Domain wildcards
  firewall: true

Found in production workflows:

• deep-report.md: [defaults, python, node]
• artifacts-summary.md: [defaults, node]
• Multiple workflows use ecosystem identifiers

Impact: Network security patterns well-documented and schema-aligned.

---

✓ Production Workflows are Conservative

Insight: Workflows copy proven patterns rather than exploring all schema features

Safe-Outputs Complexity:

• Most workflows: 1-3 operations (simple, focused)
• Outliers: issue-monster.md (12 ops), poem-bot.md (16 ops)
• Pattern: Users prefer simple, maintainable configurations

Timeout Distribution:

• Common values: 10, 15, 30 minutes (80% of workflows)
• Extended: 45, 60 minutes (complex analysis workflows)
• Quick: 5 minutes (smoke tests)

Tool Usage:

• github + bash most common combination
• cache-memory growing adoption (15% of workflows)
• playwright specialized use (docs testing, UI validation)

Impact: Schema doesn't need to support every theoretical combination. Focus on patterns actually used in production.

Workflow-First Methodology Insights

Key Insights from Bottom-Up Analysis

Insight 1: Documentation Often Ahead of Schema

Pattern Observed: Features documented and implemented but schema lags behind

Example - reaction Field:

• ✅ Documented: frontmatter.md, frontmatter-full.md, command-triggers.md
• ✅ Implemented: 12 test files, runtime code complete
• ❌ Schema: Missing entirely

Why This Happens:

1. Documentation written during feature development
2. Implementation completed and tested
3. Schema update overlooked or deprioritized
4. No automated check for doc-schema consistency

Impact: Schema becomes incomplete source of truth. External validators fail on valid workflows.

Recommendation: Establish process ensuring schema updates when documentation added.

---

Insight 2: Customization Concentrates in safe-outputs

Most Customization Found In:

• messages - Custom status messages with templates (archie.md pattern)
• title-prefix - 62 workflows (41%) use prefixes
• close-older-discussions - 33 workflows (22%) use cleanup
• footer - Custom attribution and branding

Why safe-outputs is Customization Hub:

1. User-facing output requires branding/context
2. Automation needs cleanup patterns (close-older-discussions)
3. Multi-tenant workflows need namespacing (title-prefix)
4. Status communication needs context (run URL, event type)

Impact: safe-outputs schema needs richest documentation and examples.

---

Insight 3: Tool Configuration Patterns are Diverse

Three Tools with Polymorphic Patterns:

1. cache-memory:

• Boolean: cache-memory: true (simple)
• Array: cache-memory: [{id: "x", key: "y"}] (complex)
• Timeout: timeout: 300 (companion setting)

2. bash:

• Boolean: bash: true (unrestricted)
• Array: bash: ["date *", "echo *"] (glob allowlist)
• Object: (potentially, not found in sample)

3. github.toolsets:

• 18+ unique combinations
• Range from [default] to [context, repos, code_security, pull_requests]
• Shows sophisticated API access patterns

Impact: Schema must capture polymorphic flexibility without sacrificing validation.

---

Insight 4: Workflow-First Reveals "Contract as Implemented"

Traditional Schema-First Analysis:

• Assumes schema is source of truth
• Finds where implementation diverges
• Misses where implementation exceeds schema

Workflow-First Analysis:

• Assumes production usage is source of truth
• Finds where schema is incomplete
• Reveals undocumented but working patterns

Complementary Approaches:

• Schema → Implementation: "Are we building what we specified?"
• Implementation → Schema: "Did we specify what we built?"

Result: Combined approaches provide complete consistency picture.

---

Insight 5: Import Patterns Show Modularity Success

High Import Count Workflows:

• mcp-inspector.md: 16 imports (comprehensive analysis)
• scout.md: 8 imports (research workflow)
• prompt-clustering-analysis.md: 5 imports (specialized)

Common Imports:

• shared/jqschema.md - JSON Schema querying
• shared/reporting.md - Report formatting
• shared/mcp/gh-aw.md - MCP integration
• shared/weekly-issues-data-fetch.md - Data collection
• shared/safe-output-app.md - Output helpers

Impact: imports feature successfully promotes code reuse. Workflows compose well.

Recommendations and Next Steps

Recommendations

Immediate Actions (Priority 1)

1. Add reaction Field to Schema

File: pkg/parser/schemas/main_workflow_schema.json

Action: Add as top-level property:

"reaction": {
  "description": "Emoji reaction to add on triggering items (issues, PRs, comments). Use 'none' to disable. Defaults to 'eyes' for command workflows.",
  "oneOf": [
    {
      "type": "string",
      "enum": ["+1", "-1", "laugh", "confused", "heart", "hooray", "rocket", "eyes", "none"],
      "default": "eyes"
    },
    {
      "type": "integer",
      "enum": [1, -1],
      "description": "Numeric aliases: 1 (+1), -1 (-1)"
    }
  ],
  "examples": ["eyes", "rocket", "+1", 1, "none"]
}

Validation: Cross-reference with docs/src/content/docs/reference/frontmatter-full.md:578-589

2. Validate cache-memory Array Pattern

File: pkg/parser/schemas/main_workflow_schema.json

Action: Verify schema captures array-of-objects pattern:

{
  "oneOf": [
    {"type": "boolean"},
    {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": {"type": "string"},
          "key": {"type": "string", "description": "Supports GitHub Actions expressions"}
        },
        "required": ["id", "key"]
      }
    }
  ]
}

Test: Validate against daily-code-metrics.md and daily-copilot-token-report.md

---

Short-Term Actions (Priority 2)

3. Audit GitHub toolsets Enum

File: pkg/parser/schemas/main_workflow_schema.json

Action: Extract enum values and compare with production usage:

jq '.properties.tools.properties.github.properties.toolsets.items.enum' main_workflow_schema.json

Required Values: default, all, repos, issues, pull_requests, actions, discussions, labels, code_security, dependabot, context

Add Missing: Document any missing values with descriptions

4. Document Bash Allowlist Wildcards

Files:

• pkg/parser/schemas/main_workflow_schema.json
• docs/src/content/docs/reference/tools.md

Action:

1. Verify schema supports array of glob patterns
2. Add tools documentation section on allowlist syntax
3. Include examples: bash: ["date *", "gh issue *"]
4. Document security implications

---

Medium-Term Actions (Priority 3)

5. Document safe-outputs.messages Template System

Files:

• pkg/parser/schemas/main_workflow_schema.json
• docs/src/content/docs/reference/safe-outputs.md

Action:

1. Add messages object schema with four properties
2. Document template variables: {workflow_name}, {run_url}, {event_type}, {status}
3. Add examples showing Markdown formatting
4. Link to archie.md as reference implementation

6. Establish Schema-Documentation Sync Process

Process Improvement:

Problem: Documentation updates without schema updates cause drift

Solution:

1. Add schema validation to documentation CI
2. Create checklist for feature additions:
   • Documentation updated
   • Schema updated
   • Tests updated
   • Examples added
3. Add automated check comparing documented fields to schema fields

---

Research Questions (Priority 4)

7. Investigate Expression Interpolation Support

Question: What GitHub Actions expressions are valid in which fields?

Known Valid:

• cache-memory.key: ${{ github.workflow }}, ${{ github.run_id }}
• github-token: ${{ secrets.CUSTOM_PAT }}

Need Documentation:

• Complete list of supported expression contexts
• Which fields accept expressions
• Validation behavior for invalid expressions

8. Polymorphic Type Pattern Strategy

Question: How to balance flexibility vs validation for polymorphic fields?

Examples:

• cache-memory: boolean | array
• bash: boolean | array
• network: string | object
• reaction: string | integer

Research:

• Survey all polymorphic fields
• Document type selection logic
• Provide clear examples for each variant

Strategy Performance and Methodology

Strategy Performance

Strategy-021: Workflow-First Reverse Engineering

Performance Metrics:

• Findings: 7 total (3 critical, 2 moderate, 2 informational)
• Unique Issues: 7 not found by previous 20 strategies
• Effectiveness: Very High
• Should Reuse: Yes - every 4-5 analyses

Why This Strategy Succeeded:

1. Complementary Perspective: Bottom-up vs top-down analysis

   • Traditional: Schema → Implementation (what should exist)
   • Strategy-021: Workflows → Schema (what actually exists)

2. Reality Check: Production workflows are source of truth

   • Reveals "contract as implemented" vs "contract as specified"
   • Finds working patterns not captured in schema
   • Discovers documentation-schema lag (reaction field)

3. Pattern Mining: Analyzes real-world usage diversity

   • 18+ toolset combinations
   • 3 cache-memory patterns
   • Complex safe-outputs customizations

4. Usage Statistics: Quantifies feature adoption

   • 33 workflows use close-older-discussions (22%)
   • 62 workflows use title-prefix (41%)
   • 15% adoption of cache-memory (growing)

Unique Discoveries:

• ✓ reaction field missing from schema (Critical 1)
• ✓ cache-memory polymorphic complexity (Critical 2)
• ✓ Bash allowlist wildcards (Critical 3)
• ✓ safe-outputs.messages template system (Moderate 4)
• ✓ Workflow pattern statistics (Insight 5)

---

Methodology

Data Collection

Sources:

• 150 production workflows in .github/workflows/*.md
• 12 workflows analyzed in detail (representative sample)
• Schema: pkg/parser/schemas/main_workflow_schema.json
• Docs: docs/src/content/docs/reference/*.md
• Code: pkg/parser/*.go, pkg/workflow/*.go
• Tests: pkg/workflow/*_test.go

Sampling Strategy:

• First/last workflows (edge cases)
• Random sample (diversity)
• High-complexity workflows (stress tests)
• Low-complexity workflows (common patterns)

Analysis Techniques

1. Field Enumeration (Reverse):

# Extract all top-level fields from workflows
find .github/workflows -name "*.md" -exec \
  awk '/^---$/{if(++count==1) next; if(count==2) exit} count==1 && /^[a-zA-Z-]+:/ {print $1}' {} \; |
  sort -u

2. Pattern Extraction:

• Nested structures (4+ space indentation)
• Array patterns (- item syntax)
• Object patterns (key-value pairs)
• Expression patterns (${{ ... }})

3. Value Analysis:

• Enum extraction (unique values for categorical fields)
• Range analysis (min/max for numeric fields)
• Pattern matching (glob patterns, regex)

4. Schema Validation:

# Check if field exists in schema
jq '.properties | has("field_name")' main_workflow_schema.json

# Extract enum values
jq '.properties.field.enum' main_workflow_schema.json

5. Usage Statistics:

# Count workflows using specific pattern
grep -c "pattern" .github/workflows/*.md | grep -v ":0$" | wc -l

# Calculate adoption percentage
echo "scale=1; ($count / 150) * 100" | bc

Key Files Analyzed in Detail

High-Complexity Workflows:

1. archie.md - Custom messages, command.events pattern
2. audit-workflows.md - Cache-memory, imports, steps
3. deep-report.md - Network, imports, multiple toolsets
4. mcp-inspector.md - 16 imports (maximum)
5. poem-bot.md - 16 safe-outputs operations (maximum)

Representative Workflows:
6. daily-malicious-code-scan.md - Strict mode, security
7. blog-auditor.md - Bash allowlists, playwright
8. daily-code-metrics.md - Cache-memory array pattern
9. craft.md - Command workflow, tool composition
10. schema-consistency-checker.md - Meta-analysis workflow

Edge Cases:
11. smoke-srt.md - Features.sandbox-runtime
12. ai-triage-campaign.md - Complex toolsets, project integration

---

Comparison with Previous Strategies

Strategy-021 vs Other Approaches

Strategy	Focus	Direction	Unique Strength
Strategy-001	Field enumeration	Schema → Code	Comprehensive coverage
Strategy-004	Cross-schema	Schema → Schema	Inter-file consistency
Strategy-007	Examples	Docs → Schema	Documentation quality
Strategy-012	Dynamic validation	Schema → Runtime	Actual validation behavior
Strategy-021	Workflow patterns	Workflows → Schema	Reality check

Complementary Pairs:

• 001 + 021: Schema fields ↔ Workflow fields (bidirectional validation)
• 007 + 021: Doc examples ↔ Real workflows (theory vs practice)
• 012 + 021: Schema validation ↔ Workflow validation (spec vs reality)

When to Use Strategy-021:

• ✅ After documentation updates (catch doc-schema lag)
• ✅ After major feature releases (verify schema completeness)
• ✅ When users report validation issues (find missing patterns)
• ✅ To audit polymorphic types (discover usage diversity)
• ✅ Every 4-5 analyses (maintain reality check)

When NOT to Use Strategy-021:

• ❌ For schema internal consistency (use Strategy-008)
• ❌ For error message validation (use Strategy-003)
• ❌ For type coercion analysis (use Strategy-017)
• ❌ For evolution/deprecation (use Strategy-015)

Next Analysis Recommendation

For December 5, 2025 (Day 339, mod 10 = 9):

Day 339 % 10 = 9, which triggers NEW APPROACH mode (values 7-9).

Recommended New Strategy: "Schema Evolution Impact Analysis"

• Mine git history for schema changes
• Correlate with workflow breakage/fixes
• Identify high-risk schema modifications
• Build safety checklist for schema changes
• Discover which schema fields are "load-bearing"

Alternative: "Cross-Repository Workflow Pattern Analysis"

• If access to other repos, analyze external workflow patterns
• Find common patterns across GitHub ecosystem
• Identify divergence from this project's patterns
• Discover innovative usage patterns to incorporate

Fallback: Use Strategy-004 (Cross-Schema Consistency) - proven high-effectiveness strategy complementary to today's workflow-first approach.

---

Files Requiring Updates

High Priority

• pkg/parser/schemas/main_workflow_schema.json - Add reaction field
• pkg/parser/schemas/main_workflow_schema.json - Validate cache-memory array pattern
• pkg/parser/schemas/main_workflow_schema.json - Audit toolsets enum completeness

Medium Priority

• docs/src/content/docs/reference/tools.md - Document bash allowlist wildcards
• docs/src/content/docs/reference/safe-outputs.md - Document messages template system
• Test suite - Add schema validation test for reaction field

Process Improvements

• Add schema-documentation sync check to CI
• Create feature addition checklist (docs, schema, tests, examples)
• Document GitHub Actions expression support in schema fields

AI generated by Schema Consistency Checker

[pelikhan]

/plan

[github-actions[bot]]

🎉 Yo ho ho! Plan Command found the treasure and completed successfully! ⚓💰

[github-actions[bot]]

⚓ Avast! This discussion be marked as outdated by Schema Consistency Checker.
🗺️ A newer treasure map awaits ye at Discussion #5587.
Fair winds, matey! 🏴‍☠️