Deliver and verify

Carry the authorized outcome through execution and verification at the user, partner, or operator surface. Use the existing grants and release path; preserve user data and authorized spending limits.

When changing a game, app or SaaS user journey, remaking a product, or publishing assets or configuration that change the experience, or comparing engines, read parity.md before defining the acceptance cases. It owns the screen-and-feature comparison, engine benchmarks, live evidence and automated release checks.

For engine or SDK changes affecting controls, account entry or host lifecycle, including restored integrations, read shipping-host verification. Native tests and browser previews can exercise different input and feature paths.

For credential import, guest restoration or account-continuity changes, read guest continuity before defining tests; decoding a retained value is not proof that its production consumer keeps it.

Shared implementations follow the three architectural invariants: neutral mechanisms with caller-configured policy, zero domain leakage in code/prompts/verifiers/fixtures, and exact causal state/data/authorization guards that fail closed on unreadable required state. Release independent paths concurrently when no causal dependency requires ordering.

Step 0: Route the acceptance cases

When reconciling legacy and canonical identifiers, changing multi-namespace lookups or identifier-based pagination, read identifiers.md before defining acceptance cases.

When admitting or changing selectable platforms, architectures or deploy components, read continuous integration before defining acceptance cases.

Coordinate the work

• Keep one named writer per worktree, pull request, database record, or live configuration. Before building, search open PRs for the same outcome to avoid duplicate implementations; distinct outcomes may edit the same files in parallel in isolated worktrees and resolve conflicts normally. Parallel readers and writers on independent targets can proceed together.
• Prefer finishing comparable-priority in-flight work on the same target. Continue independent work during an asynchronous wait; choose ready work using the priority method.
• During launch convergence, keep a finite checklist of the core value loop or remake parity. Defer non-blocking enhancements discovered along the way.
• Repair an owned upstream capability at its owning boundary and consume the published version. Keep downstream business rules and privileged exceptions out of shared layers. An immutable dependency hash establishes content identity, not admission: read the consumer’s release/provenance rule before selecting a revision. Wrong: pin another commit in the same unmerged PR when consumers require protected-branch ancestry; Right: merge the producer independently, then adopt its verified published revision without weakening that rule.
• Compare repair and replacement by total cost to a verified outcome, including migration, recovery, cleanup and preservation of binding constraints. Stale configuration or documentation can mix mutable assignments with independent behavioral rules: account for each retained or explicitly retired clause, because a broad replacement goal does not preserve a specific negative case. Migrate consumers before removing superseded paths; split delivery when a dependency must merge first.
• Search related components for the same defect class. Repair affected instances within the authorized boundary and record separately owned work. Use a default, type or existing check when it proportionately prevents recurrence; a one-off ruling does not need a permanent guard.

Establish the acceptance cases

Use read-only discovery to understand the target. Before changing it, state the observable positive cases and relevant negative or invariant cases. Use author-item when the brief needs clearer acceptance criteria.

Read the relevant code, configuration and external primary specification in the current session. Record the version and read time for an external dependency. For a live mutation, read the affected state before acting.

For readiness or propagation promises across replicas, or proof gates over a mutable serving population, read replicated readiness before defining the probe population and timing boundary.

For request/response limits, asynchronous effect admission, context compaction, agent tool outputs or low-rate flake comparisons, read final encoded limits and reliability evidence. For large transfers, shared response caches, fan-out streams, archive restores, or stored-output replay, read bounded memory for large transfers before choosing storage queries and transport APIs.

For code or test changes, read code.md. Formatting fixes need independent expected strings and cases that expose locale and sign errors. UI control and renderer changes also use the visual acceptance checks, including engine components tested outside a complete app. When reducing fragment-shader cost, read fragment-shader hot paths before choosing an optimization.

For preview provisioning or reduced-backend profiles, read deployment configuration and migrations before selecting a backend target. For a public preview or disposable service, also read first useful success before relying on an advertised creation, deployment or port-exposure operation.

For regional store SKU or price changes, read regional store prices.

For SQL, database cleanup or fixture changes, read database boundary tests. Time-windowed usage or billing queries also use temporal query evidence.

When storing process/tool output in JSON or a database, read binary output and text storage. For worker replacement, snapshot selection or partial checkpoints, read execution environment recovery before changing capture coverage or restoring user files.

Preserve existing users' accounts, data and supported client workflows. For a live storage or service cutover, establish the new path, verify it and switch consumers before removing the predecessor. Keep schema migrations separate from operational record changes; code.md owns the details. A reconciler change compares affected declarations with served state and explicitly handles intended removals or revocations, so a rollout does not silently narrow the supported contract. Pre-launch work with no external consumers can change directly.

For retention policies, recovery references, rollback pins or asynchronous reconcilers, read recovery references and desired state before changing target selection or resource creation order.

