@awak-app/simy-cli 0.5.12 → 0.5.14

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@awak-app/simy-cli",
-  "version": "0.5.12",
+  "version": "0.5.14",
   "description": "Local SIMY executor for non-coding Local Tasks and Agentic Loop runs.",
   "type": "module",
   "bin": {

package/src/cli-contract.js

@@ -13,7 +13,7 @@ import {
 } from "./durable-local-task-steps-contract.js";
 import { buildExecutionCapabilityContract } from "./execution-capability-contract.js";
 
-export const CLI_VERSION = "0.5.12";
+export const CLI_VERSION = "0.5.14";
 export const CLI_API_CONTRACT_VERSION = 10;
 
 export function withCliContract(

package/src/codex-plugins/simy/skills/agentic-delivery-loop/SKILL.md

@@ -53,6 +53,11 @@ Before material action, record:
   the exact user journey;
 - required evidence, applicable change boundaries, risk tier, and the few
   critical invariants that must block integration;
+- for every production-relevant experience ID, outcome and guardrail measures
+  with signal, independent source, observation window, threshold, decision and
+  owner; if no production outcome is in scope, record that once with a reason;
+- when release is in scope, staged exposure and deterministic promote, hold,
+  abort and rollback criteria, rollback mechanism, kill switch and owner;
 - requested and effective delivery levels, the risk-based safety ceiling, and
   the chat confirmation receipt;
 - exclusions and authority boundaries, especially commit, push, Draft PR
@@ -77,19 +82,20 @@ shared source, not twelve new task-local copies. Unaffected views retain their
 version; unknown As-Is facts remain unknown. Review changes through the team's
 normal version control and preserve concurrent work.
 
-Use independent agents for design review (including consistency across diagram
-kinds), implementation-to-To-Be review, and final PR/evidence review at **every**
-level. Reviewers inspect the full affected path and unchanged linked views. Fix
-findings and obtain independent re-review. A changed requirement or baseline
+Freeze and follow the risk-proportionate review plan from the selected delivery
+level. Level 3 may consolidate design, implementation-to-To-Be, affected-view and
+final evidence review into one independent final-candidate review. Inspect changed
+views and their dependency links; retain unrelated views by exact revision. Fix
+findings and independently re-review the affected behavior. A changed bound input
 invalidates affected approval; do not rewrite To-Be to disguise a failed result.
 
-PR creation and post-creation verification include the SQM loop described in the
-reference. Announce this requirement when starting Delivery Loop. Running SQM
-still follows its explicit opt-in/authority rules; if opt-in or access is absent,
-retain the unmet SQM gate and continue independent work. Ordinary PR work outside
-Delivery Loop does not activate this workflow. Record known incident coverage and
-unknown coverage separately; a green proof with no applicable rules does not prove
-that historical failures cannot recur.
+When SQM is explicitly opted in, apply the identity-aware SQM plan described in
+the reference. Announce its applicability when starting Delivery Loop. Reuse a
+verifiable proof only for exactly unchanged bound inputs; rerun for changed identity
+or newly applicable PR-only checks. If required access is absent, retain the unmet
+gate and continue independent work. Ordinary PR work outside Delivery Loop does
+not activate SQM. Record known and unknown incident coverage separately; zero
+applicable rules do not prove that historical failures cannot recur.
 
 ## Maintain the acceptance checklist outside the conversation
 
@@ -223,6 +229,63 @@ Reuse this record in implementation and review. Recheck only affected entries
 when rules, scope, revisions, execution paths, or authority change; patch the
 charter and invalidate affected evidence under the existing receipt contract.
 
+## Check equivalent-purpose consistency
+
+Before changing behavior, contracts, validation, policy, or trust-boundary rules
+that affect users, API consumers, data integrity, or security, identify every
+relevant surface and execution path that serves the same user purpose. Group
+those paths by semantic intent, then record for each path its persona, current
+source of truth, precedence, fallback, enforcement location, and observed
+behavior. Include client and server paths, platform variants, account, tenant,
+app, device, or system preferences, caches, and legacy defaults when they can
+affect the result. Use code, configuration, schemas, tests, documentation, and
+runtime evidence; matching labels alone are not proof that the same rule is
+enforced.
+
+For each equivalent-purpose group, verify whether all paths consume one
+canonical rule with the same precedence and fallback semantics. When they do
+not, determine whether the divergence is intentional and supported by an
+authoritative product decision. Also check that tests cover the shared contract
+at every affected boundary. A language choice that follows the device or OS on
+one surface and an in-app preference on another is one instance of this class,
+not a language-specific exception. Input validation split between frontend and
+backend is another: identify the canonical validation contract separately from
+where it is enforced. Multiple enforcement points may be correct when the
+frontend provides timely feedback and the backend protects the trust boundary,
+but equivalent rules must not drift.
+
+If competing sources or behaviors exist and no authoritative choice resolves
+them, do not silently select the most common implementation or whichever path
+is easiest to change. Produce a human-decision packet containing:
+
+- the shared purpose, affected personas, surfaces, and current divergence;
+- each viable unification option, including preserving an intentional
+  divergence when that is genuinely valid;
+- for each option, user benefit, user and operational risk, compatibility and
+  migration effects, fallback behavior, reversibility, support and maintenance
+  cost, security and trust-boundary constraints, validation plan, and material
+  evidence gaps;
+- a recommendation and rationale when the evidence supports one, clearly
+  separated from the decision itself.
+
+Require an explicit human selection even when one option is recommended. Mark
+the affected decision `needs_hil` and the dependent implementation
+`partially_blocked`; continue independent authorized work, but do not implement
+the behavior choice, define its test oracle, migrate data, or advance the
+affected scope to Ready or merge. A timeout or missing response is not approval.
+Human choice does not override mandatory security, privacy, data-integrity, or
+external-contract constraints; exclude unsafe or non-compliant options from the
+viable set and explain why. For example, client-only validation is not viable
+when untrusted input reaches a server-side trust boundary.
+
+Record the selected option as a revision-bound `HumanDecisionReceipt` and patch
+the charter with the canonical source, precedence, fallback, affected consumers,
+migration and rollout constraints, enforcement locations, verification plan,
+and rollback condition. Then implement every affected path against that decision
+and add boundary tests that fail if the paths drift again. A later change to the
+decision or its canonical rule invalidates dependent evidence and requires a new
+decision when the trade-off materially changes.
+
 ## Keep delivery states distinct
 
 Track and report the highest state actually proven:
@@ -290,10 +353,11 @@ Run focused regression tests first, then formatting, lint, type checking, unit
 tests, and the actual affected runtime. Apply only the relevant lanes from
 [the change-boundary matrix](references/change-boundary-matrix.md).
 
-After local verification at every level, have an independent agent compare the
-implementation and observed user outcomes to the frozen To-Be and original request.
-Include cross-view consistency, omissions and applicable historical regressions.
-Fix findings narrowly and independently re-review the affected behavior.
+After local verification, execute the frozen review plan for the effective level
+and governing repository. The independent reviewer compares the implementation
+and observed outcomes to the frozen To-Be and original request, including affected
+cross-view links, omissions and applicable historical regressions. Fix findings
+narrowly and independently re-review the affected behavior.
 
 Give the independent verifier the acceptance sources and raw evidence, not just
 the implementer's summary. Use a separate session/agent for every review; another model can help but model count is not quality evidence.
@@ -308,11 +372,14 @@ production configuration, and CI or security-policy changes.
 
 ### 4. Coordinate through Draft PR and integration state
 
-Before creating a PR, pass the independent To-Be review and pre-PR SQM loop.
 After authority for the required remote changes exists, record reproduction,
 tests, evidence, companion revisions, skipped checks, and remaining gates in the
-Draft PR. After creation, run a fresh SQM loop bound to the actual PR head/base
-and have an independent agent review the PR diff, proofs and incident coverage.
+Draft PR so the exact remote candidate can be inspected. Before Ready or merge,
+pass the reviews and explicitly opted-in SQM gates required by the frozen plan.
+Rerun a review or SQM gate only when its bound head,
+base, diff, specification, policy, evidence, environment or SQM bundle changed,
+or when a PR-only check became applicable. Otherwise retain the verified receipt
+and record its exact identity instead of duplicating ceremony.
 Before Ready or merge, combine the latest base with required companion
 and parallel changes, rerun the affected path, and confirm current CI and
 mergeability. Without combined-state proof, report `pr_only_verified`, not
@@ -342,6 +409,13 @@ remote merge result. Wait until the target environment reports the exact merge
 revision or a verifiably derived image digest. Confirm health and runtime
 identity before live verification.
 
+For a production-impacting change, release through the frozen stages. At each
+stage observe the named outcome and guardrail signals for the frozen window, then
+apply the deterministic decision: promote only when all promotion thresholds pass;
+hold when evidence is incomplete; abort or rollback when a halt threshold fires.
+Verify the rollback mechanism and kill switch before exposure. Record the owner
+and a receipt for every decision. A release plan is not evidence that a stage ran.
+
 ### 7. Verify the deployed user journey
 
 Repeat the relevant Chrome journey against the deployed environment. Include
@@ -354,6 +428,10 @@ history or claim `done`. Save the exact revision, environment, input, Run ID,
 timestamps, visible state, network evidence, and logs, then add a boundary
 regression before re-entering implementation.
 
+After the frozen observation window, evaluate the production outcome and guardrail
+measures for the same experience IDs. A functioning deployment is not successful
+delivery when the intended outcome misses its threshold or a guardrail is breached.
+
 ### Feed repaired delivery failures back into SQM
 
 When an observed failure was repaired, prepare one bounded `delivery.json` record
@@ -374,10 +452,11 @@ and validation ordering still require Delivery Loop execution controls.
 
 Remove scoped fixtures and prove the residual count is zero. Deliver a compact
 completion receipt containing shared-spec baseline/To-Be revisions and status,
-cross-view and implementation review results, pre/post-PR SQM proofs and historical
-coverage gaps, repository revisions, PR and CI, independent
+the frozen review plan and identity-bound review results, applicable SQM proofs
+and their reuse/rerun decision, historical coverage gaps, repository revisions, PR and CI, independent
 review, container/runtime results, local Chrome evidence, merge and deployment
-identity, deployed Chrome evidence, artifacts, cleanup, skipped gates, and
+identity, rollout-stage and outcome/guardrail results, deployed Chrome evidence,
+artifacts, cleanup, skipped gates, and
 residual risk. Convert recurring findings into the smallest maintainable rule,
 test, static check, or source-of-truth update selected by the five-response
 comparison. Bound debt cleanup by scope, change size, and completion criteria;

package/src/codex-plugins/simy/skills/agentic-delivery-loop/references/acceptance-evidence.md

@@ -24,6 +24,13 @@ together for the beneficiary to succeed, include an end-to-end criterion in
 addition to narrower diagnostic criteria. Independent coverage review compares
 the experience contract and original request to the frozen rows before coding.
 
+For production-relevant experience IDs, extend the same charter with outcome and
+guardrail measures. Each measure names the signal, independent source,
+observation window, threshold, resulting decision and owner. A rollout policy
+references those measure IDs for promotion and halt decisions. These fields are
+part of the same acceptance source and readable results view, not a second
+success checklist.
+
 Each criterion has two layers:
 
 - `user`: a goal-driven user journey with visible interactions and evidence of the
@@ -64,6 +71,11 @@ After every evaluated action (test, repair, review or changed inputs):
 All rows, including pending/failed ones, stay visible. A green matrix cannot advance
 an unrelated gate or prove merge/deployment. Validate again for the final environment.
 
+During staged release, append the stage, exposure, observed window, measure
+results and deterministic `promote`, `hold`, `abort` or `rollback` decision to
+the current results and receipt. Planned thresholds are not observations. A
+healthy deployment cannot replace a missed outcome or breached guardrail.
+
 After the exact candidate is built in a production-like local environment, run
 the complete experience and regenerate `checklist.md` for that same revision,
 environment, fixture, and input. Read the user and system rows together as a

package/src/codex-plugins/simy/skills/agentic-delivery-loop/references/delivery-levels.md

@@ -37,11 +37,11 @@ messages.
 
 | Level | Name | Intended work | Verification and review policy |
 | --- | --- | --- | --- |
-| 1 | 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; require the broadest applicable independent review and repository gates. |
-| 2 | Protected | Persistence, permissions, shared contracts, external side effects, cross-repository changes, and medium-risk migrations | Verify both evidence layers for every affected outcome, shared boundaries, retry/idempotency and recovery; require independent review of the change and affected integrations. |
-| 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; require independent design/To-Be/PR review, scoped to the affected path. |
-| 4 | Fast | Small, isolated, reversible UI or implementation changes | Run the direct regression and real affected path; add broader checks only for touched shared boundaries; keep mandatory review and evidence gates. |
-| 5 | Fastest | Copy, documentation, comments, metadata, or similarly trivial changes with no runtime/data/security effect | Verify the changed artifact, final diff, packaging/link integrity where applicable, and every repository-mandated check; do not claim untested runtime behavior. |
+| 1 | 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. |
+| 2 | 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. |
+| 4 | 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. |
+| 5 | 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
@@ -69,8 +69,9 @@ always choose a lower numbered, safer level.
 Every level preserves:
 
 - frozen success criteria and independent acceptance sources;
-- shared system As-Is/To-Be, cross-view consistency and independent agent reviews;
-- pre/post-PR SQM gates under explicit opt-in, with historical coverage reported;
+- 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;
@@ -78,3 +79,16 @@ Every level preserves:
 - 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.

package/src/codex-plugins/simy/skills/agentic-delivery-loop/references/minimum-completion.md

@@ -139,8 +139,8 @@ external provider calls are introduced.
 
 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, independent reviews and
-pre/post-PR SQM. These are controller workflow obligations, not fields magically
+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 skill and cannot claim an enforced host hook.

package/src/codex-plugins/simy/skills/agentic-delivery-loop/references/shared-system-specifications.md

@@ -34,9 +34,11 @@ At the start of each run:
 5. Link each experience ID to workflow, screen/control, state/sequence, API/event,
    data/relationship, permission and runtime boundaries as applicable. Map these
    stable system IDs to the run's criterion rows and implementation/evidence locations.
-6. Obtain independent design review before implementation. Supply the original
-   request, shared baseline, To-Be and linked unchanged views. Missing evidence or
-   contradictory views remains pending/failed, never silently accepted.
+6. Freeze the delivery-level review plan. At levels that require a separate
+   design review, obtain it before implementation; at level 3 the independent
+   final-candidate review may cover design, implementation and evidence together.
+   Supply the original request, shared baseline, To-Be and affected links. Missing
+   evidence or contradictory views remains pending/failed, never silently accepted.
 
 After the exact local candidate is built, update the existing acceptance matrix
 and its readable table for those same experience IDs. Compare expected experience,
@@ -68,13 +70,15 @@ interface views; do not invent application screens, APIs, tables or infrastructu
 
 ## Review evidence and neutral agents
 
-All reviews use independent agents/sessions, including design, cross-view
-consistency, implementation-versus-To-Be, verification changes and PR review.
-An agent must not approve work it authored. A reviewer can re-review fixes to its
-findings if it did not implement the fixes. Supply raw sources, not desired answers;
-require inspected references, discrepancies, uncertainty and a reasoned verdict.
-Use the repository-required model (gpt-5.5 / xhigh where mandated and available).
-If independent review is unavailable, report that gate as blocked.
+Required reviews use independent agents/sessions; an agent must not approve work
+it authored. Follow the risk-proportionate plan in `delivery-levels.md` instead of
+creating design, cross-view, implementation and PR reviews by default. A reviewer
+may cover several review kinds in one receipt when the candidate inputs are the
+same, and can re-review fixes it did not implement. Supply raw sources, not desired
+answers; require inspected references, discrepancies, uncertainty and a reasoned
+verdict. Use the repository-required model (gpt-5.5 / xhigh where mandated and
+available). If a required independent review is unavailable, report that gate as
+blocked.
 
 Persist a compact review receipt: reviewer/session identity, review kind, original
 request and shared baseline/To-Be references, candidate revisions, inspected views
@@ -122,17 +126,22 @@ Use concrete regressions for relevant uncovered incidents and have an independen
 reviewer assess coverage; keep missing incident history or untested boundaries
 visible. No finite test promises absence of all future bugs.
 
-Pre-PR: implementation-to-To-Be review and relevant regressions pass, then run SQM;
-repair findings within the bounded loop, re-review changed work, and rerun against
-the final candidate before creation. On unavailable/failed proof, withhold creation
-and report the exact blocker while continuing independent authorized preparation.
-
-Post-PR: fetch the actual PR head/base and check out/verify that combination, run
-both SQM phases again into new paths, inspect proof and current CI, and obtain
-independent PR/evidence review. The pre-PR proof cannot stand in for this run.
-If it fails, retain the PR as draft/not-ready with unmet gates recorded, repair and
-rerun affected independent reviews and SQM. A changed head/base/spec or relevant
-bundle invalidates affected approvals and proofs; preserve old receipts as history.
+Draft creation: after authority and local regressions, publish a Draft so the exact
+remote candidate can be inspected. Draft existence is not gate approval.
+
+Before Ready or merge, pass the frozen review plan. When the explicitly opted-in
+plan requires SQM, run it against the final candidate; repair findings within the
+bounded loop and rerun affected gates. On an unavailable/failed required proof,
+retain Draft/not-ready and report the exact blocker while continuing independent
+authorized preparation.
+
+Post-PR: fetch and verify the actual PR head/base and current CI. Reuse the pre-PR
+SQM proof only when repository, head, base, working-tree/diff, specification,
+policy, knowledge bundle, evidence and relevant environment identities are exactly
+unchanged and the signed proof verifies. Rerun into a new path when any identity
+changed or a PR-only scanner/policy becomes applicable. Apply the same rule to
+independent review. If a required gate fails, retain the PR as draft/not-ready,
+repair and rerun affected gates. Preserve superseded receipts as history.
 Promote Ready only with current required gates, including applicable combined-state
 verification. Merge and deployment still require their own authority and evidence.
 

package/src/codex-plugins/simy/skills/agentic-delivery-loop/references/state-and-receipts.md

@@ -12,8 +12,9 @@ Persist one controller-owned snapshot with at least:
 - frozen experience-contract identities, their mapping to acceptance rows, and
   the current readable local-experience table path and digest;
 - acceptance-source identities and digests, architecture boundaries, applicable
-  rule decisions, risk tier, requested/effective delivery levels, the safety
-  ceiling reason, and chat-confirmation receipt;
+  rule decisions, human-decision receipt IDs, approved canonical sources and
+  their precedence and fallback semantics, risk tier, requested/effective
+  delivery levels, the safety ceiling reason, and chat-confirmation receipt;
 - repository, base SHA, head SHA, companion SHAs, merge SHA, image digests, and
   deployed revision;
 - target environments, user journey, user/tenant fixture identities, and
@@ -22,7 +23,8 @@ Persist one controller-owned snapshot with at least:
 - frozen acceptance charter digest, current matrix/table paths and digests,
   superseded matrix snapshots, and the acceptance validator result for each gate;
 - verification-boundary changes, deferred-debt references, and applicable
-  outcome and guardrail measures;
+  outcome and guardrail measures, rollout policy, current rollout stage and
+  latest deterministic release decision;
 - attempt number, retry/time/cost budgets, and failure fingerprints;
 - append-only receipt IDs, evidence references, timestamps, and cleanup state.
 
@@ -35,6 +37,7 @@ an integrity failure.
 Use the smallest applicable receipts rather than free-form completion claims:
 
 - `CharterReceipt`
+- `HumanDecisionReceipt`
 - `FailureReproductionReceipt`
 - `ImplementationReceipt`
 - `LocalVerificationReceipt`
@@ -46,6 +49,8 @@ Use the smallest applicable receipts rather than free-form completion claims:
 - `ChromeUserJourneyReceipt`
 - `MergeReceipt`
 - `DeploymentIdentityReceipt`
+- `RolloutStageReceipt`
+- `OutcomeEvaluationReceipt`
 - `HealthReceipt`
 - `LiveEvidenceReceipt`
 - `CleanupReceipt`
@@ -63,6 +68,29 @@ Each receipt should contain:
   network traces, DB rows, artifact hashes, CI/deploy URLs, and timestamps;
 - a typed error category and retryability when unsuccessful.
 
+A `HumanDecisionReceipt` additionally stores or immutably references the exact
+decision packet presented to the human. Preserve the question and scope; every
+option's user benefit, user and operational risk, compatibility and migration
+effects, fallback behavior, reversibility, support and maintenance cost,
+security and trust-boundary constraints, validation plan, and material evidence
+gaps; any excluded unsafe or non-compliant option and its reason; and any
+recommendation separately from the decision. Record the selected option's exact
+text and stable ID or digest, conditions attached to the selection, decision
+maker, timestamp, and a stable approval reference such as a message or turn ID
+or an immutable transcript or artifact digest, with its channel and context when
+applicable. The selection may reference a viable presented option or an explicit
+user-authored modification or combination. When the user's decision is clear,
+executable, and introduces no undisclosed material trade-off, update the packet
+and record that same message as approval without requesting confirmation again.
+If the decision is ambiguous or introduces a material trade-off not yet explained,
+clarify only the unresolved point before proceeding with dependent work. Mandatory
+security, privacy, data-integrity, and external-contract constraints still apply.
+
+A successful `HumanDecisionReceipt` requires an explicit selection. Until then,
+store the pending decision packet in the snapshot and publish the monitor verdict
+`needs_hil` with action `request_hil`; never synthesize or infer approval from a
+recommendation, silence, or an implementation pattern.
+
 ## Monitor verdict and policy action
 
 The semantic monitor may emit:
@@ -101,6 +129,7 @@ Evidence is revision-bound:
 | Change | Invalidate |
 |---|---|
 | Charter or explicit success conditions | All affected downstream gates |
+| Human decision, canonical source, precedence, or fallback | All dependent implementation and verification evidence |
 | Acceptance source, test oracle, assertion, or CI/security gate changes | The affected gate and all dependent downstream evidence |
 | Head SHA or generated source changes | Local, CI, integration, container, and live evidence |
 | Base SHA or companion revision changes | Integration and later evidence |
@@ -108,6 +137,8 @@ Evidence is revision-bound:
 | Merge SHA changes | Deployment identity and live evidence |
 | Deployed revision changes | Health and live evidence |
 | Browser profile, tenant, or fixture changes | Affected user-journey evidence |
+| Outcome/guardrail signal, source, window, threshold, decision, or owner changes | Affected release and outcome evidence |
+| Rollout stage, exposure, recovery control, or kill switch changes | Affected rollout and later live evidence |
 
 Do not discard historical receipts; mark them superseded for the current gate.
 
@@ -146,11 +177,13 @@ done =
   && deployed_exact_revision
   && health_verified
   && live_verified
+  && production_outcome_evaluated
   && cleanup_verified
   && completion_receipt_created
 ```
 
-Remove only genuinely non-applicable terms and record why. If merge or deploy
+Remove only genuinely non-applicable terms and record why; production outcome
+evaluation is non-applicable when no production-impacting release is in scope. If merge or deploy
 is outside current authority, stop at the highest proven pre-authority state.
 
 Acceptance evidence must cover every applicable criterion for the target gate,

package/src/codex-plugins/simy/skills/agentic-delivery-loop/scripts/check-minimum-completion.mjs

@@ -4,6 +4,7 @@ import { lstat, readFile, realpath } from "node:fs/promises";
 import path from "node:path";
 import { fileURLToPath } from "node:url";
 import { isDeepStrictEqual } from "node:util";
+import { normalizeProductionContract } from "./production-contract.mjs";
 import {
   checkAcceptance,
   contextDigest,
@@ -49,6 +50,7 @@ export function minimumCharter(charter) {
     run_id: charter.id,
     source,
     experience,
+    ...normalizeProductionContract(charter.completion_contract, ids),
     criteria: charter.acceptance_criteria.map((outcome, index) => ({
       id: ids[index],
       outcome,

package/src/codex-plugins/simy/skills/agentic-delivery-loop/scripts/production-contract.mjs

@@ -0,0 +1,158 @@
+// Shared by the CLI and the independently installed skill. Keep this module
+// self-contained so validation never depends on the repository checkout.
+const cleanString = value => typeof value === "string" ? value.trim() : "";
+const record = value => value && typeof value === "object" && !Array.isArray(value) ? value : {};
+const uniqueStrings = value => [...new Set(Array.isArray(value) ? value.map(cleanString).filter(Boolean) : [])];
+const criterionIdPattern = /^[A-Za-z][A-Za-z0-9]*(?:[-_.][A-Za-z0-9]+)*$/;
+
+export function normalizeProductionContract(source, ids) {
+  const outcome_contract = normalizeOutcomeContract(source.outcome_contract, ids);
+  return { outcome_contract, rollout_policy: normalizeRolloutPolicy(source.rollout_policy, outcome_contract) };
+}
+
+function normalizeOutcomeContract(value, criterionIds) {
+  const source = record(value);
+  const criteria = new Set(criterionIds);
+  const outcomeMeasures = normalizeMeasures(
+    source.outcome_measures,
+    criteria,
+    new Set(["promote", "hold"]),
+    "outcome",
+  );
+  const guardrailMeasures = normalizeMeasures(
+    source.guardrail_measures,
+    criteria,
+    new Set(["hold", "abort", "rollback"]),
+    "guardrail",
+  );
+  const allIds = [
+    ...outcomeMeasures.map((measure) => measure.id),
+    ...guardrailMeasures.map((measure) => measure.id),
+  ];
+  if (new Set(allIds).size !== allIds.length) {
+    throw new Error("Duplicate outcome or guardrail measure IDs");
+  }
+  return {
+    outcome_measures: outcomeMeasures,
+    guardrail_measures: guardrailMeasures,
+  };
+}
+
+function normalizeMeasures(value, criterionIds, allowedDecisions, kind) {
+  if (value === undefined || value === null) return [];
+  if (!Array.isArray(value)) throw new Error(`Invalid ${kind} measures`);
+  const measures = value.map((item) => {
+    const source = record(item);
+    const measure = {
+      id: cleanString(source.id),
+      criterion_id: cleanString(source.criterion_id),
+      signal: cleanString(source.signal),
+      source: cleanString(source.source),
+      window: cleanString(source.window),
+      threshold: cleanString(source.threshold),
+      decision: cleanString(source.decision).toLowerCase(),
+      owner: cleanString(source.owner),
+    };
+    if (
+      !criterionIdPattern.test(measure.id) ||
+      !criterionIds.has(measure.criterion_id) ||
+      !measure.signal ||
+      !measure.source ||
+      !measure.window ||
+      !measure.threshold ||
+      !allowedDecisions.has(measure.decision) ||
+      !measure.owner
+    ) {
+      throw new Error(`Invalid ${kind} measure`);
+    }
+    return measure;
+  });
+  if (new Set(measures.map((measure) => measure.id)).size !== measures.length) {
+    throw new Error(`Duplicate ${kind} measure IDs`);
+  }
+  return measures;
+}
+
+function normalizeRolloutPolicy(value, outcomeContract) {
+  const source = record(value);
+  const required = source.required === true;
+  if (!required) {
+    return {
+      required: false,
+      reason: cleanString(source.reason) || "No production rollout is in scope",
+      stages: [],
+      promotion_requires: [],
+      halt_on: [],
+      rollback: null,
+      kill_switch: null,
+    };
+  }
+  const stages = normalizeRolloutStages(source.stages);
+  const outcomeIds = new Set(
+    outcomeContract.outcome_measures.map((measure) => measure.id),
+  );
+  const guardrailIds = new Set(
+    outcomeContract.guardrail_measures.map((measure) => measure.id),
+  );
+  const promotionRequires = uniqueStrings(source.promotion_requires);
+  const haltOn = uniqueStrings(source.halt_on);
+  const rollback = normalizeRecoveryControl(source.rollback, "rollback");
+  const killSwitch = normalizeRecoveryControl(source.kill_switch, "kill switch");
+  if (
+    stages.length < 2 ||
+    outcomeIds.size === 0 ||
+    promotionRequires.length !== outcomeIds.size ||
+    promotionRequires.some((id) => !outcomeIds.has(id)) ||
+    guardrailIds.size === 0 ||
+    haltOn.length !== guardrailIds.size ||
+    haltOn.some((id) => !guardrailIds.has(id))
+  ) {
+    throw new Error("Invalid progressive rollout policy");
+  }
+  return {
+    required: true,
+    reason: cleanString(source.reason) || "Production impact requires progressive exposure",
+    stages,
+    promotion_requires: promotionRequires,
+    halt_on: haltOn,
+    rollback,
+    kill_switch: killSwitch,
+  };
+}
+
+function normalizeRolloutStages(value) {
+  if (!Array.isArray(value)) throw new Error("Invalid rollout stages");
+  const stages = value.map((item) => {
+    const source = record(item);
+    const stage = {
+      id: cleanString(source.id),
+      exposure: cleanString(source.exposure),
+      observation_window: cleanString(source.observation_window),
+    };
+    if (
+      !criterionIdPattern.test(stage.id) ||
+      !stage.exposure ||
+      !stage.observation_window
+    ) {
+      throw new Error("Invalid rollout stage");
+    }
+    return stage;
+  });
+  if (new Set(stages.map((stage) => stage.id)).size !== stages.length) {
+    throw new Error("Duplicate rollout stage IDs");
+  }
+  return stages;
+}
+
+function normalizeRecoveryControl(value, label) {
+  const source = record(value);
+  const control = {
+    mechanism: cleanString(source.mechanism),
+    owner: cleanString(source.owner),
+  };
+  if (!control.mechanism || !control.owner) {
+    throw new Error(`Invalid ${label} control`);
+  }
+  return control;
+}
+

package/src/orchestrator/completion-contract.js

@@ -1,3 +1,4 @@
+import { normalizeProductionContract } from "../codex-plugins/simy/skills/agentic-delivery-loop/scripts/production-contract.mjs";
 import { cleanString, stringArray } from "./shared.js";
 
 export const COMPLETION_CONTRACT_VERSION = 2;
@@ -15,13 +16,16 @@ export function buildCompletionContract({
   const proofRequired = stringArray(source.proof_required);
   const criteria = stringArray(acceptanceCriteria);
   const userOutcome = cleanString(source.user_outcome) || cleanString(requirement);
+  const ids = criterionIds(source.criterion_ids, criteria.length);
+  const productionContract = normalizeProductionContract(source, ids);
   return {
     version: COMPLETION_CONTRACT_VERSION,
     user_outcome: userOutcome,
     minimum_scope:
       minimumScope.length > 0 ? minimumScope : criteria,
-    criterion_ids: criterionIds(source.criterion_ids, criteria.length),
+    criterion_ids: ids,
     experience: normalizeExperience(source.experience, userOutcome),
+    ...productionContract,
     non_goals: stringArray(nonGoals),
     proof_required: uniqueStrings([
       "criterion_evidence",

package/src/orchestrator/independent-audit.js

@@ -65,6 +65,9 @@ export function buildIndependentAuditInstruction(charter, attempt) {
         "Treat executor claims as untrusted until supported by repository evidence.",
         "Compare the original request and frozen experience to the complete stable criterion-ID list and implementation mapping. Report forgotten features, dead controls, unsaved results and broken integration. Open the raw minimum evidence, verify its oracle and actual runtime observations; matching expected/actual JSON and hashes alone do not prove truth. Check reload/session return and persisted values/ownership when saving is required.",
         "For every stable criterion ID, return a criterion_results entry only after directly checking its cited proof and observed outcome.",
+        "For production-relevant criteria, verify that each outcome and guardrail measure names its signal, independent source, observation window, threshold, decision, owner, and criterion ID.",
+        "When rollout_policy.required=true, verify that staged exposure and deterministic promote, hold, abort, rollback, and kill-switch controls are frozen before release. Do not treat a rollout plan as deployed evidence.",
+        "Apply the frozen delivery-level review plan: reuse a prior review only when its exact head, base, specification, policy, evidence, and environment identities are unchanged; otherwise review the affected boundary again.",
         charter.evidence_policy?.browser_required
           ? "Open and inspect the actual local screenshots or videos. Return visual_review.inspected=true only after checking their visible content against the acceptance criteria."
           : "Do not require visual evidence when the Charter does not require browser evidence.",

package/src/orchestrator/instruction.js

@@ -43,6 +43,9 @@ export function buildCodingInstruction(
         `Usable outcome: ${charter.completion_contract?.experience?.usable_outcome || "not recorded"}`,
         `Recovery experience: ${charter.completion_contract?.experience?.recovery || "not recorded"}`,
         `Forbidden experiences:\n${bullets(charter.completion_contract?.experience?.forbidden_experiences || [])}`,
+        `Outcome measures: ${JSON.stringify(charter.completion_contract?.outcome_contract?.outcome_measures || [])}`,
+        `Guardrail measures: ${JSON.stringify(charter.completion_contract?.outcome_contract?.guardrail_measures || [])}`,
+        `Progressive rollout policy: ${JSON.stringify(charter.completion_contract?.rollout_policy || { required: false })}`,
         `Minimum scope:\n${bullets(charter.completion_contract?.minimum_scope || charter.acceptance_criteria)}`,
         `Non-goals:\n${bullets(charter.completion_contract?.non_goals || charter.thread_state.non_goals)}`,
         `Proof required:\n${bullets(charter.completion_contract?.proof_required || [])}`,