@awak-app/simy-cli 0.7.15 → 0.7.16

package/src/orchestrator/delivery/references/acceptance-evidence.md

@@ -1,218 +1,6 @@
-# Acceptance evidence and living checklist
+# Checking the requested result
+Use the original request and later corrections to determine what must work. Exercise the actual product or inspect the actual output. Verify relevant error and recovery paths and repair failures. A process finishing or a test passing does not establish an unrelated user outcome.
 
-## Before implementation
+Reuse direct observations and ordinary test output. No acceptance table, source-ID ledger, screenshot package, citation syntax or review receipt is required. Preserve useful failure details for repair, without creating documents solely to authorize completion.
 
-Apply [UX behavioral completeness](ux-specification.md) to the same stable criteria
-through every phase. Preserve the complete source-linked interaction contract in
-the canonical specification; the compact checklist is its status view, not a
-replacement for the required behavior, branches, postconditions and recovery detail.
-
-Freeze the user experience before proposing the solution. Read-only discovery may
-inform it, but the first authored success record states the beneficiary and
-context, their goal, the complete usable outcome, what they should see,
-understand, and be able to do next at each observable moment, applicable recovery
-and forbidden experiences, and how those moments will be observed. Assign stable
-UX/acceptance IDs. A screen, component, endpoint, task, or stored row is an
-implementation detail unless it is tied to this experience.
-
-The controller externalizes every acceptance condition with a stable ID, observable
-outcome, source independent of the candidate, and required checks. For each
-verification gate, freeze its applicable criteria in `charter.json` and record the
-SHA-256 of the exact file bytes in the controller-owned snapshot. Reconcile the
-gate charters against the overall delivery charter so no requirement disappears.
-Do not choose a convenient subset after observing failures.
-
-Use these criteria as the structured form of the experience contract rather than
-creating a second UX checklist. Cover the full path from its real trigger to its
-usable outcome and the applicable recovery path. When several parts must work
-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
-  actual outcome. For CLI/document work, use the actual command or consumer.
-- `system`: independent deterministic checks of the affected contract, API, stored
-  values, identity/tenant/authorization, concurrency, or artifacts.
-
-For save operations, both must observe the same run, fixture and input. The user
-saves, reloads and returns in a new session; the technical check queries persisted
-values and ownership, tests unauthorized access and duplicate/retry behavior where
-relevant, and correlates request IDs/logs. An HTTP 500, other unexpected HTTP error,
-network failure, or a persistence mismatch fails the affected check. A 200 response
-or success toast alone is not a persistence oracle.
-
-Each layer is required unless genuinely inapplicable. Put a reason and authoritative
-source in the frozen charter for an exception. Tool unavailability, failed tests,
-lack of time, or missing authority mean pending/blocked, not inapplicable. At least
-one layer must remain required. User-facing state changes normally require both.
-
-## Update throughout the loop
-
-Keep `matrix.json` for current results and `checklist.md` for the readable table.
-After every evaluated action (test, repair, review or changed inputs):
-
-1. Append an immutable receipt and retain the previous matrix/table snapshot.
-2. Update current results with action, observation, timestamp, evidence paths and
-   hashes, status, unmet reason, and next action. Use `pending`, `failed`, `passed`;
-   render `not_applicable` only from the frozen charter.
-3. Bind results to the current context digest. When code, base/companion revision,
-   environment, fixture, inputs, or acceptance source changes, invalidate affected
-   receipts under the state contract; display stale checks as pending. Do not copy
-   a new digest onto an old observation to make it current.
-4. Run the validator and replace the readable table with its `markdown` output
-   (or `--markdown` stdout). Include the snapshot's revision and current gate in
-   the accompanying receipt. The table is a view of JSON, not a second authority.
-5. Inspect raw evidence and remaining rows before choosing the next bounded action.
-6. Perform that action when safe and authorized; do not stop after displaying the
-   table. Repair failures or missing behavior, run untested paths, collect missing
-   evidence, rerun stale checks, then validate and regenerate the table. Repeat
-   until all applicable requested outcomes and authorized endpoint gates pass.
-   A proposed next step is not a substitute for feasible execution.
-
-Yellow and red tables are progress, not successful delivery. For in-progress
-dependencies use available bounded waits/rechecks or approved monitoring without
-busy-polling or duplicate jobs. Preserve authorization and progress checks; local time/attempt/token counters are informational and keep the
-requester informed. If progress genuinely requires new authority, access, a
-decision, dependency availability or a triggered no-progress/failure circuit, retain affected rows and record
-observed blocker, safe alternatives tried, exact missing input, owner and resume
-trigger. Continue independent work; end only with an explicitly unfinished
-disposition when no further safe in-scope action remains or a safety/user stop
-applies. Do not require another “continue” for already authorized feasible work.
-An issue or remediation PR does not satisfy the row it tracks. Do not weaken
-criteria, hide rows, invent evidence or change the endpoint to
-force green. Local execution counters do not impose a completion limit. Reconcile the final full table against the original request and all
-current endpoint gates before reporting verified_complete.
-
-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.
-
-The readable Markdown begins with the default compact `依頼チェックリスト`:
-
-| # | ご依頼 | 現状 | 判定 |
-| ---: | --- | --- | :---: |
-| 1 | Frozen criterion outcome | Latest combined observation, or unmet reason and next repair | ✅ / 🟡 / ❌ |
-
-Render one row per frozen criterion in charter order. Aggregate its layer results
-deterministically: all applicable layers passed is `✅`; any applicable failed
-layer is `❌`; otherwise it is `🟡`. A non-applicable layer remains visible with
-its authoritative reason in the detailed table; every valid criterion keeps at
-least one applicable layer. A mixture of passed and pending is yellow, not green.
-Show green/yellow/red counts, the highest proven state, and validator status
-immediately below the compact table. In a terminal receipt,
-the controller also prints its disposition there.
-
-The compact table is maintained in the evidence record after the charter is
-frozen, after every evaluated attempt, and in the final evidence receipt.
-`checklist.md` also retains the detailed layer table so evidence, methods, and
-repairs remain reviewable. User-facing reporting follows the common
-[outcome reporting contract](../../../workflow-reporting.md). Show the table when
-requested or when it best answers the request, not after every internal step.
-An A/B-only or no-test-detail instruction takes precedence over the default table.
-Keep every non-green row internally and disclose any material effect on the
-requested answers or completion claim; brevity cannot hide incomplete delivery. Do not turn `pr_ci_green`, a healthy service,
-or a passing narrow check into a green request row unless every applicable layer
-for that criterion passed against the current charter and context.
-
-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
-single experience table: expected outcome, actual user observation, independent
-postcondition/integration result, evidence, status, and next repair. Missing,
-pending, failed, stale, or unverifiable applicable rows prevent
-`user_like_local_verified`. Individually working components cannot override a
-failed or absent end-to-end row.
-
-## File contract
-
-Charter example (illustrative values must be replaced with actual requirements):
-
-```json
-{
-  "schema_version": 1,
-  "run_id": "save-run-42",
-  "criteria": [{
-    "id": "SAVE-1",
-    "outcome": "An owner returning to the task sees the saved note, understands it was retained, and can continue editing",
-    "acceptance_source": "Approved issue acceptance criteria, revision 3",
-    "layers": {
-      "user": {"applicability": "required", "method": "Save in Chrome, reload, sign in again and compare the note"},
-      "system": {"applicability": "required", "method": "Read stored note and owner; check unauthorized read and duplicate-save behavior"}
-    }
-  }]
-}
-```
-
-The matrix has `schema_version: 1`, `charter_sha256`, `context`, and `results`.
-Context requires `run_id`, `stage`, `environment`, `fixture_id`, `input_sha256`,
-and `source_revisions` mapping repository identifiers to full 40-character SHAs.
-Include base/companion revisions, image digests, deployed revision, profile and
-other relevant identities as additional context fields. `contextDigest(context)`
-from the packaged script hashes recursively key-sorted JSON. Every context field
-participates. Compute and retain it from the independently observed controller
-snapshot, not from an untrusted result's requested context.
-
-Each result is `{ "id": "SAVE-1", "layers": { "user": cell, "system": cell } }`.
-A passed cell requires:
-
-```json
-{
-  "status": "passed",
-  "charter_sha256": "64 lowercase hex characters of the frozen charter bytes",
-  "context_sha256": "64 lowercase hex characters from the controller snapshot",
-  "action": "Actual operation or command executed",
-  "observation": "Actual observed result, including values or a comparison verdict",
-  "observed_at": "2026-09-13T10:00:00Z",
-  "evidence": [{"path": "evidence/save-check.json", "sha256": "64 lowercase hex characters of the file bytes"}]
-}
-```
-
-Failed/pending cells keep the same charter/context digests, action/observation where available,
-`reason`, and `next_action`. Missing cells render pending. Results cannot waive a
-required layer. To change applicability, update the authoritative charter through
-the existing charter-patch process and invalidate dependent results.
-Every passed cell is bound to both digests. An approved charter patch cannot reuse
-old cells simply by updating the matrix header; record new verification first.
-
-## Run and interpret
-
-From the packaged Web/CLI delivery directory, invoke the bundled script with Node
-20 or later. Paths are explicit; never assume another machine's home directory:
-
-```text
-node <delivery-directory>/scripts/check-acceptance.mjs charter.json matrix.json <trusted-charter-sha256> <current-context-sha256>
-```
-
-Exit 0 means `evidence_complete`, exit 1 means `evidence_incomplete`, and exit 2
-means invalid inputs. JSON output includes all checklist rows, errors and a Markdown
-table; append `--markdown` for the table alone. A pending run may exit 1 normally;
-use its rows to decide what to verify next. Invalid input cannot establish a gate.
-
-Evidence files must be explicit regular files under the matrix directory, not
-URLs, symlinks or parent paths. The checker reads and hashes only those referenced
-files, sends nothing, executes nothing, and prints no file contents. JSON inputs
-are limited to 1 MiB, evidence files to 16 MiB each. Store larger recordings in the
-normal evidence store and use a bounded verified receipt here; the verifier must
-check that receipt's target. Keep the bundle private and stable during validation.
-
-This checks completeness, current-context binding and file integrity, not whether
-a collector told the truth, a criterion is adequate, or a system is deployed.
-Hashes are not signatures. The controller must protect the frozen digest, verify
-requirement coverage and genuine non-applicability, and inspect raw evidence.
-Independent review checks the oracle and findings; the validator is an additional
-gate within this workflow, not a globally installed hook. The CLI now additionally
-uses [minimum completion](minimum-completion.md) to enforce current functional
-evidence at its promotion boundary; this basic validator alone is insufficient.
+If a check cannot run, keep the affected behavior unverified and investigate the obstacle. Do not label it passed or silently drop the requested outcome. Report material remaining limits in the user's requested format.

