@hassangameryt/freeflow 0.7.3 → 0.9.0

package/skills/execute-work/references/execute-work-edges.md

@@ -1,68 +0,0 @@
-# Execute Work Edges
-
-Read this when execution resumes from uncertain prior state, changes the Slice boundary, reaches a selected checkpoint, or exposes separately controlled follow-on work.
-
-The main skill owns the normal bounded-action loop. This reference covers transitions that leave, resume, or constrain that loop.
-
-## Resume Safely
-
-Recover the source that established the accepted work and compare it with relevant live state.
-
-When durable memory exists, enter [Track Work](../../track-work/SKILL.md) and use its required recovery route before relying on or mutating the Working Record. Memory preserves context; it does not prove live state or recreate authority.
-
-Resume the same Slice only while its intended result, authority, evidence boundary, and stop condition remain coherent. Otherwise preserve supported work and return the changed boundary to [Workflow](../../workflow/SKILL.md).
-
-Recover the user-facing return condition separately from the next internal action. A supported record may preserve approval for the remaining task, but a proposed next action is not that approval. After reconstruction, continue covered work rather than returning solely because a context boundary occurred.
-
-Do not restart discovery, repeat supported work, or infer progress from summaries, Plans, records, handoffs, staged files, or partial artifacts.
-
-## Distinguish Adaptation From Boundary Change
-
-Routine changes to local mechanics, implementation order, tools, and focused checks remain inside the current bounded action when they preserve:
-
-- the accepted result;
-- permitted effects;
-- source truth;
-- the required observing boundary;
-- the stop condition.
-
-A mechanical read of a known caller or a local correction may remain inside execution. If new evidence invalidates the implementation premise, stop dependent edits and re-establish the approach; do not hide renewed investigation inside a patch stream.
-
-Before following a new prerequisite, identify whether it blocks the required outcome, the chosen approach, or only the current observer. Preserve acceptance, compare supported in-scope remedies, and return to Workflow when the remedy changes behavior, scope, persistence, compatibility, public interfaces, risk, evidence quality, or another user-owned outcome.
-
-Keep an accepted extension in the current Slice only when its result remains coherent, explicit authority covers the added effects, and the combined boundary can still be verified as one unit. When a Working Record exists, Track Work records the extension before execution.
-
-Use another Slice when the work has a distinct result, authority source, evidence boundary, independently useful outcome, or explicit abandonment of the original result. Context pressure may require an earlier safe continuation boundary without inventing a completed result or new Slice.
-
-A whole-task agreement may already cover later Slices. Return their selection and lifecycle to Workflow and Track Work without requesting redundant user permission. A selected checkpoint or the agreed user-facing endpoint still stops dependent work.
-
-## Route A Selected Checkpoint
-
-A checkpoint is due only when Workflow, an approved Plan, repository policy, or explicit discussion selected it.
-
-Stop before dependent work, use the checkpoint’s owner, and return its result to Workflow:
-
-- [Decision Gate](../../decision-gate/SKILL.md) for a selected user decision;
-- [Review Work](../../review-work/SKILL.md) for selected independent judgment;
-- [Commit Work](../../commit-work/SKILL.md) for an authorized local commit;
-- [Handoff](../../handoff/SKILL.md) for selected continuity transfer;
-- [Finish Branch](../../finish-branch/SKILL.md), [Release Work](../../release-work/SKILL.md), or [Launch Work](../../launch-work/SKILL.md) for their separately authorized boundaries.
-
-When durable memory exists, Track Work preserves the checkpoint’s selection, condition, result, and task effect.
-
-Do not create a checkpoint merely because an action or Slice ended. Do not force a stale checkpoint when its condition, evidence, or protected boundary no longer holds; return the discrepancy for a supported cancellation, replacement, deferral, or revision before dependent work.
-
-## Separate Follow-On Work
-
-Useful follow-on work is not implied authority.
-
-Return it to Workflow before using:
-
-- Commit Work for an unselected commit or push;
-- [Migration Work](../../migration-work/SKILL.md) for consumer, state, or traffic movement;
-- Finish Branch for integration, preservation, discard, or branch cleanup;
-- Release Work for versioned publication;
-- Launch Work for production exposure, rollback, or recovery;
-- Handoff for point-in-time continuation transfer.
-
-Preserve the supported execution result before routing away. A follow-on owner does not retroactively change the completed action or Current Slice.

