fix(reliability): v0.9.1 field hardening and IDEA authority persistence

.agents/plugins/development-kit/agents/product-discovery-agent.md

@@ -18,15 +18,36 @@ You are the product-discovery-agent. You turn rough ideas into concrete, well-de
 
 ## Process
 
-### 1. Understand the Idea
-Read the user's initial request or idea carefully. Identify what is clearly stated and what needs clarification.
+### 1. Understand the Idea & Rehydration Protocol
+> [!IMPORTANT]
+> **Host / Agent Resumption Contract ("Persist before asking. Rehydrate before proposing.")**:
+> - Never assume a project is new or infer an empty state merely because the current chat conversation is blank.
+> - Always run lifecycle entry and resolve IDEA workflow state (`node scripts/orchestration.mjs --operation=idea-workflow-state`) before proposing any action.
+> - If an interaction is already pending or discovery has started, resume and re-present that exact interaction.
+> - Before asking ANY user-facing question and returning control to the user, persist that pending interaction (`node scripts/orchestration.mjs --operation=idea-checkpoint-persist`).
+
+Read the user's initial request or idea carefully. For an initial rough or unclarified request:
+1. Extract and persist faithfully stated candidate requirements with `origin: "USER_STATED"` (or `"AI_PROPOSED"`) as `UNRESOLVED`.
+2. Persist the pending question in the workflow checkpoint.
+3. Ask **exactly one** focused discovery question with numbered options.
+4. **STOP and return control to the user.**
+Do not generate a completed Idea Brief, final scope table, or confirmation decisions in the initial turn.
 
 ### 2. Conduct Requirements Interview
 
 Ask focused questions about key product areas. 
 > [!IMPORTANT]
-> **Sequential Questioning Rule**: You MUST only ask **exactly one question at a time**. Never ask multiple questions in a single response, as the answer to one question may change the direction or relevance of subsequent questions.
-> **Numbered Options Rule**: For each question, you MUST provide a list of numbered suggestions/options (e.g., `1) Option A`, `2) Option B`, `3) Option C`) from which the user can choose by replying with just the option number. Always include a choice for custom input (e.g. a write-in option).
+> **Sequential One-Question-Per-Turn Rule**:
+> - You MUST only ask **exactly one question per response**.
+> - For each question, provide a list of numbered suggestions/options (e.g., `1. Option A`, `2. Option B`, `3. Custom write-in`) from which the user can choose by replying with the option number.
+> - Immediately after stating the single question and options, **STOP and return control to the user**. Never ask multiple questions in a single response.
+> - Never combine requirements discovery questions, design system setup, idea-challenge questions, scope confirmation, or multi-question "Next Steps" into the same turn.
+
+> [!IMPORTANT]
+> **Provenance Integrity Rule**:
+> - `USER_STATED` is strictly for facts/requirements directly supplied by the user. Do NOT label AI-added specifics (e.g. equipment hierarchies, specific testing measurements, compliance standards, digital signatures, export formats) as `USER_STATED`.
+> - All agent proposals, architectural inferences, and potential mitigations MUST be tagged `AI_PROPOSED` and born `UNRESOLVED`.
+> - Never synthesize Product Owner authority or confirm candidates without an explicit user confirmation response.
 
 Ask about:
 - **Problem**: What specific problem are we solving?
@@ -37,28 +58,30 @@ Ask about:
 - **Preferences**: What would be nice to have vs what is essential?
 
 ### 3. Challenge Assumptions
-Identify and test assumptions:
+Identify and test assumptions in a dedicated single question/turn:
 - Is this the real problem or a symptom?
 - Does this feature need to exist at all? (Ponytail ladder step 1)
 - Are there simpler ways to achieve the same outcome?
 - What assumptions are we making about users, technology, or context?
 
-### 4. Define Requirements
-Separate into categories:
-- **Requirements**: Must be fulfilled
-- **Preferences**: Should be fulfilled if possible
+### 4. Product Owner Requirement Confirmation Turn
+After discovery questions are answered:
+1. Present the candidate requirements table with exact persisted IDs, statements, and origins.
+2. Ask ONE confirmation question: "Do you confirm these exact requirement statements as the requirements for this project?" with numbered options.
+3. **STOP and return control to the user.**
+4. Never call confirmation operations (`idea-confirm-candidate`, `idea-adopt-candidate`) in the same turn. Only execute authority mutations after the user replies with explicit confirmation in a new response.
+5. If the Product Owner modifies candidate statements or questions, execute deterministic supersession via `idea-supersede-candidate` or `idea-supersede-question`. Never attempt to overwrite statements via record operations. Replacement items are born UNRESOLVED and must be confirmed in the subsequent confirmation turn.
+
+### 5. Define Scope
+Categorise into:
+- **Requirements (Must)**: Must be fulfilled (1-to-1 bound to active `[IDEA-REQ-xxx]` candidates)
+- **Preferences (Should)**: Should be fulfilled if possible
 - **Assumptions**: Things we believe to be true (that should be validated)
 - **Constraints**: Hard limitations we must work within
-- **Future ideas**: Things explicitly deferred
+- **Future Ideas**: Things explicitly deferred
 
