azcodr 1.4.0 → 1.5.1

package/docs/rules/product_ownership.md

@@ -1,127 +1,127 @@
-# Product Ownership, Backlog Management & OKRs
-
-> **Core Mandate:** Maximize product value through empiricism (Build-Measure-Learn), clear Product Goals, strategic OKR alignment, outcome-driven value measurement, and disciplined backlog ordering.
-
----
-
-## 1. The Product Owner Accountability & Empiricism
-
-The Product Owner (PO) is accountable for maximizing the value of the product resulting from the work of the development team. This accountability is grounded in **empiricism**: making decisions based on observation, experimentation, and evidence rather than speculation.
-
-### Core Accountabilities
-1. **Developing & Communicating the Product Goal:** Formulating a singular, long-term target that provides direction and a measurable commitment for the Product Backlog.
-2. **Creating & Communicating Product Backlog Items (PBIs):** Translating stakeholder needs and strategic objectives into transparent, well-understood backlog items.
-3. **Ordering the Product Backlog:** Ranking items to optimize value, address critical risks, and sequence dependencies.
-4. **Deciding What NOT to Do:** The hallmark of effective product ownership is saying "no" to low-impact, out-of-scope, or speculative requests to preserve focus.
-5. **Ensuring Backlog Transparency:** Maintaining a single, accessible, and visible source of truth for the team and stakeholders.
-6. **Measuring Delivered Value:** Continuously gathering feedback from customers and stakeholders, calculating return on investment (ROI), and closing the satisfaction gap.
-
----
-
-## 2. Product Value & Outcome vs. Output
-
-### Defining Product Value
-Product value is the benefit a product provides to customers (by meeting needs and increasing satisfaction) and to the organization (monetary return, business longevity, brand reputation).
-
-### The Satisfaction Gap
-Value creation focuses on closing the **Satisfaction Gap**:
-$$\text{Satisfaction Gap} = \text{Desired Customer Experience} - \text{Current Customer Experience}$$
-
-### Avoiding the "Feature Factory" (Output vs. Outcome)
-- **Output:** The sheer volume of work completed (e.g., number of features shipped, story points burned, code commits). Output alone does NOT equal value.
-- **Outcome:** The measurable positive change in customer behavior, satisfaction, operational efficiency, or business performance resulting from the product increment.
-- Shipping 10 features that users ignore is pure waste. Shipping 1 vertical slice that solves a critical pain point is high value.
-
-### The Product Increment & Definition of Done
-The only vehicle through which a team delivers actual product value is a usable, high-quality **Product Increment** that fully satisfies the **Definition of Done (DoD)**. Work that is not done delivers zero value and accumulates technical debt.
-
----
-
-## 3. Strategic Alignment via OKRs (Objectives and Key Results)
-
-The OKR framework connects overarching strategic vision to sprint execution and product backlog ordering.
-
-```mermaid
-flowchart TD
-    V["Company Vision & Strategy"] --> OKR["Strategic OKRs (Annual / Quarterly)"]
-    OKR --> PG["Product Goal (Long-Term Commitment)"]
-    PG --> PB["Product Backlog (Emergent, Ordered PBIs)"]
-    PB --> SG["Sprint Goal (Tactical Increment)"]
-```
-
-### Anatomy of an OKR
-- **Objective (O):** Qualitative, aspirational, inspiring, and time-bound statement defining **WHAT** must be achieved.
-  - *Example:* "Establish our digital self-service portal as the fastest and most frictionless onboarding experience in the industry."
-- **Key Results (KRs):** 2 to 5 quantitative, outcome-focused metrics defining **HOW** progress toward the Objective is measured.
-  - *Rule:* KRs must measure outcomes or impact, never activities or tasks (e.g., "Conduct 5 meetings" is an activity; "Increase onboarding conversion from 40% to 75%" is an outcome).
-  - *Example KRs:*
-    1. Reduce average time from application approval to active service from 72 hours to under 4 hours.
-    2. Achieve a 95% digital self-service execution completion rate without customer support escalations.
-    3. Decrease manual operator review processing time by 60%.
-
-### OKRs vs. KPIs
-| Dimension | Key Performance Indicators (KPIs) | Objectives & Key Results (OKRs) |
-|---|---|---|
-| **Purpose** | Measure ongoing operational health and business-as-usual baseline metrics ("vital signs"). | Drive deliberate, time-bound, aspirational transformation and change. |
-| **Cadence** | Continuous / evergreen monitoring (e.g., server uptime, customer churn rate). | Typically quarterly or cyclical (e.g., Q1, Q2) with retrospective scoring. |
-| **Mindset** | "Keep the lights on and within acceptable thresholds." | "Move the needle on strategic priorities and break new ground." |
-
----
-
-## 4. Product Backlog Ordering & Prioritization Techniques
-
-Never prioritize a backlog solely on "gut feeling" or the loudest voice. Utilize established open-standard prioritization models:
-
-### 1. The Kano Model (Customer Delight vs. Investment)
-Categorizes features based on how customer satisfaction correlates with implementation completeness:
-- **Must-be (Basic / Expected):** Table stakes. Absence causes extreme dissatisfaction; presence is taken for granted (e.g., secure password reset, data isolation).
-- **Performance (One-dimensional):** Linear satisfaction. The more, the better (e.g., search speed, export volume, page load time).
-- **Attractive (Delighters / Excitement):** Unexpected innovations. Absence causes no dissatisfaction, but presence triggers high customer delight (e.g., instant one-click self-service onboarding).
-- **Indifferent:** Features customers do not care about. Eliminate immediately.
-- **Reverse:** Features that cause dissatisfaction if added (e.g., excessive mandatory onboarding popups).
-
-### 2. MoSCoW Prioritization
-- **Must Have (M):** Non-negotiable core invariants; without them, the increment cannot be released or is illegal/insecure.
-- **Should Have (S):** Important capabilities that add substantial value, but a workaround exists for this release.
-- **Could Have (C):** Desirable enhancements implemented only if time and capacity permit.
-- **Won't Have This Time (W):** Explicitly agreed out-of-scope items for the current planning cycle, protecting the team from scope creep.
-
-### 3. RICE Scoring
-Calculates a numerical score to rank candidate backlog items objectively:
-$$\text{RICE Score} = \frac{\text{Reach} \times \text{Impact} \times \text{Confidence}}{\text{Effort}}$$
-- **Reach:** Number of users or transactions impacted over a fixed period.
-- **Impact:** Degree of benefit per user (e.g., $3 = \text{massive}$, $2 = \text{high}$, $1 = \text{medium}$, $0.5 = \text{low}$, $0.25 = \text{minimal}$).
-- **Confidence:** Percentage reflecting data backing your estimate ($100\% = \text{high evidence}$, $80\% = \text{medium}$, $50\% = \text{speculative}$).
-- **Effort:** Total person-weeks or person-sprints required to deliver the vertical slice.
-
-### 4. Buy a Feature
-A collaborative prioritization exercise where stakeholders are allocated a constrained budget of fictitious currency to "buy" features priced according to their engineering effort. Reveals true customer value by forcing trade-offs under scarcity.
-
----
-
-## 5. Product Backlog Granularity & Progressive Elaboration
-
-Following Gunther Verheyen's backlog topology, the Product Backlog serves as an **emergent, living roadmap**:
-
-```mermaid
-flowchart TD
-    subgraph Top["Finer Granularity (Top of Backlog)"]
-        P1["PBI 1: Sprintable, vertically sliced, clear DoD & Gherkin"]
-        P2["PBI 2: High priority, well-understood, estimated"]
-        P3["PBI 3: Actionable, small, customer value clear"]
-    end
-    subgraph Middle["Medium Granularity (Middle)"]
-        P4["PBI 4: Candidate for next period, coarse slice"]
-        P5["PBI 5: Alternative approach under evaluation"]
-    end
-    subgraph Bottom["Coarser Granularity (Bottom)"]
-        P6["PBI 6: Long-term idea, future capability"]
-        P7["PBI 7: Raw thought, exploratory concept"]
-    end
-    Top --> Middle --> Bottom
-```
-
-### Rules of Progressive Elaboration
-1. **Single & Ordered:** Exactly one backlog exists per product.
-2. **Dynamic Splitting:** As coarse items approach the top of the backlog, they must be split into fine, sprintable INVEST slices.
-3. **Continuous Pruning:** Items may be reordered, added, split, or permanently deleted at any time based on empirical learning. If an item lingers at the bottom of the backlog for months without business justification, remove it.
+# Product Ownership, Backlog Management & OKRs
+
+> **Core Mandate:** Maximize product value through empiricism (Build-Measure-Learn), clear Product Goals, strategic OKR alignment, outcome-driven value measurement, and disciplined backlog ordering.
+
+---
+
+## 1. The Product Owner Accountability & Empiricism
+
+The Product Owner (PO) is accountable for maximizing the value of the product resulting from the work of the development team. This accountability is grounded in **empiricism**: making decisions based on observation, experimentation, and evidence rather than speculation.
+
+### Core Accountabilities
+1. **Developing & Communicating the Product Goal:** Formulating a singular, long-term target that provides direction and a measurable commitment for the Product Backlog.
+2. **Creating & Communicating Product Backlog Items (PBIs):** Translating stakeholder needs and strategic objectives into transparent, well-understood backlog items.
+3. **Ordering the Product Backlog:** Ranking items to optimize value, address critical risks, and sequence dependencies.
+4. **Deciding What NOT to Do:** The hallmark of effective product ownership is saying "no" to low-impact, out-of-scope, or speculative requests to preserve focus.
+5. **Ensuring Backlog Transparency:** Maintaining a single, accessible, and visible source of truth for the team and stakeholders.
+6. **Measuring Delivered Value:** Continuously gathering feedback from customers and stakeholders, calculating return on investment (ROI), and closing the satisfaction gap.
+
+---
+
+## 2. Product Value & Outcome vs. Output
+
+### Defining Product Value
+Product value is the benefit a product provides to customers (by meeting needs and increasing satisfaction) and to the organization (monetary return, business longevity, brand reputation).
+
+### The Satisfaction Gap
+Value creation focuses on closing the **Satisfaction Gap**:
+$$\text{Satisfaction Gap} = \text{Desired Customer Experience} - \text{Current Customer Experience}$$
+
+### Avoiding the "Feature Factory" (Output vs. Outcome)
+- **Output:** The sheer volume of work completed (e.g., number of features shipped, story points burned, code commits). Output alone does NOT equal value.
+- **Outcome:** The measurable positive change in customer behavior, satisfaction, operational efficiency, or business performance resulting from the product increment.
+- Shipping 10 features that users ignore is pure waste. Shipping 1 vertical slice that solves a critical pain point is high value.
+
+### The Product Increment & Definition of Done
+The only vehicle through which a team delivers actual product value is a usable, high-quality **Product Increment** that fully satisfies the **Definition of Done (DoD)**. Work that is not done delivers zero value and accumulates technical debt.
+
+---
+
+## 3. Strategic Alignment via OKRs (Objectives and Key Results)
+
+The OKR framework connects overarching strategic vision to sprint execution and product backlog ordering.
+
+```mermaid
+flowchart TD
+    V["Company Vision & Strategy"] --> OKR["Strategic OKRs (Annual / Quarterly)"]
+    OKR --> PG["Product Goal (Long-Term Commitment)"]
+    PG --> PB["Product Backlog (Emergent, Ordered PBIs)"]
+    PB --> SG["Sprint Goal (Tactical Increment)"]
+```
+
+### Anatomy of an OKR
+- **Objective (O):** Qualitative, aspirational, inspiring, and time-bound statement defining **WHAT** must be achieved.
+  - *Example:* "Establish our digital self-service portal as the fastest and most frictionless onboarding experience in the industry."
+- **Key Results (KRs):** 2 to 5 quantitative, outcome-focused metrics defining **HOW** progress toward the Objective is measured.
+  - *Rule:* KRs must measure outcomes or impact, never activities or tasks (e.g., "Conduct 5 meetings" is an activity; "Increase onboarding conversion from 40% to 75%" is an outcome).
+  - *Example KRs:*
+    1. Reduce average time from application approval to active service from 72 hours to under 4 hours.
+    2. Achieve a 95% digital self-service execution completion rate without customer support escalations.
+    3. Decrease manual operator review processing time by 60%.
+
+### OKRs vs. KPIs
+| Dimension | Key Performance Indicators (KPIs) | Objectives & Key Results (OKRs) |
+|---|---|---|
+| **Purpose** | Measure ongoing operational health and business-as-usual baseline metrics ("vital signs"). | Drive deliberate, time-bound, aspirational transformation and change. |
+| **Cadence** | Continuous / evergreen monitoring (e.g., server uptime, customer churn rate). | Typically quarterly or cyclical (e.g., Q1, Q2) with retrospective scoring. |
+| **Mindset** | "Keep the lights on and within acceptable thresholds." | "Move the needle on strategic priorities and break new ground." |
+
+---
+
+## 4. Product Backlog Ordering & Prioritization Techniques
+
+Never prioritize a backlog solely on "gut feeling" or the loudest voice. Utilize established open-standard prioritization models:
+
+### 1. The Kano Model (Customer Delight vs. Investment)
+Categorizes features based on how customer satisfaction correlates with implementation completeness:
+- **Must-be (Basic / Expected):** Table stakes. Absence causes extreme dissatisfaction; presence is taken for granted (e.g., secure password reset, data isolation).
+- **Performance (One-dimensional):** Linear satisfaction. The more, the better (e.g., search speed, export volume, page load time).
+- **Attractive (Delighters / Excitement):** Unexpected innovations. Absence causes no dissatisfaction, but presence triggers high customer delight (e.g., instant one-click self-service onboarding).
+- **Indifferent:** Features customers do not care about. Eliminate immediately.
+- **Reverse:** Features that cause dissatisfaction if added (e.g., excessive mandatory onboarding popups).
+
+### 2. MoSCoW Prioritization
+- **Must Have (M):** Non-negotiable core invariants; without them, the increment cannot be released or is illegal/insecure.
+- **Should Have (S):** Important capabilities that add substantial value, but a workaround exists for this release.
+- **Could Have (C):** Desirable enhancements implemented only if time and capacity permit.
+- **Won't Have This Time (W):** Explicitly agreed out-of-scope items for the current planning cycle, protecting the team from scope creep.
+
+### 3. RICE Scoring
+Calculates a numerical score to rank candidate backlog items objectively:
+$$\text{RICE Score} = \frac{\text{Reach} \times \text{Impact} \times \text{Confidence}}{\text{Effort}}$$
+- **Reach:** Number of users or transactions impacted over a fixed period.
+- **Impact:** Degree of benefit per user (e.g., $3 = \text{massive}$, $2 = \text{high}$, $1 = \text{medium}$, $0.5 = \text{low}$, $0.25 = \text{minimal}$).
+- **Confidence:** Percentage reflecting data backing your estimate ($100\% = \text{high evidence}$, $80\% = \text{medium}$, $50\% = \text{speculative}$).
+- **Effort:** Total person-weeks or person-sprints required to deliver the vertical slice.
+
+### 4. Buy a Feature
+A collaborative prioritization exercise where stakeholders are allocated a constrained budget of fictitious currency to "buy" features priced according to their engineering effort. Reveals true customer value by forcing trade-offs under scarcity.
+
+---
+
+## 5. Product Backlog Granularity & Progressive Elaboration
+
+Following Gunther Verheyen's backlog topology, the Product Backlog serves as an **emergent, living roadmap**:
+
+```mermaid
+flowchart TD
+    subgraph Top["Finer Granularity (Top of Backlog)"]
+        P1["PBI 1: Sprintable, vertically sliced, clear DoD & Gherkin"]
+        P2["PBI 2: High priority, well-understood, estimated"]
+        P3["PBI 3: Actionable, small, customer value clear"]
+    end
+    subgraph Middle["Medium Granularity (Middle)"]
+        P4["PBI 4: Candidate for next period, coarse slice"]
+        P5["PBI 5: Alternative approach under evaluation"]
+    end
+    subgraph Bottom["Coarser Granularity (Bottom)"]
+        P6["PBI 6: Long-term idea, future capability"]
+        P7["PBI 7: Raw thought, exploratory concept"]
+    end
+    Top --> Middle --> Bottom
+```
+
+### Rules of Progressive Elaboration
+1. **Single & Ordered:** Exactly one backlog exists per product.
+2. **Dynamic Splitting:** As coarse items approach the top of the backlog, they must be split into fine, sprintable INVEST slices.
+3. **Continuous Pruning:** Items may be reordered, added, split, or permanently deleted at any time based on empirical learning. If an item lingers at the bottom of the backlog for months without business justification, remove it.

