@msn-control/liftoff 0.10.4 → 0.11.1

package/DEVELOPER.md

@@ -3,21 +3,67 @@
 This guide covers release-owned compatibility, deterministic setup, and package
 publishing. General contribution setup remains in [CONTRIBUTING.md](CONTRIBUTING.md).
 
+## Stabilization acceptance matrix
+
+The `stabilize-and-modularize-liftoff` change separates retirement, mechanical
+extraction, and behavior corrections. This matrix identifies acceptance targets,
+not a claim of production readiness. Its OpenSpec task checklist is the progress
+authority; the locations below identify the extracted implementation, not its
+temporary compatibility facades.
+
+| Capability | Canonical implementation area under `src/` | Acceptance evidence | Change kind |
+| --- | --- | --- | --- |
+| `liftoff-cli-workflow` | `cli/args/`, `cli/commands/`, `domain/project/inputs.ts`, `interactive.ts` | Command, interactive, help and lifecycle cases | Retirement, correction, extraction |
+| `liftoff-power-apps-code-apps` | `domain/project/retired-workload.ts` and manifest/input guards | Retired-manifest rejection and explicit retirement inventory | Retirement |
+| `liftoff-project-scaffold` | `generators/{common,genai,containers}/`, `templates.ts` assembler | Template, generated-stack and seed-lifecycle cases | Retirement, correction, extraction |
+| `liftoff-standard-projects` | `generators/standard/`, `adapters/packaged-assets/` | Three-stack startup/configuration and container cases | Correction |
+| `liftoff-supported-stack-baselines` | `domain/project/supported-stack.ts`, `adapters/packaged-assets/supported-stack.ts` | Baseline identity, integrity and freshness cases | Retirement, correction |
+| `liftoff-template-dependency-security` | Audit/freshness scripts and explicit package inventories | Template dependency/security and inventory cases | Retirement |
+| `liftoff-infrastructure-governance` | `generators/infrastructure/`, `domain/project/infrastructure-layout.ts`, `cli/commands/helpers.ts` | Per-environment roots, state, naming and sender/receiver cases | Correction, extraction |
+| `liftoff-workstation-bootstrap` | `application/initialize/`, `domain/workstation/`, workstation/framework registries | Runtime/package-manager constraints and independent consent | Retirement, correction |
+| `liftoff-project-migration` | `domain/migration/`, `scan.ts`, `migrate-plan.ts`, `application/migrate/` | Complete inventory, target overrides, source preservation, cleanup-last | Correction, extraction |
+| `liftoff-template-ownership` | `domain/project/artifact-lifecycle.ts`, `reconcile.ts` | Exact ownership, create-only provisioning and force refusal | Retirement, preservation |
+| `liftoff-manifest-contract` | `domain/project/manifest/`, `application/project/manifest.ts` | API/GenAI v2-v7 readers, retirement and historical identity boundaries | Retirement, correction, extraction |
+| `liftoff-project-update` | `application/update/`, `adapters/filesystem/` | Collisions, recovery, concurrent edits, modes and layout gates | Correction, extraction |
+| `liftoff-project-doctor` | `application/diagnose/` and shared probes | Honest readiness, invalid boundaries and no-write diagnostics | Retirement, correction, extraction |
+| `liftoff-cli-self-upgrade` | `application/upgrade/`, `self-upgrade.ts`, `stable-release.ts` | Scoped registry precedence, isolation and failure classification | Correction, extraction |
+| `liftoff-npm-distribution` | Package metadata and packaging/release scripts | Packed CLI entry point, asset resolution and historical surfaces | Retirement, preservation |
+| `liftoff-repository-governance-profile` | `repository-governance.ts`, `domain/governance/policy/identity.ts` | Fixed policy, real workload boundaries and exact managed inventory | Retirement, preservation |
+| `liftoff-governance-activation-engine` | `domain/governance/activation/`, `governance-activation/` | Current-input/body binding, retries, selected paths, Spec Kit seed | Correction, extraction |
+| `liftoff-governance-assessment` | `domain/governance/assessment/`, `governance-assessment/`, read-only Git/GitHub/Azure adapters | Any-Git coverage, effective enforcement, partial reads and no writes | Correction, extraction |
+| `liftoff-user-documentation` | README, developer guide and packaged docs | Links, accurate capabilities, ownership and compatibility guidance | Retirement, correction |
+
+Mechanical extraction must preserve the existing supported help, JSON and
+generation fixtures except for separately reviewed intentional changes. The
+pre-change capture includes all nine GenAI patterns, three standard API stacks,
+Spec Kit, and a frontend-enabled production-only case. A new directory or
+forwarding callback does not establish a new implementation boundary.
+
+The explicit non-generative retirement inventory is
+`tests/fixtures/power-apps-retirement.json`. It separates whole-file removal,
+source/reference edits, shared cases to port, and the historical manifest kept
+only as negative input. Do not expand that inventory into blanket deletion of
+unknown files or user projects.
+
+Production executors, public approval/credential enrollment, and missing GenAI
+specializations remain deferred. Local baseline evidence, read-only assessment,
+and successful generated-file checks must not be described as those capabilities.
+
 ## Activation version vector
 