package/skills/finish-branch/SKILL.md

@@ -1,117 +0,0 @@
----
-name: finish-branch
-description: Use when deciding how to integrate, preserve, or discard work on a branch or isolated checkout.
----
-
-# Finish Branch
-
-Close a branch or isolated checkout without confusing readiness, integration, publication, and cleanup authority.
-
-A verified branch does not authorize merge or push. A chosen integration route does not automatically authorize branch deletion, worktree removal, release, or deployment.
-
-## Inspect The Exact State
-
-Before offering or executing a route, inspect:
-
-- current branch, detached state, repository root, and worktree ownership;
-- base branch or merge base supported by repository evidence;
-- commits and diff relative to the base;
-- staged, unstaged, and untracked work;
-- upstream, remote, and ahead/behind state;
-- fresh verification, silent self-review, and any selected independent-review status;
-- CI, policy, or repository gates relevant to the intended route.
-
-Do not infer the base, remote destination, pull-request target, or workspace owner when the wrong choice could lose work or affect collaborators.
-
-After inspecting branch, base, remote, dirty state, verification, and workspace ownership, read [integration options](references/integration-options.md) before choosing local integration, pull request, preservation, discard, or cleanup. Use [Commit Work](../commit-work/SKILL.md) when the selected route requires a local commit or simple push; do not commit merely to make branch status look finished.
-
-Use [Release Work](../release-work/SKILL.md) for a separately approved versioned release and [Launch Work](../launch-work/SKILL.md) for a separately approved production deployment or rollout.
-
-## Keep Route Authority Explicit
-
-Loading this skill, asking whether a branch is ready, or approving a general implementation Plan does not authorize merge, rebase, push, pull-request creation, branch deletion, worktree removal, discard, force push, release, or deployment.
-
-The user owns whether to:
-
-- integrate locally and by which repository-supported method;
-- push or create/update a normal or draft pull request;
-- preserve the branch, worktree, or dirty state;
-- discard commits or uncommitted work;
-- delete local or remote branches;
-- rewrite or force-push history;
-- clean up a checkout or worktree.
-
-Present only routes supported by the observed state. Do not force a fixed menu when an option is impossible, unsafe, or irrelevant. Approval of one route covers only the scope shown and accepted.
-
-## State Readiness Honestly
-
-Present a branch as ready for its intended integration boundary only when:
-
-- the accepted branch outcome is clear;
-- intended commits and remaining dirty state are known;
-- fresh direct evidence supports the branch claim;
-- silent self-review has no unresolved material issue;
-- any selected independent review is resolved for the unchanged state;
-- no source conflict, owner decision, required evidence gap, or repository gate blocks the route.
-
-Read [Verify Work](../verify-work/SKILL.md) when matching branch-readiness claims to evidence. A feature-branch pass does not prove the integrated result.
-
-Unverified or failing work may still be preserved, handed off, or shared through an explicitly approved draft route. State the gaps; do not describe it as integration-ready.
-
-## Execute Only The Chosen Route
-
-### Local Integration
-
-- refresh base evidence without overwriting local work;
-- use the repository's accepted merge or rebase policy;
-- stop when a conflict requires a behavior, source, or owner decision;
-- verify the integrated result on the resulting base state;
-- delete branch or worktree state only when cleanup was included in the approved route and integration verification succeeded.
-
-### Pull Request
-
-- inspect remote and upstream state before pushing;
-- push only intended commits to the accepted destination;
-- create or update the pull request using repository conventions;
-- mark incomplete or failing work as draft when that is the approved route;
-- report CI, review, merge, migration, release, or launch requirements still pending;
-- preserve the worktree when iteration or feedback may continue.
-
-A pull-request URL proves creation, not readiness or merge.
-
-### Preserve
-
-Report the branch, worktree, commit and dirty state, evidence status, reason preserved, and next approved route. Read [Handoff](../handoff/SKILL.md) only when continuation needs durable transfer context.
-
-### Discard
-
-Before destructive action, state exactly which commits, paths, branches, worktrees, and remote state would be lost and what remains recoverable. Require explicit confirmation for that concrete scope.
-
-Do not treat “finish,” “clean up,” a menu number, or approval of integration as confirmation for broader destruction.
-
-## Protect Workspace Ownership
-
-Do not remove a worktree, checkout, session, or harness state you did not create or are not authorized to manage. If ownership is unclear, preserve it and report the uncertainty.
-
-Do not run destructive reset, clean, branch deletion, worktree removal, remote deletion, or force push merely to produce a clean status.
-
-## Return Conflicts And Failures
-
-Resolve a conflict locally only when both sides' intended behavior is settled and the resolution is mechanical. Return behavior, source-truth, API, data, security, compatibility, or architecture conflicts to [Workflow](../workflow/SKILL.md).
-
-Use [Diagnose Failure](../diagnose-failure/SKILL.md) when integrated checks fail without a supported cause. Return mixed or unrelated branch contents to [Commit Work](../commit-work/SKILL.md), which owns staging decisions. Preserve branch state before re-entering another owning activity.
-
-## Report The Chosen Outcome
-
-Report:
-
-- branch, base, and selected route;
-- commit and dirty state handled or preserved;
-- integration, push, or pull-request result;
-- verification on the final observed state;
-- selected-review and repository-gate status;
-- cleanup performed or deliberately omitted;
-- unresolved CI, review, migration, release, or deployment work;
-- recoverability and next approved route.
-
-Branch closeout is complete only for the chosen route. A pushed branch is not merged, a merged branch is not released, and a released artifact is not deployed.

