dev-flow-codex 0.3.0 → 0.4.0

package/plugin/skills/dev-flow/references/method-profiles.md

@@ -0,0 +1,153 @@
+# Codex Method Profile Rendering Reference
+
+This is the closed Codex Host-rendering reference for Core Contract 0.2 semantic method steps. Read
+it only after Core returns a complete current Action. It explains how Codex may perform the work; it
+is not a process definition or a second task cursor.
+
+## Authority boundary
+
+Core owns task and process identity, the current node and Action, node obligations, semantic step
+IDs and order, legal transitions and guards, problem-class validation, destination, evidence
+validity, recovery, blockers, and terminal outcome. The Adapter owns capability visibility checks,
+rendered instructions, expected artifact descriptions, plain-equivalent work, and honest bounded
+method evidence.
+
+The Adapter must not derive or select a transition or destination outside the complete current
+Action. A command result, artifact checkbox, proposal status, verification status, or archive status
+does not advance or mutate Core. Only a valid Core apply using one returned transition can do that.
+The Adapter keeps no independent current node, baseline, profile cursor, or completion state.
+
+## Profiles and rendered operation
+
+The immutable task profile is exactly one of `plain`, `spec-kit`, or `openspec`. `plain` uses no
+external method capability. The other profiles map only capabilities actually visible in the
+current Host; listing a capability here does not prove that it is installed.
+
+Present each Core-returned step with this closed shape:
+
+<!-- rendered-operation-example:start -->
+```json
+{
+  "step_id": "requirements.clarify",
+  "purpose": "Resolve material requirement ambiguity.",
+  "required": true,
+  "profile": "spec-kit",
+  "capability_id": "speckit-clarify",
+  "rendered_instruction": "Use the installed Spec Kit clarify capability for the active feature.",
+  "expected_artifacts": ["active feature specification clarification"],
+  "availability": "available"
+}
+```
+<!-- rendered-operation-example:end -->
+
+`availability` is closed and ordered as:
+
+```text
+available
+unavailable
+not_applicable
+unknown
+```
+
+This shape is presentation and admission guidance only. It is never persisted as Core task state.
+
+## Semantic step rendering catalog
+
+Capability cells name preferred stable capability IDs. A slash-command spelling is not part of the
+contract. “Direct” means the profile has no mandatory external capability for that step; render
+`not_applicable` and perform the listed plain-equivalent work. Conditional capabilities are rendered
+only when actually visible and appropriate to the current authorized artifacts.
+
+<!-- semantic-step-table:start -->
+| Step ID | Developer-readable purpose | Plain-equivalent work | Spec Kit capability guidance | OpenSpec capability guidance | Expected artifacts or result |
+| --- | --- | --- | --- | --- | --- |
+| `requirements.capture` | Capture a bounded goal, scope, exclusions, acceptance criteria, constraints, and assumptions. | Write or revise those bounded requirements. | `speckit-specify` only when no prepared feature exists; otherwise review and revise the current specification. | Use visible `openspec-explore` when intent is unclear, then visible `openspec-propose` when a proposal is needed. | Current requirements specification or proposal/delta specification. |
+| `requirements.clarify` | Resolve material requirement questions with the developer. | Ask only material questions and record the answers. | `speckit-clarify`. | Direct proposal/specification revision; visible `openspec-explore` may support exploration. | Recorded material clarifications. |
+| `requirements.validate` | Verify that requirements are observable, bounded, and free of material ambiguity. | Review acceptance and confirm that no material question remains. | `speckit-checklist` or direct checklist review. | `openspec-validate` plus human review. | Requirements-quality review or structurally valid current change. |
+| `design.choose_approach` | Select the simplest viable approach for the current requirements. | Choose a direct bounded design. | `speckit-plan`. | Revise the proposal/design through visible `openspec-propose`. | Current design artifact. |
+| `design.review_complexity` | Identify unnecessary abstractions and justify retained complexity. | Review the design and justify every retained abstraction. | `speckit-plan` plus direct design review. | Direct review; visible `openspec-explore` may support comparison. | Complexity rationale and rejected alternatives. |
+| `design.record_decisions` | Record components, decisions, rejected alternatives, and risks. | Record the current decisions and affected components. | `speckit-plan` artifact updates. | Update the proposal/design through visible `openspec-propose`. | Current decisions, risks, and design references. |
+| `tasks.decompose` | Decompose the current design into bounded, ordered work items. | Create bounded items with dependencies and expected paths. | `speckit-tasks`. | Revise proposal task artifacts through visible `openspec-propose`. | Current bounded task plan. |
+| `tasks.map_acceptance` | Map every current acceptance criterion to work and verification. | Record acceptance-to-work and verification traceability. | `speckit-tasks`. | Review delta specifications and tasks through visible `openspec-propose`. | Acceptance traceability. |
+| `tasks.analyze_consistency` | Check requirements, design, and tasks for gaps or contradictions. | Perform a direct cross-artifact consistency review. | `speckit-analyze`. | `openspec-validate` plus direct consistency review. | No unresolved blocking consistency gap, or exact findings. |
+| `implementation.execute_plan` | Execute only the work authorized by the current task plan. | Implement the current authorized slice. | `speckit-implement`. | `openspec-apply`. | Implemented current work slice. |
+| `implementation.record_surface` | Record exact changed paths or the no-change state and deviations. | Observe and record the exact changed surface. | Direct implementation result; no mandatory capability. | Direct apply result; no mandatory capability. | Changed paths or explicit no-change result. |
+| `implementation.classify_deviations` | Classify deviations as requirement, design, or complexity concerns. | Record the exact concern and route it through Core facts. | Direct classification; amend active artifacts before continuing when semantics change. | Direct classification and current change-artifact update. | Exact deviations and findings. |
+| `test.run_budgeted_checks` | Run only verification authorized by the current verification budget. | Run the current bounded verification steps. | Direct plan-defined checks; no mandatory Spec Kit capability. | Use `openspec-verify` only when visible; otherwise run plan-defined checks. | Actual current verification result. |
+| `test.record_evidence` | Record actual evidence sources, outcomes, and unverified or manual items. | Record actual sources and statuses without relabeling. | Direct evidence recording; no mandatory capability. | Direct evidence recording; no mandatory capability. | Current bounded evidence summary. |
+| `test.classify_failure` | Classify failures as implementation, design, or requirement problems. | Classify current failures from observed facts. | Direct classification; no mandatory capability. | Direct classification; no mandatory capability. | Exact failure class and findings. |
+| `comprehension.explain` | Explain current behavior, design, and code paths in developer-readable terms. | Present a bounded explanation to the developer. | Direct review; no Spec Kit command owns the verdict. | Direct review; no OpenSpec command owns the verdict. | Developer-readable explanation. |
+| `comprehension.identify_complexity` | Identify unnecessary abstractions and maintenance risks. | List concrete complexity and maintenance concerns. | Direct review; no mandatory capability. | Direct review; no mandatory capability. | Exact abstraction and risk findings. |
+| `comprehension.obtain_user_verdict` | Obtain the developer's explicit understanding or remediation verdict. | Ask the developer and wait for an explicit answer. | Direct user interaction; no Spec Kit capability can answer. | Direct user interaction; no OpenSpec capability can answer. | Explicit current user verdict. |
+| `refactor.simplify` | Remove unnecessary complexity within the approved behavior boundary. | Perform the bounded simplification. | `speckit-implement` only after affected artifacts and tasks are current. | Update change artifacts as needed, then use visible `openspec-apply`. | Bounded simplification. |
+| `refactor.reconcile_artifacts` | Reconcile affected process artifacts with the simplification. | Amend only artifacts affected by the simplification. | Use visible `speckit-clarify`, `speckit-plan`, `speckit-tasks`, or `speckit-analyze` only as needed. | Revise proposal/design/spec/task artifacts through visible `openspec-propose` as needed. | Current affected artifacts. |
+| `refactor.record_surface` | Record exact simplifications and the changed surface. | Record simplifications and exact changed paths. | Direct refactor result; no mandatory capability. | Direct apply result; no mandatory capability. | Refactor summary and changed surface. |
+| `delivery.reconcile_acceptance` | Map the latest acceptance criteria to current test and comprehension evidence. | Reconcile every current criterion with current evidence. | `speckit-analyze` or direct final consistency review. | Use visible `openspec-verify` and/or `openspec-validate` as appropriate. | Current acceptance/evidence mapping. |
+| `delivery.reconcile_method_artifacts` | Reconcile method artifacts with delivered behavior. | Ensure current process artifacts describe the delivered behavior. | Direct status reconciliation; `speckit-converge` may be used only when available and appropriate. | Use visible `openspec-sync` and/or `openspec-archive` only when appropriate. | Current reconciled or archived change artifacts. |
+| `delivery.prepare_summary` | Prepare a bounded delivery summary and remaining risks. | Write the final bounded summary and risks. | Direct summary; no mandatory capability. | Direct summary; no mandatory capability. | Delivery summary and remaining risks. |
+<!-- semantic-step-table:end -->
+
+The recognized Spec Kit capability IDs are `speckit-specify`, `speckit-clarify`, `speckit-plan`,
+`speckit-checklist`, `speckit-tasks`, `speckit-analyze`, and `speckit-implement`.
+`speckit-converge` is an optional repository capability and is never a Core required step.
+
+The recognized OpenSpec capability IDs are `openspec-explore`, `openspec-propose`, `openspec-apply`,
+`openspec-verify`, `openspec-sync`, `openspec-archive`, and `openspec-validate`. Some integrations do
+not expose verify, sync, or archive. Render only a capability actually visible to the Host. The
+presence of an ID in this reference does not prove installation, and OpenSpec installation or
+initialization is never automatic Core behavior.
+
+## Availability and fallback
+
+For each step returned by Core:
+
+1. Check only the Host's actual capability surface.
+2. When the preferred capability is visible and appropriate, render its exact ID and expected result.
+3. When visibility is absent or cannot be confirmed, report `unavailable` or `unknown` honestly.
+4. Always show the catalog's plain-equivalent work.
+5. Do not automatically install a tool, silently run another tool, or treat invocation as completion.
+6. Record completion only after the semantic work actually completes.
+
+For `plain`, render external capability availability as `not_applicable`. When the ordinary work
+actually completes, evidence uses `status="plain_fallback"` and an empty `capability`; plain work is
+never labeled as an external capability completion. The same `plain_fallback` rule applies when a
+selected external capability is unavailable but the equivalent work actually completes.
+
+When equivalent work remains incomplete, record `unavailable` or `not_run` honestly. Neither status
+can satisfy a required semantic step, so the Adapter must not call apply for that Action.
+
+## MethodEvidence
+
+A normal mutation supplies exactly one `MethodEvidence` item for every current Action method step,
+in Action order. Each item contains only `step_id`, `status`, `capability`, and `summary`.
+
+- `completed` requires the non-empty ID of the actual capability that completed the work.
+- `plain_fallback` requires an empty `capability` and completed plain-equivalent work.
+- `unavailable` and `not_run` do not satisfy a required step.
+- Unknown, duplicate, previous-node, reordered, or omitted steps are invalid.
+- Capability output cannot substitute for the typed `node_result` or any current Core evidence gate.
+
+## Artifact references
+
+Submit artifact evidence only as `role`, repository-relative `path`, `digest`, and `summary`. Refer
+only to a file actually observed by the Host. Never submit full contents, command output, prompts,
+token data, runtime configuration, or private locations. An artifact digest does not replace the
+repository binding. File existence, checkboxes, validation, sync, or archive status never advances
+Core by itself.
+
+For Spec Kit, determine the exact active Feature from explicit repository context. Never infer it
+only from the branch name. Existing specification, design, and task artifacts should be reviewed and
+amended intentionally; step names do not require rerunning specify, plan, or tasks. Checklist marks
+are reviewer evidence, not implementation progress. Analyze findings become typed node facts, and
+implement work produces repository changes, but neither selects a Core transition.
+
+For OpenSpec, propose, apply, verify, sync, and archive results remain method evidence only. Archive
+cannot replace DELIVERY acceptance, current test, comprehension, or evidence gates.
+
+## Comprehension verdict
+
+All profiles present a bounded requirements/design/code-path explanation, list unnecessary
+abstractions and maintenance risks, ask whether the developer can explain and maintain the result,
+and wait for an explicit user verdict. No AI statement or Spec Kit/OpenSpec capability may provide
+that confirmation. The Adapter then considers only the matching transition that Core returned; Core
+still validates the typed result and derives the destination.