package/src/orchestrator/delivery/references/change-boundary-matrix.md

@@ -1,105 +1,6 @@
-# Change-Boundary Verification Matrix
+# Choosing checks for a change
+Inspect affected behavior and shared dependencies. Start with a direct regression, then run the relevant repository checks and real execution path. Use the actual failure to decide what to fix. Reuse unaffected results rather than repeating every test.
 
-Apply only the lanes touched by the change, plus shared boundaries needed to
-prove the user outcome.
+For persistence, check reload and retry behavior. For permissions, check allowed and denied access. For external operations, check duplicate prevention and unknown-result recovery. For shared APIs, check both producer and consumer. For UI changes, check the visible flow, clarity, keyboard access and error recovery where relevant.
 
-## Common foundation
-
-- Preserve a failing reproduction or explain why it cannot be captured.
-- Bind acceptance to a human-confirmed requirement, external contract, prior
-  regression, or another source independent of the candidate implementation.
-- Run focused regressions, formatting, lint, type checks, unit tests, and the
-  real affected build/runtime in that order when available.
-- Inspect the final diff for scope, secrets, generated files, and unrelated
-  churn.
-- Use current source and dependency revisions in every evidence receipt.
-
-## Architecture, rules, and documentation
-
-- Read instruction files as routing maps and follow only the relevant links to
-  architecture, product, security, reliability, and intentional-debt sources.
-- Verify dependency direction and other deterministic critical invariants with
-  existing structural tests or static analysis. Add or change enforcement only
-  after the five-response comparison in the main workflow.
-- Distinguish merge-blocking invariants from advisory debt. Keep blocking gates
-  minimal and record non-blocking findings with evidence and an owner or explicit
-  follow-up condition.
-- Check that changed behavior and source-of-truth documentation agree, that
-  required links resolve, and that superseded guidance is removed or marked.
-- Flag deleted tests, weakened assertions, expected-value changes, disabled
-  checks, and CI or security-policy relaxation for independent review. Re-run
-  the affected gate against the newly approved boundary.
-- Prefer small consolidation, deletion, or repair changes over broad cleanup.
-  Bound maintenance work by scope, change size, and an observable stop condition.
-
-## UI and user-state changes
-
-- Render the actual UI in a browser.
-- Exercise refresh during and after completion, back/forward navigation,
-  another session and return, delayed stream/poll responses, and stale-cache or
-  replica responses where relevant.
-- Verify follow-up and parent/child lineage, optimistic state reconciliation,
-  authorization, and tenant separation.
-- Capture and inspect screenshots; capture video for streaming, recovery,
-  animation, or timing-dependent behavior.
-
-## Authentication and session recovery (when touched)
-
-- Derive the error/state matrix from the current provider contract and application
-  policy. Distinguish a temporarily unavailable or unknown response from a
-  confirmed invalid, deleted or banned identity. Verify the expected exit/recovery
-  path as well as the message; a permanent failure must not trap the user in retry.
-- Include current membership suspension/removal, account/session switching and
-  stale in-flight results where affected. Preserve unknown-error handling unless
-  an authoritative contract changes it; do not turn all unknown errors into logout.
-- For refresh/cookie changes, inventory affected callers, propagation and concurrent
-  refresh behavior. Record untested callers and load concerns separately from
-  confirmed defects; a review follow-up is not automatically a release blocker.
-
-## Generated artifacts
-
-- Download through the user-facing path.
-- Verify non-empty bytes, expected type, stable hash, and ownership/tenant.
-- Open with the real consumer. Render every page/slide/sheet when layout
-  matters and inspect the rendered output.
-- Confirm final-result metadata and artifact storage agree.
-
-## Runtime and packaging
-
-- Build the exact production Dockerfile/image, not only a development image.
-- Start the real entrypoint and execute a representative app-server turn.
-- Check required binaries, fonts, renderers, runtime dependencies, health,
-  signals, and restart behavior inside the image.
-- Record the image digest and bind later evidence to it.
-
-## Backend, database, and asynchronous work
-
-- Apply migrations against an isolated representative database and verify
-  rollback/compatibility expectations where required.
-- Exercise the real API, authentication, authorization/RLS, persistence,
-  replay/idempotency, retries, concurrency, queue/worker delivery, and late
-  updates.
-- Confirm visible state against persisted rows and runtime logs using the same
-  Run ID.
-
-## Cross-repository changes
-
-- Pin every repository and contract revision.
-- Identify required merge/deploy order and backward-compatibility window.
-- Compose companion and parallel changes before Ready. For an older candidate,
-  compare current base behavior and successor changes, including permission guards,
-  canonical ownership and supported persisted formats. Reapply the requested delta
-  without restoring superseded behavior, even when Git reports no conflict.
-- When a regression expectation conflicts with a later contract, identify that
-  contract and preserve its protection. Independently review the expectation change
-  and test the combined behavior; do not weaken assertions just to obtain green.
-- Run the user journey against the combined revisions and record all SHAs and
-  image digests.
-
-## External providers
-
-- Use real APIs only when the charter permits cost and side effects.
-- Prefer scoped sandbox accounts, dedicated users/tenants, unique Run IDs, and
-  explicit cleanup.
-- Require human authorization for production messages, destructive writes, or
-  other consequential effects not already authorized.
+A matrix, incident inventory, independent review or new rule proposal is not required. Do not invent changes to satisfy a template. Preserve branch protection and required CI; skipped required checks are not passing checks.