package/skills/finish-branch/references/integration-options.md

@@ -1,80 +0,0 @@
-# Integration Options
-
-Read this after inspecting branch, base, remote, dirty state, verification, and workspace ownership and before choosing local integration, pull request, preservation, discard, or cleanup.
-
-## Local Integration
-
-Appropriate when the user wants the branch integrated locally and repository policy permits it.
-
-Before cleanup:
-
-1. preserve or resolve dirty state deliberately;
-2. update base evidence safely;
-3. integrate without rewriting unrelated history;
-4. run the checks that prove the combined result;
-5. inspect final log and status;
-6. remove branch/worktree state only after success.
-
-A feature-branch pass does not prove the merged result.
-
-## Pull Request
-
-Appropriate when review, CI, collaboration, protected branches, or remote integration owns the next gate.
-
-Capture:
-
-- target branch and commit range;
-- intended push/upstream behavior;
-- PR summary and source requirements;
-- verification already run;
-- known residuals, migrations, rollout, or compatibility notes;
-- required reviewers or checks from repo policy.
-
-A draft pull request may preserve or share incomplete work when that route is explicitly approved. State failing or unavailable evidence. Do not claim merge readiness from a pull-request URL alone.
-
-## Keep For Later
-
-Appropriate when work is valid but integration is deferred, feedback is expected, or environment ownership prevents cleanup.
-
-Report:
-
-```text
-Branch / worktree:
-Commit and dirty state:
-Review / verification:
-Reason preserved:
-Next action:
-Stop conditions:
-```
-
-## Discard
-
-Classify what is recoverable before deleting:
-
-- uncommitted changes may be unrecoverable;
-- local commits may be recoverable through reflog for a limited time;
-- pushed commits may affect collaborators;
-- worktrees may be harness-owned;
-- remote branch deletion has a different scope from local cleanup.
-
-Show the exact destructive operations and require explicit confirmation that matches their scope.
-
-## Detached Or Managed Checkouts
-
-Do not assume a detached checkout is disposable. It may be owned by an IDE, CI system, coding harness, or external worktree manager.
-
-Offer only routes supported by that environment, such as creating a named branch, preserving the checkout, exporting a patch, or asking the harness to close it.
-
-## Conflict Handling
-
-Mechanical conflict resolution is safe only when both sides' intended behavior is already settled.
-
-Stop when conflict resolution would choose between:
-
-- competing product or API behavior;
-- changed tests versus changed implementation;
-- incompatible migrations or data ownership;
-- security, privacy, billing, permissions, or compatibility policies;
-- two architecture directions.
-
-Return the conflict and evidence to Workflow. The next route may be review, diagnosis, Decision Gate, Spec revision, or Plan revision—not “take ours” or “take theirs.”

package/skills/handoff/SKILL.md