package/plugin/skills/dev-flow/references/node-payloads.md

@@ -0,0 +1,305 @@
+# Core Contract 0.2 Node Payload Construction
+
+This reference helps the Codex Adapter construct the one closed payload branch returned by the
+current Core Action. It is not a process definition, transition table, cursor, or authority. The
+fresh Action, the live `dev_flow_apply_action` `inputSchema`, and Core validation remain authoritative.
+
+## Construction rules
+
+Before every ordinary apply:
+
+1. Bind one complete fresh Action and read `action_kind`, `current_node`, `payload_contract`,
+   `method_steps`, and every `available_transition`.
+2. Select only a transition returned by that Action. Never submit `destination`, `next_node`,
+   `next_cursor`, resume node, guard result, or caller classification.
+3. Select the matching `dev_flow_apply_action` `inputSchema` branch and use exactly the six common
+   payload members: `transition_id`, `summary`, `reason`, `artifacts`, `method_evidence`, and
+   `node_result`.
+4. `required_evidence` and `artifacts` are different concepts. `repository_observation` is a Core evidence requirement, not an ArtifactReference role. When no real repository-relative process
+   artifact exists, submit `"artifacts": []`.
+5. Allowed ArtifactReference roles are only `requirements`, `design`, `task_plan`,
+   `implementation`, `test`, `comprehension`, `refactor`, `delivery`, and `other_process`.
+6. Preserve the complete `node_result` branch wrapper. Never flatten baseline fields or encode an
+   array as prose.
+7. Submit exactly one MethodEvidence item for every current Action method step, in Action order.
+   For completed `plain` work use `"status": "plain_fallback"` and `"capability": ""`.
+8. Replace every value beginning `placeholder-` and every exemplar revision/ID with the current
+   normalized value read from the current Task/Action. Delivery acceptance, record IDs, and exact
+   evidence sets always come from the latest Task projection and are never guessed.
+9. Do not include repository facts, payload digests, raw command/output/environment data, or
+   unknown members.
+10. `INVALID_ARGUMENT` is a completed Core domain rejection: stop, report a payload-contract error,
+    and do not probe with another payload or treat it as transport uncertainty.
+
+<!-- node-payload-template:requirements:start -->
+```json
+{
+  "transition_id": "requirements_ready",
+  "summary": "placeholder-normalized-summary",
+  "reason": "",
+  "artifacts": [],
+  "method_evidence": [
+    {"step_id": "requirements.capture", "status": "plain_fallback", "capability": "", "summary": "placeholder-capture-summary"},
+    {"step_id": "requirements.clarify", "status": "plain_fallback", "capability": "", "summary": "placeholder-clarify-summary"},
+    {"step_id": "requirements.validate", "status": "plain_fallback", "capability": "", "summary": "placeholder-validation-summary"}
+  ],
+  "node_result": {
+    "problem_class": "none",
+    "baseline": {
+      "goal": "placeholder-goal",
+      "scope": ["placeholder-scope"],
+      "out_of_scope": ["placeholder-exclusion"],
+      "acceptance_criteria": ["placeholder-acceptance-criterion"],
+      "constraints": ["placeholder-constraint"],
+      "assumptions": []
+    },
+    "unresolved_questions": []
+  }
+}
+```
+<!-- node-payload-template:requirements:end -->
+
+Never use `repository_observation` as an artifact role, place goal/scope beside `node_result`, or
+omit `problem_class`, `baseline`, or `unresolved_questions`.
+
+<!-- node-payload-template:design:start -->
+```json
+{
+  "transition_id": "design_ready",
+  "summary": "placeholder-normalized-summary",
+  "reason": "",
+  "artifacts": [],
+  "method_evidence": [
+    {"step_id": "design.choose_approach", "status": "plain_fallback", "capability": "", "summary": "placeholder-approach-summary"},
+    {"step_id": "design.review_complexity", "status": "plain_fallback", "capability": "", "summary": "placeholder-complexity-summary"},
+    {"step_id": "design.record_decisions", "status": "plain_fallback", "capability": "", "summary": "placeholder-decision-summary"}
+  ],
+  "node_result": {
+    "problem_class": "none",
+    "baseline": {
+      "requirements_revision": 1,
+      "approach": "placeholder-approach",
+      "components": ["placeholder-component"],
+      "decisions": ["placeholder-decision"],
+      "rejected_alternatives": ["placeholder-rejected-alternative"],
+      "complexity_justification": [],
+      "risks": []
+    },
+    "findings": []
+  }
+}
+```
+<!-- node-payload-template:design:end -->
+
+Use the current requirements revision. The field `complexity` is forbidden; the required field is
+`complexity_justification`, even when its value is an empty array.
+
+<!-- node-payload-template:tasks:start -->
+```json
+{
+  "transition_id": "tasks_ready",
+  "summary": "placeholder-normalized-summary",
+  "reason": "",
+  "artifacts": [],
+  "method_evidence": [
+    {"step_id": "tasks.decompose", "status": "plain_fallback", "capability": "", "summary": "placeholder-decomposition-summary"},
+    {"step_id": "tasks.map_acceptance", "status": "plain_fallback", "capability": "", "summary": "placeholder-acceptance-map-summary"},
+    {"step_id": "tasks.analyze_consistency", "status": "plain_fallback", "capability": "", "summary": "placeholder-consistency-summary"}
+  ],
+  "node_result": {
+    "problem_class": "none",
+    "baseline": {
+      "design_revision": 1,
+      "work_items": [
+        {
+          "work_item_id": "placeholder-work-item-id",
+          "summary": "placeholder-work-item-summary",
+          "expected_paths": ["src/placeholder.mjs"],
+          "acceptance_indexes": [0],
+          "verification_steps": ["placeholder-targeted-verification"],
+          "dependencies": []
+        }
+      ]
+    },
+    "findings": []
+  }
+}
+```
+<!-- node-payload-template:tasks:end -->
+
+<!-- node-payload-template:implement:start -->
+```json
+{
+  "transition_id": "implementation_ready_for_test",
+  "summary": "placeholder-normalized-summary",
+  "reason": "",
+  "artifacts": [],
+  "method_evidence": [
+    {"step_id": "implementation.execute_plan", "status": "plain_fallback", "capability": "", "summary": "placeholder-execution-summary"},
+    {"step_id": "implementation.record_surface", "status": "plain_fallback", "capability": "", "summary": "placeholder-surface-summary"},
+    {"step_id": "implementation.classify_deviations", "status": "plain_fallback", "capability": "", "summary": "placeholder-deviation-summary"}
+  ],
+  "node_result": {
+    "problem_class": "none",
+    "task_plan_revision": 1,
+    "completed_work_item_ids": ["placeholder-work-item-id"],
+    "changed_paths": ["src/placeholder.mjs"],
+    "no_file_changes": false,
+    "deviations": [],
+    "findings": []
+  }
+}
+```
+<!-- node-payload-template:implement:end -->
+
+Exactly one of a nonempty `changed_paths` list or `no_file_changes=true` describes the current
+implementation result.
+
+<!-- node-payload-template:test:start -->
+```json
+{
+  "transition_id": "tests_passed",
+  "summary": "placeholder-normalized-summary",
+  "reason": "",
+  "artifacts": [],
+  "method_evidence": [
+    {"step_id": "test.run_budgeted_checks", "status": "plain_fallback", "capability": "", "summary": "placeholder-check-summary"},
+    {"step_id": "test.record_evidence", "status": "plain_fallback", "capability": "", "summary": "placeholder-evidence-summary"},
+    {"step_id": "test.classify_failure", "status": "plain_fallback", "capability": "", "summary": "placeholder-classification-summary"}
+  ],
+  "node_result": {
+    "problem_class": "none",
+    "checks": [
+      {"source": "automated", "name": "placeholder-check-name", "status": "passed", "summary": "placeholder-check-result", "command_count": 1, "full_suite": false}
+    ],
+    "failed_items": [],
+    "unverified_items": [],
+    "manual_handoff_items": [],
+    "findings": []
+  }
+}
+```
+<!-- node-payload-template:test:end -->
+
+<!-- node-payload-template:comprehension-complexity:start -->
+```json
+{
+  "transition_id": "code_too_complex",
+  "summary": "placeholder-normalized-summary",
+  "reason": "placeholder-required-complexity-reason",
+  "artifacts": [],
+  "method_evidence": [
+    {"step_id": "comprehension.explain", "status": "plain_fallback", "capability": "", "summary": "placeholder-explanation-summary"},
+    {"step_id": "comprehension.identify_complexity", "status": "plain_fallback", "capability": "", "summary": "placeholder-complexity-summary"},
+    {"step_id": "comprehension.obtain_user_verdict", "status": "plain_fallback", "capability": "", "summary": "placeholder-user-verdict-summary"}
+  ],
+  "node_result": {
+    "problem_class": "code_complexity",
+    "explained_components": ["placeholder-component"],
+    "unresolved_questions": [],
+    "unnecessary_abstractions": ["placeholder-unnecessary-abstraction"],
+    "maintenance_risks": [],
+    "user_confirmation": null,
+    "findings": ["placeholder-matching-complexity-fact"]
+  }
+}
+```
+<!-- node-payload-template:comprehension-complexity:end -->
+
+<!-- node-payload-template:comprehension-passed:start -->
+```json
+{
+  "transition_id": "comprehension_passed",
+  "summary": "placeholder-normalized-summary",
+  "reason": "",
+  "artifacts": [],
+  "method_evidence": [
+    {"step_id": "comprehension.explain", "status": "plain_fallback", "capability": "", "summary": "placeholder-explanation-summary"},
+    {"step_id": "comprehension.identify_complexity", "status": "plain_fallback", "capability": "", "summary": "placeholder-complexity-summary"},
+    {"step_id": "comprehension.obtain_user_verdict", "status": "plain_fallback", "capability": "", "summary": "placeholder-user-verdict-summary"}
+  ],
+  "node_result": {
+    "problem_class": "none",
+    "explained_components": ["placeholder-component"],
+    "unresolved_questions": [],
+    "unnecessary_abstractions": [],
+    "maintenance_risks": [],
+    "user_confirmation": {"source": "user", "status": "passed", "summary": "placeholder-explicit-user-verdict-summary"},
+    "findings": []
+  }
+}
+```
+<!-- node-payload-template:comprehension-passed:end -->
+
+No AI or method capability may create the passing user confirmation.
+
+<!-- node-payload-template:refactor:start -->
+```json
+{
+  "transition_id": "refactor_ready_for_test",
+  "summary": "placeholder-normalized-summary",
+  "reason": "",
+  "artifacts": [],
+  "method_evidence": [
+    {"step_id": "refactor.simplify", "status": "plain_fallback", "capability": "", "summary": "placeholder-simplification-summary"},
+    {"step_id": "refactor.reconcile_artifacts", "status": "plain_fallback", "capability": "", "summary": "placeholder-reconciliation-summary"},
+    {"step_id": "refactor.record_surface", "status": "plain_fallback", "capability": "", "summary": "placeholder-surface-summary"}
+  ],
+  "node_result": {
+    "problem_class": "none",
+    "changed_paths": ["src/placeholder.mjs"],
+    "no_file_changes": false,
+    "simplifications": ["placeholder-simplification"],
+    "behavior_change_intended": false,
+    "findings": []
+  }
+}
+```
+<!-- node-payload-template:refactor:end -->
+
+<!-- node-payload-template:delivery:start -->
+```json
+{
+  "transition_id": "delivery_complete",
+  "summary": "placeholder-normalized-summary",
+  "reason": "",
+  "artifacts": [],
+  "method_evidence": [
+    {"step_id": "delivery.reconcile_acceptance", "status": "plain_fallback", "capability": "", "summary": "placeholder-acceptance-summary"},
+    {"step_id": "delivery.reconcile_method_artifacts", "status": "plain_fallback", "capability": "", "summary": "placeholder-artifact-summary"},
+    {"step_id": "delivery.prepare_summary", "status": "plain_fallback", "capability": "", "summary": "placeholder-delivery-summary"}
+  ],
+  "node_result": {
+    "problem_class": "none",
+    "acceptance": [{"criterion": "placeholder-current-criterion", "status": "satisfied"}],
+    "automated_evidence_ids": ["placeholder-current-automated-evidence-id"],
+    "manual_evidence_ids": ["placeholder-current-comprehension-evidence-id"],
+    "test_record_id": "placeholder-current-test-record-id",
+    "comprehension_record_id": "placeholder-current-comprehension-record-id",
+    "unverified_items": [],
+    "risks": [],
+    "findings": []
+  }
+}
+```
+<!-- node-payload-template:delivery:end -->
+
+Acceptance order/text and the automated/manual evidence lists must exactly equal the latest Core
+projection. Use only current TestRecord and ComprehensionAssessment IDs; stale or guessed IDs are
+forbidden.
+
+<!-- node-payload-template:blocked:start -->
+```json
+{
+  "blocker_id": "placeholder-current-blocker-id",
+  "condition": {
+    "kind": "restore_issuance_binding",
+    "expected_binding_digest": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+  },
+  "observed_binding_digest": "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
+}
+```
+<!-- node-payload-template:blocked:end -->
+
+For `RESOLVE_BLOCKER`, use the exact current blocker ID, stored condition, and freshly observed
+binding digest required by Core. Never submit a resume node or destination.