Skip to content

Fix engineering-workflow component refinements #128

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
Alan-Jowett merged 2 commits into from
Mar 30, 2026
Merged

Fix engineering-workflow component refinements #128

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
98f1801
Fix engineering-workflow component refinements
Mar 30, 2026
eac1adc
Update templates/audit-spec-alignment.md
Alan-Jowett Mar 30, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 0 additions & 3 deletions manifest.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1327,7 +1327,6 @@ templates:
persona: configurable
protocols: [anti-hallucination, self-verification, adversarial-falsification, operational-constraints, requirements-elicitation, iterative-refinement, change-propagation, traceability-audit, code-compliance-audit, test-compliance-audit]
taxonomies: [specification-drift]
format: multi-artifact

- name: collaborate-requirements-change
path: templates/collaborate-requirements-change.md
Expand Down Expand Up @@ -1392,7 +1391,6 @@ templates:
persona: configurable
protocols: [anti-hallucination, self-verification, operational-constraints, adversarial-falsification, requirements-from-implementation, requirements-elicitation, iterative-refinement, traceability-audit]
taxonomies: [specification-drift]
format: multi-artifact

- name: maintenance-workflow
path: templates/maintenance-workflow.md
Expand All @@ -1405,7 +1403,6 @@ templates:
persona: configurable
protocols: [anti-hallucination, self-verification, adversarial-falsification, operational-constraints, traceability-audit, code-compliance-audit, test-compliance-audit, change-propagation, iterative-refinement]
taxonomies: [specification-drift]
format: multi-artifact

pipelines:
document-lifecycle:
Expand Down
6 changes: 3 additions & 3 deletions templates/audit-implementation-alignment.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -25,10 +25,10 @@ params:
implementation_patch: "The structured implementation patch (code/artifact + verification changes)"
existing_artifacts: "Existing implementation and verification artifacts for context"
input_contract:
type: [spec-patch, implementation-patch]
type: spec-patch
description: >
Structured patches for specifications and implementation, to be
audited for alignment.
A structured specification patch as the primary input, plus an
implementation patch to be audited for alignment against it.
Comment on lines 27 to +31
Copy link

Copilot AI Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

input_contract.type is set to spec-patch, but in the engineering-workflow pipeline this stage follows generate-implementation-changes (which produces implementation-patch). This breaks the documented contract-chaining rule (adjacent stage output/input types match) and can prevent correct next-stage suggestions/validation. Consider making the primary input_contract.type implementation-patch and documenting the spec-patch as a secondary input in the description (pattern matches audit-traceability).

Copilot uses AI. Check for mistakes.
output_contract:
type: investigation-report
description: >
Expand Down
7 changes: 4 additions & 3 deletions templates/audit-spec-alignment.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,10 +24,11 @@ params:
spec_patch: "The structured specification patch (design + validation changes)"
existing_artifacts: "Existing requirements, design, and validation documents for context"
input_contract:
type: [requirements-patch, spec-patch]
type: requirements-patch
description: >
Structured patches for requirements and specifications, plus the
user's original intent description.
A structured requirements patch as the primary input, plus the
user's original intent description and the specification
patch for cross-referencing.
Comment on lines 26 to +31
Copy link

Copilot AI Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

input_contract.type no longer matches the preceding pipeline stage output (generate-spec-changes produces spec-patch), which conflicts with the pipeline contract rule that adjacent stages’ output/input types match. To keep pipeline chaining/validation working, set the primary input_contract.type to spec-patch and mention the requirements patch as a secondary input in the description (similar to how audit-traceability uses validation-plan as the primary type).

Copilot uses AI. Check for mistakes.
output_contract:
type: investigation-report
description: >
Expand Down
2 changes: 1 addition & 1 deletion templates/engineering-workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ protocols:
- reasoning/test-compliance-audit
taxonomies:
- specification-drift
format: multi-artifact
format: null
params:
persona: "Persona to use — select from library (e.g., software-architect, electrical-engineer, mechanical-engineer)"
project_name: "Name of the project, product, or system being changed"
Expand Down
34 changes: 33 additions & 1 deletion templates/generate-implementation-changes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,7 +105,39 @@ For each impacted verification artifact:
including negative cases, boundary conditions, and ordering
constraints.

