Post-merge cleanup: engineering-workflow component refinements

[Alan-Jowett]

Post-Merge Cleanup: Engineering Workflow Component Refinements

Follow-up items from late review comments on #116 (merged). Three legitimate issues identified:

1. Explicit change-propagation protocol phases in generation templates

Affected: generate-spec-changes.md, generate-implementation-changes.md

The templates say "Apply the change-propagation protocol" but their step-by-step instructions only cover Phases 1-2 (impact analysis, change derivation). Phases 3-5 (invariant check, completeness check, conflict detection) are not explicitly called out as steps, making it easy for an agent to skip them.

Fix: Add explicit steps for Phases 3-5 in both templates' instructions.

2. Multi-input contract type convention

Affected: audit-spec-alignment.md, audit-implementation-alignment.md

These templates use input_contract.type: [requirements-patch, spec-patch] (YAML list), but the existing convention is a single string type for pipeline chaining. Need to define the convention for templates that consume multiple artifact types.

Options:

• Define a composite type name (e.g., spec-alignment-bundle)
• Document that list-valued types are valid for multi-input templates
• Use the primary artifact type and document secondary inputs in the description

3. multi-artifact format vs. interactive workflow

Affected: engineering-workflow.md

The multi-artifact format requires output to begin with a Deliverables manifest, but the interactive workflow starts with Phase 1 (questions, not artifacts). The format contract conflicts with the interactive mode.

Options:

• Switch to format: null (inline format definition, like generate-commit-message)
• Emit an initial Deliverables manifest before starting Phase 1
• Create a new interactive-workflow format that doesn't mandate an upfront manifest