@msn-control/liftoff 0.11.2 → 0.12.0

package/DEVELOPER.md

@@ -51,32 +51,33 @@ and successful generated-file checks must not be described as those capabilities
 
 ## Activation version vector
 
-Current deterministic setup contract, retained by the 0.11.2 CLI patch:
+Current deterministic setup contract, published by Liftoff 0.12.0:
 
 ```json
 {
-  "liftoffVersion": "0.11.0",
+  "liftoffVersion": "0.12.0",
   "manifestArtifactVersion": 7,
   "policyVersion": "6",
-  "activationContractVersion": 2,
-  "phaseGraphSchemaVersion": 1,
-  "phaseGraphHash": "ac160e3fc86f3e438141d985658e09f419508b3adbe176ddd13100d5dfdee47c",
-  "activationStateSchemaVersion": 2,
-  "evidenceHeaderSchemaVersion": 2,
-  "approvalEnvelopeSchemaVersion": 2,
+  "activationContractVersion": 3,
+  "phaseGraphSchemaVersion": 2,
+  "phaseGraphHash": "2e214353fe73edeea246dac49aa5126c3d1e50afb3e12801940b661afb853703",
+  "activationStateSchemaVersion": 3,
+  "evidenceHeaderSchemaVersion": 3,
+  "approvalEnvelopeSchemaVersion": 3,
   "supersessionSchemaVersion": 1,
   "credentialPolicySchemaVersion": 1
 }
 ```
 
 `phaseGraphHash` is the lowercase SHA-256 hex digest of the canonical packaged
-phase graph bytes. When documenting unreleased work before the final graph is
+29-phase graph bytes, spanning from local readiness through `bootstrap-workflow-source-ready`
+to final lifecycle disposal. When documenting unreleased work before the final graph is
 known, use a clear placeholder such as `<sha256-of-canonical-phase-graph-json>`;
 do not fabricate a historical value.
 
 The generated `liftoff.manifest.json` records this as manifest `artifactVersion`
 7 plus the activation identity fields shown above. Compatibility metadata uses
-schema version 3 in its own document, not a new required manifest field.
+schema version 4 in its own document, not a new required manifest field.
 Assessment report/catalog, graph, supersession, and credential-policy schemas
 remain at version 1; normative policy remains 6.
 