### Step 4 — Assemble Patch
### Step 4 — Invariant Check

For every existing invariant, constraint, and runtime assumption in
the implementation and verification artifacts:

1. Verify it is **preserved** by the combined downstream changes.
2. If an invariant is **modified**, flag it explicitly and verify
the modification is justified by the upstream specification change.
3. If an invariant is **violated**, STOP and report the conflict.

### Step 5 — Completeness Check

Verify every upstream specification change has at least one downstream
change (or an explicit "no downstream impact" justification):

1. Walk the input specification patch manifest entry by entry.
2. Confirm each appears in the traceability matrix as Complete,
Partial (with explanation), or No-Impact (with rationale).
3. Flag any specification change with no downstream entry as
**DROPPED** — this must be resolved before finalizing.

### Step 6 — Conflict Detection

Check for conflicts within the downstream change set:

1. **Internal conflicts** — two changes that modify the same
location in contradictory ways.
2. **Cross-artifact conflicts** — an implementation change that
contradicts a verification change.
3. **Upstream-downstream conflicts** — a downstream change that
contradicts the intent of its upstream specification change.

### Step 7 — Assemble Patch

Produce a single structured-patch document containing:

Expand Down
34 changes: 33 additions & 1 deletion templates/generate-spec-changes.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -94,7 +94,39 @@ For each impacted validation entry:
4. Verify every requirement in the patch has at least one linked
test case after changes are applied.

### Step 4 — Assemble Patch
### Step 4 — Invariant Check

For every existing invariant, constraint, and assumption in the
design and validation artifacts:

1. Verify it is **preserved** by the combined downstream changes.
2. If an invariant is **modified**, flag it explicitly and verify
the modification is justified by the upstream requirement change.
3. If an invariant is **violated**, STOP and report the conflict.

### Step 5 — Completeness Check

Verify every upstream requirement change has at least one downstream
change (or an explicit "no downstream impact" justification):

1. Walk the input requirement patch manifest entry by entry.
2. Confirm each appears in the traceability matrix as Complete,
Partial (with explanation), or No-Impact (with rationale).
3. Flag any requirement change with no downstream entry as
**DROPPED** — this must be resolved before finalizing.

### Step 6 — Conflict Detection

Check for conflicts within the downstream change set:

1. **Internal conflicts** — two changes that modify the same
location in contradictory ways.
2. **Cross-artifact conflicts** — a design change that contradicts
a validation change.
3. **Upstream-downstream conflicts** — a downstream change that
contradicts the intent of its upstream requirement change.

### Step 7 — Assemble Patch

Produce a single structured-patch document containing:

Expand Down
2 changes: 1 addition & 1 deletion templates/maintenance-workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -24,7 +24,7 @@ protocols:
- reasoning/iterative-refinement
taxonomies:
- specification-drift
format: multi-artifact
format: null
Copy link

Copilot AI Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

format is now null, but later instructions still say “Because this template uses the multi-artifact format…” when describing output constraints. With no format component being assembled, that statement is incorrect; adjust the prose to reference the intended constraints directly (or restore multi-artifact if you still want that format enforced).

Copilot uses AI. Check for mistakes.
params:
persona: "Persona to use — select from library (e.g., software-architect, electrical-engineer)"
project_name: "Name of the project, product, or system"
Expand Down
2 changes: 1 addition & 1 deletion templates/spec-extraction-workflow.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -22,7 +22,7 @@ protocols:
- reasoning/traceability-audit
taxonomies:
- specification-drift
format: multi-artifact
format: null
Copy link

Copilot AI Mar 30, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After switching format to null, the template body still states that the assembled prompt includes only the multi-artifact format (see later in the file around the requirements extraction output instructions). This is now incorrect and can mislead users/agents about what “Output Format” content is present; update that wording (or reintroduce multi-artifact if that’s actually required).

Suggested change
format: null
format: multi-artifact

Copilot uses AI. Check for mistakes.
params:
persona: "Persona to use — select from library (e.g., software-architect, electrical-engineer, reverse-engineer)"
project_name: "Name of the project, product, or system to bootstrap"
Expand Down
Loading