package/src/orchestrator/delivery/references/chrome-user-verification.md

@@ -1,136 +1,8 @@
-# Codex Chrome User Verification
+# Browser verification
+When the request affects a browser experience, use the available authorized browser to exercise the relevant visible flow. Check what the user can understand and accomplish, including persistence and recovery when affected. Direct API tests can diagnose failures but do not establish usability of an untested UI.
 
-Read this before running a local production-like or deployed user journey with
-Codex controlling the user's Chrome through the browser extension.
+Use the correct candidate and environment. A local working journey does not establish deployment. After an authorized deployment, verify the target revision and the affected visible behavior.
 
-## Meaning of this gate
-
-This is goal-driven user simulation, not a direct API test and not merely a
-fixed selector script. Codex receives a user outcome, perceives the real page,
-and operates Chrome through normal visible interactions. Deterministic checks
-then judge the resulting evidence.
-
-Use distinct claims:
-
-- `user_like_local_verified`: the exact candidate revisions passed in a local
-  production-like stack through Chrome;
-- `live_verified`: the exact deployed revision passed in the target shared or
-  production environment through Chrome.
-
-## Prepare the local environment
-
-Prefer a Compose-style environment bundle over one monolithic container. Use
-the production Dockerfiles and exact candidate revisions for applicable
-services such as:
-
-```text
-web
-API / orchestration
-backend or edge functions
-agent runtime
-database and authentication
-queue and workers
-object storage
-supporting renderers or processors
-```
-
-Run Chrome on the host and route it to the environment through stable local
-URLs. Account for container networking: `127.0.0.1` inside a container is not
-the host. Use the platform's supported host gateway or service DNS and record
-the resolved endpoints.
-
-Start services, apply migrations and seeds, verify health, and record service
-SHAs plus image digests before opening the user journey.
-
-## Connect Codex to Chrome
-
-Use the Chrome/browser-control skill available in the current environment. The
-user's Chrome profile must have the ChatGPT browser extension installed and
-connected through the desktop app's Computer Use settings. Use the explicitly
-selected Chrome surface; do not silently substitute another browser.
-
-Use a dedicated verification profile and allowlist only the required local,
-dev, and external-provider domains. Do not inspect cookies, passwords, browser
-history, or profile storage. If authentication blocks the task, ask the user to
-sign in in the selected Chrome profile and resume from the same journey.
-
-## Define the user scenario
-
-Give the browser actor a natural-language goal and observable success criteria,
-not internal API steps. Example shape:
-
-```text
-Open the application, complete <real user objective>, wait for completion,
-refresh the page, leave and return through another session, follow up on the
-result, download the final artifact, and open it.
-```
-
-The actor should use visible UI interactions. Direct API, database, and log
-access are secondary evidence and diagnosis channels, not substitutes for the
-browser journey.
-
-## Use real APIs safely
-
-When permitted, use the actual model/provider and real integration APIs to
-exercise streaming, tool calls, latency, rate limits, and output variability.
-Require:
-
-- sandbox or dedicated verification accounts;
-- scoped credentials and tenant/user fixtures;
-- unique Run IDs and timestamps;
-- attempt, time, and spend caps;
-- dedicated Slack/Gmail/calendar or other external destinations;
-- reconciliation before retrying an ambiguous external effect;
-- recorded cleanup and residual count zero.
-
-Do not broaden existing authority. External messages, production writes,
-destructive operations, and new paid effects still require the applicable
-authorization.
-
-## Execute and collect evidence
-
-Codex may orchestrate the full sequence in one task:
-
-1. Build/start/restart services from the shell.
-2. Confirm health and runtime identity.
-3. Operate the application through Chrome.
-4. Capture screenshots and video when supported and relevant.
-5. Record visible messages, navigation, refresh/session behavior, download
-   paths, browser console/network failures, and timestamps.
-6. Correlate the visible result with backend logs, persisted state, Run IDs,
-   queue/worker activity, and artifact hashes.
-7. Evaluate the evidence against the frozen charter.
-8. On failure, classify the boundary, add a pre-fix regression, patch the
-   smallest surface, rebuild changed images, and repeat within the authorized scope while verification improves.
-
-The same Codex task may perform actor and verifier phases, but the verifier must
-use recorded observable evidence rather than accepting the actor's completion
-claim.
-
-## Default acceptance predicate
-
-Tailor this to the charter:
-
-```text
-chrome_user_journey_passed =
-  visible_result_confirmed
-  && refresh_persistence_confirmed
-  && session_return_confirmed
-  && follow_up_lineage_confirmed_when_applicable
-  && backend_run_id_matched
-  && no_unexpected_console_or_network_failure
-  && artifact_download_open_hash_confirmed_when_applicable
-  && fixture_cleanup_confirmed
-```
-
-Save the browser profile label, target URL/environment, source revisions, image
-digests, user/tenant fixture, Run ID, start/end time, screenshots/video,
-download hashes, and skipped checks in the receipt.
-
-## After deployment
-
-First verify that the target environment serves the exact merge revision or
-derived image digest. Then repeat the smallest user journey that still crosses
-the changed boundary. A preview, local environment, or healthy endpoint cannot
-establish `live_verified` for another deployed environment.
+Preserve authentication boundaries and use isolated test accounts or resources where needed. Do not inspect unrelated private browser data. Do not send messages, incur new costs or make production changes beyond existing authorization. Reconcile uncertain external effects before retries and clean up test resources you created.
 
