@msn-control/liftoff 0.10.4 → 0.11.2

package/docs/safety-and-consent.md

@@ -22,9 +22,13 @@ Selecting repository governance or passing `--yes` authorizes only deterministic
 local handoff files. It never authorizes agent execution, Git mutation, GitHub
 APIs, Azure or other cloud resources, rulesets, security configuration,
 deployment, monitoring, file replacement, machine tools, or project
-dependencies. `/liftoff-setup` first completes and archives the local bootstrap
-seed, then stops at authority gates. Live activation begins only after explicit
+dependencies. `/liftoff-setup` first verifies and archives the OpenSpec bootstrap
+or finalizes the real Spec Kit bundle locally, then stops at authority gates.
+Live activation requires explicit
 commit/push approval, read-only Phase 0, and activation-plan approval.
+Missing public approval persistence, secure credential enrollment, or production
+executors remain blockers; this sequence does not promise a complete production
+activation workflow.
 
 An approved downstream local-state bootstrap remains encrypted, gitignored, and
 single-writer. It is never transferred through GitHub artifacts or secrets,
@@ -48,6 +52,9 @@ cannot redirect machine-level discovery. Canonical npm selects the target while
 the configured registry must provide that exact release. Liftoff does not expose
 registry credentials, rewrite npm configuration, bypass a stale mirror, invoke
 `sudo` or another elevation mechanism, or touch project files.
+Machine-level `@msn-control:registry` takes precedence over default `registry`;
+canonical verification isolates both settings, but installation still honors
+the effective delivery registry.
 
 npm replacement is not a Liftoff file transaction. If npm or post-install
 verification fails, Liftoff reports an exact-version repair command and does not
@@ -87,16 +94,40 @@ Structural collisions are not overridable:
 
 ## Atomic writes and rollback
 
+Project mutations share an exclusive cooperating-writer lock across initialization,
+migration, dependency setup, managed update, and setup execution. The lock is a
+sibling file named `.liftoff-mutation-<project-path-digest>.lock`, created with
+0600 mode where POSIX permissions apply; the target's
+parent directory must be writable. Reserving a new target does not create that
+target or project state. Nested steps in one operation retain the same lock.
+Reservation identities are NFC-normalized and lowercased on every platform; this
+may serialize case-distinct sibling projects on case-sensitive volumes, but never
+merges their ownership.
+Read-only commands, including assessment and `update --check`, never acquire it.
+An existing or changed lock blocks mutation and is never automatically stolen or
+removed. After an interrupted process, verify its owner has stopped before
+reviewing the exact reported lock. This coordinates Liftoff writers; it does not
+replace path/content preconditions or isolate the project from other programs.
+
 Individual project files use temporary-file replacement. Initialization keeps
 backups for replaced files and records created files and directories. A handled
-merge failure restores or removes those entries in reverse order.
-
-Plain `liftoff update` preflights every eligible managed-core or authorized
-create-only provisioning path and applies those writes, managed-core moves or
-deletes, and the manifest as one rollback-capable transaction. Schema upgrades
-are committed only after the other mutations succeed.
-
-Managed update may install manifest v7, policy v6, activation-contract v1,
+merge failure restores or removes attributable unchanged entries in reverse
+order; concurrent or uncertain edits are preserved and reported.
+Existing destination modes are preserved where supported, including POSIX 0600
+files. Windows does not provide equivalent POSIX mode-bit guarantees; this is
+not a promise to preserve all Windows ACLs or filesystem metadata.
+
+`liftoff update --check` presents compatibility and the exact proposed changes,
+then discloses its external preview receipt without changing project bytes.
+Apply requires that matching preview and explicit exact-plan approval. It
+rechecks protected inputs under the project lock before writing. Noninteractive
+approval uses `--approve-plan <fingerprint>`, not a generic yes.
+
+The approved transaction preflights exact managed-core and create-only
+provisioning paths separately from any explicitly authorized activation migration.
+Schema/successor changes commit consistently with their manifest and history link.
+
+Managed update may install manifest v7, policy v6, activation-contract v2,
 phase graph, compatibility metadata, credential-policy schema, setup
 integrations, and forced removal of exact retired generated setup-alias entries
 from older manifests. It preserves user-owned activation state, approvals,
