Process Change Request

Purpose

Process an enhancement or change request by reconciling requirements across the spec stack, agreeing a target state with the user, then closing with an approved reconciliation record and in-place spec updates. This activity does not implement code.

Requirements Sources

Reconcile across all layers that exist in this project. Read what is present; skip absent layers and note the gap in the matrix.

For each affected Screen ID, build a reconciliation matrix:

Steps

1. Reconcile Requirements (read-only first)

• Read inputs per ## Inputs below
• Read the change request thoroughly; identify affected Screen IDs and scope
• Read user journey — locate affected screen sections
• Read feature files — locate affected scenarios
• Read mockups — locate affected prototype screens
• Read screen flow and IA guidelines when UI or navigation is in scope
• Read SAO.md for architectural constraints touched by the change
• Inspect as-built code and tests for the same Screen IDs
• Flag conflicts between layers; do NOT assume — list open questions
• If you don't understand user intent or UX details — ASK

Fast path: If the matrix shows zero drift across all present spec layers and the change is purely cosmetic with no scenario impact, document the empty matrix and note minimal delta in the reconciliation document.

2. Propose Target State

• Draft in-place revisions to canonical consumed artifacts (only layers where drift was found). Do not create parallel "Updated *" copies — revise the same User Journey, Feature Files, Mockups, Screen Flow, and IA documents the project already uses.
• Create Change Reconciliation Document at docs/plans/{FEAT}_CHANGE_RECONCILIATION.md containing:
• Trigger (change request summary)
• Reconciliation matrix (from Step 1)
• Proposed spec diffs (summary + file paths)
• Open questions for user
• Fast-path justification (if applicable)
• Present target state to user; ask clarification questions
• Gate: User must approve target state before closing this activity

3. Close Reconciliation

• Ensure approved Change Reconciliation Document is saved at docs/plans/{FEAT}_CHANGE_RECONCILIATION.md
• Ensure in-place revisions to canonical spec artifacts are complete (Step 2)
• Technical replanning and implementation are out of scope for this activity — the human may invoke Plan Feature (Activity 96) separately when ready

Rules to Follow

I. Do Not Assume

If unclear — ASK. Never guess user intent or implementation details.

II. Spec Before Code

Reconcile and update requirements artifacts before any implementation planning or coding.

III. No Execution in Process Change Request

Implementation, testing, and commits happen in later Build Feature activities after separate planning approval.

IV. Traceability

Every affected Screen ID must appear consistently across all present spec layers. Verify with project grep conventions.

Success Criteria

• Change request captured and understood
• Reconciliation matrix complete for all affected Screen IDs
• Canonical spec artifacts revised in place or explicitly marked unchanged (fast path)
• Change Reconciliation Document created, saved, and user-approved
• No code changes made during this activity

Inputs

Read these before starting this activity. They are produced earlier in the playbook and are authoritative — raise a drift event instead of deviating.

• User Journey (Document, Required) — produced by Define User Journey (#36).
• Screen Flow / Dialogue Map (Diagram, Required) — produced by Create Dialogue Maps (#38).
• Feature Files (Document, Required) — produced by Write Feature Files (#39).
• HTML Mockups (Code, Optional) — produced by Create Mockups (#40).
• IA Guidelines (Document, Optional) — produced by Define Information Architecture (#37).
• System Architecture Overview Template (Document, Required) — produced by Write SAO.md (#59).
• Implementation Plan Template (Template, Required) — produced by Plan Feature (#96).
• Definition of Done Checklist Template (Template, Required) — produced by Check Definition of Done (#101).