package/docs/rules/project_management.md

@@ -1,49 +1,49 @@
-# Project Management, Work-In-Progress Limits & Definition of Done
-
-> **Core Mandate:** Enforce strict Work-In-Progress (WIP) limits, vertical task slicing, SMART developer task decomposition, explicit task lifecycle states, and an uncompromising Definition of Done (DoD).
-
----
-
-## 1. Task Lifecycle & WIP Limits
-
-- **Task States**: Every operational task must progress through explicit states:
-  ```
-  BACKLOG ──► TODO ──► IN_PROGRESS ──► REVIEW ──► DONE
-  ```
-- **Strict WIP Limit**: Maintain a Work-In-Progress (WIP) limit of **exactly 1 atomic task** at any given time. Never begin a new task while a previous task is incomplete or failing tests.
-- **Vertical Task Slicing**: Stories must deliver full-stack value across UI, API, Domain, and DB layers (no horizontal layers like "create migration only").
-
----
-
-## 2. Decomposing Stories into SMART Developer Tasks
-
-While user stories represent customer-facing value (governed by the INVEST model), engineering execution requires decomposing each story into technical developer tasks. Apply Bill Wake's **SMART** criteria to all developer tasks:
-
-- **S - Specific:** The task scope is clearly defined so every team member understands what is involved. Avoids overlapping with concurrent work and ensures all tasks aggregate into the complete story.
-- **M - Measurable:** Defined by the question: *"Can we objectively mark it as done?"* Completion requires that:
-  1. The code fulfills its intended behavior.
-  2. Automated tests are written and passing.
-  3. Clean code principles and refactoring have been applied.
-- **A - Achievable:** The task owner has the skills and context to complete it. Establish a psychological safety norm: anyone can ask for help immediately if a task encounters unexpected obstacles.
-- **R - Relevant:** Every developer task directly contributes to delivering the parent user story. Technical infrastructure tasks must be justified by the business capability they unlock.
-- **T - Time-Boxed:** Each task has a bounded duration expectation (typically 2–4 hours, never exceeding 1 day). Exceeding the time-box acts as an automatic trigger to pause, split the task, pair with a peer, or adjust the plan.
-
----
-
-## 3. Definition of Done (DoD)
-
-A user story or task is only marked `DONE` when all of the following verifiable criteria are met:
-- [ ] **Lifecycle Provenance**: Code developed strictly via the 5-Phase Agile Domain Lifecycle (Requirements ➔ Domain Analysis ➔ Outer Acceptance RED ➔ Inner Unit RED-GREEN-REFACTOR ➔ Outer GREEN). Zero production code written before tests.
-- [ ] **Tests Green**: 100.00% full-stack test coverage maintained across statement, branch, function, and line metrics (`npm test` / `pnpm test`).
-- [ ] **Boundary Verified**: Cross-package boundary smoke tests passed against live running servers (`scripts/smoke_test.sh`).
-- [ ] **Zero Lints & Types**: 0 ESLint warnings and 0 TypeScript compilation errors (`npm run lint && npm run typecheck`).
-- [ ] **No Unverified Assumptions**: All behavior backed by tests, schema invariants, or verified command evidence.
-- [ ] **ADR Logged**: An Architectural Decision Record is logged in `memory.md` if architectural trade-offs were made.
-- [ ] **Documentation Clean**: Zero broken markdown links across workspace files and relevant knowledge documents updated.
-
----
-
-## 4. Blocker Escalation & Risk Management
-
-- If a blocker or ambiguity arises, immediately transition the task to `BLOCKED`, halt execution, and interrogate the root cause.
-- Never guess or write speculative code to bypass an unresolved requirement.
+# Project Management, Work-In-Progress Limits & Definition of Done
+
+> **Core Mandate:** Enforce strict Work-In-Progress (WIP) limits, vertical task slicing, SMART developer task decomposition, explicit task lifecycle states, and an uncompromising Definition of Done (DoD).
+
+---
+
+## 1. Task Lifecycle & WIP Limits
+
+- **Task States**: Every operational task must progress through explicit states:
+  ```
+  BACKLOG ──► TODO ──► IN_PROGRESS ──► REVIEW ──► DONE
+  ```
+- **Strict WIP Limit**: Maintain a Work-In-Progress (WIP) limit of **exactly 1 atomic task** at any given time. Never begin a new task while a previous task is incomplete or failing tests.
+- **Vertical Task Slicing**: Stories must deliver full-stack value across UI, API, Domain, and DB layers (no horizontal layers like "create migration only").
+
+---
+
+## 2. Decomposing Stories into SMART Developer Tasks
+
+While user stories represent customer-facing value (governed by the INVEST model), engineering execution requires decomposing each story into technical developer tasks. Apply Bill Wake's **SMART** criteria to all developer tasks:
+
+- **S - Specific:** The task scope is clearly defined so every team member understands what is involved. Avoids overlapping with concurrent work and ensures all tasks aggregate into the complete story.
+- **M - Measurable:** Defined by the question: *"Can we objectively mark it as done?"* Completion requires that:
+  1. The code fulfills its intended behavior.
+  2. Automated tests are written and passing.
+  3. Clean code principles and refactoring have been applied.
+- **A - Achievable:** The task owner has the skills and context to complete it. Establish a psychological safety norm: anyone can ask for help immediately if a task encounters unexpected obstacles.
+- **R - Relevant:** Every developer task directly contributes to delivering the parent user story. Technical infrastructure tasks must be justified by the business capability they unlock.
+- **T - Time-Boxed:** Each task has a bounded duration expectation (typically 2–4 hours, never exceeding 1 day). Exceeding the time-box acts as an automatic trigger to pause, split the task, pair with a peer, or adjust the plan.
+
+---
+
+## 3. Definition of Done (DoD)
+
+A user story or task is only marked `DONE` when all of the following verifiable criteria are met:
+- [ ] **Lifecycle Provenance**: Code developed strictly via the 5-Phase Agile Domain Lifecycle (Requirements ➔ Domain Analysis ➔ Outer Acceptance RED ➔ Inner Unit RED-GREEN-REFACTOR ➔ Outer GREEN). Zero production code written before tests.
+- [ ] **Tests Green**: 100.00% full-stack test coverage maintained across statement, branch, function, and line metrics (`npm test` / `pnpm test`).
+- [ ] **Boundary Verified**: Cross-package boundary smoke tests passed against live running servers (`scripts/smoke_test.sh`).
+- [ ] **Zero Lints & Types**: 0 ESLint warnings and 0 TypeScript compilation errors (`npm run lint && npm run typecheck`).
+- [ ] **No Unverified Assumptions**: All behavior backed by tests, schema invariants, or verified command evidence.
+- [ ] **ADR Logged**: An Architectural Decision Record is logged in `memory.md` if architectural trade-offs were made.
+- [ ] **Documentation Clean**: Zero broken markdown links across workspace files and relevant knowledge documents updated.
+
+---
+
+## 4. Blocker Escalation & Risk Management
+
+- If a blocker or ambiguity arises, immediately transition the task to `BLOCKED`, halt execution, and interrogate the root cause.
+- Never guess or write speculative code to bypass an unresolved requirement.