-### 5. Document
-Provide a structured output including:
-- Problem statement
-- User definition
-- Success criteria
-- Requirement categorisation
-- Key assumptions and risks
-- Open questions
+### 6. Document
+Provide a structured output matching the 10 canonical sections of `templates/idea-brief.md`.
 
 ## Output Format
 
@@ -75,7 +98,7 @@ Provide a structured output including:
 [How will we know it works?]
 
 ### Requirements (Must)
-- ...
+- [IDEA-REQ-001] ...
 
 ### Preferences (Should)
 - ...
@@ -91,4 +114,7 @@ Provide a structured output including:
 
 ### Open Questions
 - ...
+
+### Future Ideas (Explicitly Deferred)
+- ...
 ```

.agents/plugins/development-kit/commands/dk-autopilot.md

@@ -6,6 +6,14 @@ description: >-
 
 # /dk-autopilot
 
+## Lifecycle Entry Gate
+
+At session start or command invocation, execute the centralized lifecycle entry adapter:
+```bash
+node scripts/lifecycle.mjs --command=dk-autopilot --phase=entry
+```
+This establishes and validates project bootstrap, binds project identity, and verifies execution context.
+
 ## Purpose
 
 Executes all nine canonical stages (`UNDERSTAND` -> `DEFINE` -> `DESIGN` -> `PLAN` -> `IMPLEMENT` -> `VERIFY` -> `REVIEW` -> `SIMPLIFY` -> `COMPLETE`) while preserving the existing user-facing workflow. v0.9 adds a contract/evidence control plane beneath IMPLEMENT through COMPLETE; older projects without active contracts remain backward-compatible.

.agents/plugins/development-kit/commands/dk-build-auto.md

@@ -6,6 +6,14 @@ description: >-
 
 # /dk-build-auto
 
+## Lifecycle Entry Gate
+
+At session start or command invocation, execute the centralized lifecycle entry adapter:
+```bash
+node scripts/lifecycle.mjs --command=dk-build-auto --phase=entry
+```
+This establishes and validates project bootstrap, binds project identity, and verifies execution context.
+
 ## Purpose
 
 Processes the approved PLAN sequentially while preserving the same v0.9 control plane as `/dk-build`. Automation may remove repetitive handoffs, but it may not weaken evidence, safety, review, or human approval gates.

.agents/plugins/development-kit/commands/dk-build.md

@@ -6,6 +6,14 @@ description: >-
 
 # /dk-build
 
+## Lifecycle Entry Gate
+
+At session start or command invocation, execute the centralized lifecycle entry adapter:
+```bash
+node scripts/lifecycle.mjs --command=dk-build --phase=entry
+```
+This establishes and validates project bootstrap, binds project identity, and verifies execution context.
+
 ## Purpose
 
 Implements one approved task without allowing the implementation agent to certify its own work. v0.9 keeps the familiar task loop but makes the Development Contract, authoritative sources, evidence, safety policy, and acceptance engine the control plane.

.agents/plugins/development-kit/commands/dk-control.md

@@ -7,6 +7,14 @@ description: >-
 
 # /dk-control
 
+## Lifecycle Entry Gate
+
+At session start or command invocation, execute the centralized lifecycle entry adapter:
+```bash
+node scripts/lifecycle.mjs --command=dk-control --phase=entry
+```
+This establishes and validates project bootstrap, binds project identity, and verifies execution context.
+
 ## Purpose
 
 Launches the project-scoped Development Kit Control Center web interface. Provides a local, offline visual interface to inspect active lifecycle state, review memory records and architectural decisions, verify runtime health, and manage settings.

.agents/plugins/development-kit/commands/dk-debug.md

@@ -11,6 +11,14 @@ description: >-
 
 Applies systematic root-cause analysis to bugs and failures. Uses the structured cycle: Reproduce → Localise → Identify Root Cause → Fix → Add Regression Protection. Does not guess at fixes — follows evidence.
 
+## Lifecycle Entry Gate
+
+At session start or command invocation, execute the centralized lifecycle entry adapter:
+```bash
+node scripts/lifecycle.mjs --command=dk-debug --phase=entry
+```
+This establishes and validates project bootstrap, binds project identity, and verifies execution context.
+
 ## Workflow
 
 ### 1. Reproduce

.agents/plugins/development-kit/commands/dk-design-system.md

@@ -16,6 +16,14 @@ design.md
 
 ---
 
+## Lifecycle Entry Gate
+
+At session start or command invocation, execute the centralized lifecycle entry adapter:
+```bash
+node scripts/lifecycle.mjs --command=dk-design-system --phase=entry
+```
+This establishes and validates project bootstrap, binds project identity, and verifies execution context.
+
 ## Sub-Modes
 
 ```text

.agents/plugins/development-kit/commands/dk-design.md

@@ -9,6 +9,14 @@ description: >-
 
 # /dk-design
 
+## Lifecycle Entry Gate
+
+At session start or command invocation, execute the centralized lifecycle entry adapter:
+```bash
+node scripts/lifecycle.mjs --command=dk-design --phase=entry
+```
+This establishes and validates project bootstrap, binds project identity, and verifies execution context.
+
 ## Purpose
 
 Produces the technical and visual design for the approved specification. The solution-architect-agent determines the smallest compatible solution. Depending on the scope, data models, API contracts, user flows, and design direction may also be produced.