@msn-control/liftoff 0.10.1 → 0.10.3

package/docs/cli-reference.md

@@ -30,7 +30,7 @@ install -> upgrade CLI -> plan -> init or migrate -> /liftoff-setup -> validate,
 | `liftoff governance plan [project]` | Previews ready and blocked phase transitions, required evidence, approval gates, permitted mutations, and cost-envelope impact without writes |
 | `liftoff governance apply-next [project]` | Previews the next graph-ready transition; add `--execute` to execute at most one approved mutation |
 | `liftoff governance resume [project]` | Rechecks external blockers and readiness descendants without rerunning verified operations |
-| `liftoff governance verify [project]` | Read-only validation of graph, state, evidence, task projection, policy identity, active-change identity, and live readback |
+| `liftoff governance verify [project]` | Read-only validation of graph, state, evidence, task projection, policy identity, active-change identity, and live readback; reports consistency separately from setup completion and reports completion as indeterminate when inspection fails |
 | `liftoff upgrade` | Replaces a verified global npm installation with the exact canonical stable release exposed by the configured registry |
 | `liftoff upgrade --check` | Checks installation origin and registry parity without installing; exits 2 when an installable update exists |
 | `liftoff update [project]` | Applies safe managed-core maintenance and authorized create-only component provisioning |
@@ -112,9 +112,8 @@ emits a setup-skill version. Future identities, unsupported compatibility
 tuples, and unrecognized graph hashes block without rewriting state; the remedy
 names the exact field and required Liftoff upgrade.
 
-`/liftoff-setup` and the compatibility alias `/liftoff-repository-governance`
-call these commands instead of inferring phase completion from prose or task
-checkboxes.
+`/liftoff-setup` calls these commands instead of inferring phase completion from
+prose or task checkboxes.
 
 OpenSpec projects use all 12 OpenSpec 1.11 workflows with both skills and
 commands. `--copilot-cloud` opts into the GitHub-hosted coding-agent workflow and
@@ -176,10 +175,11 @@ Plain `liftoff update` is imperative and prompt-free. It applies safe new,
 missing, untouched-upgrade, clean-move, and recorded-state changes only for
 explicit `managed-core` artifacts. For manifest v7 this includes governance
 policy, context, guide, phase graph, compatibility metadata, credential-policy
-schema, setup integrations, and selected-agent compatibility aliases. Core
-conflicts are skipped and core orphans are reported without deletion. During
-legacy governance adoption, preserved unrecorded conflicts remain outside
-managed ownership and set local state to `handoff-partial`.
+schema, and selected-agent `/liftoff-setup` integrations. Core conflicts are
+skipped and core orphans are reported without deletion. During legacy governance
+adoption, preserved unrecorded conflicts remain outside managed ownership and
+set local state to `handoff-partial`. Forced update may remove exact retired
+generated setup-alias entries from older manifests after review.
 
 Application source, tests, dependencies and locks, database assets, Docker and
 Compose files, environment files, documentation, Power Apps starter files, and
@@ -244,6 +244,8 @@ liftoff validate --json
 liftoff doctor --json
 liftoff governance status --json
 liftoff governance plan --json
+liftoff governance apply-next --json
+liftoff governance apply-next --json --execute
 liftoff governance verify --json
 liftoff upgrade --json
 liftoff upgrade --check --json

package/docs/configuration-and-manifests.md

@@ -152,8 +152,9 @@ category or filename:
 The manifest is a CLI-owned transaction record rather than an ordinary
 template artifact. Current managed core is limited to the exact repository
 governance policy, context, guide, phase graph, compatibility metadata,
-credential-policy schema, `/liftoff-setup` integrations, and selected-agent
-compatibility aliases. A name such as `config.go`, a `configuration` category,
+credential-policy schema, and selected-agent `/liftoff-setup` integrations.
+Forced update may remove exact retired generated setup-alias entries from older
+manifests after review. A name such as `config.go`, a `configuration` category,
 or a path under `.github` does not grant update authority.
 
 User-owned governance artifacts are deliberately excluded from managed-core

package/docs/existing-repositories.md

