fix(skills): recover interrupted RPI critiques without bypassing readiness gates

.github/agents/hve-core/rpi-agent.agent.md

@@ -46,7 +46,7 @@ Coordinate a resumable RPI session through Research, Plan, Implement, Review, an
 * Progression and decision participation follow confirmed direction. Manual phases wait for explicit advancement; automatic sessions resume the recorded phase and continue within their persisted boundary without routine approvals.
 * A stop before Implementation completes Plan gates, returns to manual Plan, and walks the user through the research and plan. Research and Planning can be refined here; Implementation waits for an explicit request.
 * State transitions are durably recorded, task completion remains distinct from session completion, and canonical artifacts govern recovery.
-* Each task uses at most one final-candidate critique and one post-implementation Review. Required gates, unresolved evidence, safety confirmations, and human review cannot be bypassed by starting a child task.
+* Each task uses one initial final-candidate critique, with only the single user-confirmed interruption recovery owned by `rpi-plan`, and one post-implementation Review. Terminal critique results are not retried. Required gates, unresolved evidence, safety confirmations, and human review cannot be bypassed by starting a child task.
 * Phase skills own their canonical evidence and gates; the agent preserves their state and artifact pointers across transitions.
 * Follow-ups stay current and evidence-grounded across parent and child tasks. Through-Review automatic sessions select required in-scope work until acceptance criteria are met, honoring retained selection and stopping without manufacturing optional work.
 * Phase-aware updates and closeout identify current status, evidence, blockers, and the eligible next action using the Response contract.
@@ -116,7 +116,7 @@ Store preferences and gate state in `confirmed_decisions` without adding schema
 
 ### One-pass gate records
 
-* Use one `Planning critique execution` entry for the parent-state reservation required by `rpi-plan`: status `started` before dispatch, with critique path, depth, and candidate identity. Update it with execution, verdict, dispositions, and unresolved decisions after return. Let `rpi-plan` reconcile consumed invocations and original finding closure; do not create a second agent-owned critique procedure.
+* Keep one `Planning critique execution` entry for `rpi-plan` reservations, with `started` before dispatch and evidence containing task, attempt ID/kind, candidate identity/hash boundary, depth, output and current-dispatch provenance. Preserve the original and any recovery pointers and explicit consent in that entry; do not reset it. Update execution, verdict and dispositions from saved evidence. `rpi-plan` owns current-worker admission, terminal-result reconciliation and its single confirmed interruption recovery; the agent does not duplicate or widen that procedure.
 * Before a Review record exists, store `Review decision preference` as `agent-owned` or `user-retained` with provenance. Pass `user-owned` directly in manual mode. At Review initialization, perform the successful preference-to-pointer state write required by `rpi-review` before continuing.
 * Store one `Review decision record` entry with status `current` and evidence containing the review path, latest Parent Decision Record event ID, and content revision or hash. `rpi-review` owns reservation, append-only decisions, and recovery semantics; do not duplicate execution, outcome, walkthrough, or route payloads in state.
 * Mirror only derived active routing in `next_action` and accepted follow-up work in `prioritized_follow_ups`. Read the canonical Parent Decision Record before rebuilding stale projections; persist the corrected state before transitioning. Use its latest participation event instead of a stale pre-record preference.
@@ -134,7 +134,7 @@ If the resulting-state write fails, stop before dispatching destination work or
 
 * In manual mode, do not infer phase advancement from apparent completion. Continue the active phase until the user explicitly requests the next phase or invokes its canonical skill.
 * Honor `before-implementation` before any automatic transition to Implement, including recovery with a pending Implement `next_action`. Complete applicable Plan gates, then use the state transition protocol to set `mode` to `manual`, `session_status` to `stopped`, `active_phase` to `Plan`, and task `status` to `active`. Set `next_action` to await an explicit `/rpi-implement` request. Do not activate Implement or mark the task completed. A generic resume does not authorize Implementation.
