Add engineering-workflow: domain-agnostic incremental development pipeline

formats/structured-patch.md

@@ -0,0 +1,160 @@
+<!-- SPDX-License-Identifier: MIT -->
+<!-- Copyright (c) PromptKit Contributors -->
+
+---
+name: structured-patch
+type: format
+description: >
+  Output format for traceable, structured patches to existing artifacts.
+  Each change entry links to its upstream motivation, enabling full
+  traceability from requirements through design, validation, and
+  implementation. Domain-agnostic — works for specifications, code,
+  schematics, test plans, or any versioned artifact.
+produces: structured-patch
+---
+
+# Format: Structured Patch
+
+Use this format when producing **incremental changes** to existing artifacts
+rather than generating documents from scratch.  Every change MUST trace to
+an upstream motivation (a requirement change, a design decision, a user
+request) so reviewers can verify alignment at each transition.
+
+## Document Structure
+
+```markdown
+# <Patch Title>
+
+## 1. Change Context
+## 2. Change Manifest
+## 3. Detailed Changes
+## 4. Traceability Matrix
+## 5. Invariant Impact
+## 6. Application Notes
+```
+
+All six top-level sections (1–6) are **mandatory**. If a section has no
+content for this patch, still include the heading and state "None identified"
+or "Not applicable" rather than omitting the section.
+
+## 1. Change Context
+
+Provide the context for this patch set:
+
+- **Upstream artifact**: what motivated these changes (e.g., requirements
+  patch, design revision, user request)
+- **Target artifacts**: what is being changed (e.g., design document,
+  validation plan, source code, schematic)
+- **Scope**: what areas are affected and what is explicitly unchanged
+
+## 2. Change Manifest
+
+A summary table of all changes in this patch:
+
+```markdown
+| Change ID  | Type   | Target Artifact | Section / Location | Summary             |
+|------------|--------|-----------------|--------------------|---------------------|
+| CHG-001    | Add    | design-doc      | §3.2 API Layer     | New endpoint for... |
+| CHG-002    | Modify | validation-plan | TC-012             | Update expected...  |
+| CHG-003    | Remove | design-doc      | §4.1 Legacy API    | Remove deprecated...|
+```
+
+**Change types**:
+- **Add** — new content that did not previously exist
+- **Modify** — alteration of existing content
+- **Remove** — deletion of existing content
+
+## 3. Detailed Changes
+
+For each change in the manifest, provide a detailed entry:
+
+```markdown
+### CHG-<NNN>: <Short Title>
+
+- **Type**: Add | Modify | Remove
+- **Upstream ref**: <ID of the upstream change that motivates this — e.g.,
+  REQ-FUNC-005, CHG-003 from requirements patch, user request>
+- **Target**: <artifact and section/location being changed>
+- **Rationale**: <why this change is necessary to maintain alignment>
+
+#### Before
+
+<existing content being changed, or "N/A — new content" for additions>
+
+#### After
+
+<new content, or "N/A — content removed" for removals>
+
+#### Impact
+
+<what downstream artifacts may need updates as a result of this change>
+```
+
+**Rules for detailed changes**:
+
+- Every change MUST have an upstream ref.  If the change is motivated by
+  the user's direct request (not a downstream propagation), use
+  `USER-REQUEST: <summary of what the user asked for>`.
+- Before/After sections MUST show enough context to apply the change
+  unambiguously.  For code or structured documents, include surrounding
+  lines or section headers.
+- For modifications, clearly mark what changed between Before and After.
+  Use **bold** for inserted text and ~~strikethrough~~ for removed text
+  when showing inline diffs in prose.
+
+## 4. Traceability Matrix
+
+Map every upstream change to its downstream changes:
+
+```markdown
+| Upstream Ref      | Downstream Changes          | Status    |
+|-------------------|-----------------------------|-----------|
+| REQ-FUNC-005      | CHG-001, CHG-002            | Complete  |
+| REQ-PERF-002      | CHG-003                     | Complete  |
+| USER-REQUEST: ... | CHG-004                     | Partial   |
+```
+
+**Status values**:
+- **Complete** — all necessary downstream changes are included
+- **Partial** — some downstream changes are deferred (explain in notes)
+- **No-Impact** — upstream change verified to have no downstream effect
+  (MUST include rationale)
+- **Blocked** — downstream changes cannot be made yet (explain why)
+
+## 5. Invariant Impact
+
+For each invariant or constraint affected by this patch set:
+
+```markdown
+| Invariant / Constraint | Effect                | Verification          |
+|------------------------|-----------------------|-----------------------|
+| CON-SEC-001: All...    | Unchanged — preserved | Existing TC-008 valid |
+| ASM-003: Network...    | Modified — relaxed    | New TC-025 added      |
+| INV-PERF-002: Resp...  | Unchanged — preserved | No action needed      |
+```
+
+If no invariants are affected, state explicitly:
+`No existing invariants or constraints are affected by this patch set.`
+
+## 6. Application Notes
+
+Instructions for applying this patch:
+
+- **Method**: how to apply (e.g., "apply as git diff", "manually update
+  sections", "replace schematic sheet 3")
+- **Order**: if changes must be applied in a specific sequence
+- **Verification**: how to verify the patch was applied correctly
+- **Rollback**: how to revert if needed
+
+## Formatting Rules
+
+1. Change IDs MUST use the format `CHG-<NNN>` with zero-padded
+   three-digit numbers, sequential within the patch.
+2. Every change MUST have exactly one upstream ref.
+3. The traceability matrix MUST account for every upstream change —
+   no upstream change may be silently dropped.
+4. Before/After sections MUST be unambiguous — a reviewer should be
+   able to locate and apply the change without additional context.
+5. The invariant impact section MUST be present even if empty
+   (state "no invariants affected" explicitly).
+6. Sections MUST appear in the order specified above.

manifest.yaml

@@ -474,6 +474,14 @@ protocols:
         Maps execution back to PromptKit components and produces
         actionable optimization recommendations.
 
+    - name: change-propagation
+      path: protocols/reasoning/change-propagation.md
+      description: >
+        Systematic reasoning protocol for propagating changes through
+        artifact layers while maintaining alignment. Covers impact
+        analysis, change derivation, invariant checking, completeness
+        verification, and conflict detection. Domain-agnostic.
+
 formats:
   - name: requirements-doc
     path: formats/requirements-doc.md
@@ -644,6 +652,15 @@ formats:
       state, and cross-cutting implications (security, performance,
       management, observability, testing).
 
+  - name: structured-patch
+    path: formats/structured-patch.md
+    produces: structured-patch
+    description: >
+      Traceable, structured patch format for incremental changes to
+      existing artifacts. Each change entry links to its upstream
+      motivation with Before/After content, traceability matrix, and
+      invariant impact assessment. Domain-agnostic.
+
 taxonomies:
   - name: stack-lifetime-hazards
     path: taxonomies/stack-lifetime-hazards.md
@@ -1290,6 +1307,71 @@ templates:
       protocols: [anti-hallucination, self-verification, protocol-validation-design]
       format: protocol-validation-spec
 
+  engineering-workflow:
+    - name: engineering-workflow
+      path: templates/engineering-workflow.md
+      description: >
+        Full incremental engineering workflow with human-in-the-loop
+        review. Guides an agent through requirements discovery,
+        specification changes, implementation changes, adversarial
+        audits, and deliverable creation. Domain-agnostic.
+      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
+      description: >
+        Interactive requirements discovery for incremental changes.
+        Work with the user to understand, refine, and produce a
+        structured requirements patch. Domain-agnostic.
+      persona: configurable
+      protocols: [anti-hallucination, self-verification, requirements-elicitation, iterative-refinement]
+      format: structured-patch
+
+    - name: generate-spec-changes
+      path: templates/generate-spec-changes.md
+      description: >
+        Generate design and validation specification changes from a
+        requirements patch. Propagates each requirement change to
+        design sections and validation entries. Domain-agnostic.
+      persona: configurable
+      protocols: [anti-hallucination, self-verification, change-propagation]
+      format: structured-patch
+
+    - name: generate-implementation-changes
+      path: templates/generate-implementation-changes.md
+      description: >
+        Generate implementation and verification changes from a
+        specification patch. Propagates design and validation changes
+        to implementation artifacts. Domain-agnostic.
+      persona: configurable
+      protocols: [anti-hallucination, self-verification, operational-constraints, change-propagation]
+      format: structured-patch
+
+    - name: audit-spec-alignment
+      path: templates/audit-spec-alignment.md
+      description: >
+        Adversarial audit of specification patches against user intent.
+        Verifies requirements, design, and validation changes faithfully
+        represent what the user asked for. Domain-agnostic.
+      persona: specification-analyst
+      protocols: [anti-hallucination, self-verification, adversarial-falsification, traceability-audit]
+      taxonomies: [specification-drift]
+      format: investigation-report
+
+    - name: audit-implementation-alignment
+      path: templates/audit-implementation-alignment.md
+      description: >
+        Adversarial audit of implementation patches against specification
+        deltas. Verifies implementation and verification changes correctly
+        realize the specification changes. Domain-agnostic.
+      persona: specification-analyst
+      protocols: [anti-hallucination, self-verification, adversarial-falsification, operational-constraints, code-compliance-audit, test-compliance-audit]
+      taxonomies: [specification-drift]
+      format: investigation-report
+
 pipelines:
   document-lifecycle:
     description: >
@@ -1345,3 +1427,26 @@ pipelines:
       - template: review-layout
         consumes: requirements-document
         produces: investigation-report
+
+  engineering-workflow:
+    description: >
+      Domain-agnostic incremental engineering workflow with
+      human-in-the-loop review. Propagates changes through
+      requirements, specifications, and implementation with
+      adversarial audits at each transition. Phases can loop
+      back based on audit verdicts or user feedback.
+    stages:
+      - template: collaborate-requirements-change
+        produces: requirements-patch
+      - template: generate-spec-changes
+        consumes: requirements-patch
+        produces: spec-patch
+      - template: audit-spec-alignment
+        consumes: [requirements-patch, spec-patch]
+        produces: investigation-report
+      - template: generate-implementation-changes
+        consumes: spec-patch
+        produces: implementation-patch
+      - template: audit-implementation-alignment
+        consumes: [spec-patch, implementation-patch]
+        produces: investigation-report

protocols/reasoning/change-propagation.md

@@ -0,0 +1,104 @@
+<!-- SPDX-License-Identifier: MIT -->
+<!-- Copyright (c) PromptKit Contributors -->
+
+---
+name: change-propagation
+type: reasoning
+description: >
+  Systematic reasoning protocol for propagating changes through artifact
+  layers while maintaining alignment.  Ensures every upstream change
+  produces the correct downstream changes, no invariants are broken,
+  and no changes are silently dropped.  Domain-agnostic — works for
+  specifications, code, schematics, test plans, or any layered artifacts.
+applicable_to:
+  - generate-spec-changes
+  - generate-implementation-changes
+  - engineering-workflow
+---
+
+# Protocol: Change Propagation
+
+Apply these phases **in order** when deriving downstream changes from
+upstream changes.  Do not skip phases.
+
+## Phase 1: Impact Analysis
+
+For each upstream change, determine which downstream artifacts are affected:
+
+1. **Direct impact** — downstream sections that explicitly reference or
+   implement the changed upstream content.
+2. **Indirect impact** — downstream sections that depend on assumptions,
+   constraints, or invariants affected by the upstream change.
+3. **No impact** — downstream sections verified to be unaffected.
+   State WHY they are unaffected (do not silently skip).
+
+Produce an impact map:
+
+```
+Upstream CHG-<NNN> →
+  Direct:   [list of downstream locations]
+  Indirect: [list of downstream locations]
+  Unaffected: [list with rationale]
+```
+
+## Phase 2: Change Derivation
+
+For each impacted downstream location:
+
+1. Determine the **minimal necessary change** — the smallest modification
+   that restores alignment with the upstream change.
+2. Classify the change type: Add, Modify, or Remove.
+3. Draft Before/After content showing the exact change.
+4. Record the upstream ref that motivates this downstream change.
+
+**Constraints**:
+- Do NOT introduce changes beyond what the upstream change requires.
+  If you identify an improvement opportunity unrelated to the upstream
+  change, note it separately as a recommendation — do not include it
+  in the patch.
+- Do NOT silently combine multiple upstream changes into one downstream
+  change.  If two upstream changes affect the same downstream location,
+  create separate change entries (they may be applied together, but
+  traceability requires distinct entries).
+
+## Phase 3: Invariant Check
+
+For every existing invariant, constraint, and assumption in the
+downstream artifact:
+
+1. Verify it is **preserved** by the combined set of downstream changes.
+2. If an invariant is **modified** by the changes, flag it explicitly
+   and verify the modification is justified by the upstream change.
+3. If an invariant is **violated** by the changes, STOP and report
+   the conflict.  Do not proceed with a patch that breaks invariants
+   without explicit acknowledgment.
+
+## Phase 4: Completeness Check
+
+Verify that every upstream change has at least one corresponding
+downstream change (or an explicit "no downstream impact" justification):
+
+1. Walk the upstream change manifest entry by entry.
+2. For each upstream change, confirm it appears in the traceability
+   matrix with status Complete, Partial (with explanation), or
+   No-Impact (with rationale).
+3. Flag any upstream change that has no downstream entry as
+   **DROPPED** — this is an error that must be resolved before
+   the patch is finalized.
+
+## Phase 5: Conflict Detection
+
+Check for conflicts within the downstream change set:
+
+1. **Internal conflicts** — two downstream changes that modify the
+   same location in contradictory ways.
+2. **Cross-artifact conflicts** — a change in one downstream artifact
+   that contradicts a change in another (e.g., a design change that
+   conflicts with a validation change).
+3. **Upstream-downstream conflicts** — a downstream change that
+   contradicts the intent of its upstream motivator.
+
+For each conflict found:
+- Describe the conflicting changes
+- Identify the root cause (usually an ambiguity or gap in the upstream)
+- Recommend resolution