@@ -273,15 +274,16 @@ npm run verify:generated-containers
 npm run verify:release-identity
 ```
 
-## 0.11.2 release checklist
+## 0.12.0 release checklist
 
 - Package metadata, lockfile metadata, `liftoff --version`, and tag agree on
-  `0.11.2`. Preparing these files is not publication or permission to create a tag.
+  `0.11.3`. Preparing these files is not publication or permission to create a tag.
 - Activation package identity remains `0.11.0`; no phase semantics or graph
   identity change is introduced by patch-release preparation.
-- Release notes prominently identify the breaking update-CLI/report changes:
-  mandatory matching preview and exact-plan approval, schema-3 project-update
-  reports, and exit 2 after committed but incomplete local revalidation.
+- Release notes identify context-aware update follow-ups, root-aware validation
+  guidance, and reason-specific preview errors. Mandatory matching preview and
+  exact-plan approval, schema-3 project-update reports, and exit 2 after committed
+  but incomplete local revalidation remain unchanged.
 - Manifest writes use artifactVersion 7; readers accept v2-v7.
 - Policy version is `"6"`; activation contract/state/evidence-header/approval
   remain v2. Compatibility metadata and update reports are v3; preview receipts,
@@ -298,8 +300,8 @@ npm run verify:release-identity
   activation history remain preserved. Only the exact approved migration lane
   can create a linked v2 successor; it does not retag historical proof.
 - Independent infrastructure provenance explicitly admits generation versions
-  `0.11.0`, `0.11.1`, and `0.11.2`, including mixed component histories. Unknown
-  releases remain blocked rather than being accepted through a version range.
+  `0.11.0`, `0.11.1`, `0.11.2`, and `0.11.3`, including mixed component histories.
+  Unknown releases remain blocked rather than being accepted through a version range.
 - No setup-skill version exists in manifests, JSON status, docs, or generated
   integrations.
 - Doctor states and remedies cover seed-incomplete, phase-blocked,
@@ -429,17 +431,17 @@ and facade use. Packed smoke covers runtime asset lookup outside this checkout.
 ## Activation completeness and separate follow-up plan
 
 The activation engine is not yet an end-to-end production provisioning engine.
-Of its 26 declared phases, 10 have built-in handler paths, 2 require an injected
-GitHub ruleset adapter that the public CLI does not currently supply, and 14
+Of its 29 declared phases, 11 have built-in handler paths, 2 require an injected
+GitHub ruleset adapter that the public CLI does not currently supply, and 16
 fall back to an explicit missing-production-adapter blocker.
 
-The missing production phase handlers are `provider-ready`,
-`state-path-selected`, `existing-private-path`, `bootstrap-local`,
+The missing production phase handlers are `bootstrap-workflow-source-ready`,
+`provider-ready`, `state-path-selected`, `existing-private-path`, `bootstrap-local`,
 `runner-ready`, `private-backend-proof`, `remote-import-verified`,
+`application-prerequisites-ready`, `application-artifact-ready`,
 `application-foundation`, `workflow-source-ready`, `dev-proof`,
-`staging-qualified`, `production-rehearsed`, `green-red-proof`, and
-`enforcement-approved`. `rulesets-applied` and `live-readback` have adapter
-contracts but need production wiring.
+`staging-qualified`, `production-rehearsed`, and `green-red-proof`.
+`rulesets-applied` and `live-readback` have adapter contracts but need production wiring.
 
 Built-in handler presence does not establish a complete user journey:
 approval envelopes are read from disk but no public approval-persistence

package/README.md

@@ -2,7 +2,8 @@
 
 **Initialize governed GenAI applications and APIs from one
 interactive CLI.** Liftoff combines reviewable starter projects with OpenSpec or
-Spec Kit and integrates GitHub Copilot, Claude Code, or both from the first commit.
+Spec Kit and integrates GitHub Copilot, Claude Code, and Codex in any selected
+combination.
 
 [![npm version](https://img.shields.io/npm/v/%40msn-control%2Fliftoff?logo=npm)](https://www.npmjs.com/package/@msn-control/liftoff)
 [![CI](https://github.com/voyager163/liftoff/actions/workflows/ci.yml/badge.svg)](https://github.com/voyager163/liftoff/actions/workflows/ci.yml)
@@ -27,16 +28,15 @@ cd my-project
 
 `liftoff init` asks for workload, spec workflow, agents, readiness, and plan
 confirmation before writing local files. Repository governance is enabled by
-default as a local deterministic handoff. For OpenSpec, `/liftoff-setup` completes,
+default as a deterministic setup handoff. For OpenSpec, `/liftoff-setup` completes,
 syncs, and archives the generated bootstrap seed. Spec Kit finalizes its one-time
 bootstrap bundle locally, without an OpenSpec archive or new Git branch.
 No model selection is required for setup; the CLI phase graph, evidence, and
-approvals are authoritative. Missing production executors, credential enrollment,
-and approval-persistence capabilities remain explicit blockers, not completed
-automation.
+approvals are authoritative. Setup coordinates reviewed repairs and local readiness,
+then separately approved publication, Azure activation, deployment, and governance.
+Local-only use remains supported. Codex invokes `$liftoff-setup` or selects the native skill.
 
-After the first self-upgrade-capable release is installed globally through npm,
-later CLI releases use `liftoff upgrade --check` followed by `liftoff upgrade`.
+After global npm install, later releases use `liftoff upgrade --check` then `liftoff upgrade`.
 This replaces the CLI only; generated projects use `liftoff update` separately
 for reviewed project maintenance. Useful project-read-only checks:
 
@@ -52,15 +52,15 @@ matching plan. Check leaves project bytes unchanged and discloses a preview
 receipt saved outside the repository. Missing or stale previews block apply.
 Automation uses `--approve-plan <fingerprint>`; `--json` only selects formatting.
 
-Supported activation-v1 migration preserves original records inside the project
-and creates a linked v2 activation. Failed revalidation leaves v2 blocked and
-resumable, not reset to v1. Application source, dependencies, schemas, containers,
-environments, documentation, and infrastructure remain project-owned and outside
-template replacement, including `--force`.
+Supported activation-v1/v2 migration preserves original records inside the project
+and creates a linked v3 activation. Failed revalidation leaves v3 blocked and
+resumable, not reset to an older contract. Application source, dependencies, schemas,
+containers, environments, documentation, and infrastructure remain project-owned
+and outside template replacement, including `--force`. Topology, additive agent repairs,
+and stateful migration require their own exact preview, backups, and write authority.
 
 Older projects may display the retired `/liftoff-repository-governance` alias.
-After upgrading the CLI, review `liftoff update --check`; `liftoff update --force`
-can remove only its exact recorded aliases. Reload the coding-agent session.
+Review `liftoff update --check`; `liftoff update --force` removes only exact recorded aliases.
 
 ![Liftoff terminal showing interactive workload, workflow, multi-agent, readiness, and safe completion steps](docs/assets/liftoff-terminal.svg)
 
@@ -77,11 +77,11 @@ PydanticAI invocation foundation without assuming RAG, chat, agents, streaming,
 fine-tuning, or workflows.
 
 Both workloads can use **OpenSpec** or **Spec Kit** with **GitHub Copilot**,
-**Claude Code**, or both.
+**Claude Code**, **Codex**, or any combination. Official stable and preview releases
+are accepted; runtime and framework pins remain enforced.
 
-Power Apps and its Code Apps plugin integration are retired. Existing Power Apps
-projects receive an unsupported-workload error without changing their files;
-`--force` does not provide a compatibility or conversion path.
+Power Apps is retired. Existing Power Apps projects receive an unsupported-workload
+error without changing files; `--force` does not provide a conversion path.
 
 [Compare workload questions and outputs](docs/workloads.md) |
 [Choose a spec workflow and agents](docs/spec-workflows-and-agents.md)