@@ -92,8 +92,8 @@ and run `openspec update`.
 Projects created before manifest artifact version 7 automatically preview the
 default deterministic setup handoff as new named drift. Plain update safely
 adopts collision-free policy, context, guide, phase graph, compatibility
-metadata, credential-policy schema, setup integrations, and selected-agent
-aliases without rewriting a configuration that omitted `governanceProfile`.
+metadata, credential-policy schema, and selected-agent setup integrations
+without rewriting a configuration that omitted `governanceProfile`.
 Existing different files remain unowned conflicts and the v7 manifest records
 `handoff-partial`.
 Resolving every conflict promotes a later update to `handoff-generated`.

package/docs/project-structure.md

@@ -52,9 +52,7 @@ project/
 |-- .github/workflows/copilot-setup-steps.yml              # optional hosted agent
 |-- .github/agents/openspec.agent.md                       # optional hosted agent
 |-- .github/prompts/liftoff-setup.prompt.md
-|-- .github/prompts/liftoff-repository-governance.prompt.md # compatibility alias
 |   or .claude/commands/liftoff-setup.md
-|   and .claude/commands/liftoff-repository-governance.md
 |-- frontend/                  # only when selected
 |-- functions/<worker-name>/  # only for worker-enabled GenAI patterns
 `-- migration/legacy/         # only after liftoff migrate
@@ -89,8 +87,7 @@ project/
   generated only after explicit opt-in.
 - `/liftoff-setup` is generated when repository governance is enabled. It calls
   `liftoff governance status|plan|apply-next|resume|verify` and has no model
-  selection or separate setup-skill version. `/liftoff-repository-governance` is
-  a compatibility alias for the same state.
+  selection or separate setup-skill version.
 
 ### Conditional areas
 
@@ -148,8 +145,9 @@ Liftoff intentionally does not generate `backend/`, `database/`,
 
 `liftoff.manifest.json` v7 records managed-core hashes for the governance policy,
 context, guide, phase graph, compatibility metadata, credential-policy schema,
-setup integrations, and compatibility aliases. `liftoff update` may reconcile
-only those managed-core paths. It preserves user-owned activation state,
+and setup integrations. `liftoff update` may reconcile only those managed-core
+paths. Forced update may remove exact retired generated setup-alias ownership
+from older manifests after review. It preserves user-owned activation state,
 immutable evidence, approvals, credential policies, active OpenSpec changes, and
 project source.
 

package/docs/repository-governance.md

@@ -15,9 +15,8 @@ cd my-project
 ```
 
 `/liftoff-setup` completes the generated bootstrap seed, then enters the
-deterministic Liftoff governance engine and its read-only Phase 0 discovery. The older
-`/liftoff-repository-governance` launcher is a compatibility alias for the same
-engine and user-owned activation state; it is not a separate activation path.
+deterministic Liftoff governance engine, user-owned activation state, and
+read-only Phase 0 discovery.
 
 ## Managed files and user-owned state
 
@@ -31,11 +30,13 @@ Enabled governance adds managed-core files:
 .liftoff/governance/compatibility.json
 .liftoff/governance/credential-policy.schema.json
 .github/prompts/liftoff-setup.prompt.md                # Copilot selected
-.github/prompts/liftoff-repository-governance.prompt.md # compatibility alias
 .claude/commands/liftoff-setup.md                      # Claude selected
-.claude/commands/liftoff-repository-governance.md       # compatibility alias
 ```
 
+Older generated setup aliases are retired. Use `liftoff update --force` after
+review to remove exact modified retired alias entries from older manifests; do
+not invoke them as commands.
+
 User-owned execution state is separate and is never advanced by
 `liftoff update`:
 
@@ -170,8 +171,9 @@ seed blocks Phase 0. Exactly one compatible active governance change is resumed.
 Multiple overlapping changes require a schema-valid supersession or archive
 record before any phase advances.
 
-Managed updates install new policy, graph, schema, compatibility metadata, setup
-integrations, and aliases without touching user-owned state. When a policy,
+Managed updates install new policy, graph, schema, compatibility metadata, and
+setup integrations without touching user-owned state. Forced update can remove
+exact retired generated setup-alias entries from older manifests. When a policy,
 activation-contract, schema, or graph-hash change affects active work, status
 reports `reconciliation-required`, invalidates only affected descendants, and
 waits for explicit acknowledgement of the current compatible identity and exact
@@ -204,6 +206,7 @@ The generated setup integrations call only strict, project-aware CLI commands:
 ```bash
 liftoff governance status --json
 liftoff governance plan --json
