ship-mini · diff
git:20260621.222bc22 to git:20260727.eb50b76
70 added, 35 removed. Audit A to A.
---
name: ship-mini
- description: Run a lightweight GO or NO-GO gate before use, especially for autonomous or scheduled workflows.
+ 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 a small project, dashboard, ML workflow, or agent workflow is ready to use.
+ 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 before user-facing release, scheduled runs, autonomous agent execution, decision-impacting analysis, or sharing outputs with others.
- Use when an agent will write, send, trigger, or act with tools on your behalf.
+ 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
- - `SPEC.md`
- - `VERIFY.md`
- - Changed files
- - Test/build/lint results
- - Data/model/agent context if relevant
- - Allowed tools
- - Forbidden tools or actions
- - Destructive operations
- - Secrets and credentials
- - PII or sensitive data access
- - Dry-run mode
+ - `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 path
+ - Rollback / disable path
- Owner notification
- Stop conditions
## Workflow
- 1. Create or update `SHIP.md`.
- 2. Check user-facing behavior or the scheduled/autonomous action.
- 3. If the run can write, send, or trigger actions, record allowed tools, forbidden tools or actions, destructive operations, secrets and credentials, PII or sensitive data access, dry-run mode, human approval gates, audit logging, rollback path, owner notification, and stop conditions.
- 4. Check test, build, and lint commands.
- 5. Check data freshness if relevant.
- 6. Check row counts, nulls, and metric deltas if relevant.
- 7. Check model artifact/version if relevant.
- 8. Check agent tool permissions if relevant.
- 9. Decide GO or NO-GO.
+ 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`.
+ 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.
+ - `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
- - Blockers
- - Accepted risks
- - Rollback plan
+ - 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
- - A GO / NO-GO decision is recorded.
- - A required approval, dry-run, or rollback path is still unclear.
- - A blocker requires more implementation or verification.
+ - 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
- - Calling something shipped just because the implementation task passed.
- - Ignoring data freshness or permissions for automated workflows.
- - Shipping without a rollback path.
- - Treating autonomous or scheduled runs like interactive sessions.
+ - 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.