@awak-app/simy-cli 0.7.15 → 0.7.17

package/src/orchestrator/delivery/references/delivery-levels.md

@@ -1,118 +1,4 @@
-# Delivery levels and chat confirmation
+# Proportionate verification
+Choose checks that can reveal defects in the requested behavior. A wording fix may need only a diff and rendered-output check; persistence, authorization, payments and migrations need the relevant failure, isolation, retry and recovery paths exercised. Use judgment rather than a numbered minimum level.
 
-Use delivery levels to vary verification depth, review breadth, and how readily
-the controller proceeds on reversible assumptions. They do not change the goal,
-completion predicate, authority boundaries, or truthfulness of evidence.
-
-Numbering version: `assurance-ascending-v2`. Level 5 is the highest assurance;
-level 1 is the lightest. These numbers describe assurance, not task priority.
-
-## AI selection without a confirmation gate
-
-AI selects the proportionate effective level after understanding the task and
-checking the highest applicable safety floor. Preserve explicit user selections
-and mandatory verification; a reversible selection needs no human confirmation.
-Record AI as the decision maker, the rationale, applicable risk and uncertainty.
-Do not fabricate a user message or approval reference. Refresh the decision on
-material scope/risk changes without adding a second continuation request.
-
-Show all five levels only when requested. Estimates help planning but missing
-numeric estimates or a complete comparison table do not block implementation.
-Unknown facts prompt research, and ambiguous historical numbering uses source
-reconciliation and a conservative assurance floor. Irreversible operations still
-require the relevant exact decision; an assurance level never creates credentials
-or overrides provider permission, user stops, rejections or budget limits.
-
-## The five levels
-
-| Level | Name | Intended work | Verification and review policy |
-| --- | --- | --- | --- |
-| 5 | Maximum assurance | Authentication, payments, destructive or irreversible changes, production security/configuration, sensitive data, and risky migrations | Exercise all affected and adjacent invariants, failure/recovery and rollback paths. Use separate independent design, implementation-boundary, and final PR/evidence reviews plus every repository gate. |
-| 4 | Protected | Persistence, permissions, shared contracts, external side effects, cross-repository changes, and medium-risk migrations | Verify both evidence layers, shared boundaries, retry/idempotency, staged rollout and recovery. Require independent boundary/design and final candidate/integration review; combine them only when the reviewed inputs are exactly identical. |
-| 3 | Balanced (default) | Normal features and bug fixes with bounded, reversible impact | Run focused regressions, applicable static checks, the real affected runtime and main user journey. One independent final-candidate review may cover design, implementation, affected views and evidence; repeat only when its bound identity changes. |
-| 2 | Fast | Small, isolated, reversible UI or implementation changes | Run the direct regression and real affected path, adding shared-boundary checks only when touched. Use a scoped independent diff/actual-path review when repository policy or material ambiguity requires it. |
-| 1 | Fastest | Copy, documentation, comments, metadata, or similarly trivial changes with no runtime/data/security effect | Verify the artifact, final diff, packaging/link integrity and repository-mandated checks. Independent review is needed only when governing policy requires it or material ambiguity remains. |
-
-Level 3 is the recommendation when no task-specific signal favors another level.
-Faster levels reduce work only by declaring genuinely unaffected lanes not
-applicable in the frozen charter with a source and reason. They cannot convert a
-failed, unavailable, stale, or skipped applicable check into non-applicability.
-
-## Task-specific duration estimates
-
-For every level, give a numeric lower-to-upper range in hours for the same frozen
-task scope and delivery endpoint. Do not hardcode universal durations, product
-examples or multipliers by level. Derive estimates from discovered change
-boundaries, implementation work, applicable checks, review passes, environment
-setup, likely repair/retest work and available run history. Explain assumptions,
-evidence, uncertainty and confidence; estimates are not measured results or
-deadlines. Use read-only discovery to narrow uncertainty before selection.
-
-Distinguish hands-on/execution time from CI, queue, reviewer, approval and external
-waiting time. Compute elapsed ranges using the dependency critical path, accounting
-for parallel work without adding overlapping durations twice. Show known waiting
-ranges separately and the resulting elapsed range. If an external wait has no
-defensible bound, show a conditional numeric execution range plus explicitly
-unbounded/unknown waiting time; do not invent a finite total. If even execution
-cannot yet be estimated, retain that level's row as estimate pending with the
-missing input and next discovery step. Continue reversible work; complete numeric estimates are not a selection gate.
-Unavailable levels have conditional estimates for comparison only, not permission
-to execute below the risk floor. A stricter level cannot appear faster by silently
-omitting required work; explain any overlap or inversion from verified reuse,
-parallelism or uncertainty. Refresh estimates when scope, evidence reuse,
-environment or review needs change. Estimates authorize neither paid services
-nor additional work and do not weaken checks to fit the range.
-
-## Safety floors
-
-The minimum permitted assurance level is determined by the highest applicable risk:
-
-| Risk trigger | Minimum permitted assurance level |
-| --- | --- |
-| Authentication or authorization policy; payments; secrets or sensitive personal data; destructive/irreversible operations; production security/configuration; data-loss migration risk | 5 |
-| Persistence or ownership; externally visible side effects; shared API/schema contracts; cross-repository rollout; reversible migration; meaningful concurrency/idempotency risk | 4 |
-| Ordinary runtime behavior with bounded and reversible impact | 3 |
-| Isolated reversible presentation or implementation behavior without persistent, permission, contract, or external effects | 2 |
-| Non-runtime copy, documentation, comments, or metadata only | 1 |
-
-When several triggers apply, use the highest numbered floor. Governing
-instructions or a verified project policy may require a safer level. The user may
-always choose a higher numbered, safer level. The effective level is the maximum
-of the requested level, risk floor and governing-policy floor.
-
-## Existing selections and historical receipts
-
-Do not reinterpret an old number using the new direction. Preserve original
-receipts and their version/source. For a verified legacy descending-assurance
-selection, map old to new as 1→5, 2→4, 3→3, 4→2, 5→1, record both meanings and
-explain the conversion. Keep the same assurance scope; this is not a fresh grant
-of authority or evidence. If the old numbering cannot be established, research its source and use a conservative assurance floor while preserving the ambiguous historical receipt. AI re-evaluates reversible assurance decisions; do not ask the user to resolve numbering bookkeeping.
-
-## What never varies
-
-Every level preserves:
-
-- frozen success criteria and independent acceptance sources;
-- shared system As-Is/To-Be and consistency of affected cross-view links;
-- the frozen risk-proportionate review plan and every governing repository review;
-- SQM only under explicit opt-in, with identity-bound proof and historical coverage reported;
-- honest state transitions and current revision/context binding;
-- required user/system evidence for applicable outcomes;
-- protection of user work, secrets, data integrity, and tenant boundaries;
-- explicit failure, pending, skipped, and non-applicable reporting;
-- repository-required tests, reviews, CI, and approval/authority boundaries.
-
-All levels retain the [minimum functional floor](minimum-completion.md): requirement mapping, actual operation/result, and independent postcondition/integration observations. Persistence requires reload and stored-state checks. Non-runtime work verifies its real consumer/artifact; no imaginary DB or API checks are added. The minimum checker has no level-based bypass.
-
-## Reuse instead of duplicate ceremony
-
-Freeze the review and SQM plan in the charter. Reuse a passing review or SQM
-proof only when its repository, head, base, working-tree/diff, specification,
-policy, knowledge bundle, evidence and relevant environment identities are exactly
-unchanged and the proof remains verifiable. A PR URL alone is not a changed input.
-Rerun the affected review or SQM phase when any bound identity changes or when a
-PR-only scanner, policy or integration check first becomes applicable.
-
-Do not reopen or re-attest every shared view. Inspect the changed views and their
-declared dependency links; retain unchanged views by exact revision. Do not turn a
-failed, unavailable or applicable gate into `not_applicable` to save time.
+No comparison table, hour estimate, selection receipt or independent review is required by this guide. Honor explicit user verification preferences. Ask only for a material unresolved choice that cannot be inferred or investigated. A verification preference never grants permission for an external action or overrides a user stop or budget.

