baldart 3.6.2

package/framework/.claude/skills/prd/references/discovery-phase.md

@@ -0,0 +1,359 @@
+# Discovery Phase (Steps 0-2)
+
+## Step 0 — Context Recovery
+
+Run BEFORE any other step.
+
+1. Check if `${paths.prd_dir}/sessions/` contains a state file for the current feature.
+2. If found: read it, identify last completed step, resume from next pending step.
+3. If not found: fresh session, proceed to Step 1.
+
+Triggers: session start, context compression, re-invocation of `/prd`.
+
+## Step 1 — Kickoff
+
+**Precondition:** user has described the feature.
+
+1. Derive `<slug>`: kebab-case, lowercase, max 40 chars, no special chars.
+   Example: "Nutritional info on menu" -> `menu-nutritional-info`
+2. **Obsidian spec detection:** scan the user's message for Obsidian note references:
+   - Wikilink pattern: `[[Note Name]]` or `[[Note Name|Alias]]`
+   - If found: extract the note name and save it in the state file under
+     `## Obsidian Spec Note: [[Note Name]]`. This will be added to Canonical Sources in the PRD.
+   - Read the note content from the vault path in memory (`reference_obsidian_vault.md`)
+     to pre-populate discovery dimensions where possible — treat it as a user-provided spec.
+3. Create state file: `${paths.prd_dir}/sessions/YYYY-MM-DD-<slug>-state.md`
+   using template from `assets/state-template.md`.
+3. Create 5 macro-tasks via TaskCreate:
+   - `[PRD] Discovery & comprensione feature`
+   - `[PRD] Design UI & approvazione`
+   - `[PRD] Conferma specifiche complete`
+   - `[PRD] Creazione backlog cards`
+   - `[PRD] Validazione e commit`
+4. Mark task 1 as `in_progress`.
+5. **Context Loading (MANDATORY):** invoke the context-primer skill (`/cont`) with
+   2-4 keywords extracted from the user's feature description. This launches
+   `codebase-architect` which searches the Obsidian-first LightRAG MCP index,
+   docs, backlog, source code, and git history. The returned context informs all
+   subsequent discovery dimensions. Additionally, run `search_docs` MCP with `mode: "hybrid"` for the
+   feature domain. Use Obsidian hits for concept context, then verify
+   implementation and stateful claims against repo docs/code before carrying
+   them into the PRD.
+6. Mark clearly irrelevant dimensions as "N/A" with reason
+   (e.g., backend-only -> UI impact = N/A).
+   If UI impact is N/A, immediately mark task 2 as `completed` ("Skipped — no UI").
+7. **Business Rationale Extraction (MANDATORY):** Before entering the discovery loop,
+   evaluate the user's initial feature description for business rationale signals:
+   - WHY is this feature needed? (business motivation)
+   - What customer/market signal triggered it?
+   - What is the expected business impact?
+   - How does it align with the product strategy?
+
+   If the user's description already covers these clearly, capture them in the state
+   file under `## Business Rationale` and mark the dimension as covered
+   (source: "user-provided").
+
+   If the description is purely functional (WHAT, not WHY), leave the dimension
+   uncovered — it will be the FIRST question in the discovery loop (Dimension 0).
+
+**Output:**
+
+```
+Ho creato la sessione PRD per **<slug>**.
+
+Descrizione: <user's description>
+Contesto caricato: <one-line summary from context-primer>
+
+Ora comincio la fase di **Discovery** — ti faro delle domande per capire bene
+la feature prima di scrivere qualsiasi documento.
+
+<Progress Bar>
+```
+
+**Gate:** state file exists on disk AND all tasks created AND context loaded.
+
+**Immediately proceed to Step 2** — do NOT stop here. Show the kickoff message
+and continue to the discovery loop in the same turn.
+
+## Step 2 — Discovery Question Loop
+
+Multi-turn loop. Each iteration covers ONE uncovered dimension.
+Repeats until ALL relevant dimensions are covered.
+
+**CRITICAL:** ONE question, then STOP. User answers. Process answer,
+update state, send NEXT question, STOP again.
+
+### Dimension 0 — Business Rationale (ALWAYS FIRST)
+
+If already covered in Step 1.7, skip to dimension 1.
+
+Otherwise, present this question:
+
+> ### Domanda — Motivazione di business
+>
+> Capisco COSA vuoi costruire. Ora ho bisogno di capire il **PERCHE** — questa
+> informazione viene documentata permanentemente per il team e per gli agenti futuri.
+>
+> 1. **Perché adesso?** Cosa rende questa feature urgente/importante in questo momento?
+> 2. **Quale segnale** l'ha innescata? (feedback clienti, dati d'uso, pressione competitiva, requisito normativo, altro)
+> 3. **Quale impatto** ti aspetti? (ricavi, retention, efficienza operativa, riduzione rischio)
+> 4. **Come si inserisce** nella visione del prodotto?
+> 5. **Alternative considerate?** Hai valutato altre strade e perché le hai scartate?
+>
+> Anche risposte brevi vanno bene — l'importante è che il "perché" resti documentato.
+
+**STOP.** Wait for user response.
+
+When user responds: record in Discovery Log AND populate `## Business Rationale`
+section of the state file. Mark dimension as covered.
+
+### Per-iteration sequence (dimensions 1-10)
+
+**Precondition:** at least one dimension has status `-` (uncovered).
+
+1. Select next uncovered dimension (in checklist order).
+2. **Use the context already loaded by context-primer (Step 1.5)** to check if
+   the codebase already answers this dimension. The context-primer output includes
+   key docs, key code paths, status, and gotchas — use these to evaluate.
+   If more specific detail is needed beyond what context-primer provided,
+   invoke `codebase-architect` agent (foreground) with a targeted question:
+   ```
+   For feature `<slug>`: regarding the dimension `<dimension>`, does the codebase
+   already answer this? Specifically check: existing collections, routes, components,
+   permissions, and patterns. Report what you find with file references.
+   ```
+   Avoid launching codebase-architect when the context-primer output already
+   provides sufficient information for the dimension.
+3. **If the loaded context (or codebase-architect) provides a COMPLETE answer (no ambiguity):**
+   - Mark dimension as covered (source: "codebase", with file refs)
+   - Log: `**Auto-risolto:** dal contesto caricato [details]`
+   - Show user: `Dimensione **<dimension>**: risolta automaticamente dal codice.
+     [1-line summary]. Passo alla prossima.`
+   - Continue to next dimension in SAME message (no user input needed).
+   - If ALL remaining auto-resolved: show them all, display Progress Bar,
+     proceed to next phase.
+
+4. **If user input is needed:**
+   Present ONE question with:
+
+   ```
+   ### Domanda N — <dimension>
+
+   [Question]
+
+   **Raccomandazione**: **[Option]** (Confidenza: ALTA/MEDIA/BASSA)
+   > [Brief rationale]
+
+   **Perche e importante**: [one line]
+
+   **Alternative**:
+   - **A)** [Recommended] <- consigliato
+   - **B)** [Alternative]
+   - **C)** [Alternative if relevant]
+   ```
+
+   **STOP.** Display Progress Bar and wait.
+
+5. **When user responds:**
+   - Record in Discovery Log: question, recommendation, user answer, source
+   - Update checklist: mark dimension with source and detail
+   - Recalculate comprehension: `covered / relevant * 100`
+   - **Scope Expansion Check** (mandatory on every user answer):
+     Scan the user's answer for NEW entities not in the original feature description:
+     new endpoints, new collections, new pages, new roles, new flows, new integrations.
+     If detected:
+     - Inform: `Ho rilevato un possibile ampliamento di scope: **<entity>**.
+       Questo sembra una nuova funzionalita non coperta dalla descrizione originale.
+       Vuoi che avvii un'analisi di impatto (/prd-add) per integrarla nel PRD,
+       oppure la notiamo come out-of-scope?`
+     - **STOP.** Wait for user response.
+     - If user confirms: read [prd-add-phase.md](prd-add-phase.md) and execute
+       the Change Request flow. After it completes, resume discovery from the
+       next uncovered dimension.
+     - If user says out-of-scope: note in Discovery Log and continue.
+   - Update state file
+   - Proceed to next uncovered dimension (back to action 1)
+
+### Dimension 9 — Integration Surface Analysis (ISA)
+
+This dimension uses **automated codebase scan** — do NOT ask the user a generic question.
+Instead, run the ISA scan and present findings for validation.
+
+**ISA Scan Procedure:**
+
+1. Invoke `codebase-architect` agent with this specific prompt:
+
+   ```
+   For feature `<slug>`: perform an Integration Surface Analysis (ISA).
+   Find ALL existing code that should reference, link to, or interact with this
+   new feature. Scan these categories systematically:
+
+   - NAVIGATION: sidebar links, menu items, breadcrumbs, tab bars, footer links
+   - PERMISSIONS: permission type enums/constants, role-check lists, guard clauses,
+     permission management UI
+   - SETTINGS/CONFIG: settings pages, feature flag lists, config files, env vars
+   - SEARCH/DISCOVERY: search indexes, filter dropdowns, autocomplete sources,
+     listing pages that should include this entity
+   - NOTIFICATIONS: notification type enums, handlers, templates, push configs
+   - DASHBOARD/OVERVIEW: summary pages, widgets, counters, activity feeds,
+     recent-items lists
+   - API CONSUMERS: existing client code that calls related APIs, shared API
+     utilities, API route indexes
+   - SHARED STATE: stores, contexts, providers that manage related data,
+     session/cache keys
+
+   For each touchpoint found, report:
+   - Category (from above)
+   - File path and line number
+   - What action is needed (add link, add entry, add handler, etc.)
+   - Risk if omitted (e.g., "page unreachable", "no access control", "data invisible")
+
+   Also check: are there existing features that do something similar? How are THEY
+   integrated? Use those as a pattern reference.
+   ```
+
+2. **Process findings:**
+   - Build the ISA table from codebase-architect results.
+   - Assign sequential ISA-N IDs to each touchpoint.
+   - Classify each by risk: HIGH (feature broken/unreachable), MEDIUM (degraded UX),
+     LOW (nice-to-have completeness).
+
+3. **Auto-resolve (no user confirmation needed):**
+   - Record final ISA table in state file under `## Integration Surface Map`.
+   - Mark dimension as covered (source: "codebase-scan").
+   - Show a brief summary inline (do NOT stop):
+
+   ```
+   **Auto-risolto:** ISA scan completato — N touchpoint trovati
+   (X HIGH, Y MEDIUM, Z LOW). Dettagli nel state file.
+   ```
+
+   - Continue to next dimension in the SAME message.
+
+**If codebase-architect finds 0 touchpoints** (rare — e.g., completely standalone utility):
+   - Mark dimension as "N/A — standalone feature, no integration surface detected"
+   - Log inline: `**Auto-risolto:** nessun punto di integrazione trovato — feature standalone.`
+   - Continue to next dimension (no user confirmation needed).
+
+### Dimension 10 — Test Strategy & Credentials (special handling)
+
+This dimension has **built-in evaluation logic** — do NOT ask the user a generic question.
+Instead, run the E2E Evaluation Decision Tree and present the result.
+
+**E2E Evaluation Decision Tree:**
+
+```
+1. Does the feature have UI impact? (check dimension "UI impact")
+   → N/A or no UI → E2E: NOT NEEDED (reason: "no UI impact")
+   → Yes → continue to 2
+
+2. Is it a multi-step flow? (booking, onboarding, checkout, wizard, multi-form)
+   → Yes → E2E: REQUIRED
+   → No → continue to 3
+
+3. Is it on a critical path? (auth, payment, booking, permissions, transaction)
+   → Yes → E2E: REQUIRED
+   → No → continue to 4
+
+4. Does it have >3 UI acceptance criteria?
+   → Yes → E2E: RECOMMENDED
+   → No → continue to 5
+
+5. Is it a simple display/component with no complex interaction?
+   → Yes → E2E: NOT NEEDED (reason: "simple display, no complex interaction")
+   → No → E2E: RECOMMENDED
+```
+
+**Result categories:**
+- **NOT NEEDED**: auto-resolve — log reason, mark dimension covered, show inline
+  summary, continue to next dimension (no STOP, no user confirmation needed).
+- **RECOMMENDED**: auto-accept (default: yes) — proceed to credential gathering
+  without asking. Show inline: `E2E: RECOMMENDED — accettato automaticamente.`
+- **REQUIRED**: E2E tests MUST be planned. Proceed to credential gathering.
+
+**When E2E is REQUIRED or user accepts RECOMMENDED:**
+
+1. Identify test scenarios from user stories and acceptance criteria (2-5 scenarios max).
+2. Determine test persona:
+
+   **Consumer feature** (target users include CUSTOMER):
+   - Auto-set credentials: `phone: 3486417303, auth: OTP (manual input by user during test)`
+   - Inform user: `Credenziali test consumer: 3486417303 (OTP manuale durante il test).`
+   - No question needed.
+
+   **Merchant feature** (target users include MERCHANT or MERCHANT_STAFF):
+   - ASK the user:
+     ```
+     ### Domanda — Credenziali test merchant
+
+     Questa feature richiede test E2E come merchant.
+     Su quale merchant e store vuoi testare?
+     Servono le credenziali di login (username/password).
+
+     Esempio: antonio.baldassarre2336 / bRkS2bzqyesK su store "Bar Roma"
+     ```
+   - **STOP.** Wait for user response. Store credentials in state file under `## Test Plan`.
+
+   **Super Admin feature** (target users include SUPER_ADMIN):
+   - ASK the user for admin credentials (same pattern as merchant).
+
+   **Mixed personas**: gather credentials for each persona that needs E2E.
+
+3. After credentials are gathered, summarize the test plan:
+   ```
+   ### Test Plan Summary
+
+   E2E: REQUIRED | RECOMMENDED (accettato)
+   Scenari: N test scenarios
+   Persona: [Consumer | Merchant | Super Admin | Mixed]
+   Credenziali: [summary]
+
+   Scenari pianificati:
+   1. [scenario description — maps to US-X / AC-X]
+   2. [scenario description — maps to US-X / AC-X]
+   ```
+
+4. Mark dimension as covered. Update state file `## Test Plan` section.
+
+### Research Trigger (evaluated at ~75% comprehension)
+
+When 6+ non-test dimensions are covered, evaluate complexity signals from
+discovery answers and codebase-architect findings. Read
+[research-phase.md](research-phase.md) for full signal list and logic.
+
+**Quick decision:**
+- **2+ signals OR regulatory (S2) OR user uncertainty (S5)** → HIGH confidence
+  → launch `senior-researcher` in **background immediately**, continue discovery.
+  Update progress bar: `Ricerca: 🔍 in corso (background)`.
+- **1 non-critical signal** → MEDIUM confidence → note for later (ask at exit).
+- **No signals** → skip research. Update progress bar: `Ricerca: ⏭️ non necessaria`.
+
+If research launched in background: it runs in parallel with remaining questions.
+
+### Exit condition
+
+Comprehension >= 99% OR user explicitly says to proceed.
+
+**Before exiting, check research status** (read [research-phase.md](research-phase.md)):
+1. **HIGH confidence, researcher returned** → process findings, ask follow-up
+   questions if gaps found, then exit.
+2. **HIGH confidence, researcher still running** → inform user, wait for result.
+3. **MEDIUM confidence (not yet asked)** → ask user if they want research.
+   If yes, launch in foreground and process. If no, mark skipped.
+4. **No research needed** → exit normally.
+
+When loop exits: mark task 1 as `completed`. Update state file status to
+`ui-design` (or `specs-confirmed` if UI is N/A).
+
+**Output:**
+
+```
+Discovery completata! Tutte le dimensioni sono coperte.
+
+[Brief summary of key decisions made]
+[If research: brief summary of key findings]
+
+Passo alla fase successiva: [UI Design / Scrittura PRD]
+
+<Progress Bar>
+```

