launch-work · diff
git:20260712.615397c to git:20260718.66a680b
54 added, 54 removed. Audit A to A.
---
name: launch-work
- description: Use when preparing, approving, executing, monitoring, or rolling back a production deployment or user rollout; defining launch readiness, staged exposure, migration ordering, operational signals, advance/hold/abort criteria, or post-launch verification.
+ description: Use when preparing or carrying out a production deployment, rollout, rollback, or recovery.
---
# Launch Work
- Change production deliberately, observably, and with an explicit recovery path.
-
- A build, merge, release, or staging pass is not production proof. Deployment changes what runs; rollout changes who experiences it.
+ Change production deliberately, observe the result, and preserve a safe recovery path.
- ## Decision Boundary
+ Deployment changes what runs. Rollout changes who or what is exposed. A build, merge, release, or staging pass does not prove production behavior.
- Production deployment, exposure, rollback, destructive migration, launch window, acceptable degradation, and user communication are user-owned unless an accepted operational policy already decides them.
+ ## Establish Authority And Boundary
- Use `../decision-gate/SKILL.md` when any of those choices are unresolved. Recommend strict-workflow for security, privacy, billing, permissions, data-loss, public API, compatibility, infrastructure, or hard-to-reverse launches.
+ Loading this skill, preparing launch options, or approving a general implementation Plan does not authorize deployment, exposure, rollback, destructive migration, or another production action. Execute only the stages explicitly requested or separately approved through an inspected launch contract or accepted operational policy.
- Read [launch readiness](references/launch-readiness.md) when selecting risk lenses, operational evidence, rollout stages, or recovery checks.
+ Use [Decision Gate](../decision-gate/SKILL.md) when deployment, exposure, rollback, destructive migration, launch window, acceptable degradation, user communication, or recovery direction remains a user-owned choice.
- Use `../release-work/SKILL.md` when a versioned artifact must be produced first. Use `../migration-work/SKILL.md` when the launch moves data, traffic, consumers, or compatibility contracts.
+ Read [launch readiness](references/launch-readiness.md) when selecting risk lenses, operational evidence, rollout stages, or recovery checks. Use [Release Work](../release-work/SKILL.md) when a versioned artifact must be published first. Use [Migration Work](../migration-work/SKILL.md) when the launch transitions data, traffic, consumers, configuration, or compatibility contracts between old and replacement paths with migration or removal obligations.
- ## Launch Contract
+ ## Define The Launch Contract
Before changing production, establish:
```text
- Outcome and affected users/systems:
+ Outcome and affected users / systems:
Artifact / commit / configuration identity:
Target environment and owner:
- Deployment versus exposure steps:
+ Deployment versus exposure stages:
Dependencies and migration ordering:
- Expected operational and business signals:
+ Expected technical, user, business, and data signals:
Advance / hold / abort criteria:
Rollback or forward-recovery path:
Observation and post-launch verification:
Communication and escalation:
+ Approved stages and scope:
```
Use thresholds and observation periods supported by SLOs, baselines, policy, or explicit owner decisions. Do not import universal canary percentages, fixed windows, or “every feature needs a flag” rules.
- ## Readiness
+ ## Establish Readiness
- Select checks based on the actual change. Relevant categories may include:
+ Select evidence for the actual production boundary. Relevant concerns may include:
- accepted behavior and regression evidence;
- security, privacy, permissions, billing, and data safety;
- compatibility and migration readiness;
- capacity, performance, dependency, and failure behavior;
- configuration, secrets, infrastructure, and environment drift;
- accessibility and critical user paths;
- logs, metrics, traces, dashboards, alerts, and runbooks;
- - support, communication, ownership, and rollback authority.
+ - support, communication, ownership, and recovery authority.
- A checklist item is required only when its risk applies. Missing required evidence is not green.
+ A concern is required only when its risk applies. Missing required evidence is not green. Confirm the intended artifact and configuration identity, required pre-production checks, recovery path, operational signals, and any selected review before starting an approved production stage.
- Do not deploy merely to obtain evidence that should exist safely before production. When only production can answer a question, define a bounded learning rollout and stop/rollback conditions first.
+ Read [Verify Work](../verify-work/SKILL.md) to match readiness claims to fresh direct evidence. Do not deploy merely to obtain evidence that should exist safely before production. When only production can answer a question, define an approved bounded learning rollout with observation, hold, abort, and recovery conditions first.
- ## Deploy And Expose
+ Return unresolved owner decisions, material evidence gaps, or broader review needs to [Workflow](../workflow/SKILL.md). This skill defines the production boundary and evidence; Workflow owns routing and review selection.
- Separate operations when the system allows it:
+ ## Deploy And Expose In Approved Stages
- - deploy inert code or infrastructure;
+ Separate operations when the platform permits it:
+
+ - deploy inert code, configuration, or infrastructure;
- verify health and compatibility;
- - expose to a bounded cohort or traffic segment;
- - compare required signals with baseline;
- - advance, hold, roll back, or recover forward based on the contract.
+ - expose a bounded cohort, tenant, region, or traffic segment;
+ - compare required signals with the accepted baseline;
+ - advance, hold, abort, roll back, or recover forward according to the contract.
- Feature flags, canaries, blue/green, shadow traffic, or phased regions are options, not defaults. Choose the mechanism supported by the platform and accepted failure contract.
+ Feature flags, canaries, blue/green, shadow traffic, and phased regions are options, not defaults. Choose only mechanisms supported by the platform and accepted failure contract.
- For each stage:
+ For each approved stage:
- 1. confirm artifact/config identity and target;
- 2. execute the approved bounded action;
+ 1. confirm artifact, configuration, target, and current production state;
+ 2. execute the bounded action once;
3. verify technical and user-visible behavior;
- 4. inspect telemetry and data integrity;
- 5. record anomalies and decide the route before expanding exposure.
+ 4. inspect telemetry, data integrity, and unexpected side effects;
+ 5. preserve anomalies and choose the next route before expanding exposure.
- Do not continue rollout because elapsed time passed while required signals are missing.
+ Do not continue because elapsed time passed while required signals are missing. Approval of one stage does not authorize the next unless the accepted launch contract already does so.
- ## Failure And Recovery
+ ## Handle Failure And Recovery
- Stop or abort when accepted safety, data, security, compatibility, or service criteria are violated.
+ Hold or abort when accepted safety, data, security, compatibility, or service criteria are violated.
- Before rollback, determine whether code, schema, data, messages, caches, clients, or external side effects make rollback unsafe or incomplete. Forward recovery may be safer, but choosing it is not automatic permission to broaden scope.
+ Before rollback, determine whether code, schema, data, messages, caches, clients, or external effects make rollback unsafe or incomplete. Forward recovery may be safer, but it is not automatic permission to broaden scope.
- If deployment state is ambiguous, inspect the target before retrying. Do not issue duplicate migrations, jobs, publishes, or configuration changes blindly.
+ If production state is ambiguous, inspect the target before retrying. Do not repeat migrations, jobs, publishes, configuration changes, or exposure operations blindly.
- Use `../diagnose-failure/SKILL.md` for unexpected behavior and preserve incident evidence. Do not weaken alerts, tests, or thresholds merely to declare the launch healthy.
+ Use [Diagnose Failure](../diagnose-failure/SKILL.md) for unexpected behavior without a supported cause. Preserve incident evidence. Do not weaken alerts, checks, thresholds, or accepted behavior merely to declare the launch healthy.
- ## Post-Launch
+ ## Verify The Production Outcome
- Verify from production-observable paths:
+ Observe from the production boundary as applicable:
- - intended artifact/configuration is active;
+ - intended artifact and configuration are active;
- critical user and failure paths behave as accepted;
- - data and compatibility invariants hold;
+ - data, compatibility, privacy, and permission invariants hold;
- telemetry is present, queryable, bounded, and free of unexpected sensitive data;
- - alerts and escalation routes work when required;
- - rollback/recovery remains available during the accepted window;
- - temporary flags, adapters, dashboards, elevated logging, or support procedures have owners and cleanup checkpoints.
+ - alerts, escalation, and recovery routes work where required;
+ - temporary flags, adapters, dashboards, elevated logging, permissions, or support procedures have owners and cleanup conditions.
- A quiet dashboard is not evidence when telemetry is absent or broken.
+ A quiet dashboard is not evidence when telemetry is absent or broken. State production paths, cohorts, observation windows, or recovery behavior that remain unverified.
- ## Completion
+ ## Report Completion Precisely
Report:
- - deployed artifact/config and exposure state;
- - readiness evidence and owner approvals;
- - rollout stages and decisions;
- - operational, user, business, and data observations;
- - rollback/recovery status;
- - incidents, holds, or deviations;
- - temporary machinery and cleanup owner;
- - residual risk and next observation, advance, cleanup, or stop route.
+ - approved launch stage and exposure state;
+ - deployed artifact, configuration, and target identity;
+ - readiness evidence and owner decisions;
+ - stage results and technical, user, business, and data observations;
+ - holds, incidents, deviations, rollback, or forward recovery;
+ - temporary machinery, owner, and cleanup condition;
+ - residual risk and next approved observation, advance, cleanup, or stop route.
- Launch completion means the accepted exposure and observation contract is satisfied—not merely that a deployment command succeeded.
+ Launch completion means the accepted production exposure and observation contract is satisfied—not merely that a deployment command succeeded. A completed launch does not authorize later migration removal, release publication, or cleanup outside the approved scope.
+