package/src/orchestrator/delivery/references/local-sqm-evidence.md

@@ -30,5 +30,5 @@ dev origin when testing dev. SQM analysis must already be enabled for the organi
 
 An identical record from the same user returns the same job. Changed evidence
 creates a new digest/job and retains the earlier revision. Keep the returned job ID
-for monitoring in SQM. Candidate checks still need independent review/evaluation;
+for monitoring in SQM. Submitting a local result does not require a separate review;
 local success never proves deployment or production impact.

package/src/orchestrator/delivery/references/minimum-completion.md

@@ -1,146 +1,6 @@
-# Minimum functional completion
+# Completion
+Finish when the requested endpoint works, including explicit corrections and applicable constraints. Use direct checks of actual behavior and relevant test results. Repair concrete failures; a returned success flag or completed process alone is insufficient.
 
-Every level must prove that the requested work exists, actual operations reach
-the intended result, and necessary persistence/integration works. Speed changes
-adjacent verification breadth, never this floor. The CLI requires this matrix for
-all coding-loop attempts, including legacy v2 resumes/rechecks. No opt-out field
-in an executor result or assurance-level selection disables the gate.
+There is no mandatory minimum evidence package, matrix, screenshot, diagram, score or second reviewer. Legacy validator commands remain available for explicitly supplied legacy files but do not gate ordinary execution or completion.
 