For live database backups or service recovery, read recovery procedure before choosing snapshot and rollback verification.

When a policy change must update existing resources, verify declarations created before the change as well as newly rendered output. Rendering only on creation or redeploy leaves existing specifications unchanged; use the normal writer's bounded reconciliation or backfill, preserving exclusions and intended absence, and verify the served objects before reporting rollout complete.

For long builds or tests, work in leased environments, source handoffs or execution-placement changes, or results resumed after a turn boundary, read turn-boundaries.md before starting execution or resubmitting work.

For public social feed publishing, follow the social post media and visual inspection checks before sending and verify the attached image afterward.

Execute and verify

For destructive or conditional API writes, read destructive and conditional writes.

Before bulk mutations, including cancelling CI runs, read bulk mutation controls.

When changing selected-source release inputs or their CI guards, read selected release inputs.

When changing CI runner selectors, shared runtime settings, identity-label selectors or deployment overlays, rotating secrets consumed by Jobs, or changing resource sizing or retention, read deployment configuration.

For container packaging, one-off container probes or runtime fixtures copied from read-only artifacts, read container builds and probes.

For source checkout or materialization changes, shared-cache permission failures, child-workspace or build-output sharing, UID/GID fixtures, pinned-tool launch failures, generated CLI calls, sandbox build templates, native compilation failures, or diagnostic capture and cleanup failure handling, read first useful success. Source publication and receipt adoption after a rewrite also use source publication authority.

When changing database test setup or disposable fixture cleanup, read database test fixtures and affected-test selection. New fixture objects still enter repository-wide policy scans.

When changing admission or access rules or admission policies, read security.md for caller-identity authority and acceptance controls.

When changing runtime isolation or removing operational access, read runtime isolation.

For privileged filesystem changes under directories another principal can write, or when filesystem or tool-resolution trust would relax inspection, read security.md before trusting resolution or changing objects.

Before changing database roles, privileges, reader transports or session-bound database checks, read shared reader privileges.

When changing credential routing, credential input/output guards or diagnostic or stored-body redaction, read security.md to protect the actual launching process, preserve useful diagnostics and prevent content from reappearing through later writes.

When a secret scanner refuses publication, follow reviewing scanner findings.

For public API changes, dependency lockfiles, package publication or registry/download mirrors, read interfaces and packages.

When changing generator inputs, running a generator locally or remotely, or running a package manager through a remote command wrapper, read source generation.

When editing PR titles or bodies, changing CI workflows or concurrency, publishing CI probe workflows, enrolling disabled tests in CI, running tests in fresh build leases, or selecting checks for source, SDK or transport changes, read affected-test selection. Tests can depend on files across language and workspace boundaries.

Before changing server status-code/error-envelope translation, provider calls, shared HTTP-client features or defaults, HTTP test doubles, streamed output, queued dispatch, receipt parsing or webhooks, read integration.md. Preserve relevant endpoint and error-contract boundaries in tests. Admission and later dispatch can run under different provider configuration.

For browser keyboard, clipboard, pointer, focus or foreground lifecycle changes, also read browser input and foreground tests.

For changes to transaction locks or nested transactional helpers, read transactions and idempotency before editing; the lock order starts at the outer transaction and spans a batch.

Before publishing or updating a PR, read publication and merge intent. A publisher can combine a source update with activation; its effective defaults determine the write boundary.