package/docs/rules/relentless_questioning.md

@@ -1,48 +1,52 @@
-# Relentless Questioning Loop & Dynamic Interrogation Protocol
-
-> **Core Mandate:** Enforce context-aware, adaptive interrogation of requirements, technical constraints, and failure modes before code authoring, dynamically branching questions based on previous answers to eliminate all hidden assumptions.
-
----
-
-## 1. The Context-Aware Interrogation Lifecycle
-
-Never write speculative code or draft implementation plans based on underspecified user prompts. Every non-trivial feature, database modification, or architectural task must pass through the **4-Stage Relentless Questioning Loop**:
-
-```
-1. CLASSIFY (Detect Archetype) ──► 2. ADAPTIVE BRANCHING (Context Questions) ──► 3. TENSION RECONCILIATION (Rule Conflicts) ──► 4. CONVERGENCE (Signed-Off Spec)
-```
-
-1. **Stage 1: Intent & Archetype Classification**: Analyze the incoming prompt to identify core domains (e.g. Financial/Ledger, Multi-Tenant Mutation, Async/Event-Driven, External Integration, Public API, or Read-Heavy Analytics).
-2. **Stage 2: Context-Aware Adaptive Branching**: Ask targeted questions in digestible batches (2–4 questions per turn). **Question $N+1$ must directly incorporate the answer to Question $N$**, exploring deep technical trade-offs rather than reciting generic checklists.
-3. **Stage 3: Architectural Tension Reconciliation**: If the user's proposed approach violates an existing workspace rule (e.g. dual-writes without an outbox, sparse nullable columns, or missing tenant isolation), immediately highlight the architectural conflict and propose compliant alternatives.
-4. **Stage 4: Convergence & Feature Alignment Specification (FAS)**: Lock down the scope with an unambiguous summary covering Invariants, Negative Scope (Non-Goals), Error Matrix, and Test Verification Strategy.
-
----
-
-## 2. Adaptive Contextual Decision Branches
-
-Questions must dynamically pivot depending on the technical archetype:
-
-### Branch A: State Mutations & Financial Transactions
-*Trigger:* The feature involves balances, orders, payments, inventories, or status transitions.
-- *Adaptive Inquiries:* What isolation level is required (`REPEATABLE READ` vs `SERIALIZABLE`)? What is the idempotency key TTL? In the event of a downstream gateway failure, how is the compensating rollback (Saga) triggered? How is concurrent mutation race condition prevented (Optimistic Concurrency Control vs row lock)?
-
-### Branch B: Multi-Tenancy & Data Boundaries
-*Trigger:* The feature touches tenant-scoped entities or custom fields.
-- *Adaptive Inquiries:* How is the tenant context resolved if accessed via background workers? Which isolation model applies (AST interceptor, database RLS, or schema namespace)? If custom fields are needed, does the tenant's JSON Schema govern validation?
-
-### Branch C: Asynchronous Tasks & Event Streaming
-*Trigger:* The feature processes background jobs, emails, webhooks, or messaging.
-- *Adaptive Inquiries:* Is message delivery at-least-once or exactly-once? How are dual-writes prevented (Transactional Outbox)? How are poison pills and retries handled (Dead-Letter Queue with exponential backoff)?
-
-### Branch D: External Integrations & 3rd-Party APIs
-*Trigger:* The feature interacts with external SaaS, webhooks, or cloud services.
-- *Adaptive Inquiries:* What is the project-owned Port/Adapter boundary interface? What are the rate-limiting and circuit-breaking parameters? How are mock test doubles constructed without mocking third-party types directly?
-
----
-
-## 3. Anti-Assumption Guardrails
-
-- **Zero Implicit Defaults**: If the user does not specify a behavior (e.g. timeout duration, error status code, rollback behavior), treat it as strictly unknown and ask.
-- **Explicit Non-Goals (Negative Scope)**: Every inquiry must establish what the feature will **NOT** do, preventing scope creep and unrequested architectural bloat.
-- **Mandatory User Confirmation**: Never transition from interrogation to code generation without an explicit confirmation from the user on the synthesized alignment specification.
+# Relentless Questioning Loop & Dynamic Interrogation Protocol
+
+> **Core Mandate:** Enforce context-aware, adaptive interrogation of requirements, technical constraints, and failure modes before code authoring, dynamically branching questions based on previous answers to eliminate all hidden assumptions.
+
+---
+
+## 1. The Context-Aware Interrogation Lifecycle
+
+Never write speculative code or draft implementation plans based on underspecified user prompts. Every non-trivial feature, database modification, or architectural task must pass through the **4-Stage Relentless Questioning Loop**:
+
+```
+1. CLASSIFY (Detect Archetype) ──► 2. ADAPTIVE BRANCHING (Context Questions) ──► 3. TENSION RECONCILIATION (Rule Conflicts) ──► 4. CONVERGENCE (Signed-Off Spec)
+```
+
+1. **Stage 1: Intent & Archetype Classification**: Analyze the incoming prompt to identify core domains (e.g. Financial/Ledger, Multi-Tenant Mutation, Async/Event-Driven, External Integration, Public API, or Read-Heavy Analytics).
+2. **Stage 2: Context-Aware Adaptive Branching**: Ask targeted questions in digestible batches (2–4 questions per turn). **Question $N+1$ must directly incorporate the answer to Question $N$**, exploring deep technical trade-offs rather than reciting generic checklists.
+3. **Stage 3: Architectural Tension Reconciliation**: If the user's proposed approach violates an existing workspace rule (e.g. dual-writes without an outbox, sparse nullable columns, or missing tenant isolation), immediately highlight the architectural conflict and propose compliant alternatives.
+4. **Stage 4: Convergence & Feature Alignment Specification (FAS)**: Lock down the scope with an unambiguous summary covering Invariants, Negative Scope (Non-Goals), Error Matrix, and Test Verification Strategy.
+
+---
+
+## 2. Adaptive Contextual Decision Branches
+
+Questions must dynamically pivot depending on the technical archetype:
+
+### Branch A: State Mutations & Financial Transactions
+*Trigger:* The feature involves balances, orders, payments, inventories, or status transitions.
+- *Adaptive Inquiries:* What isolation level is required (`REPEATABLE READ` vs `SERIALIZABLE`)? What is the idempotency key TTL? In the event of a downstream gateway failure, how is the compensating rollback (Saga) triggered? How is concurrent mutation race condition prevented (Optimistic Concurrency Control vs row lock)?
+
+### Branch B: Multi-Tenancy & Data Boundaries
+*Trigger:* The feature touches tenant-scoped entities or custom fields.
+- *Adaptive Inquiries:* How is the tenant context resolved if accessed via background workers? Which isolation model applies (AST interceptor, database RLS, or schema namespace)? If custom fields are needed, does the tenant's JSON Schema govern validation?
+
+### Branch C: Asynchronous Tasks & Event Streaming
+*Trigger:* The feature processes background jobs, emails, webhooks, or messaging.
+- *Adaptive Inquiries:* Is message delivery at-least-once or exactly-once? How are dual-writes prevented (Transactional Outbox)? How are poison pills and retries handled (Dead-Letter Queue with exponential backoff)?
+
+### Branch D: External Integrations & 3rd-Party APIs
+*Trigger:* The feature interacts with external SaaS, webhooks, or cloud services.
+- *Adaptive Inquiries:* What is the project-owned Port/Adapter boundary interface? What are the rate-limiting and circuit-breaking parameters? How are mock test doubles constructed without mocking third-party types directly?
+
+### Branch E: User Interface, Experience Duality & Interaction Flows
+*Trigger:* The feature introduces or modifies user interfaces, web pages, screen layouts, form mutations, or navigation.
+- *Adaptive Inquiries:* Who is the target user persona (Operator/Admin dense workspace vs Consumer/Member portal)? How does the view fit into the Persistent App Shell (collapsible sidebar, global header) vs Dynamic Canvas? What is the URL state synchronization strategy (`useSearchParams` for `?tab=`, `?q=`, `?page=`, `?modal=`)? What server-state cache manager synchronizes data (TanStack Query)? How are validation feedback and errors displayed (RFC 7807 inline/toast alerts, WCAG 2.2 live regions, zero native `window.alert()`)?
+
+---
+
+## 3. Anti-Assumption Guardrails
+
+- **Zero Implicit Defaults**: If the user does not specify a behavior (e.g. timeout duration, error status code, rollback behavior), treat it as strictly unknown and ask.
+- **Explicit Non-Goals (Negative Scope)**: Every inquiry must establish what the feature will **NOT** do, preventing scope creep and unrequested architectural bloat.
+- **Mandatory User Confirmation**: Never transition from interrogation to code generation without an explicit confirmation from the user on the synthesized alignment specification.