package/framework/.claude/skills/prd/references/impact-analysis.md

@@ -0,0 +1,233 @@
+# ICIAS Impact Analysis Protocol
+
+Full protocol for Change Impact Analysis on PRD sessions.
+Based on ProReFiCIA (Etezadi et al. 2025), CodePlan (Bairi et al. 2023),
+and FMEA-adapted scoring.
+
+---
+
+## Phase 1 — Semantic Scan
+
+Evaluate each dimension against the change request description.
+
+### Procedure
+
+For each of the 10 dimensions, determine:
+- **Is there a direct impact?** (yes/no)
+- **Impact depth** (I):
+  - 0 = no impact
+  - 1 = cosmetic (labels, copy, minor display)
+  - 2 = logic (new conditions, validation, flow branches)
+  - 3 = structural (new entities, schemas, endpoints, pages)
+
+### Refinement pass (mandatory)
+
+After initial scan, re-read the change request and check dimensions 4-7
+again (the "middle" of the list — LLMs tend to under-evaluate items in
+the middle of lists, per "lost-in-the-middle" research). Adjust any
+dimension that was initially scored 0 but deserves >= 1 on second look.
+
+---
+
+## Phase 2 — Structural Propagation (Coupling Matrix)
+
+Apply the coupling matrix to find transitive (cascade) impacts.
+
+### Rules
+
+1. Start from all dimensions with direct impact (I > 0 from Phase 1).
+2. For each directly impacted dimension, check outgoing edges in the matrix.
+3. If edge strength >= 2 AND target dimension has I = 0: mark as cascade impact.
+   - Cascade I = max(1, source_I - 1) (degrades by hop)
+   - Cascade C = source_C - 1 (min 1) (confidence degrades)
+4. Max hop depth = 2. Do NOT propagate beyond 2 hops.
+5. If a dimension is reached by both direct and cascade: use direct (higher confidence).
+
+### Coupling Matrix (10x10)
+
+Rows = source dimension, Columns = target dimension.
+Values: 0 = independent, 1 = weak, 2 = moderate, 3 = strong (almost always co-impacted).
+
+```
+        D1   D2   D3   D4   D5   D6   D7   D8   D9   D10
+D1  U   -    1    0    0    1    1    0    0    0    0
+D2  J   0    -    1    1    3    0    2    0    1    1
+D3  DM  0    0    -    3    0    0    1    3    1    2
+D4  API 0    1    3    -    1    1    1    0    3    3
+D5  UI  0    2    0    0    -    0    1    0    1    2
+D6  P   0    0    0    1    1    -    1    0    1    3
+D7  EC  0    0    0    0    0    0    -    0    0    1
+D8  RM  0    0    1    0    0    0    1    -    0    1
+D9  IS  0    0    0    1    0    0    0    0    -    1
+D10 TS  0    0    0    0    0    0    0    0    0    -
+```
+
+**Key:**
+- D1=Users, D2=Journey, D3=Data Model, D4=API, D5=UI
+- D6=Permissions, D7=Edge Cases, D8=Rollout/Migration
+- D9=Integration Surface, D10=Test Strategy
+
+### High-coupling pairs (strength=3, rationale)
+
+| Source → Target | Why |
+|-----------------|-----|
+| D2 Journey → D5 UI | New flow = new interface almost always |
+| D3 Data → D4 API | Schema change = API contract change |
+| D3 Data → D8 Rollout | Schema change = migration needed |
+| D4 API → D3 Data | New endpoint often needs new/modified schema |
+| D4 API → D9 Integration | New endpoint = new touchpoints in existing code |
+| D4 API → D10 Tests | New endpoint = new test scenarios |
+| D6 Perms → D10 Tests | Permission change = critical test update |
+
+---
+
+## Phase 3 — ICIAS Scoring
+
+For each dimension with I > 0 (direct or cascade):
+
+### Score = I x C x A
+
+**I = Impact Depth** (from Phase 1/2):
+| Value | Meaning | Examples |
+|-------|---------|----------|
+| 1 | Cosmetic | Label, copy, minor display change |
+| 2 | Logic | New condition, validation, flow branch, field |
+| 3 | Structural | New entity, endpoint, page, collection, role |
+
+**C = Confidence** (how certain the impact is):
+| Value | Meaning | When to use |
+|-------|---------|-------------|
+| 1 | Inferred | Cascade-only, no direct evidence |
+| 2 | Probable | Logical deduction, codebase pattern suggests it |
+| 3 | Certain | Explicitly stated in CR, or direct code dependency |
+
+**A = Artifact Stakes** (pre-assigned, fixed per dimension):
+| A=3 (High stakes) | A=2 (Medium stakes) | A=1 (Low stakes) |
+|-------------------|---------------------|-------------------|
+| D3 Data Model | D2 User Journey | D1 Target Users |
+| D4 API | D5 UI | D7 Edge Cases |
+| D9 Integration Surface | D6 Permissions | D8 Rollout/Migration |
+| | D10 Test Strategy | |
+
+### Verdict thresholds
+
+| Score Range | Verdict | Meaning |
+|-------------|---------|---------|
+| 0 | SKIP | No impact detected |
+| 1–3 | SKIP | Negligible impact, no revision needed |
+| 4–9 | PATCH | Moderate impact, surgical update to affected sections |
+| 10–27 | REDO | Major impact, phase must be substantially re-executed |
+
+### Bias rule
+
+**False negatives are worse than false positives.** When uncertain:
+- Round C up, not down
+- Prefer PATCH over SKIP when on the boundary (score = 3)
+- Prefer REDO over PATCH only when I = 3 (structural)
+
+---
+
+## Phase Mapping
+
+After scoring all dimensions, map to PRD phases:
+
+### Discovery phase impact
+- ANY dimension with PATCH/REDO → Discovery needs delta update
+- PATCH: update state file checklist, run codebase-architect on affected dims
+- REDO: re-run discovery question loop for affected dims
+
+### UI Design phase impact
+- D2 Journey REDO OR D5 UI REDO → UI Design REDO
+- D5 UI PATCH → UI Design PATCH (update existing design)
+- Otherwise → UI Design SKIP
+
+### PRD document impact
+- ANY dimension with PATCH/REDO → PRD needs update
+- Map dimensions to PRD sections:
+
+| Dimension | PRD Sections Affected |
+|-----------|----------------------|
+| D1 Users | 3 (Personas) |
+| D2 Journey | 4 (User Stories), 7 (UI Specs) |
+| D3 Data | 5 (Data Model), 12 (Dependencies) |
+| D4 API | 6 (API Contract), 14 (Pipeline) |
+| D5 UI | 7 (UI Specs), 8 (i18n) |
+| D6 Perms | 9 (Acceptance Criteria) |
+| D7 Edge Cases | 10 (Edge Cases) |
+| D8 Rollout | 12 (Dependencies) |
+| D9 Integration | 15 (ISA) |
+| D10 Tests | 13 (Test Plan) |
+
+### Backlog Cards impact
+- New structural entities (I=3) → new cards needed
+- Changed acceptance criteria → update existing cards
+- Changed dependencies → update `depends_on` fields
+
+---
+
+## Worked Example
+
+**CR: "Add POST /api/v1/merchant/reservations/bulk-confirm for batch confirmation"**
+
+Change type: Addition (new endpoint)
+
+### Phase 1 — Semantic Scan
+
+| Dim | Direct? | I | Rationale |
+|-----|---------|---|-----------|
+| D1 Users | no | 0 | Same users (merchant staff) |
+| D2 Journey | yes | 2 | New batch flow alongside single confirm |
+| D3 Data | no | 0 | Same reservation schema |
+| D4 API | yes | 3 | New endpoint, new payload, new validation |
+| D5 UI | yes | 2 | Need selection mode + bulk button |
+| D6 Perms | no | 0 | Same permission (manage_reservations) |
+| D7 Edge | yes | 2 | Partial failure in batch, max batch size |
+| D8 Rollout | no | 0 | No migration needed |
+| D9 Integration | no | 0 | (check in Phase 2) |
+| D10 Tests | no | 0 | (check in Phase 2) |
+
+### Phase 2 — Structural Propagation
+
+From D4 (API, I=3):
+- D4→D3 (strength=3): cascade. D3 I=max(1, 3-1)=2, C=2 → but wait,
+  CR says "same schema" → override to I=0. No cascade (semantic override).
+- D4→D9 (strength=3): cascade. D9 I=2, C=2
+- D4→D10 (strength=3): cascade. D10 I=2, C=2
+
+### Phase 3 — ICIAS Score
+
+| Dim | I | C | A | Score | Verdict |
+|-----|---|---|---|-------|---------|
+| D1 | 0 | - | 1 | 0 | SKIP |
+| D2 | 2 | 3 | 2 | 12 | REDO |
+| D3 | 0 | - | 3 | 0 | SKIP |
+| D4 | 3 | 3 | 3 | 27 | REDO |
+| D5 | 2 | 3 | 2 | 12 | REDO |
+| D6 | 0 | - | 2 | 0 | SKIP |
+| D7 | 2 | 3 | 1 | 6 | PATCH |
+| D8 | 0 | - | 1 | 0 | SKIP |
+| D9 | 2 | 2 | 3 | 12 | REDO |
+| D10 | 2 | 2 | 2 | 8 | PATCH |
+
+### Phase mapping result
+
+| Phase | Verdict | Scope |
+|-------|---------|-------|
+| Discovery | PATCH | Update D2, D4, D5, D7, D9, D10 in checklist |
+| UI Design | REDO | New batch selection flow |
+| PRD | REDO | Sections 4, 6, 7, 10, 13, 15 |
+| Backlog Cards | PATCH | New cards for bulk endpoint + UI; update deps |
+
+---
+
+## Calibration Notes
+
+These thresholds are FMEA-adapted heuristics, not empirically validated
+for PRD CIA. After 10-15 real change requests, review:
+
+1. Were any SKIPs that should have been PATCHes? → Lower threshold.
+2. Were any REDOs that could have been PATCHes? → Raise threshold.
+3. Did the coupling matrix miss any real cascades? → Add/strengthen edges.
+4. Did the coupling matrix produce false cascades? → Weaken/remove edges.
+
+Track calibration data in state file `## Change Requests` section.