-## Collect real observations
-
-Before implementation, reconcile the original request, acceptance criteria and
-planned operations against the frozen experience contract. Preserve every
-observable moment from the real trigger to a usable result, including applicable
-recovery and forbidden experiences; a missing requirement must
-be added through the controller's charter process, not omitted from the matrix.
-The independent auditor compares original-request coverage and checks the oracle
-against raw evidence. Machine mapping checks cannot discover an omitted idea in
-natural language or authenticate what an evidence collector observed.
-
-For each stable criterion ID record implementation_refs (repository-relative file
-paths). New UX-first charters preserve the IDs supplied by the experience
-contract; legacy charters without explicit IDs retain deterministic `AC-N` IDs.
-Then:
-
-- user/operation: operate the actual UI or CLI/consumer. Expected is true; actual
-  is whether the intended operation really executed, not just whether a click
-  command succeeded. Include screenshots/traces where relevant.
-- user/result: observe the requested visible outcome, including reload and session
-  return for a saving feature. Compare expected and actual values, user
-  understanding, and the next action the experience makes available.
-- system/postcondition: independently inspect the final state; for persistence,
-  include the saved values and ownership, not a toast or HTTP status.
-- system/integration: inspect the necessary combined path through APIs, storage,
-  workers or consumers. Job acceptance is not job completion. Use the same input
-  and execution context across layers; cite trace/runtime identities in subject
-  and additional evidence.
-
-For document-only work these mean opening the actual consumer and checking content,
-links and packaged bytes. No DB/API is required if none participates. Both generic
-layers remain required; there is no post-failure waiver. Tests, permissions or
-runtime unavailable means pending/blocked. Never fabricate expected/actual equality.
-Passing narrower rows for controls, APIs, services, or artifacts cannot substitute
-for the end-to-end row when the requested experience depends on their combination.
-
-## Executable contract
-
-`check-minimum-completion.mjs` and `check-acceptance.mjs` ship together under the
-CLI runtime delivery/scripts directory. The CLI instruction supplies controller input
-JSON; save it as charter.json for the standalone command. It contains id,
-requirement, repository, acceptance_criteria, completion_contract (version 2), and
-thread_state.original_request. For standalone use the controller freezes the same
-fields independently of implementation. The matrix otherwise follows
-[acceptance evidence](acceptance-evidence.md).
-
-To derive the frozen specification/context, import `minimumCharter(charter)` and
-`minimumContext(charter, fullHeadSha)` from the minimum script; import `sha256`
-and `contextDigest` from check-acceptance.mjs. The charter digest is
-`sha256(Buffer.from(JSON.stringify(minimumCharter(charter))))`.
-The context digest is `contextDigest(minimumContext(charter, fullHeadSha))`.
-The CLI derives both itself; it never takes expected digests from executor output.
-
-The current CLI context is one local checkout, its full HEAD, controller charter
-ID and request digest. A clean checkout is required and checked again after
-collection. This is not automatic multi-repository deployment identity discovery.
-For companion services, verify the combined path and record the pinned service
-identities in the evidence; the independent reviewer must validate their current
-identity. Do not claim that this single-checkout gate automatically re-reads a
-companion service's Git HEAD or production environment.
-
-Every matrix row uses the same stable criterion ID and adds
-`implementation_refs: ["src/example.js"]`. Each required
-user/system cell's **first** evidence file is JSON with this shape (user example):
-
-```json
-{
-  "criterion_id": "AC-1",
-  "context_sha256": "<current context digest>",
-  "checks": {
-    "operation": {"subject": "Save clicked and request observed for fixture run", "expected": true, "actual": true},
-    "result": {"subject": "Note after reload and session return", "expected": "requested text", "actual": "requested text"}
-  }
-}
-```
-
-The system file uses `postcondition` and `integration` instead. Each has `subject`,
-non-null `expected` and actual observed `actual`. Values may be objects/arrays to
-compare saved values and ownership together. The checker compares values exactly;
-missing fields or mismatches fail regardless of a cell's passed flag. Additional
-cell evidence may contain screenshots or logs; all artifact hashes are validated.
-Keep raw evidence local and use synthetic data, never credentials/personal data.
-
-Store matrix and evidence under ui_evidence_root, or under repository `.artifacts`
-when no root was specified. All artifact paths are relative to the matrix directory.
-Return `delivery_evidence_path` in SIMY_RESULT_JSON, absolute under that root or
-relative to it. Source mappings must resolve to files inside the current repository.
-Evidence must be bounded regular files; path escapes/symlinks are rejected.
-
-Standalone invocation, with controller-owned trusted digests:
-
-```text
-node <cli-package>/src/orchestrator/delivery/scripts/check-minimum-completion.mjs charter.json matrix.json context.json <trusted-charter-sha256> <trusted-context-sha256>
-```
-
-Exit 0 is evidence_complete; 1 is evidence_incomplete; 2 means invalid/unavailable
-inputs. JSON includes a readable checklist and floor failures. Check the top-level
-status, not only individual base-matrix rows. The standalone checker validates
-mapping structure; only the CLI additionally resolves mappings in its checkout.
-Neither file hashes nor a passed report authenticate the collector or prove an
-oracle matches the original requirement. Independent coverage/oracle review is
-required by the CLI and must inspect the raw evidence. The standalone command
-cannot stop Codex/Claude's final chat response and does not install global hooks.
-
-## State, review and recovery
-
-The CLI's implementation gate includes the minimum report before independent
-review. The review returns coverage_review with requirements_complete,
-unmapped_requirements and a concrete observation. The controller binds that
-review to the matrix digest, then recollects evidence. Changing the matrix after
-review requires a new review; changing HEAD or dirtying the tree invalidates the
-proof. A concurrent call using the same run ID is rejected, including cloned snapshots.
-A repeated start rechecks evidence without executing the implementation again;
-explicit resume remains the repair path. Cross-process
-execution remains subject to existing runner/host ownership controls.
-
-PR recheck clears prior completion flags and reruns the floor. Missing evidence
-never promotes an old successful audit. The old history is retained; do not rewrite
-it as verified under the new floor. Fix the named criterion, collect fresh evidence
-and resume with the same task identity and progress checks. Reconcile ambiguous external side effects
-before retrying. The minimum pass is a prerequisite for existing CI/review/authority
-gates, not merge, deployment or a complete production delivery.
-
-Rollback: restoring the older CLI removes this additional enforcement. Retain the
-versioned evidence/history and report that limitation; never relabel old evidence
-as verified by this floor. Monitor minimum-completion findings and subsequent
-reviewer-discovered gaps through existing local run records; no new telemetry or
-external provider calls are introduced.
-
-## Shared specifications and independent review
-
-The floor's stable criterion rows trace back to requirement IDs in the team's shared
-As-Is/To-Be specification. Follow [shared system specifications](shared-system-specifications.md)
-for purpose, user experience, cross-view consistency, risk-proportionate independent
-reviews and explicitly opted-in, identity-aware SQM. These are controller workflow obligations, not fields magically
-validated by the minimum checker. The CLI gate verifies minimum structured evidence;
-it does not launch every design review or SQM phase on its own. Standalone hosts
-remain responsible for executing this workflow and cannot claim an enforced host hook.
+Respect real permissions, user stops, budgets and unknown external effects. If dependent work cannot proceed, continue independent authorized work and identify the actual unresolved condition. Do not claim deployment from local success or a PR.