-* At the stop before Implementation, present the research and plan links and explain the proposed approach, trade-offs, open questions, and readiness. Use `askQuestions` to offer refining Research, refining the Plan, staying paused, or explicitly starting eligible Implementation. Iteration preserves task identity, the Implementation boundary, and consumed gates; do not rerun the planning critique.
+* At the stop before Implementation, present the research and plan links and explain the proposed approach, trade-offs, open questions, and readiness. Use `askQuestions` to offer refining Research, refining the Plan, staying paused, or explicitly starting eligible Implementation. Iteration preserves task identity, the Implementation boundary, and consumed gates; it does not authorize another critique. An interrupted started-only attempt remains in Plan for `rpi-plan` recovery eligibility and task-specific consent, never automatic gate clearance.
 * Automatic progression does not require routine phase-start, phase-advancement, or plan-approval prompts. Retained material decisions use the phase skill's walkthrough without switching the session to manual mode. An unresolved evidence gap remains a blocker, not a request for the user to invent facts.
 * Request exceptional confirmation before a concrete destructive, hard-to-reverse, shared-system, or externally visible action when repository or platform safety rules require it. If confirmation is unavailable or declined, record a blocker and stop the affected action or phase. Automatic authorization is not consent for these actions.
 * Leave required human-review checkboxes unchecked and treat incomplete human review as a blocker or next action rather than completed approval.

.github/skills/rpi/rpi-plan-critique/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: rpi-plan-critique
-description: "Independently critique an RPI implementation plan once against supplied evidence without editing the plan. Use when planning credibility needs a read-only assessment."
+description: "Independently assess an RPI plan against supplied evidence without editing it. Use for a current initial or planner-authorized recovery critique dispatch."
 argument-hint: "[plan=...] [evidence=...] [output=...] [depth={standard|deep}]"
 license: MIT
 user-invocable: true
@@ -15,9 +15,18 @@ Return one substantive, evidence-grounded credibility assessment of an RPI imple
 ## Flow
 
 1. Confirm the exact task identity, plan, evidence, requirements, decisions, dependencies, task Requirements, critique output path, and critique depth supplied by the caller. Use `standard` when depth is omitted. Use `deep` only when the caller records explicit user direction; otherwise downgrade an unsupported deep request to standard and record the limitation.
-2. Before assessment, inspect the plan's Critique Disposition, supplied parent state when available, and critique output path for the same task. A prior `started`, `Complete`, `Partial`, or `Blocked` execution record or existing critique artifact means the invocation was consumed. Return the existing execution status, verdict or limitation, path, depth, and provenance to the caller without writing or reassessing. When task identity cannot establish whether existing evidence belongs to this task, return Blocked rather than risking a second invocation.
+2. Before assessment, inspect Critique Disposition, supplied parent state and recorded output paths for this task. Standalone first use follows the local preflight below and does not require the `rpi-plan` skill or its files.
+   * Return any prior terminal `Complete`, `Partial`, or `Blocked` execution and its verdict or limitation without reassessing, even when its file is missing. Ambiguous task identity blocks assessment.
+    * For a parent dispatch, read the Reservation and current-dispatch ownership and Interrupted critique recovery contracts from the planning parent's resolved canonical reference pointer. When no pointer is supplied, locate the available skill by its stable name `rpi-plan` and read `references/planning.md` relative to that skill's resolved root, not an assumed sibling directory.
+       If the reference cannot be resolved or read, return a missing-dependency preflight limitation to the parent without assessment, reservation changes or standalone fallback. Reading the contract does not authorize the worker to run its recovery procedure.
+   * For a parent dispatch, verify task, attempt ID/kind, candidate identity/hash boundary, depth, output and immediate current-dispatch provenance against the saved reservation. That worker may execute its own initial or approved recovery reservation once. Saved matching identifiers alone cannot authorize a replay; earlier `started` records route to the planning parent's recovery protocol without a new assessment.
+   * A recovery worker also verifies the saved task-specific approval, original-attempt provenance and distinct output. It cannot authorize recovery, reset its reservation or request another attempt. Any failure returns the preflight limitation; it does not claim a substantive assessment ran or overwrite an existing result.
+    * For standalone use with no consumed attempt, persist an initial `started` reservation in the specified output with task, unique attempt ID/kind, candidate identity and saved-content hash boundary, depth, output and uninterrupted reservation-to-assessment provenance before assessing. If it cannot be saved and read back, stop.
+       Existing standalone reservations route to the planning parent for reconciliation, not another standalone invocation. If `rpi-plan` is unavailable for that reconciliation, return the dependency limitation and preserve the existing evidence; do not reserve or reassess.
 3. Read the plan and directly relevant supplied evidence. Do not perform open-ended research, browse for additional concerns, or infer missing evidence as fact.
 4. Define the supplied inputs and criterion boundary, then assess the full boundary once across requirements, research, phase and task Goals, task Requirements, Details, References, dependencies, decisions, risks, and missed concerns.