1. Run practical targeted checks, then publish one coherent change. State the remaining uncertainty; fix failures and rerun the affected checks on the same branch. Follow the repository's required checks and normal merge queue without force-push or bypass merge. Review depth follows the change's risk; independent review can run alongside or after delivery and does not create a separate completion stage. When a CLI publishes a title, description or comment from a file, create that file in a unique directory owned by this run (mktemp -d) and publish only after the write succeeds. A predictable shared path can retain another run's text when your write fails. Read the published title and body back before reporting success. A structured text argument needs no temporary file.
2. For an external mutation, identify the intended operation and read its live status/timeline before submitting. A mutable target can change after that read: bind the write to the reviewed version through the provider's precondition, such as gh pr merge --match-head-commit <sha> or HTTP If-Match; a version mismatch requires a fresh read and review. Continue from an existing receipt instead of creating another in-flight submission. On the first call, record endpoint, UTC time, response status and returned operation/resource ID. Use provider-supported idempotency and the duplicate-safety recovery contract; an unknown harmful effect needs reconciliation before a repeat. Recovered or overlapping sessions can repeat a step, so guard a duplicate-sensitive one-time action with a lock, a fresh read of the authoritative attempt and an exclusive marker written before the call; once the marker exists, reconcile and never resend. Keep the guard in a script, so whoever holds working execution can run it safely.
3. For a blocked operational route, follow unblock. A temporary repair stays within existing grants and has a durable fix and removal condition. Coordinate reconciliation on a GitOps-managed resource and merge the matching configuration.
4. Read the authoritative result back before claiming completion, following prove-it. A service needs the loaded artifact identity and affected acceptance cases checked on every changed serving path; hashing the installed replacement or checking only its management process does not prove that workers adopted it. An operation needs the updated object and dependent behavior; a package, CLI or document needs its required checks and published artifact or source verified where applicable. Use a soak only when its measured behavior is part of the outcome.
5. Cross-Currency Entitlement Normalization & Canonical Analytics Read-Model: When shipping or verifying a new checkout, voucher, credit, or payment channel, verify at the live surface that:
   • Cross-currency entitlement normalization: Issued vouchers, credits, or wallet top-ups normalize to the recipient wallet's currency via the authoritative FX rate so redemption never fails on a currency mismatch (for example, a USD checkout credit applied to an HKD or TWD wallet).
   • Canonical analytics read-model: Settled orders write to—or project into—the same canonical order table that powers live revenue analytics and payment-history lookups, rather than stranding settled revenue in an isolated channel table.
   • Auth-Redirect Attribution & Public Metadata Hygiene: When shipping or modifying a web storefront, checkout/voucher funnel, invite landing page, or web/game pack, verify on the live HTML response (curl -sS) that campaign touches survive /sign-in?nextUrl=... redirects into authenticated checkout headers, and that public <title>, <meta name="description">, <link rel="canonical">, absolute og:image (HTTP 200), and JSON-LD (VideoGame / SoftwareApplication) exclude forbidden launch-branding strings resolved from the owning product contract.
6. Synthetic Probe CDN Cache Bypass: When adding or modifying synthetic health, readiness, or scale-to-zero activator probes that traverse a CDN on public domains, ensure probe requests or responses carrying internal routing headers (such as K-Network-Probe) explicitly bypass CDN caching (cache: false or Cache-Control: no-store, private) so synthetic probe bodies never poison public page caches.
7. For webhook-less external monitoring, use the zero-token watcher method, including end-to-end wake verification and subscription handoff. A slow inventory read can kill an observer precisely when independent error-rate measurements matter; keep those timestamped measurements and record the timed-out operation, deadline, elapsed time and UTC as an unknown observation. Use per-target failure budgets bounded by the acceptable observation gap; one unknown target need not stop independent observations, while quota, authorization and write boundaries still apply. Wrong: reset an unknown alert after stale 200 OK data and wake repeatedly; Right: retain the alert until fresh evidence re-establishes that target's observation, with failure/exit wake coverage. Capture dependency health and resource use alongside a repeated timeout before attributing it to the monitored breach.
8. Autonomous Skill Distillation Gate (Completion / Exit Gate): Before declaring an outcome complete, check whether the task or incident required a second-attempt detour (an initial approach hit an undocumented trap and a fallback approach was needed), fixed a post-ship defect or rework (an existing verification checklist missed a dimension), surfaced a recurring cross-agent blind spot, or produced a verified reusable playbook (such as a zero-token file-watch trigger daemon). When any of these occurred, distill the role-neutral governing mechanism into the owning skill in the shared skills repository following author-skill—refining the existing skill in place 90% of the time and verifying its YAML description: "Use when..." covers the entry moment—as part of completion, without waiting for a human prompt.

Size the mechanism to the harm. A reversible change to a few fields takes one conditional statement with the row read before and after, not a new role, schema and scheduler. Verify what crosses a boundary: a release, an upload, a live surface. Rehashing your own working files, auditing your own helper with another helper or tracing a queue that will drain by itself costs time and proves nothing to a user.

Opening or merging a pull request is a checkpoint. Completion is the acceptance receipt at the delivered surface plus any triggered skill distillation. Pre-launch code can be judged by automated checks in its target environment; verification does not add an approval ritual before first use.

Domain references

• parity.md: verifying game, app and SaaS journeys against a category leader; remake parity, live captures, asset/table checks and automatic recovery.
• code.md: domain boundaries, transactions, recovery references, desired state, tests and migrations.
• auth.md: sign-in, sessions, recovery and delegated access.
• security.md: authority, privileged tool maintenance, secrets, personal data and recovery.
• integration.md: provider calls, HTTP test doubles and routing, queued dispatch, partial acceptance, webhooks and reconciliation.
• identifiers.md: identity, text encodings, slugs and credentials.
• performance.md: journey budgets, queries and measurement.
• dx.md: APIs, packages, affected-test selection, feedback loops and releases.
• private-device-preview.md: art, text or layout edits in a private real-client session without publishing content or a store build; cold/warm timing and exclusive device handoff.