@@ -104,25 +135,40 @@ 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.
+Exact known historical v1 can use the reviewed successor lane, not in-place
+retagging. Original records are copied byte-for-byte into immutable in-project
+history before their exact active paths are retired or replaced. A linked v2
+activation obtains fresh evidence; historical approvals never become current
+permission. Unavailable revalidation remains an explicit blocker.
 
 If automatic rollback itself cannot safely restore a path because another
 process changed it, Liftoff reports the incomplete rollback rather than
 overwriting unknown bytes.
 
-Update snapshots exist only for rollback after a failed transaction. Liftoff
-does not retain them as backups after success.
+Ordinary transaction backups are for failed-write recovery. Activation history
+is different: it remains after success and is never removed with disposable
+preview receipts. A durable recovery journal must match a separately persisted
+external transaction approval; a project-local claim alone cannot authorize
+recovery. Post-commit revalidation failure preserves v2 and its historical link.
+
+Dependency execution has a different recovery boundary: installer scripts can
+write arbitrary project files, and a concurrent developer edit cannot be
+attributed safely from a content difference alone. Changed or deleted protected
+metadata is therefore preserved and reported, not automatically restored.
+Liftoff stops further dependency commands and identifies the recovery shell and
+literal-path recipe. This does not claim the entire scaffold was unchanged.
 
 ## Update ownership
 
 Update mode is selected explicitly rather than from terminal interactivity:
 
 - Existing project artifacts are never compared with current template bytes.
-- Plain `liftoff update` immediately applies safe new, missing,
-  untouched-upgrade, clean-move, and recorded-state changes only for exact
-  managed-core artifacts.
-- `liftoff update --check` is read-only and performs no preflight or mutation.
-- `liftoff update --json` applies safe changes and returns an apply result;
-  `liftoff update --check --json` is the read-only machine drift gate.
+- Plain `liftoff update` applies the matching explicitly approved plan, retaining
+  safe managed-core classification and the separate migration/provisioning lanes.
+- `liftoff update --check` changes no project bytes but saves and discloses a
+  preview receipt outside the repository.
+- `--json` changes output formatting only; machine apply still requires the
+  matching preview and exact plan-fingerprint approval.
 - Managed-core developer edits are conflicts. Project edits are outside update.
 - Default update skips core conflicts and lists them by portable relative path.
   `liftoff update --force` extends authority only to those guarded core
@@ -133,18 +179,27 @@ Update mode is selected explicitly rather than from terminal interactivity:
 - A newly selected frontend or environment is provisioned once only at absent
   or byte-identical destinations. A collision blocks the complete group and
   cannot be forced.
+- A new environment additionally requires recorded independent-root provenance
+  and safe existing shared-module files. Legacy or unknown layouts are blocked
+  without moving state or rewriting project-owned infrastructure.
 - Unrecorded governance conflicts remain outside manifest ownership and produce
   `handoff-partial` until a later update safely writes or adopts every artifact.
 - Orphans are reported and left on disk for manual review.
 - Dependency definitions and locks are project-owned; update neither changes
   nor installs them.
 
-`--force` cannot be combined with `--check` and cannot weaken project-boundary,
-symlink, collision, manifest, or transaction guards.
+`--force` cannot be combined with `--check` and cannot weaken preview, approval,
+compatibility, project-boundary, symlink, collision, manifest, or transaction guards.
+
+Power Apps support is retired. Its manifests are rejected without fetching
+starter source, changing application files, or treating force as conversion
+authority.
 