-Example for the Liftoff 0.10.0 deterministic setup contract:
+Current deterministic setup contract, retained by the 0.11.1 CLI patch:
 
 ```json
 {
-  "liftoffVersion": "0.10.0",
+  "liftoffVersion": "0.11.0",
   "manifestArtifactVersion": 7,
   "policyVersion": "6",
-  "activationContractVersion": 1,
+  "activationContractVersion": 2,
   "phaseGraphSchemaVersion": 1,
-  "phaseGraphHash": "b84bcde6cd614637f2486b0f3a202860e6e9a6142ac60c773daa11786dbeb7f7",
-  "activationStateSchemaVersion": 1,
-  "evidenceHeaderSchemaVersion": 1,
-  "approvalEnvelopeSchemaVersion": 1,
+  "phaseGraphHash": "ac160e3fc86f3e438141d985658e09f419508b3adbe176ddd13100d5dfdee47c",
+  "activationStateSchemaVersion": 2,
+  "evidenceHeaderSchemaVersion": 2,
+  "approvalEnvelopeSchemaVersion": 2,
   "supersessionSchemaVersion": 1,
   "credentialPolicySchemaVersion": 1
 }
@@ -29,7 +75,15 @@ 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.
+7 plus the activation identity fields shown above. Compatibility metadata uses
+schema version 2 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.
+
+`src/domain/governance/policy/identity.ts` is the version authority;
+`src/domain/governance/activation/graph.ts` computes the canonical graph hash and
+phase digests. Documentation tests compare this example with the source identity,
+rather than blessing an obsolete hardcoded tuple.
 
 | Axis | Tracks |
 | --- | --- |
@@ -69,9 +123,20 @@ changes in another.
 - Future manifest, policy, contract, schema, or graph identities must block
   without rewriting state and must report the exact field, found value, supported
   identity, and minimum Liftoff remedy.
-- Historical state migration requires schema-valid input, an explicit old-to-new
-  mapping, transactional writes, immutable evidence preservation, and rollback
-  on any failed preflight.
+- Manifest composition injects `validateReadableActivationIdentity` only at the
+  manifest boundary. Exact known v1 identities remain readable without retagging;
+  state, evidence, approval, readiness, and scope use strict current validation.
+- Known v1 activation is diagnostic-only. `diagnosticOnly` maintenance may update
+  safe managed core while retaining historical identity/state/evidence. No public
+  history reconciliation or automatic old-to-new state migration is implemented.
+- The eight flat-root OpenTofu identities are an explicit new-output-only
+  exception to append-only naming in 0.11.0. Preserve historical records and
+  files; use the exact [retirement inventory](docs/azure-deployment.md#explicit-flat-root-identity-retirement),
+  never aliases, prefix ownership, or force conversion.
+- A CLI-only patch does not retag activation history. When unchanged renderer
+  semantics support a new CLI generation, add that exact version to the
+  infrastructure generation compatibility inventory and cover mixed old/new
+  component provenance; do not infer compatibility from a SemVer range.
 - Never fabricate history: prose, filenames, timestamps, or checked tasks are
   not evidence.
 
@@ -92,6 +157,13 @@ and referenced, validated saved-plan/evidence receipts. Reject placeholder
 digests, future-dated approvals, and inferred bindings. Missing bindings remain
 `not-observed`; remediation must never suggest manually fabricating activation
 state, baselines, receipts, or evidence.
+Use `inspectCurrentActivationEvidence` from
+`src/governance-activation/read-only.ts`: its contexts include actual input
+snapshots, reviewed immutable plans, and state evidence references. Consume
+validated selected payloads, never reselect an unvalidated raw duplicate.
+`bodyDigest` commits payload and normalized readbacks; `planDigest` binds semantic
+inputs and `savedPlanDigest` binds the complete saved plan, including clocks.
+Writing receipts does not invalidate their own source-input snapshot.
 
 Reports distinguish target, recorded baseline, declared configuration, and
 observed enforcement with expected/observed values, provenance, impact, and
@@ -179,7 +251,7 @@ npx vitest run tests/seed-lifecycle.test.ts
 npx vitest run tests/governance-assessment.test.ts tests/governance-assessment-engine.test.ts
 npx vitest run tests/commands.test.ts tests/file-system.test.ts tests/contract.test.ts tests/update.test.ts
 npm run build
-openspec validate add-deterministic-liftoff-setup --strict
+openspec validate stabilize-and-modularize-liftoff --strict
 ```
 
 Before release, run:
@@ -189,22 +261,27 @@ npm run check
 npm run smoke:package
 npm run verify:standard-node-templates
 npm run verify:generated-containers
-npm run verify:power-apps-starter
 npm run verify:release-identity
 ```
 
-## 0.10.0 release checklist
+## 0.11.1 release checklist
 
 - Package metadata, lockfile metadata, `liftoff --version`, and tag agree on
-  `0.10.0`.
+  `0.11.1`. 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.
 - Manifest writes use artifactVersion 7; readers accept v2-v7.
-- Policy version is `"6"`; activation contract, graph/state/evidence/approval/
-  supersession/credential schemas are v1.
+- Policy version is `"6"`; activation contract/state/evidence-header/approval
+  and compatibility metadata are v2. Graph, supersession, credential-policy,
+  assessment report, and assessment catalog schemas remain v1.
 - The graph hash in code, docs, generated artifacts, compatibility metadata, and
   release-integrity tests is
-  `b84bcde6cd614637f2486b0f3a202860e6e9a6142ac60c773daa11786dbeb7f7`.
-- `/liftoff-setup` is the primary post-init path and archives the bootstrap seed
-  before any commit/push or Phase 0 authority.
+  `ac160e3fc86f3e438141d985658e09f419508b3adbe176ddd13100d5dfdee47c`.
+- `/liftoff-setup` archives the OpenSpec bootstrap or finalizes the real Spec Kit
+  B001–B006 bundle locally before separate publication and Phase 0 gates.
+- Power Apps and the eight explicitly retired flat-root infrastructure IDs have
+  no positive new-generation lane. Old API/GenAI project provenance and v1
+  activation history remain preserved, not converted by update or force.
 - No setup-skill version exists in manifests, JSON status, docs, or generated
   integrations.
 - Doctor states and remedies cover seed-incomplete, phase-blocked,
@@ -223,51 +300,113 @@ evidence. Failed post-publish verification requires a dist-tag correction when
 the immutable package is correct, or a corrected patch release; do not unpublish
 as routine recovery.
 
-## Functional engines and recommended boundaries
+## Functional engines and implementation boundaries
 
-Grouped at the top-level command/workflow-domain boundary, Liftoff currently
-has eight functional engines. Each contains smaller services; these are
-responsibility groups, not eight classes named `Engine`:
+Liftoff remains one npm package and a modular monolith. It has eight functional
+responsibility groups, not eight separately deployed services or classes named
+`Engine`. Workloads, patterns, activation phases, and assessment controls are
+different dimensions; adding a template does not create another engine.
 
 | Subsystem | Current implementation |
 | --- | --- |
-| Project planning and generation | `planner.ts`, `templates.ts`, workload renderers and template assets |
-| Workstation/framework bootstrap | `workstation.ts`, `project-dependencies.ts`, framework adapters and initialization safety |
-| Source migration | `scan.ts`, `migrate-plan.ts`, migration orchestration |
-| Managed project maintenance | `reconcile.ts`, artifact lifecycle declarations and guarded filesystem transactions |
-| CLI self-upgrade | `self-upgrade.ts`, stable release lookup and installed-package verification |
-| Diagnostics | Manifest validation, doctor, runtime and framework checks |
-| Governance activation | `governance-activation/` state graph, approvals, evidence and transition dispatch |
-| Governance assessment | `governance-assessment/` control catalog, observations, comparison and reporting |
+| Project planning and generation | `domain/project/`, `application/project/`, `generators/`, resolved packaged template assets |
+| Workstation/framework bootstrap | `application/initialize/`, workstation registry, framework adapters, `init-filesystem.ts`, dependency setup |
+| Source migration | `domain/migration/`, `scan.ts`, `migrate-plan.ts`, `application/migrate/` |
+| Managed project maintenance | `application/update/{planning,reporting,use-case}.ts`, `reconcile.ts`, filesystem transactions |
+| CLI self-upgrade | `application/upgrade/use-case.ts`, `self-upgrade.ts`, stable release lookup and installed-package verification |
+| Diagnostics | `application/diagnose/`, pure manifest contracts, shared runtime/framework/governance checks |
+| Governance activation | `domain/governance/{policy,activation}/` rules and `governance-activation/` execution composition |
+| Governance assessment | `domain/governance/assessment/` comparison/report contracts and `governance-assessment/` read-only collection |
 
 Telemetry, terminal presentation, process execution, catalogs, and filesystem
 access support those subsystems rather than constituting additional business
 engines.
 
-The next structural change should be incremental. First extract the command
-handlers from the large `commands.ts` orchestrator. Then separate pure domain
-rules from filesystem/process/GitHub/Azure adapters, and group workload
-generators separately from governance policy definitions:
+### Canonical entry points and ports
+
+| Responsibility | Entry point or data contract |
+| --- | --- |
+| CLI parsing/dispatch | `src/cli/args/parser.ts`, `src/cli/commands/dispatch.ts` |
+| Typed use-case requests | `src/application/context.ts`, `src/application/initialize/use-case.ts`, `src/application/update/use-case.ts`, `src/application/migrate/use-case.ts`, `src/application/upgrade/use-case.ts` |
+| Pure plans/catalog/manifest rules | `src/domain/project/contracts.ts`, `src/domain/project/catalog.ts`, `src/domain/project/planning.ts`, `src/domain/project/manifest/reader.ts` |
+| Release composition | `src/application/project/catalog.ts`, `src/application/project/manifest.ts` |
+| Generator assembly and resolved subsets | `src/templates.ts`, `src/generators/context.ts` and its renderer families |
+| Installed-package assets | `src/adapters/packaged-assets/package-root.ts`, `src/adapters/packaged-assets/template-assets.ts` |
+| Guarded mutations | `src/adapters/filesystem/project-lock.ts`, `src/adapters/filesystem/atomic-write.ts`, `src/adapters/filesystem/project-transaction.ts` |
+| Exact infrastructure inventory/layout | `src/domain/project/infrastructure-layout.ts` |
+| Current activation observations | `src/governance-activation/inputs.ts`, `src/governance-activation/read-only.ts` |
+| Activation planning/execution ports | `src/governance-activation/transition-planning.ts`, `src/governance-activation/transition-ports.ts`, locked coordinator `src/governance-activation/transitions.ts` |
+| Concrete phase handlers and persistence | `src/governance-activation/seed-lifecycle.ts`, `src/governance-activation/phase-publication.ts`, `src/governance-activation/phase-discovery.ts`, `src/governance-activation/phase-governance.ts`, `src/governance-activation/phase-bootstrap-state.ts`, `src/governance-activation/transition-records.ts` |
+| Pure evidence/availability contracts | `src/domain/governance/activation/evidence.ts`, `src/domain/governance/activation/capabilities.ts` |
+| Read-only assessment | `src/governance-assessment/project.ts`, `src/domain/governance/assessment/`, `src/adapters/git/governance-assessment.ts`, `src/adapters/github/governance-assessment.ts`, `src/adapters/azure/governance-assessment.ts` |
+
+The source boundaries are:
 
 ```text
 src/