package/src/orchestrator/delivery/references/pr-closure.md

@@ -1,202 +1,6 @@
-# PR closure: SIMY Web / CLI procedure
+# Closing a pull request
+Close a PR only when authorized. Verify which PR it is and why closing it fits the request: completed, superseded, duplicated or intentionally cancelled. Check that useful unfinished behavior is not accidentally lost. A request to inspect or compare PRs alone does not authorize closing, commenting, merging or deployment.
 
-This procedure is loaded by the Web/CLI executor and independent auditor through
-`src/orchestrator/pr-closure.js`. It is not a local Codex skill or a GitHub hook.
-It adds a closure safety gate to the existing delivery workflow, not a new remote
-mutation tool, permission or terminal state. Closing a PR never proves delivery.
+Use current remote state and the actual replacement behavior where relevant. No before/after table, separate approval, review receipt or closure evidence package is required. Existing clear authorization need not be requested again.
 
-Flow: scope/authority -> original requirements and exact revisions -> before/after
-table -> real outcome verification -> independent review -> decision -> freshness
-and authority recheck -> authorized close -> remote read-back and durable receipt.
-When blocked, stop the close, not independent authorized investigation. Reuse the
-run's attempt/time/cost limits; do not repeat unchanged failed checks indefinitely.
-
-## 1. Define the scope and reason
-
-Record repository/PR, purpose, beneficiary, source requirements and non-goals.
-Distinguish merged, duplicate/fully superseded, transfer to unfinished work, and
-intentional cancellation/retirement. An already merged PR needs its actual merge
-identity verified, not a manual unmerged close. Merge is not deployment.
-
-An audit/table request is read-only. Record close and comment-posting authority
-separately; a factual same-PR comment must be covered by explicit authorization
-or governing policy. Otherwise prepare an unposted draft. Do not infer authority
-to merge successors, deploy, delete branches or reopen an already closed PR.
-An existing clear authorization need not be requested twice; a newly discovered
-loss of functionality requires an informed decision on that consequence.
-
-## 2. Freeze requirements and comparison identities
-
-Use original requests, acceptance criteria and approved decisions as the oracle,
-not the closing comment or candidate's own tests alone. Reuse stable acceptance
-IDs from the delivery charter. Independently reconcile the original sources with
-the ID list so an omitted requirement cannot disappear before validation.
-
-Record full old PR head and merge-base SHAs, current target base, successor and
-companion heads, exact integrated candidate, PR/merge state, build/runtime identity,
-flags, permissions/tenant, environment and observation time. Track deployed state
-separately; never infer it from a branch. Preserve a recoverable reference to
-unmerged source before cleanup. An SHA without retrievable objects is not backup.
-
-Keep requested, intended-in-code, observed-in-runtime, absent and unknown distinct.
-An unavailable old environment does not prove a feature never existed. Old missing
-code does not waive an explicit requirement, and labels do not prove old guarantees.
-
-## 3. Persist the before/after table
-
-Use [UX behavioral completeness](ux-specification.md) for both sides of the
-comparison. A concise table cell must link to the complete interaction contract;
-do not reduce the comparison to feature labels or omit divergent branches.
-
-Use the existing [acceptance evidence](acceptance-evidence.md) and stable IDs.
-Keep separate bound results for each context and link the comparison to them;
-do not overwrite base-only results with combined or live results. Persist outside
-chat and retain failed/pending rows. Minimum comparison columns:
-
-| ID / requirement source | Persona, condition, required outcome | Old PR intended / observed | Current base alone | Base + successors | Deployed target | Decision, gap, owner, remediation PR | Evidence |
-| --- | --- | --- | --- | --- | --- | --- | --- |
-| Stable criterion | Trigger, real entry, action, result, next action | Exact revision, evidence level | Exact revision, evidence level | Exact integrated identity | Observed identity or unknown | Retained / approved change / transferred / missing / unknown | Source locations, raw results, artifact hashes, times |
-
-For each affected journey cover real navigation, discoverability, first use and
-empty data, flags/roles/ownership; transferred input/context, confirmation, state
-changes, actual execution, usable output and next action; persistence, reload and
-session return, history/sync, privacy and data migration; loading, no-match,
-permission denial, error, cancellation and retry/recovery. Include accessibility
-and device variants when affected. Extra clicks or lost controls may be regressions
-even if an API is unchanged.
-
-For workflow products, separately account for existing-workflow reuse, composition,
-conversational design of a saved workflow, immediate ad-hoc work without saving a
-workflow, and background discovery/learning. Explicitly test the no-workflow or
-no-match branch: can the user ask for help, preserve intent, clarify/design/execute
-as required and obtain a usable result? A catalog recommender or background
-learning is not proof of conversational/ad-hoc fallback. Classify each capability
-against authoritative requirements; do not invent an old capability or silently
-exclude one because old code lacked it.
-
-Inventory every changed file, including deletions/renames, contracts, flags, tests
-and affected consumers outside the diff. Map each to criteria or a justified
-non-behavioral classification. Trace all requirements forward to proof, removed
-behavior back to retained behavior or approved retirement, and added permissions,
-data collection, automation, costs, defaults or steps back to authorized scope.
-Identical blobs, ancestry and file counts prove accounting, not UX equivalence.
-
-### Yellow/red rows must become remediation PR work
-
-Display unresolved partial/changed/unverified outcomes as yellow (🟡), and verified
-missing/regressed outcomes as red (❌). Keep factual behavior, evidence sufficiency
-and approved scope separate; uncertainty alone is not proof of a product defect.
-For every yellow/red row, create a new remediation PR for the required repair or
-verification within the active task's implementation/commit/push/PR authority.
-Group rows only when they form one coherent behavior change; do not mechanically
-create one PR per row or combine unrelated fixes. Use a Draft PR while unfinished.
-Before creation, check existing remediation PRs: reuse an exact open match with
-explicit criterion coverage rather than creating duplicate competing work. A broad
-successor link does not count without that mapping.
-
-Record criterion IDs, original PR, observed gap/evidence, required outcome, owner,
-repository/base, tests/E2E and acceptance gates in each remediation PR. Add its real
-URL and state to every covered table row; include dependencies and re-evaluation
-triggers. Evidence-only yellow rows need the missing verification, not speculative
-product changes. AI resolves reversible product choices from the original purpose, with recorded assumptions and rollback. Only irreversible or explicitly reserved choices remain `needs_decision`; do not change the original goal just to open a PR. If implementation or publication is
-unauthorized, blocked or outside the current budget, record a concrete PR plan and
-the missing decision/authority, but do not claim a PR exists. A plan/issue alone
-does not satisfy the requested PR handoff or justify `transfer_ready`.
-
-Independent review must reconcile all yellow/red IDs with the actual remediation
-PRs and explicitly named blockers before the original PR can be closed by transfer.
-Creating a PR is not fixing the issue: keep the row non-green until its required
-revision-bound checks pass. Approved changes/retirements may resolve a row only
-with the product decision and applicable safety evidence; preserve its history.
-
-## 4. Verify the actual consumer and independent postconditions
-
-Trace normal production entry -> caller -> UI/service -> backend -> persisted
-result -> next user action. Verify actual imports, routes, permissions and flags.
-A surviving component/API used only in fixtures is not a production experience.
-Test the unchanged old candidate where feasible, base alone and exact integrated
-candidate. Inspect the combined behavior, not just mergeability or individual CI.
-Reuse valid bound evidence; do not inflate counts with unnecessary reruns.
-
-For browser behavior, use [normal-user verification](chrome-user-verification.md)
-on the complete production-like stack with authorized services and safe fixtures.
-Capture meaningful visible states, errors and correlated technical postconditions
-for the same input/run. Mocked/component E2E, direct API calls and static analysis
-are supporting evidence, not substitutes. Only an exact-runtime live journey proves
-live inheritance. Do not imply that local or merged verification is deployed proof.
-For docs/CLI/library/API work use the actual artifact, command or downstream
-consumer; record why browser checks are inapplicable. Unavailable checks are pending,
-not inapplicable. Never make production writes solely to satisfy this procedure.
-
-Preserve initial failures. Classify product, environment and oracle failures with
-independent evidence. Changed assertions/fixtures create a different tested
-candidate and require independent oracle review; do not credit their passes to
-the unchanged original PR. A stale label alone does not explain a missing route.
-
-## 5. Independent review and decision
-
-Before the close action, a separate reviewer receives original requirements,
-candidate revisions, complete file inventory, table and raw artifacts, without
-a prescribed verdict. Review omissions, reachability, fallback, integrated results,
-unapproved scope and unfinished dependencies. Record identity-bound findings in
-the existing independent-review receipt. A comment claiming a review occurred is
-not review evidence. Repair only within authority; re-review changed inputs.
-The normal post-execution CLI audit is not a substitute for review before closing.
-
-Store these labels in the closure record, not in the delivery-state enum:
-
-| Decision | Required evidence and permitted action |
-| --- | --- |
-| `close_ready` | All requirements accounted for, candidate evidence and independent review pass; no hidden loss or pending implementation. State separately whether base-only or live. Deployment may remain an explicit delivery obligation. |
-| `transfer_ready` | Every pending outcome/risk has an accepted owner or authorized assignment, actual open remediation PR with criterion coverage, acceptance gate and re-evaluation trigger; explicit informed administrative-close authorization. No unmapped yellow/red row or unresolved handoff blocker. Not full inheritance/completed delivery. |
-| `retirement_ready` | Explicit product decision retires named outcomes; necessary user-data/migration/safety obligations verified or safely assigned before close. Not equivalence. |
-| `needs_decision` | Irreversible consequences or an explicitly reserved choice need human selection. AI resolves reversible trade-offs using grounded purpose, alternatives and rollback; do not leave PR closure waiting solely for a preference. |
-| `blocked` | Missing/stale evidence, review, authority, classification or handoff, or unsafe consequence prevents the proposed action/claim. |
-
-Unknown/failed applicable rows cannot support `close_ready`. A deliberately
-authorized transfer keeps them non-green and visible. Verify the successor exists,
-is open and carries the actual pending criteria; a link alone is insufficient.
-Do not invent an owner's acceptance. Transfer cannot waive mandatory security,
-privacy, data-integrity or external-contract constraints. Retain the actual highest
-proven delivery state, independently of the closure-task disposition.
-
-## 6. Freshness check, authorized action and read-back
-
-Immediately before mutation refresh old head, target base, all successor heads and
-states, integrated identity, checks/review inputs, flags/environment and authority.
-Any changed bound input invalidates affected verification/review under
-[state and receipts](state-and-receipts.md). Inspect and reverify before continuing;
-checking only the old head is insufficient. Use conditional updates if available;
-otherwise read immediately before/after, record residual races and stop on drift.
-
-Prepare a factual explanation: reason, exact identities, comparison/evidence/review
-links, approved changes, pending obligations/owners, deployment status and recovery
-reference. Do not say nothing remains if work is unknown or unmerged. Missing close
-authority blocks closing; missing posting authority retains a draft. If policy
-requires a posted explanation, missing posting authority also blocks closing.
-
-After an authorized close, read back state, close/merge timestamps and identities,
-any authorized posted explanation, and successor status (open or demonstrably
-resolved). Reconcile ambiguous responses before retrying to avoid duplicate
-actions/comments. On unexpected concurrent changes, preserve evidence and report;
-do not silently reopen or declare success. Audit previously closed PRs read-only,
-separating the historical decision's evidence from today's state.
-
-## 7. Durable receipt and handoff
-
-Add a `closure` section to the existing completion/handoff evidence record, reusing
-its run/input digest, idempotency key and append-only rules. Record target/reason,
-decision, comparison/context digests, criterion/file coverage, all non-green rows,
-review and artifact references/hashes, human decisions and separate authorities,
-pre/post state/timestamps, mutation identity, comment ID/URL or unposted draft,
-pending owners/gates/triggers, yellow/red-ID-to-remediation-PR mappings and blocked
-PR plans, and source recovery references. Record unperformed
-actions as unperformed; reconcile retries with the same logical action identity.
-This documented section is not a new automatically validated CLI schema.
-
-Preserve the table, relevant raw proof, review and recoverable unmerged source in
-an approved durable location before deleting temporary worktrees. Verify links
-remain accessible and remove secrets/unrelated personal data. Never remove the
-only evidence/source copy. Administrative closure can finish a scoped closure task,
-not unfinished feature delivery. Promise ongoing monitoring only if authorized and
-actually configured; otherwise hand off to the recorded owner/tracking item.
+Read back the remote result before reporting success. Reconcile an unknown close result before repeating it. Closing or merging a PR does not establish that its functionality is deployed or usable.