@msn-control/liftoff 0.10.3 → 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 |
 | --- | --- |
@@ -43,6 +97,10 @@ There is no separate `/liftoff-setup` skill version. The setup integration is a
 thin managed artifact; its managed content hash plus the activation contract and
 graph hash are sufficient identity.
 
+The same rule applies to `/liftoff-governance-assess`: it has no independent
+assessment-skill version. Report schema v1 and the packaged assessment catalog
+schema identify read-only data contracts, not a new policy or activation identity.
+
 ## Bump rules
 
 | Change | Required bump |
@@ -65,12 +123,91 @@ 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.
 
+## Read-only assessment maintenance
+
+The pinned target is the installed CLI's packaged policy, activation identity,
+phase graph, and control catalog, never registry latest. The local-only
+`liftoff governance assess --json` path must make no network requests or require
+cloud credentials. Only an explicit `--live` request authorizes bounded
+read-only GitHub/Azure metadata using existing permissions and validated scope.
+No mode may enroll credentials, run project scripts, mutate configuration,
+update or upgrade anything, or write state, approvals, or evidence.
+Every assessment invocation, including `--live` and `--help`, must skip telemetry
+and disclosure entirely. Local Git reads use only repository root, HEAD, and
+origin metadata; never call `git status`, whose clean filters can execute code.
+Azure scope and evidence-backed applicability require a current active-baseline
+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
+ownership-aware advisory remediation. Preserve all seven classifications:
+`aligned`, `outdated`, `missing`, `conflicting`, `approved-exception`,
+`inapplicable`, and `not-observed`. Coverage must expose unknown applicability,
+unobserved live proof, stale evidence, and unsupported evaluators.
+Exit 0 means fully observed aligned or explicitly disabled not-applicable
+governance, not interchangeable claims; exit 2 means partial coverage or
+differences including approved exceptions; exit 1 means error. An assessment
+cannot advance a phase or supply approval for a future governance upgrade.
+Show the project policy version when available and expected/observed values.
+Optional normalized observation `facts` retain sanitized details alongside
+evaluator predicate values without retaining raw provider payloads.
+
+When adding a control or evaluator:
+
+- Use unique stable control IDs, normative policy references, explicit expected
+  values, applicability/proof layers, valid phase IDs, and narrow exception scope.
+- Bind the catalog digest to the canonical policy digest; test policy/catalog
+  coherence and non-empty enabled coverage. Keep every normative policy family
+  in the reviewed inventory, including explicit unsupported coverage.
+- Add deterministic fixtures for equivalent reordered facts, known differences,
+  stale/denied/unknown/incomplete observations, and scope-bound exceptions.
+  Unknown proof must not become missing, inapplicable, or aligned.
+- Prove read-only behavior with filesystem fingerprints and injected operation
+  logs, including failure paths and unsupported identities. Test redaction
+  before retention/truncation and fixed live read allowlists and limits.
+- Cover Windows/macOS/Linux paths, CRLF, spaces, case handling, and
+  symlink/junction rejection; never execute project YAML, hooks, or scripts.
+- Keep both agent wrappers equivalent and limited to
+  `liftoff governance assess --json` or, after explicit live consent,
+  `liftoff governance assess --live --json`. Keep `/liftoff-setup` primary.
+- Append exact `liftoff-governance-assess-copilot` and
+  `liftoff-governance-assess-claude` ownership identities and portable paths.
+  Older supported inventories must load and expose safe new drift. Test
+  unowned collision protection under force, managed conflict handling,
+  transactional rollback, and unchanged state/evidence bytes.
+
+Assessment diagnoses unsupported activation mappings without weakening mutation
+loaders or claiming a migration exists. A future governance upgrade must collect
+fresh observations, produce its own authoritative plan, and obtain approvals.
+See [assessment guidance](docs/repository-governance.md#read-only-governance-assessment).
+
 ## Release integrity requirements
 
 - Validate the canonical graph, graph hash, per-phase contract digests, and
@@ -80,17 +217,25 @@ changes in another.
   bump and affected descendant invalidation.
 - Generated OpenSpec seeds must include metadata, proposal, design, tasks, and
   declared capability specs, and must pass strict validation immediately.
+  Test external archival before activation as well: the baseline must retain
+  every applicable local check and validate synchronized specs rather than an
+  inactive change name. A persisted archived-baseline blocker is retryable only
+  through a new explicit execution, never by fabricating evidence on resume.
 - Copilot and Claude `/liftoff-setup` integrations must be behaviorally
   equivalent, command-only, model-agnostic, and free of skill-version fields.
   They must distinguish the read-only `apply-next --json` preview from
   `apply-next --json --execute`, and execute only when approval status is
   `not-required` or `reused`.
+  Use `selectedPhase` and `executedPhase` for the apply-next attempt; read the
+  subsequent status or verify result for post-transition `nextReadyPhase`.
 - Governance verification must report state consistency separately from setup
   progress. A consistent `not-started` or `in-progress` result is not complete;
   completion requires every phase to have a successful terminal state.
 - Credential tests must prove PAT/App policy equivalence, exact workflow/job
   allowlists, masked input, no command-argument/file/log/evidence leaks, and
   compromised revoke/rotate guidance.
+  OpenSpec failure diagnostics must be bounded, stripped of terminal controls,
+  and screened for credential-shaped content before truncation or persistence.
 - Path tests must cover Windows, macOS, and Linux path-part arrays, symlink
   rejection, atomic state writes, and rollback.
 
@@ -103,8 +248,10 @@ npx vitest run tests/documentation.test.ts
 npx vitest run tests/templates.test.ts tests/repository-governance.test.ts
 npx vitest run tests/governance-activation.test.ts tests/governance-commands.test.ts tests/governance-credentials.test.ts
 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:
@@ -114,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,
@@ -147,3 +299,195 @@ signing material in repository files, workflow logs, chat, screenshots, or
 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 implementation boundaries
+
+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 | `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.
+
+### 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/                 # parsing/help and per-command transport
+  application/         # typed requests, execution ports and workflow orchestration
+  domain/
+    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
+```
+
+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
+
+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
+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`,
+`runner-ready`, `private-backend-proof`, `remote-import-verified`,
+`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.
+
+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. 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. 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. 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.
+
+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 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 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:** 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:** 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
+criteria. Do not enlarge a patch into a production platform rewrite or claim
+that unavailable behavior has been implemented.

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,9 +104,9 @@ 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 |
-| [Repository governance](docs/repository-governance.md) | Review `/liftoff-setup`, phase order, authority gates, evidence, credentials, and compatibility |
+| [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 |
 | [Supported stack baseline](docs/supported-stack.md) | Review pinned runtimes, frameworks, dependency locks, images, and refresh policy |
@@ -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).