+   * Assess coverage across the supplied plan and evidence as a whole. Do not require a task to repeat requirements already established elsewhere solely for restatement. A stated requirement alone does not prove implementation coverage; ground required changes in demonstrated omissions, contradictions, or material evidence gaps.
+   * Treat missing detail in an abbreviated task or excerpt as a limitation of the supplied evidence, not proof that the full plan omits it. Identify the evidence needed to resolve a decision-critical uncertainty; do not turn the same uncertainty into a separate requirement-restatement finding.
    * In `standard`, assess the complete supplied boundary while prioritizing implementation blockers, contradictions, missing dependencies or acceptance coverage, unsupported scope or architecture, and material risks. Follow direct evidence and omit plan restatement, cosmetic feedback, exhaustive strengths, and low-impact suggestions so the complete evidence-supported actionable set is recorded with minimal elapsed work.
    * In `deep`, trace supplied evidence more broadly, stress-test alternatives and boundaries, and include substantive lower-severity concerns. Deep remains one assessment and does not widen research authority.
    * In either depth, return one complete finding set rather than serializing findings across critique passes.
@@ -31,19 +40,20 @@ Return one substantive, evidence-grounded credibility assessment of an RPI imple
 * Supplied research, evidence pointers, draft details, and decisions
 * Dependencies and task Requirements
 * One critique output path
+* For parent dispatch: current attempt ID/kind, reservation and dispatch provenance, candidate hash boundary, parent state when present, the parent's resolved canonical planning reference pointer or discoverable `rpi-plan` skill, and task-specific recovery approval when applicable
 * Critique depth and provenance: `standard` by default or `deep` from explicit user direction
 
 ## Success criteria
 
 * The critique distinguishes evidence-backed concerns from missing evidence.
 * Critique depth and provenance are recorded. Standard completely assesses the material supplied boundary while minimizing low-value work; deep occurs only from explicit user direction.
-* Re-entry preflight returns existing same-task critique evidence without writing or reassessing and blocks when task identity cannot safely distinguish it.
+* Preflight admits the verified current initial or approved recovery worker, but returns prior same-task evidence without reassessment on replay and blocks ambiguous identity or dispatch provenance. Standalone first use reserves before assessment without requiring another skill; missing parent-dispatch guidance never permits standalone fallback.
 * Findings identify substantive gaps rather than structure, formatting, or cosmetic preferences.
 * The critique records its inputs, criterion boundary, coverage assessment, and limitations.
 * Each actionable finding has a severity, related IDs, evidence, impact, and smallest useful change.
 * Each actionable finding identifies its action owner, exact resolving evidence, and whether it is a direct correction or requires a significant or divergent user decision.
 * The critique returns one complete actionable finding set for the supplied boundary; cosmetic preferences and separately withheld late findings do not create serial passes.
-* The invocation is terminal for its task: Complete, Partial, or Blocked consumes the one critique slot, and no retry or closure critique is requested.
+* Complete, Partial, or Blocked consumes the assessment regardless of verdict; no terminal result is retried and no closure critique is requested. Only the planning parent may authorize the single started-only interruption recovery defined in its reference.
 * The closeout identifies the highest-impact finding, action owner, smallest next action, and whether a user response is required.
 * The plan remains unchanged.
 

.github/skills/rpi/rpi-plan-critique/templates/plan-critique.md

@@ -10,6 +10,10 @@
 * Critique depth: {{standard_or_deep}}
 * Depth provenance: {{default_or_explicit_user_request}}
 * Invocation consumed: yes
+* Attempt ID and kind: {{unique_attempt_id_and_initial_or_recovery}}
+* Candidate identity and saved hash boundary: {{revision_hash_and_reservation_metadata_boundary}}
+* Current-dispatch provenance: {{immediate_parent_dispatch_or_standalone_initial_reservation}}
+* Original attempt and recovery approval: {{not_applicable_or_original_pointer_and_task_specific_consent}}
 
 ## Inputs and Criterion Boundary