-  cli/                 # arguments, per-command handlers, presentation
-  application/         # bootstrap, migration, update and upgrade use cases
+  cli/                 # parsing/help and per-command transport
+  application/         # typed requests, execution ports and workflow orchestration
   domain/
-    project/           # manifests, ownership and compatibility
-    governance/        # versioned policy and common control definitions
-    activation/        # phases, approval envelopes and evidence
-    assessment/        # pure comparison and coverage rules
-  infrastructure/      # filesystem, process, Git, GitHub, Azure and npm ports
-  generators/          # common, standard, GenAI and Power Apps renderers
+    project/           # injected catalogs/planning, manifest contracts and ownership
+    migration/         # declaration parsing, inventory and placement decisions
+    governance/
+      policy/          # shared version identities
+      activation/      # graph, approval, applicability, evidence and readiness rules
+      assessment/      # observations, comparison, coverage and report rules
+  generators/
+    common/            # shared files, frontend, configuration and workflow seeds
+    standard/          # Python, Node.js and Go implementations
+    genai/             # configuration, backend, patterns, database and functions
+    containers/        # Compose, images and build-context exclusions
+    infrastructure/    # independent Azure roots and resource naming
+  adapters/
+    filesystem/        # guarded discovery/read/write, transactions and locks
+    packaged-assets/   # one installed-package root and resolved release assets
+    process/           # shell-specific literal command formatting
 assets/governance/     # immutable policy bundles, catalogs and compatibility data
 ```
 
-Keep one source of truth for policy and version identities, retain content
-digest checks between policy/catalog/graph artifacts, and make read-only and
-mutating adapter capabilities distinct. Preserve current import/CLI contracts
-through small extraction changes rather than mixing a broad refactor into a
-feature release.
+Activation planning, process transport, outcome persistence, and phase handlers
+are real modules, not callbacks into a monolithic dispatcher.
+`phase-bootstrap-state.ts` handles retention/disposal boundaries, not the missing
+`bootstrap-local` cloud-provisioning executor. `transition-process.ts` centralizes
+command outcomes; `transition-records.ts` commits the reviewed plan/evidence/state
+contracts through guarded filesystem operations.
+
+`commands.ts`, `args.ts`, `file-system.ts`, and the project/catalog entry modules
+are compatibility facades. `templates.ts` assembles actual renderer modules;
+it must not regain backend, container, infrastructure, or workflow implementation.
+Internal callers use canonical modules rather than routing back through facades.
+
+CLI handlers parse syntax and pass typed `ProjectOptions`, `MigrationRequest`,
+`UpdateRequest`, and `UpgradeRequest` to application use cases with
+`ExecutionContext` ports from `application/context.ts`.
+Application code does not call back into CLI parsing. Pure rules receive data or
+narrow context explicitly: `createProjectCatalog`, `buildProjectPlanWithCatalog`,
+and `createManifestReader` do not discover files, run processes, or contact
+providers. `application/project/catalog.ts` composes the release catalog;
+`domain/project/catalog.ts` remains the pure factory.
+Root generator composition accepts `PackagedTemplateAssetContext` and calls
+`createGeneratorContext` in `generators/context.ts`. Pure renderers receive narrow
+resolved subsets and do not import adapters. Only composition loads
+`packagedTemplateAssets` through the canonical `resolvePackageFile` /
+`resolvePackageFileUrl` resolver.
+
+Manifest grammar, workload normalization, artifact authority, and governance
+compatibility have separate project-domain modules. Filesystem discovery,
+path safety, file access, and transactions live in distinct adapters.
+`withProjectMutationLock` coordinates writers, while snapshots and path/content
+preconditions still protect reviewed mutations and conflict-preserving rollback.
+Its operation receives a lease with `assertHeld()`; nested same-root mutations
+reuse it, while read-only paths do not acquire a lock.
+Read-only assessment receives read capabilities, never activation executors or
+mutation adapters.
+
+When changing a feature, update its narrow rule/renderer first, wire the
+application and CLI boundary, then extend the existing focused cases. Add exact
+artifact lifecycle/provenance identities; do not infer ownership from folders.
+The import-boundary suite checks cycles, domain I/O, application-to-CLI coupling,
+and facade use. Packed smoke covers runtime asset lookup outside this checkout.
 
 ## Activation completeness and separate follow-up plan
 
@@ -287,62 +426,66 @@ 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
 command is exposed; secure credential enrollment helpers are not wired into
-the command-only setup flow; and existing activation inspection still uses
-placeholder baseline/input digests. Assessment does not accept those
-placeholders as current proof. Do not fabricate state, approvals, or evidence
-to get past these gaps.
+the command-only setup flow. Current activation inspection now binds real
+baseline/input snapshots, reviewed plans, state references, and evidence bodies.
+Historical placeholder-bound records remain diagnostic-only, never current
+proof. Do not fabricate state, approvals, or evidence to get past capability gaps.
 
 Complete this work separately from the read-only assessment feature:
 
 1. Add explicit approval-persistence and secure credential-enrollment entry
    points with narrow consent and selected-agent command contracts.
-2. Bind activation contexts to actual baseline, phase inputs, and transitions;
-   define reviewed reconciliation for existing placeholder-bound history
+2. Define a separately reviewed reconciliation workflow for historical activation
+   identities and placeholder-bound history
    without rewriting immutable evidence or inventing completion.
 3. Supply production implementations for the missing phase adapters and the
    GitHub ruleset adapter, enforcing resource, permission, cost, and destructive
    bounds at execution.
-4. Complete retry and rollback behavior, including recovery from active local
-   baseline failures, without blanket retries of remote or destructive phases.
+4. Design phase-specific production retry/rollback behavior without blanket
+   remote or destructive retries. Explicit local seed/baseline/finalization
+   recovery and cooperating-writer locking are already implemented.
 5. Prove the entire activation and upgrade/reconciliation path with
    end-to-end positive and negative cases, then gated live readback where
    explicitly authorized.
 
-The assessment/bootstrap patch can ship independently while these fail-closed
+This stabilization can ship independently while these fail-closed
 limitations remain documented; it must not advertise them as completed
 production capabilities.
 
 ## Broader audit follow-ups
 
-The whole-CLI review also identified work outside the bounded assessment,
-bootstrap, release-safety, and guidance patch. These are not repaired by
-successful rendering, unit tests, package smoke, or OpenTofu syntax validation:
-
-- **GenAI capability completeness:** review catalog scaffold labels against an
-  executable behavior matrix. Current RAG retrieval/citation code, conversation
-  and tool orchestration, prompt-file loading, worker handlers, and streaming
-  behavior still require project-level implementation work in several patterns.
-- **Azure deployment completeness:** finish RAG publisher configuration and
-  sender permissions, Function code packaging/deployment, dependency readiness,
+The following work remains outside this stabilization, despite the repaired
+runtime configuration, infrastructure generation, and local safety boundaries.
+Rendering, unit tests, package smoke, and OpenTofu syntax validation alone do not
+establish these production capabilities:
+
+- **GenAI capability completeness:** all nine catalog entries now say
+  `foundation` and describe actual behavior. Retrieval/citations, conversation
+  history, tools, prompt-file loading, worker processing, coordination,
+  fine-tuning, workflow stages, and incremental streaming remain project work.
+  Generic has no pgvector package/extension or application-worker requirement.
+- **Azure deployment completeness:** RAG publisher configuration and queue-scoped
+  sender/receiver separation are implemented. Function code packaging/deployment,
+  dependency readiness,
   authenticated ingress, private connectivity, environment-specific safeguards,
-  and regional service settings before treating generated applications as
-  production-ready.
+  and regional service settings still need reviewed implementation and verification
+  before treating generated applications as production-ready.
 - **Baseline prerequisites:** keep dependency installation separately
   consented. Python test settings and npm dependency preparation need explicit
   validated recipes; an unprepared baseline must block with a remedy, not pass
   vacuously.
-- **Persistent validation coverage:** expand framework delivery validation and
-  Power Apps lock compatibility checks, validate exact plugin
-  identity/version/enabled state, and strengthen deep readiness rather than
-  equating liveness with dependency health.
+- **Persistent validation coverage:** preserve framework delivery validation,
+  retired-workload rejection, and shared safety coverage, and strengthen deep
+  readiness rather than equating liveness with dependency health.
 - **Supply-chain delivery:** configured-registry version parity is not proof
   that its bytes equal the canonical release. Plan canonical artifact integrity
   verification before self-upgrade installation, with an explicit trust model
   for dependencies and approved mirrors. Pin or package mutable runtime/CDN
   assets as part of that work.
-- **Filesystem concurrency:** strengthen shared mutation locking and
-  no-follow/fd-relative writes against noncooperating processes replacing
-  ancestors between validation and mutation. Existing preflight/rollback
+- **Filesystem concurrency:** cooperating-writer locks, guarded transactions,
+  mode preservation, and conflict-preserving recovery are implemented. Stronger
+  no-follow/fd-relative isolation against noncooperating processes replacing
+  ancestors between validation and mutation remains future hardening. Existing preflight/rollback
   safeguards are not a complete adversarial-filesystem isolation mechanism.
 
 Treat these as separate reviewed changes with workload/runtime acceptance

package/README.md

@@ -1,7 +1,7 @@
 # Liftoff
 
-**Initialize governed GenAI applications, APIs, and Power Apps code apps from one
-interactive CLI.** Liftoff combines production-oriented scaffolds with OpenSpec or
+**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.
 
 [![npm version](https://img.shields.io/npm/v/%40msn-control%2Fliftoff?logo=npm)](https://www.npmjs.com/package/@msn-control/liftoff)
@@ -27,12 +27,13 @@ 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. `/liftoff-setup` then completes,
-syncs, and archives the generated bootstrap seed through local baseline checks,
-then stops at explicit authority gates for repository publication, credentials,
-billed infrastructure or exceptions, final enforcement, destructive cleanup, and
-external blockers. No model selection is required for setup; the CLI phase graph,
-evidence, and approvals are authoritative.
+default as a local deterministic 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.
 
 After the first self-upgrade-capable release is installed globally through npm,
 later CLI releases use `liftoff upgrade --check` followed by `liftoff upgrade`.
@@ -52,35 +53,30 @@ environments, documentation, and infrastructure are project-owned after
 generation and remain outside every update mode, including `--force`. Use
 `liftoff update --check --json` for a read-only core-maintenance gate.
 
-Projects generated before `0.10.2` may still display the retired
-`/liftoff-repository-governance` command. Review `liftoff update --check`, then
-remove that generated alias with:
-
-```bash
-liftoff upgrade
-liftoff update --force
-```
-
-Reload the coding-agent session afterward so its command index refreshes.
+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.
 
 ![Liftoff terminal showing interactive workload, workflow, multi-agent, readiness, and safe completion steps](docs/assets/liftoff-terminal.svg)
 
-## One flow, three workloads
+## One flow, two workloads
 
 | Workload | Generated foundation | Deferred until you choose |
 | --- | --- | --- |
-| **GenAI application** | Python, FastAPI, PydanticAI, data and messaging boundaries, optional frontend, Docker, and Azure OpenTofu | Model credentials, cloud sign-in, deployment |
+| **GenAI application** | Python, FastAPI, PydanticAI, data and messaging boundaries, optional frontend, Docker, and Azure OpenTofu | Model credentials, specialized behavior, cloud sign-in, deployment |
 | **API application** | Python/FastAPI, Node.js/Fastify, or Go/Huma API, database assets, optional frontend, Docker, and Azure OpenTofu | Service configuration, cloud sign-in, deployment |
-| **Power Apps code app** | Microsoft's pinned React, Vite, TypeScript, Power Apps SDK starter and project-local CLI | Environment binding, connectors, `power-apps push` |
 
 If the GenAI specialization is not yet known, choose **I'm not sure yet -
 Generic GenAI starter** or use `--pattern generic`. It creates a neutral
 PydanticAI invocation foundation without assuming RAG, chat, agents, streaming,
 fine-tuning, or workflows.
 
-Every workload can use **OpenSpec** or **Spec Kit** with **GitHub Copilot**,
-**Claude Code**, or both. The optional Microsoft Code Apps agent plugin remains an
-explicit, Preview-only choice.
+Both workloads can use **OpenSpec** or **Spec Kit** with **GitHub Copilot**,
+**Claude Code**, or both.
+
+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.
 
 [Compare workload questions and outputs](docs/workloads.md) |
 [Choose a spec workflow and agents](docs/spec-workflows-and-agents.md)
@@ -96,6 +92,10 @@ regular-file replacements, asks before overwrite, rejects structural and symlink
 conflicts, keeps tool/dependency permissions independent, and rolls back handled
 write failures.
 
+To assess any Git repository without initializing it, run
+`liftoff governance assess --json`. The default is local-only and read-only.
+Missing or unsupported proof is reported as partial coverage, not success.
+
 [Initialize an existing repository](docs/existing-repositories.md) |
 [Understand target and consent safety](docs/safety-and-consent.md)
 
@@ -104,8 +104,8 @@ write failures.
 | Guide | Use it to |
 | --- | --- |
 | [Getting started](docs/getting-started.md) | Install safely and complete the first interactive project |
-| [Workloads](docs/workloads.md) | Compare GenAI, API, and Power Apps choices and outputs |
-| [Spec workflows and agents](docs/spec-workflows-and-agents.md) | Configure OpenSpec, Spec Kit, Copilot, Claude, and the optional Code Apps plugin |
+| [Workloads](docs/workloads.md) | Compare GenAI/API choices and understand retired-workload handling |
+| [Spec workflows and agents](docs/spec-workflows-and-agents.md) | Configure OpenSpec, Spec Kit, Copilot, and Claude |
 | [Repository governance](docs/repository-governance.md) | Review `/liftoff-setup`, read-only `/liftoff-governance-assess`, authority gates, evidence, and compatibility |
 | [Existing repositories](docs/existing-repositories.md) | Understand in-place, child-directory, and migration behavior |
 | [Prerequisites](docs/prerequisites.md) | Review plan-derived runtimes, tools, authentication, and dependency setup |
@@ -116,13 +116,13 @@ write failures.
 | [Generated project structure](docs/project-structure.md) | Locate workload-specific and conditional generated areas |
 | [Configuration and manifests](docs/configuration-and-manifests.md) | Edit desired state, manifest v7, activation identity, and managed artifacts |
 | [Azure deployment](docs/azure-deployment.md) | Review generated Azure and OpenTofu contracts for API workloads |
-| [Troubleshooting](docs/troubleshooting.md) | Recover from registry, readiness, validation, update, and plugin issues |
+| [Troubleshooting](docs/troubleshooting.md) | Recover from registry, readiness, validation, update, and retired-workload issues |
 | [Developer guide](DEVELOPER.md) | Maintain version vectors, compatibility maps, release checks, and publishing |
 
 ## Contributing and security
 
 See [CONTRIBUTING.md](CONTRIBUTING.md) and [DEVELOPER.md](DEVELOPER.md) for build,
-test, packaging, starter-refresh, compatibility, and release procedures. Report
+test, packaging, baseline-refresh, compatibility, and release procedures. Report
 vulnerabilities through the private process in [SECURITY.md](SECURITY.md).
 
 Liftoff is licensed under [GPL-3.0-only](LICENSE).