+liftoff governance apply-next --json
 liftoff governance apply-next --json --execute
 liftoff governance resume --json
 liftoff governance verify --json
@@ -211,8 +214,12 @@ liftoff governance verify --json
 
 `status`, `plan`, and `verify` are read-only. `apply-next` previews mutations
 unless `--execute` is supplied, and even then executes at most one graph-ready,
-evidence-ready, approved phase. Unknown subcommands, flags, or extra positionals
-fail before project discovery or mutation.
+evidence-ready, approved phase. Here, approved means its approval status is
+`not-required` or `reused`. Unknown subcommands, flags, or extra positionals
+fail before project discovery or mutation. Verification reports consistency
+separately from setup completion: a valid not-started or in-progress state may
+have `ok: true` and `verificationStatus: "consistent"` while `complete` remains
+false.
 
 ## Existing projects
 

package/docs/safety-and-consent.md

@@ -98,11 +98,12 @@ are committed only after the other mutations succeed.
 
 Managed update may install manifest v7, policy v6, activation-contract v1,
 phase graph, compatibility metadata, credential-policy schema, setup
-integrations, and compatibility aliases. It preserves user-owned activation
-state, approvals, immutable evidence, credential policies, active OpenSpec
-changes, and bootstrap retention/disposal records. If the current activation
-identity is future, unsupported, or graph-incompatible, update and setup block
-with a remedy instead of downgrading or rewriting state.
+integrations, and forced removal of exact retired generated setup-alias entries
+from older manifests. It preserves user-owned activation state, approvals,
+immutable evidence, credential policies, active OpenSpec changes, and bootstrap
+retention/disposal records. If the current activation identity is future,
+unsupported, or graph-incompatible, update and setup block with a remedy instead
+of downgrading or rewriting state.
 
 If automatic rollback itself cannot safely restore a path because another
 process changed it, Liftoff reports the incomplete rollback rather than

package/docs/troubleshooting.md

@@ -193,8 +193,9 @@ completes, syncs, and archives the generated bootstrap seed with local baseline
 checks, then stops at explicit authority gates for commit/push, credentials,
 billed infrastructure or exceptions, final enforcement, destructive cleanup, or
 external blockers. Rerun `/liftoff-setup` to resume; verified phases are not
-repeated. `/liftoff-repository-governance` is only a compatibility alias for the
-same engine and state.
+repeated. Older generated setup aliases are retired; after review,
+`liftoff update --force` removes exact modified retired alias entries from older
+manifests.
 
 Missing licenses, runner-provisioning authority, a private Staging assignment or
 reachable network path, alert routes, parallel deployment, or sufficient canary

package/docs/workloads.md

@@ -40,7 +40,7 @@ Automation can select the neutral starting point explicitly with
 - Docker Compose and Azure OpenTofu.
 - Optional Vue frontend and pattern-specific Azure Functions workers.
 - Versioned repository-governance policy, workload context, guide, and
-  selected-agent launcher unless `none` is selected.
+  selected-agent `/liftoff-setup` integration unless `none` is selected.
 
 ### Deferred actions
 
@@ -107,7 +107,7 @@ environment, API frontend, Docker, or OpenTofu selection.
 - `liftoff.config.json`, manifest-v7 `liftoff.manifest.json`, starter provenance,
   and third-party attribution.
 - Official OpenSpec or Spec Kit output and every selected agent marker.
-- The common local governance policy and selected-agent launcher, with backend,
+- The common local governance policy and selected-agent `/liftoff-setup` integration, with backend,
   container, OpenTofu, custom deployment, and API DAST controls marked
   inapplicable.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@msn-control/liftoff",
-  "version": "0.10.1",
+  "version": "0.10.3",
   "description": "Interactive CLI for governed GenAI, API, and Power Apps code app projects.",
   "type": "module",
   "license": "GPL-3.0-only",