-Power Apps starter source and metadata are project-owned after generation.
-Update does not fetch upstream source or transition an existing project to a
-newer packaged starter.
+The eight flat-root OpenTofu identities are retired from new 0.11.0 output only.
+Their historical records, paths, generation hashes, files, and state remain
+unchanged by update, force, helpers, or assessment. They are not aliases to new
+roots or managed-core deletion targets; see the
+[explicit inventory](azure-deployment.md#explicit-flat-root-identity-retirement).
 
 ## Framework and seed ownership
 
@@ -153,7 +208,11 @@ initializers. Liftoff validates the selected contract and agent markers but
 does not claim framework-owned files in durable artifact hashes.
 
 One-time seed content is also omitted from durable hashes so it can follow its
-own lifecycle after generation.
+own lifecycle after generation. Spec Kit's `000-liftoff-bootstrap` bundle is
+project-owned, separate from official markers, and not an active governance
+change. Missing older seeds require reviewed adoption. Failed local checks leave
+B001–B006 unchecked; explicit successful execution commits the projection with
+body/full-plan-bound evidence. Read-only verify, status, and resume never mark it.
 
 OpenSpec workflow profile and delivery are global machine preferences. Liftoff
 changes them only after dedicated consent and verifies the result before
@@ -188,19 +247,22 @@ Liftoff does not:
 - Store cloud or agent credentials.
 - Perform cloud sign-in.
 - Apply OpenTofu.
-- Bind or push a Power Apps code app.
-- Run Microsoft's broad Code Apps marketplace installer.
+- Restore or manage the retired Power Apps workload or Code Apps integration.
 
 Those actions require their own review, authentication, and consent.
 
 Governance runner-preflight credentials have a stricter contract. Setup first
 uses an existing verified selected-repository GitHub App installation when it
-has the required read permissions. Otherwise it guides one fine-grained PAT:
+has the required read permissions. The normative fallback specifies one
+fine-grained PAT:
 display name `<repo>-runner-preflight-read`, repository secret
 `RUNNER_CONFIGURATION_READ_TOKEN`, 30-day lifetime, current repository only,
 repository metadata read, organization hosted-runner read and
 network-configuration read, no writes, and only the recorded workflow/job
-allowlist. The value must be entered through masked input only. Never paste or
+allowlist. The CLI currently lacks public secure enrollment, independent
+credential readback, and approval-persistence entry points; stop at the capability
+blocker instead of creating JSON or inventing an input channel. Any future
+supported enrollment must use masked input. Never paste or
 show it in chat, argv, command arguments, logs, evidence, generated files, or
 screenshots. If it appears there, treat it as compromised and manually revoke and
 rotate it before continuing.

package/docs/spec-workflows-and-agents.md

@@ -36,6 +36,29 @@ integration, and records the default separately from the full agent set.
 Generated projects contain `.specify/`, `specs/`, and the selected agent
 integration markers.
 
+New projects also receive `specs/000-liftoff-bootstrap/spec.md`, `plan.md`, and
+`tasks.md`. These are explicit one-time, project-owned `seed` artifacts, separate
+from official framework templates. Local setup validates the real bundle and
+official markers, performs the applicable baseline, and then finalizes its task
+projection and receipt. It creates neither a Git branch nor an OpenSpec archive.
+
+All three files identify `000-liftoff-bootstrap`. The tasks contain exactly one
+initial unchecked entry each for **B001–B006**: review the real bundle and markers;
+use already-installed locked dependencies or install with explicit consent;
+run Liftoff/backend/applicable-worker checks; build the frontend or record
+inapplicability; validate Compose and all infrastructure roots; then finalize.
+The non-checkbox command reference list is not execution evidence.
+Only after every applicable check passes does explicit setup execution commit
+the checked projection with body/full-plan-bound baseline evidence. Failed checks
+leave tasks untouched; status, verify, and resume do not edit checkboxes.
+`seed-archived` means a local handoff for Spec Kit, not an archive operation.
+This exact bootstrap is not an active governance change and has no
+`liftoff-governance.json`.
+
+An existing Spec Kit project without this bundle receives a seed-adoption
+blocker. Adopting it requires separate reviewed project work; ordinary update,
+force, and assessment do not create seeds or infer earlier completion.
+
 Liftoff does not hand-write framework-owned core or integration output. It
 executes the tested official initializer, confines its writes to allowed roots,
 and validates the declared markers before merging.
@@ -92,9 +115,9 @@ files.
 Repository-governance launchers are separate managed-core Liftoff files at the exact
 Copilot prompt and Claude command paths documented in
 [repository governance](repository-governance.md). They reference one canonical
-policy and context rather than duplicating framework-owned content. After
-read-only Phase 0 and explicit approval, the agent creates a new change using
-the selected framework; Liftoff never pre-creates or restores that change.
+policy and context rather than duplicating framework-owned content. Later
+governance changes are distinct from the exact bootstrap seed. The setup kernel
+does not invent an active change, approval, or missing production executor.
 
 Install the exact selected framework release with its supported package manager:
 
@@ -118,29 +141,9 @@ Use `--copilot-cloud` or `--no-copilot-cloud` in automation. The choice is
 recorded as `githubCopilot.cloudAgent` in `openspec/config.yaml`; it is not stored
 as Liftoff overwrite or machine-configuration consent.
 
-## Optional Code Apps plugin
-
-Power Apps projects can request Microsoft's
-`code-apps-preview@power-platform-skills` plugin. The integration is optional,
-Preview, and independent for each selected agent.
-
-Liftoff runs only allowlisted read-only plugin-list probes. A missing or
-unobservable plugin produces advisory guidance and never makes initialization
-or doctor fail by itself.
-
-Install the targeted plugin manually inside the selected agent:
-
-```text
-/plugin marketplace add microsoft/power-platform-skills
-/plugin install code-apps-preview@power-platform-skills
-```
-
-Liftoff does not run Microsoft's broad marketplace installer and does not
-invoke `/create-code-app`. The plugin's connector and deployment skills remain
-available for post-creation work.
+## Retired Code Apps integration
 
-Changing the valid plugin preference in `liftoff.config.json` is reconciled by
-plain `liftoff update`; it updates manifest intent and applicable managed-core
-governance context without rewriting the project-owned Power Apps README or
-starter. Use `liftoff update --check` to inspect that maintenance without
-writing.
+The Power Apps workload and Code Apps plugin options are retired. Liftoff no
+longer installs, probes, or manages that integration. This does not uninstall
+machine-wide tools or plugins; existing installations remain outside Liftoff's
+maintenance authority.

package/docs/supported-stack.md

@@ -17,17 +17,20 @@ file; they never resolve mutable `latest` versions.
 | OpenSpec | 1.11.0 |
 | Spec Kit | 1.0.1 |
 | AzureRM provider | 5.3.0 |
-| Power Apps SDK | 1.2.7 |
 
-Power Apps SDK 1.2.7 is an explicit compatibility selection. Versions 1.2.12
-and newer remove the project-local `power-apps` CLI required by Liftoff's
-current workload contract. Moving to Microsoft's global `pa` CLI is a separate
-reviewed workload migration; the freshness check recognizes only the recorded
-1.3.0 exclusion and will reopen the decision when a newer candidate appears.
+Python's tested patch is 3.14.7; its supported runtime floor is 3.14.0 within
+3.14.x. Floors, tested versions, and allowed release lines are separate values
+in the baseline; a newer untested major is not automatically compatible.
+
+Power Apps is retired and has no active SDK, starter snapshot, or source-commit
+compatibility lane in the supported baseline.
 
 Generated npm projects include `package-lock.json`. Python projects include
 `uv.lock` and use `uv sync --frozen`. Go projects include `go.mod` and
 `go.sum`. Generated OpenTofu includes a multi-platform `.terraform.lock.hcl`.
+Each selected independent environment root receives its own provider lock and
+backend configuration; the application module is shared. Generic GenAI's default
+Python project and lock do not require a `pgvector` package.
 
 Container references include a readable stable tag and an immutable
 multi-architecture digest. The optional Langfuse profile uses the v4 web and
@@ -52,11 +55,10 @@ digests and upstream provenance, then run:
 npm run refresh:supported-stack
 npm run check
 npm run verify:standard-node-templates
-npm run verify:power-apps-starter
 ```
 
-Power Apps source is refreshed only through its reviewed immutable upstream
-commit workflow. Do not edit Microsoft-owned starter files independently.
+Retired Power Apps fixtures are negative inputs only and do not participate in
+generation, freshness, or dependency promotion.
 
 ## Existing generated projects
 

package/docs/troubleshooting.md

@@ -5,7 +5,7 @@
 Check the canonical release:
 
 ```bash
-npm view @msn-control/liftoff@latest version --registry=https://registry.npmjs.org
+npm view @msn-control/liftoff@latest version --registry=https://registry.npmjs.org --@msn-control:registry=https://registry.npmjs.org
 liftoff --version
 liftoff upgrade --check
 liftoff upgrade
@@ -21,7 +21,7 @@ that version supported.
 Versions that predate `liftoff upgrade` require one manual global installation:
 
 ```bash
-npm install -g @msn-control/liftoff@latest --registry=https://registry.npmjs.org
+npm install -g @msn-control/liftoff@latest
 ```
 
 ## CLI upgrade is blocked by installation origin
@@ -38,6 +38,14 @@ Canonical npm defines the exact stable target, but Liftoff installs through the
 configured registry. Ask the mirror owner to synchronize or approve that exact
 version, then rerun `liftoff upgrade --check`. Liftoff does not edit `.npmrc` or
 bypass the managed registry.
+The package's machine-level `@msn-control:registry` takes precedence over npm's
+default `registry`. A canonical default does not cancel a scoped mirror.
+Liftoff reads this configuration from a neutral directory, not a project's
+`.npmrc`, and never prints credential-bearing registry values.
+
+A response-body timeout is a transport failure, not invalid release metadata.
+Retry after connectivity is restored; do not change registry policy or regenerate
+project locks to work around it.
 
 ## npm cannot write the global prefix
 
@@ -140,11 +148,12 @@ hand-edited unsafe path.
 
 ## Update reports managed-core conflicts or orphans
 
-`liftoff update` applies safe managed-core changes immediately and skips core
-conflicts.
+Run `liftoff update --check` before apply. `liftoff update` requires the matching
+preview and explicit approval, then applies its safe scope and skips core
+conflicts. A missing or stale receipt requires a fresh check, not force.
 
-- Use `liftoff update --check` for a read-only human report or
-  `liftoff update --check --json` for an automation drift gate.
+- Use `liftoff update --check` for a project-read-only human report or add
+  `--json` for automation. Both disclose an external preview receipt.
 - Project-owned application files never enter the report or mutation set.
 - Managed-core conflicts remain untouched by default.
 - Use `liftoff update --force` only after reviewing every listed path and
@@ -154,7 +163,8 @@ conflicts.
 - Update neither changes nor installs project dependencies.
 
 Commit or copy local work before overwriting. Transaction rollback protects a
-failed update, but Liftoff keeps no backup after success.
+failed ordinary update. Activation migration additionally retains original
+history after success; failed revalidation retains blocked/resumable v2.
 
 For a new governance policy or launcher conflict, review that exact local file
 before considering `liftoff update --force`; do not delete it or activate remote
@@ -168,7 +178,7 @@ unrecorded conflicting file remains user-owned and is not reported as an
 orphan.
 
 If a newer Liftoff release contains different source, dependencies, schemas,
-containers, environment files, Power Apps starter files, or infrastructure,
+containers, environment files, or infrastructure,
 ordinary update intentionally reports nothing for those project-owned
 differences. Review and migrate them as production changes. The existing
 `liftoff migrate` command does not perform an in-place Liftoff project upgrade.
@@ -189,8 +199,9 @@ the existing project files and infrastructure are project-owned.
 
 That is the expected initial state. The manifest records `handoff-generated`,
 not active enforcement. Run `/liftoff-setup` from a selected agent. It first
-completes, syncs, and archives the generated bootstrap seed with local baseline
-checks, then stops at explicit authority gates for commit/push, credentials,
+completes, syncs, and archives the OpenSpec bootstrap, or finalizes Spec Kit's
+real `000-liftoff-bootstrap` bundle locally after baseline checks. It 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. Older generated setup aliases are retired; after review,
@@ -205,14 +216,20 @@ policy's repository-dedicated provisioning exception, but it must stop for
 explicit approval before creating any Azure or GitHub resource. Do not replace
 missing capability with duplicate scanners, partial provisioning, or
 placeholder success.
+These are target-policy requirements; 14 production phases lack executors and
+two ruleset phases require an injected adapter absent from the public CLI.
+Public approval persistence and credential enrollment also remain unavailable.
+An unavailable executor or authority entry point is a blocker, not an instruction
+to run its provider commands directly.
 
 If a private ZRS state backend cannot be reached because public network access
 is disabled and no approved private management path exists, do not enable
-public access or upload local state to GitHub. Use the policy's explicitly
-approved minimum `bootstrap-local` phase, adopt resources through declarative
+public access or upload local state to GitHub. The target policy requires an
+explicitly approved minimum `bootstrap-local` phase, adoption through declarative
 imports from the private runner, verify identity parity, locking, versioning,
 and a clean no-change plan, then retain the frozen local state read-only for 30
-days before secure deletion.
+days before secure deletion. That production adapter is not implemented by this
+release; stop at the capability blocker and plan separately reviewed platform work.
 
 If an Azure bootstrap fails with a namespace-not-registered error while
 `resource_provider_registrations = "none"` is configured, do not retry the same
@@ -239,23 +256,23 @@ or allow TCP and UDP 53 to exact custom resolver addresses.
 
 | State | Remedy |
 | --- | --- |
-| `seed-incomplete` | Run `/liftoff-setup`; fix failing local baseline checks and rerun until the seed is archived. |
-| `phase-blocked` | Read the blocking phase, evidence requirement, and approval gate; satisfy the named prerequisite rather than skipping it. |
-| `evidence-stale` | Regenerate evidence from the current baseline, activation identity, graph hash, and phase input digest. |
+| `seed-incomplete` | Repair local checks, then explicitly retry the supported seed phase. OpenSpec archives; Spec Kit finalizes its real bundle locally. |
+| `phase-blocked` | Read the phase, proof, and authority blocker; unavailable production or enrollment capabilities remain blocked. |
+| `evidence-stale` | Obtain fresh proof through supported, authorized execution from current inputs; never edit receipts or reuse stale headers as current inputs. |
 | `credential-expiring` | Rotate before the recorded lead time using the same App or PAT policy. |
-| `reconciliation-required` | Review the policy/contract/schema/graph change and acknowledge the current compatible identity before applying another phase. |
-| `identity-incompatible` | Upgrade to the reported minimum Liftoff version or provide an explicit supported migration/import mapping. |
+| `reconciliation-required` | Review `liftoff update --check`. An exact supported v1 source can use the approved history-preserving successor lane; unknown formats remain blocked. Never edit JSON to acknowledge identity. |
+| `identity-incompatible` | Upgrade when the supported tuple requires a newer CLI. A historical receipt never becomes executable through force, retagging, or an invented mapping. |
 | `enforcement-incomplete` | Prove exact required contexts green and deliberately red, then approve final enforcement before ruleset mutation. |
-| `disposal-pending` | After day 30, approve destructive disposal of retained bootstrap state and rerun setup. |
+| `disposal-pending` | Review retention, exact imported paths, destructive scope, and proof. Execution requires valid authority; there is no public approval-entry shortcut. |
 
 Do not hand-edit task checkboxes to clear these states. Tasks are projections of
 validated phase evidence.
 
 ## Runner-preflight credential setup is blocked
 
-Setup first prefers an existing verified selected-repository GitHub App with the
-required read permissions. If none is available, create one fine-grained PAT with
-exactly these fields: display name `<repo>-runner-preflight-read`, secret
+The policy prefers an existing verified selected-repository GitHub App with the
+required read permissions. Its fallback contract describes a fine-grained PAT
+with these fields: display name `<repo>-runner-preflight-read`, secret
 `RUNNER_CONFIGURATION_READ_TOKEN`, 30-day lifetime, current repository only,
 repository metadata read, organization hosted-runner read and
 network-configuration read, no writes, and the recorded workflow/job allowlist
@@ -264,24 +281,81 @@ network-configuration read, no writes, and the recorded workflow/job allowlist
 `private-dast-preflight` unless the generated policy records a narrower
 applicable set).
 
