git:20260727.eb50b76 to git:20261005.a4c4424

12 added, 5 removed. Audit A to A.

---

name: ship-mini

description: Run a lightweight activation GO or NO-GO gate only when verified work is about to gain material real-world side effects, autonomy, permissions, or production/shared-state impact.

---

# Ship Mini

## Purpose

Decide whether verified work is safe and authorized to activate in a real operating environment.

`verify-contract` owns correctness and evidence. `ship-mini` does not re-verify the implementation; it owns the additional operational question: should this verified thing be allowed to act on the world now?

## When to use

Use after verification when activation introduces one or more material operational risks:

- production or shared-state writes

- scheduled, autonomous, or unattended execution

- sending, publishing, triggering jobs, or other external side effects

- new or expanded tool permissions

- secrets, credentials, PII, or sensitive-data access

- destructive or difficult-to-reverse actions

- a required human approval boundary

- a meaningful rollback, audit, or owner-notification requirement

Skip `ship-mini` for ordinary local or interactive changes whose effects remain reviewable and reversible. A user-facing change, shared report, dashboard update, model result, or successful `verify-contract` does not require `ship-mini` merely because it may be released or seen by others.

Do not create `SHIP.md` when no material activation risk exists.

## Inputs

- `VERIFY.md` status and evidence reference

- What will be activated and where

- Allowed tools / actions

- Forbidden tools / actions

- Target environment or shared state

- Destructive or irreversible operations

- Secrets, credentials, PII, or sensitive-data scope

- Dry-run or staged activation path when relevant

- Human approval gates

- Audit logging

- Rollback / disable path

- Owner notification

- Stop conditions

+ - Optional operator profile `Autonomy boundary`

## Workflow

1. Confirm the implementation already has sufficient verification evidence. Reference `VERIFY.md`; do not replay correctness checks merely because `ship-mini` is invoked.

2. Classify activation risk:

- `NONE` — no material side effect, autonomy, permission, data, or rollback boundary exists. Stop without creating `SHIP.md`.

- `PRESENT` — one or more material activation risks exist. Continue.

3. Name the exact activation surface: what will run, write, send, publish, trigger, access, or mutate, and in which environment.

4. Record allowed and forbidden actions, permission/data boundaries, destructive operations, and required human gates.

- 5. Confirm the smallest practical dry-run or staged activation path when one exists.

- 6. Confirm rollback or disable path before irreversible or shared-state effects are enabled.

- 7. Confirm audit logging, owner notification, and stop conditions when unattended or externally visible effects are possible.

- 8. Resolve any `REVIEW_REQUIRED` verification item that affects activation safety. A functional `FAIL` cannot be shipped.

- 9. Create or update `SHIP.md` with the activation decision and only the operational evidence needed for `GO` / `NO-GO`.

+ 5. If an operator profile is available, apply its `Autonomy boundary` as an

+ additional ceiling. `propose-only` or `human-gate-side-effects` may require an

+ earlier human gate. `bounded-execution` does not grant activation permission;

+ it only means the profile itself adds no stricter gate inside already-authorized

+ bounded work.

+ 6. Confirm the smallest practical dry-run or staged activation path when one exists.

+ 7. Confirm rollback or disable path before irreversible or shared-state effects are enabled.

+ 8. Confirm audit logging, owner notification, and stop conditions when unattended or externally visible effects are possible.

+ 9. Resolve any `REVIEW_REQUIRED` verification item that affects activation safety. A functional `FAIL` cannot be shipped.

+ 10. Create or update `SHIP.md` with the activation decision and only the operational evidence needed for `GO` / `NO-GO`.

Do not rerun tests, builds, lint, data-quality checks, or model validation unless activation changed the environment or inputs in a way that invalidates the existing verification evidence.

## Activation gate

Status: GO | NO-GO

- `GO` only when verification is trustworthy for the activated state and every material activation boundary is explicit enough to operate safely.

+ - An operator profile may make the activation gate stricter, but it cannot authorize a side effect, permission, or deployment that the task and runtime did not already allow.

- `NO-GO` when a required approval, permission boundary, data boundary, rollback path, audit path, owner notification, or stop condition is unresolved.

- `NO-GO` when verification is `FAIL`.

- `REVIEW_REQUIRED` verification may proceed only after a human explicitly resolves or accepts the item and it does not hide a functional failure.

## Outputs

When activation risk is `PRESENT`:

- `SHIP.md`

- GO / NO-GO decision

- Activation surface

- Operational blockers

- Accepted operational risks

- Human gates

- Rollback / disable path

- Audit / notification / stop conditions when relevant

When activation risk is `NONE`:

- No `SHIP.md`

- Continue from verification to the next appropriate workflow step

## Stop conditions

- Activation risk is `NONE`; skip the skill artifact.

- `GO` is recorded with operational boundaries explicit.

- `NO-GO` is recorded because a material activation boundary remains unresolved.

## Anti-patterns

- Running `ship-mini` after every successful `verify-contract`.

- Re-running correctness checks already captured in `VERIFY.md` without evidence they became stale.

- Treating ordinary release, sharing, or visibility as activation risk by itself.

- Creating `SHIP.md` when no material side effect or operational boundary exists.

- Shipping autonomous or external side effects without approval, rollback, audit, or stop conditions appropriate to the risk.