@@ -1,82 +0,0 @@
----
-name: handoff
-description: "Use when work must continue safely after a pause, context change, or ownership transfer."
----
-
-# Handoff
-
-Preserve the point-in-time information another context needs to continue the agreed work without restarting discovery or changing its goal.
-
-A [Working Record](../track-work/SKILL.md) maintains living task state. A handoff identifies that record, the relevant sources, and transfer-specific facts the recipient would otherwise miss. Neither is authority, proof of completion, or a replacement for current user direction and live evidence.
-
-## Choose The Transfer Boundary
-
-Identify the recipient, purpose, and available transfer mechanism before writing.
-
-- **Ephemeral handoff:** use the response or host continuation mechanism for immediate transfer, including compaction. Use a temporary file only when the transfer needs it.
-- **Repo-memory handoff:** use the repository's established destination when durable continuation documentation is requested or approved.
-- **User-provided destination:** follow the requested safe location and format.
-
-Do not turn an ephemeral transfer into repository memory. If the destination materially changes durability, privacy, repository state, audience, or authority and the user has not chosen it, ask one question and wait.
-
-Read [Handoff Templates](references/handoff-templates.md) after the shape, recipient, and purpose are clear. Use only fields that change safe continuation; the template is not a requirement to create another document.
-
-## Prepare From The Actual State
-
-Inspect only the relevant worktree, artifacts, processes, and evidence needed to describe what the recipient will encounter. Reconcile an existing Working Record through Track Work when its understanding, current work, dependencies, evidence, or next action changed.
-
-Preserve the execution agreement separately from the immediate assignment: what outcome remains authorized, what this unit covers, what is excluded, and when the user expects a return. Identify the assignment's source and any superseded instruction whose reuse would misdirect continuation. A recommendation to continue is not the same as approval to finish the remaining task.
-
-Do not create a record merely because a handoff exists or change task/Slice state merely because context will be transferred. Use the host's safe boundary for ongoing operations; do not infer an unobserved result or interrupt a mutation to make a cleaner handoff.
-
-Partial work is a valid transfer state. Preserve unverified edits, failing checks, unresolved causes, and residual effects honestly. Do not rush to completion because compaction is near.
-
-## Capture The Next Useful Continuation
-
-Include only material information:
-
-- the intended outcome, agreed scope, user-facing return condition, and defining sources;
-- current task/Slice and Workflow route when present;
-- completed and partial work, supporting evidence, and what remains unverified;
-- relevant repository, worktree, artifact, configuration, or process identity;
-- accepted decisions and their sources, later amendments, and remaining hypotheses;
-- changed assumptions, consequential rejected approaches, and affected Spec or Plan sections;
-- dependencies for remaining work and which are established versus unresolved;
-- the next accepted action and the minimum sources needed for it, or a recommendation awaiting authority;
-- blockers, selected checkpoints, and conditions requiring return rather than continuation.
-
-Point to the current Working Record and accepted artifacts instead of duplicating their full contents. A Plan preserves strategy; the record preserves actual work and deviations. The handoff preserves transfer-specific context, not a second mutable task narrative.
-
-For learning, preserve the question, evidence and limits, the discard/revise/promote/inconclusive result, exploratory-artifact disposition, and consequence for dependent work. A recorded promotion does not grant production authority.
-
-For selected independent review, preserve review number, reviewed state, reviewer and adjudicated judgments, material Accepted or Open findings, changed areas, and whether follow-up remains selected. A new context or reviewer does not reset the budget.
-
-## Preserve Scope And Evidence
-
-A newer summary is not necessarily a newer accepted decision. Distinguish source-backed changes from proposals; do not let "next" turn an optional follow-up into an obligation or carry a stronger claim than the evidence supports.
-
-Include narrow dirty-state or process details when omission could cause loss, overwrite, duplicate execution, or false completion. Keep check outputs linked to the code/artifact and observer state they examined using available identities or source pointers. Distinguish an actual prior observation from whether it still applies after later changes. A missing output is unavailable evidence, not a reason to invent or automatically repeat the run. Do not copy full diffs, logs, transcripts, or reviewer reports when exact recoverable pointers suffice.
-
-Exclude secrets, credentials, unrestricted personal data, and private payloads unnecessary for continuation. Do not promise access to unavailable sources or reconstruct their exact content from memory.
-
-If safe transfer would require inventing intent, approval, evidence, status, or destination, state the missing information. Use [Decision Gate](../decision-gate/SKILL.md) when resolving it needs one user-owned choice.
-
-## Reconstruct Before Resuming
-
-Follow current core and capability recovery guidance before task action. A handoff's earlier route or profile description is not current runtime state.
-
-1. Read the complete Working Record through `view full` when resuming after context loss or into another context. Do not substitute its `resume` view or the handoff's summary. With intact context, follow Track Work's bounded in-session read guidance.
-2. Reconcile the record and handoff with current user direction, defining sources, and the relevant live environment. Follow supersession and corrections without silently reviving historical decisions.
-3. Check important completion, verification, review, commit, and artifact-identity claims against their evidence before repeating them. Reuse adequate current evidence; a transfer alone does not require rerunning every check.
-4. Establish the actual partial state, remaining dependencies, accepted work agreement, current assignment, and next useful action. Resolve contradictory old/new instructions from their sources before acting; do not resume editing when the current unit permits inspection only. Reopen only additional sources whose exact content or freshness changes that action.
-5. Return the recovered state to [Workflow](../workflow/SKILL.md) for the supported route and authority check. Continue covered work through its owner; stop for a genuine blocker or uncovered choice.
-
-Without a Working Record, use the available transfer and exact sources to reconstruct enough state; report any missing boundary rather than inventing it. If a required full-record read is incomplete or unavailable, follow Track Work's stop condition instead of claiming recovery succeeded.
-
-Do not edit merely because a handoff names a next action. Do not restart the whole task or ask for another "continue" solely because an already-authorized task crossed a context boundary. Slice selection and lifecycle remain with Workflow and Track Work, not the handoff.
-
-## Report And Stop
-
-Report the transfer shape and destination, sources preserved, actual state and evidence limits, next accepted action or pending recommendation, and material missing or intentionally omitted sensitive information.
-
-At the selected pause or transfer boundary, stop after delivering the handoff. It does not complete, block, abandon, or supersede the task or Slice. On recovery, end Handoff once the next owner can continue with coherent scope, authority, and evidence.