+No fixed browser brand, container topology, recording, screenshot package, receipt or universal journey template is required unless the user specifically requests it. Capture information when useful to understand or repair a concrete problem.

package/src/orchestrator/delivery/references/cross-repository-control.md

@@ -1,76 +1,6 @@
-# Cross-Repository and Concurrent Delivery Control
+# Coordinating related changes
+Identify related changes and choose non-conflicting ownership for writes. Prefer isolated worktrees and test resources. Use leases or equivalent exclusive ownership for shared mutable databases, queues, profiles and ports; do not reset another task's resources.
 
-Read this reference before related Codex tasks, stacked PRs, multiple repositories,
-or shared test infrastructure can affect one user outcome.
+Check shared contracts and the combined user journey using the intended versions. A passing component test does not establish the whole result. Recheck affected boundaries when a dependency changes, retaining unaffected results. No integration matrix or typed delivery receipt is required.
 
-## Elect one controller
-
-Persist one `controller_id` for the user outcome. Discover related active tasks,
-branches, PRs, worktrees, environments, and delivery snapshots before changing
-code. A related task may own a lane, but it must not independently promote the
-overall delivery state.
-
-Each lane returns revision-bound typed receipts to the controller. The controller
-alone may freeze companion revisions, order integration gates, declare Ready,
-merge, deploy, or issue the completion receipt. If two controllers are found,
-stop overlapping writes, select one controller, record the superseded controller,
-and reconcile both snapshots before continuing.
-
-## Freeze an integration snapshot
-
-Before expensive verification, atomically record:
-
-- every repository, base SHA, candidate SHA, companion SHA, and generated artifact digest;
-- one owner and one dedicated worktree for each writable lane;
-- one owner and one unique identity for each mutable database, port range, tenant,
-  browser profile, queue, and fixture set;
-- dependency and merge order;
-- the cross-boundary contract smoke test and the combined user journey;
-- retry budgets and known failure fingerprints.
-
-Reject a receipt whose revision or environment identity does not match the frozen
-snapshot. A lane must not reuse another lane's worktree or mutable environment.
-
-## Verify cheap boundaries first
-
-Use this order unless the charter records a justified exception:
-
-1. schema, receipt, API, and generated-artifact contract smoke tests;
-2. focused regression tests at the escaped boundary;
-3. repository formatting, lint, type checks, and unit/integration suites;
-4. independent review as required by risk/repository rules; SQM only when
-   explicitly opted in for this task;
-5. composed multi-repository runtime and user journey;
-6. CI, authorized merge/deploy, and exact-revision live verification.
-
-The first failing gate stops later expensive gates for that candidate. Preserve
-unaffected passing receipts rather than rerunning every suite.
-
-## Lock shared resources
-
-Prefer isolated resources. When isolation is impossible, acquire a lease containing
-`controller_id`, `lane_id`, `run_id`, resource identity, acquisition time, expiry,
-and heartbeat. Compare-and-set acquisition and release. A reset, migration, seed,
-queue purge, browser-profile mutation, or port rebinding without the matching lease
-is an integrity failure, not a retryable test failure.
-
-Local Supabase runs must use a unique project identity and non-overlapping ports per
-lane, or a single leased stack. Never let two lanes reset the same stack.
-
-## Bound retries and HEAD changes
-
-Normalize each failure into a fingerprint containing gate, revision set,
-environment identity, error category, and stable error signature. Default to three
-evaluated attempts. The same fingerprint three times, two non-improving candidates,
-or an A-B-A pattern requires root-cause repair or replan; do not repeat the command.
-
-When a repository HEAD changes, update the snapshot first. Invalidate only gates
-whose inputs changed according to the state-and-receipt matrix. Run the contract
-smoke test before returning to full suites.
-
-## Prove the combined state early
-
-For overlapping features, define execution ownership before implementation. One
-component must own each side effect, retry, wait, wake, cancellation, and completion
-decision. Projections may display state but must consume the same canonical receipt
-chain. Test the combined ownership contract before calling either feature complete.
+Preserve operation identity, cancellation and duplicate prevention across components. If a check repeatedly fails without progress, investigate the cause or choose another useful approach instead of repeating the same operation. Preserve user limits and action-specific authority.