-Enter the value only through the masked input. Never paste or show the value in
-chat, argv, command arguments, logs, evidence, files, or screenshots. A leaked value is
-compromised; manually revoke it, create a replacement, update the repository
-secret through setup, and rerun `liftoff governance verify --json`.
+This release does not expose public credential enrollment or masked input.
+Do not create or submit a credential through an invented setup channel, and do
+not hand-write state or receipts to bypass the capability blocker. Never paste
+or show the value in chat, argv, command arguments, logs, evidence, files, or
+screenshots. Revoke and rotate leaked credentials through their owner-controlled
+system. A payload-free policy file alone is not independent readback evidence.
 
 ## Governance identity or manifest migration is blocked
 
 Current Liftoff reads manifest v2-v7 and writes v7. It resumes only explicit
-compatible tuples: policy version 6, activation contract 1, schema-v1 activation
-artifacts, and a recognized phase-graph hash. Future versions, individually
+compatible tuples: policy version 6, activation contract 2, state/evidence-header/
+approval/compatibility metadata versions 2, and a recognized phase-graph hash.
+Phase graph, supersession, and credential-policy schemas stay at 1.
+Future versions, individually
 known but unsupported combinations, unknown graph hashes, or unversioned ad hoc
 state block without rewriting files. Use the exact upgrade, import-mapping, or