package/skills/handoff/references/handoff-templates.md

@@ -1,150 +0,0 @@
-# Handoff Templates
-
-Read this after the transfer shape, recipient, and purpose are clear. Omit every field that does not change safe continuation.
-
-Handoffs are memory, not authority. Live sources and repository state override stale handoff text.
-
-## Ephemeral Handoff
-
-Use in the current response, a host continuation mechanism, or a temporary file for immediate continuation.
-
-```md
-# Continuation Handoff
-
-Generated: <optional reliable date or time>
-Recipient / purpose:
-
-## Goal And Owning Sources
-- Agreed outcome and scope:
-- User-facing return condition:
-
-## Current State
-- Workflow route:
-- Working Record, Spec, or Plan pointers:
-- Relevant source or artifact identity:
-
-## Completed Work And Evidence
-- Result:
-- Evidence:
-- Supports:
-- Does not support:
-
-## Decisions And Authority
-- Decision:
-- Established by:
-- Scope:
-
-## Deviations Or Invalidated Assumptions
-
-## Worktree, Process, Or Environment Watchouts
-
-## Review Continuity
-
-## Open Decisions, Evidence, Or Blockers
-
-## Next Action
-- Accepted action:
-- Authority source:
-- Required dependencies and whether they hold:
-- Sources needed for this action:
-
-Or, when not approved:
-- Recommended route:
-- Approval or decision needed:
-
-## Stop Conditions
-```
-
-Keep dirty-state details narrow. Include only paths, processes, environments, or artifacts whose omission risks loss, overwrite, duplicate work, or a false claim. In Current State, preserve the current assignment and source when older instructions could compete. In Completed Work And Evidence, distinguish the state actually checked from later changes whose verification remains unresolved.
-
-## Repo-Memory Handoff
-
-Use for durable project continuation in the repository's established location.
-
-```md
-# Project Handoff
-
-Generated: <optional reliable date or time>
-Recipient / purpose:
-
-## Goal And Accepted Outcome
-- Agreed scope and exclusions:
-- User-facing return condition:
-
-## Owning Sources
-
-## Stable Context
-
-## Current State And Evidence
-
-## Working Record, Spec, And Plan Pointers
-
-## Decisions, Authority, And Approval Scope
-
-## Deviations, Invalidated Assumptions, Or Superseded Direction
-
-## Review Continuity
-
-## Open Decisions, Evidence Gaps, And Stop Conditions
-
-## Next Accepted Action
-- Action:
-- Authority source:
-- Required dependencies and whether they hold:
-- Sources needed for this action:
-
-Or:
-
-## Recommended Next Route
-- Route:
-- Approval or decision needed:
-```
-
-Do not copy living progress from a Working Record or turn directional Plan content into committed work. Preserve only stable or transfer-critical context that belongs in the handoff.
-
-## Learning-Slice Addendum
-
-Include when an experiment, prototype, benchmark, or investigation changed the route:
-
-```md
-Question:
-Competing hypotheses or designs:
-Evidence captured:
-Result: discard | revise | promote | inconclusive
-Exploratory artifacts retained:
-Affected Working Record, Spec, Plan, or later work:
-Next accepted action and authority, or recommended route:
-```
-
-Promotion records a decision; it does not itself authorize production implementation.
-
-## Review-Continuity Addendum
-
-Include only when review state must survive the transfer:
-
-```md
-Review number: 1 | 2 | 3
-Reviewed state identity:
-Reviewer judgment: Pass | Non-blocking | Inconclusive | Blocking
-Adjudicated judgment: Pass | Non-blocking | Inconclusive | Blocking
-Material review items and evidence pointers:
-Active-agent item adjudication:
-- <item>: Accepted | Rejected | Open — <reason>
-Accepted Blocking or Non-blocking Issues:
-Material Open items:
-Changed areas after review:
-Follow-up review status and authority:
-```
-
-Do not copy full reviewer output when a stable pointer exists. A new context or reviewer continues the existing budget; local edits, renamed scope, or a different reviewer do not reset it.
-
-## Resume Checklist
-
-- After context loss or transfer into another context, read the complete Working Record through `view full` when one exists. A summary or `resume` projection is not a substitute. Use Track Work's bounded reads for intact-session continuation.
-- Reconcile the record and handoff with current user direction and relevant live state; reopen named source truth where exact meaning or freshness matters.
-- Confirm artifact, environment, commit, and configuration identity where claims depend on them.
-- Check important completion and evidence claims before repeating them; distinguish that a run occurred from whether it applies to the current candidate. Reuse adequate evidence rather than rerun every check merely because a transfer occurred.
-- Compare the execution agreement, current assignment and its source, return condition, decisions, dependencies, and review state with the next proposed action. Resolve superseded or conflicting directions before acting.
-- Preserve valid and partial work; identify only the invalidated layer. Missing or incomplete recovery remains a reported limit.
-- Return the supported route and authority state to Workflow before editing; do not require another user turn merely to continue an already-covered task.
-- Use Decision Gate for user-owned choices or source conflicts.