-reconciliation remedy printed by status or update; do not downgrade the
-manifest or copy evidence between identities.
+reconciliation diagnostic printed by status or update; do not downgrade the
+manifest or copy evidence between identities. Historical v1 state and evidence
+remain diagnostic-only and byte-preserved. This release has no automatic or
+public historical-state reconciliation workflow; managed-core update does not
+make that history executable.
 
 Do not run an older Liftoff release to reverse a completed baseline migration.
-Restore the affected generated files and `liftoff.manifest.json` through version
-control, then reinstall from the restored locks.
+Restore separately reviewed project changes through version control and reinstall
+from the restored locks; do not alter immutable activation evidence to claim
+compatibility.
+
+## Spec Kit setup reports seed adoption required
+
+The real bundle must contain `specs/000-liftoff-bootstrap/spec.md`, `plan.md`,
+and `tasks.md`, its identity markers, and B001–B006 exactly once. Framework
+templates are not a substitute for project artifacts. Existing projects missing
+the bundle need separate reviewed adoption; update, force, assessment, or
+read-only resume will not create it. Never invent an OpenSpec archive or Git
+branch to make Spec Kit setup pass.
+
+## Infrastructure helpers or baseline report migration required
+
+Independent roots require exact recorded shared-module/root provenance and safe
+existing module files. Creating folders alone, changing tfvars paths, or updating
+managed governance context does not establish eligibility. Existing flat-root
+provenance remains unchanged after the explicit new-output-only retirement.
+Do not move state or force new roots into place to clear the result; plan a
+separate reviewed migration.
+
+## Native startup rejects configuration or appears to ignore the file
+
+Python and Node read root `.env`; Python backend-CWD startup still resolves that
+same file. Go's backend-CWD recipe reads `../runtime.config.json`. Use
+`LIFTOFF_ENV_FILE` for an explicit selection, relative to the startup directory
+unless absolute. Process values override the file, and settings are resolved
+once, so restart after edits.
+
+An explicit missing, unreadable, malformed, invalid-UTF-8, or NUL-containing
+dotenv file fails rather than falling back. Fix `KEY=value` syntax and balanced
+quotes; Node rejects escaped quote delimiters, so use the other quote style.
+Go requires valid JSON with string values, not null or numeric values.
+Do not source configuration as shell code. An absent default file is allowed
+only when the required settings come from process configuration.
+
+For offline `/health`, `/ready`, and `/openapi.json` probes, provide
+`DATABASE_URL` and `REDIS_URL` but leave `PYDANTIC_AI_MODEL`,
+`LANGFUSE_PUBLIC_KEY`, and `LANGFUSE_SECRET_KEY` blank. These probes do not
+contact a model or prove external-service health. `PYDANTIC_AI_MODEL=test` is
+not a supported model provider; no special test-model flag is needed.
+
+See [runtime recipes](configuration-and-manifests.md#application-runtime-configuration).
+
+## A locally prepared container build includes host files
+
+Keep the generated root and frontend `.dockerignore` files in their respective
+build contexts. They exclude host `.venv`, `node_modules`, caches, build output,
+VCS metadata, state, and local secrets. Function publication uses its own
+`.funcignore`. If those project-owned files were changed or removed, repair them
+through reviewed project work; update or force cannot restore them.
 
 ## A frozen Python install cannot reach the package index
 
@@ -299,30 +373,16 @@ docker build --build-arg UV_DEFAULT_INDEX=https://packages.example.test/simple/
 Do not place credentials in build arguments. Configure authenticated registries
 through an approved secret-aware build mechanism.
 
-## Power Apps dependencies or CLI are missing
-
-From the project root:
-
-```bash
-npm ci
-npx --no-install power-apps --version
-npm run dev
-```
+## Power Apps workload or Code Apps options are rejected
 
-The CLI is project-local. Do not replace the locked install with an unrelated
-global package.
-
-## The Code Apps plugin is missing or not observable
-
-Plugin state is advisory. In each selected agent session, use:
-
-```text
-/plugin marketplace add microsoft/power-platform-skills
-/plugin install code-apps-preview@power-platform-skills
-```
+Power Apps creation and existing-project support are retired. The workload and
+plugin options now fail explicitly; this is not a missing dependency or an
+installation problem.
 
-Then rerun `liftoff doctor`. Do not run `/create-code-app` in a Liftoff project.
-Liftoff does not run Microsoft's broad plugin installer.
+The rejection leaves application files, dependencies, framework files, and
+historical state unchanged. Do not change the manifest's workload identity, hide
+it to trigger another discovery path, or use force to bypass retirement. This
+CLI provides no automatic conversion or continued Power Apps maintenance lane.
 
 ## Terminal output is hard to read or being captured