package/skills/launch-work/SKILL.md

@@ -1,116 +0,0 @@
----
-name: launch-work
-description: Use when preparing or carrying out a production deployment, rollout, rollback, or recovery.
----
-
-# Launch Work
-
-Change production deliberately, observe the result, and preserve a safe recovery path.
-
-Deployment changes what runs. Rollout changes who or what is exposed. A build, merge, release, or staging pass does not prove production behavior.
-
-## Establish Authority And Boundary
-
-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.
-
-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.
-
-Before selecting risk lenses, operational evidence, rollout stages, or recovery checks, read [launch readiness](references/launch-readiness.md). 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.
-
-## Define The Launch Contract
-
-Before changing production, establish:
-
-```text
-Outcome and affected users / systems:
-Artifact / commit / configuration identity:
-Target environment and owner:
-Deployment versus exposure stages:
-Dependencies and migration ordering:
-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.
-
-## Establish Readiness
-
-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 recovery authority.
-
-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.
-
-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.
-
-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.
-
-## Deploy And Expose In Approved Stages
-
-Separate operations when the platform permits it:
-
-- deploy inert code, configuration, or infrastructure;
-- verify health and compatibility;
-- 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, and phased regions are options, not defaults. Choose only mechanisms supported by the platform and accepted failure contract.
-
-For each approved stage:
-
-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, data integrity, and unexpected side effects;
-5. preserve anomalies and choose the next route before expanding exposure.
-
-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.
-
-## Handle Failure And Recovery
-
-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 effects make rollback unsafe or incomplete. Forward recovery may be safer, but it is not automatic permission to broaden scope.
-
-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](../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.
-
-## Verify The Production Outcome
-
-Observe from the production boundary as applicable:
-
-- intended artifact and configuration are active;
-- critical user and failure paths behave as accepted;
-- data, compatibility, privacy, and permission invariants hold;
-- telemetry is present, queryable, bounded, and free of unexpected sensitive data;
-- 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. State production paths, cohorts, observation windows, or recovery behavior that remain unverified.
-
-## Report Completion Precisely
-
-Report:
-
-- 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 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.