@msn-control/liftoff 0.10.4 → 0.11.1

package/docs/project-structure.md

@@ -17,7 +17,9 @@ project/
 |-- liftoff.config.json
 |-- liftoff.manifest.json
 |-- .env.example
+|-- runtime.config.example.json # Go native configuration only
 |-- Dockerfile
+|-- .dockerignore
 |-- docker-compose.yml
 |-- .liftoff/
 |   `-- governance/             # managed-core local handoff when enabled
@@ -45,8 +47,10 @@ project/
 |-- infrastructure/
 |   `-- opentofu/
 |       `-- azure/
-|           `-- .terraform.lock.hcl
+|           |-- modules/application/
+|           `-- environments/<env>/ # independent root, <env>.tfvars and provider lock
 |-- openspec/ or .specify/
+|-- specs/000-liftoff-bootstrap/ # Spec Kit only: one-time spec.md, plan.md, tasks.md
 |-- .github/skills/openspec-*/ and .github/prompts/opsx-*  # OpenSpec + Copilot
 |-- .claude/skills/openspec-*/ and .claude/commands/opsx/  # OpenSpec + Claude
 |-- .github/workflows/copilot-setup-steps.yml              # optional hosted agent
@@ -64,7 +68,9 @@ project/
 
 - `backend` contains the selected API stack and Scalar/OpenAPI wiring. Python
   uses `backend/apis`, Node.js uses `backend/src`, and Go uses
-  `backend/cmd/api` plus `backend/internal`.
+  `backend/cmd/api` plus `backend/internal`. Node includes an explicit
+  `backend/vitest.config.ts`; Go's `backend/cmd/migrate/main.go` passes resolved
+  configuration to the existing pinned Goose migration tool.
 - `backend/orchestration` appears only in GenAI projects and contains
   PydanticAI agents, prompts, model configuration, and integration boundaries.
   The generic pattern creates `generic_agent.py`, `generic.md`, and the neutral
@@ -80,8 +86,12 @@ project/
 - Python Docker builds export the committed `uv.lock` in frozen mode and install
   only hash-verified requirements. `UV_DEFAULT_INDEX` can select a
   credential-free managed mirror without changing the lock.
-- `infrastructure/opentofu/azure` contains modules, environment tfvars, local
-  state configuration, and a remote-state example.
+- `infrastructure/opentofu/azure/modules/application` contains the shared module.
+  Each selected `infrastructure/opentofu/azure/environments/<env>` root owns its
+  named tfvars, provider lock, and independent local/remote state configuration.
+  Existing shared-state projects are not relocated by update or force.
+  The eight [retired flat-root identities](azure-deployment.md#explicit-flat-root-identity-retirement)
+  remain historical provenance; new root-looking files do not establish eligibility.
 - `openspec` is created for OpenSpec. `.specify` and `specs` are created for
   Spec Kit.
 - OpenSpec projects receive all 12 pinned workflows as both skills and commands
@@ -104,47 +114,30 @@ project/
   separate from Azure Functions runtime files.
 - `migration/legacy` contains the filtered source copy created by migration.
 
-## Power Apps code app
+### Runtime configuration and image boundaries
 
-```text
-project/
-|-- README.md
-|-- THIRD_PARTY_NOTICES.md
-|-- liftoff.config.json
-|-- liftoff.manifest.json
-|-- package.json
-|-- package-lock.json
-|-- index.html
-|-- vite.config.ts
-|-- eslint.config.js
-|-- tsconfig.json
-|-- public/
-|-- src/
-|   |-- App.tsx
-|   |-- main.tsx
-|   |-- router.tsx
-|   |-- components/
-|   |-- hooks/
-|   |-- pages/
-|   `-- providers/
-|-- .liftoff/governance/        # managed-core setup files when enabled
-|-- governance/                 # user-owned activation state after setup starts
-`-- openspec/ or .specify/
-```
+Python and Node.js native startup read the project-root `.env`; process
+environment values take precedence over file-backed settings and nonsecret
+defaults. Go native startup from `backend/` reads `../runtime.config.json`;
+copy `runtime.config.example.json` to that path or select explicit JSON with
+`LIFTOFF_ENV_FILE`. It does not shell-source `.env`. Configuration is resolved
+once per process; restart after editing the selected file.
+Explicit missing, unreadable, or malformed selected files fail before fallback.
+See [configuration syntax and native commands](configuration-and-manifests.md#application-runtime-configuration)
+for strict dotenv quoting and Go's string-valued JSON contract.
 
-The exact selected-agent setup and assessment launchers are generated only when the
-repository-governance profile is enabled. They are Liftoff-owned; neighboring
-framework files remain framework-owned. Agent-created governance changes and
-`governance/activation-state.json`, approvals, evidence, credentials, and
-supersession records remain user-owned and are not listed as managed artifacts.
+Compose passes applicable runtime settings explicitly while keeping PostgreSQL,
+Redis, and other generated service addresses container-reachable. Root and
+frontend `.dockerignore` files exclude host virtual environments, `node_modules`,
+build outputs, VCS metadata, state, and local secrets. Installing dependencies
+locally must not copy a host environment over dependencies installed in an image.
 
-This root follows the pinned official Microsoft starter. It includes the
-Power Apps SDK, Vite plugin, and project-local CLI through locked npm
-dependencies.
+## Retired project layouts
 
-Liftoff intentionally does not generate `backend/`, `database/`,
-`docker-compose.yml`, `environments/`, `infrastructure/`, or
-`power.config.json` for this workload.
+Power Apps code app generation and maintenance are retired. An existing
+Power Apps manifest is rejected without converting its root layout or modifying
+application, framework, dependency, or governance files. The remaining generated
+layouts are the API and GenAI layouts above.
 
 ## Managed versus user-owned governance artifacts
 
@@ -169,12 +162,12 @@ success-shaped placeholders:
   invocation fails clearly.
 - Redis Streams uses `REDIS_URL` and `REDIS_STREAM_NAME`.
 - Azure Service Bus uses `SERVICE_BUS_QUEUE_NAME` and either
-  `SERVICE_BUS_CONNECTION_STRING` or
-  `SERVICE_BUS_FULLY_QUALIFIED_NAMESPACE`; `AZURE_CLIENT_ID` selects a
-  user-assigned managed identity.
+  `SERVICE_BUS_AUTH_MODE=connection-string` with `SERVICE_BUS_CONNECTION_STRING`,
+  or `managed-identity` with `SERVICE_BUS_FULLY_QUALIFIED_NAMESPACE` and
+  `AZURE_CLIENT_ID` for the selected user-assigned identity.
 - Langfuse requires both `LANGFUSE_PUBLIC_KEY` and
-  `LANGFUSE_SECRET_KEY`, with optional `LANGFUSE_HOST`. Without both keys,
-  tracing is explicitly disabled.
+  `LANGFUSE_SECRET_KEY`, with optional `LANGFUSE_HOST`. Both blank disables
+  tracing; only one configured key is an error.
 - Frontends read `VITE_API_BASE_URL`, call the route selected by the pattern or
   API stack, and expose loading, response, and failure states.
 - Backends allow the local frontend origin by default.

package/docs/repository-governance.md

@@ -14,9 +14,10 @@ cd my-project
 /liftoff-setup
 ```
 
-`/liftoff-setup` completes the generated bootstrap seed, then enters the
-deterministic Liftoff governance engine, user-owned activation state, and
-read-only Phase 0 discovery.
+`/liftoff-setup` uses the deterministic Liftoff governance engine to complete
+the workflow-specific local bootstrap, then encounters the separately authorized
+publication and read-only Phase 0 boundaries. The user-owned activation state records
+execution, not an agent's claim of completion.
 
 **Current activation limits:** local bootstrap is implemented, but the CLI does
 not yet wire every production phase executor or expose approval persistence
@@ -72,6 +73,18 @@ runs assessment. It needs no commit, push, activation, or cloud credentials:
 liftoff governance assess --json
 ```
 
+The same CLI command works in an ordinary Git repository without initialization,
+a manifest, or generated slash commands. An explicit path is authoritative;
+otherwise the nearest applicable Git or Liftoff boundary is used, including
+linked worktrees and unborn repositories. A malformed, unreadable, symlinked,
+dangling, or retired inner manifest blocks fallback to an outer project or Git
+repository. Assessment never installs agent wrappers into unrelated repositories.
+
+For ordinary Git repositories the installed single-maintainer policy is the
+displayed target, not a policy inferred from existing branches. Recorded Liftoff
+identity stays nullable, and missing baseline, ownership, or evidence stays
+`not-observed`. It is not the same as a valid Liftoff governance opt-out.
+
 The pinned target is the **installed CLI** and its packaged policy, activation
 identity, phase graph, and assessment control catalog, never registry latest.
 The report compares four distinct layers: target, recorded project baseline,
@@ -103,8 +116,10 @@ enrolls credentials, expands permissions, registers providers, reads state blobs
 executes project code, runs scanners or infrastructure tools, or changes local
 or remote configuration.
 Azure scope and evidence-backed applicability require a current active-baseline
-and referenced, validated saved-plan/evidence receipts. Placeholder digests,
-future-dated approvals, and inferred bindings cannot establish proof. Missing
+and referenced, validated saved-plan/evidence receipts. Current receipts bind
+their canonical payload and live readback through `bodyDigest`; a header hash
+alone cannot authorize changed runner IDs or Azure resources. Placeholder digests,
+historical v1 receipts, future-dated approvals, and inferred bindings cannot establish proof. Missing
 bindings remain `not-observed`. Do not fabricate or hand-edit activation state,
 baselines, receipts, or evidence to manufacture alignment; use separately
 approved setup or governance work to obtain trustworthy proof.
@@ -127,6 +142,21 @@ zero-required-reviewer policy rather than generic peer-review advice.
 Approved exceptions remain differences; free-form or expired claims cannot
 waive controls or hide coverage gaps.
 
+Collection failures do not erase independent facts. For example, denied GitHub
+access cannot invalidate an unchanged local workflow, and a denied Azure resource
+cannot hide a proven violation on another resource. Effective/classic/inherited
+branch protection, release/hotfix check bindings, transitive required-job
+dependencies, and complete runner restrictions are evaluated separately.
+Rejected exception claims retain diagnostics instead of disappearing.
+Required checks bind both their names and application identities. A passing
+aggregator cannot hide a required scanner with `continue-on-error`; unresolved
+reusable-workflow, matrix, or dynamic semantics stay unobserved. Runner checks
+include repository/group restrictions, not only matching IDs or labels.
+
+The catalog retains 30 controls across 17 families, including 10 unsupported
+evaluators. Available evaluators are not completed proof; always-applicable
+unsupported controls keep enabled assessments partial even with live access.
+
 Human and schema-v1 JSON reports share `readOnly: true`, target and project
 identities, findings, diagnostics, provenance, and coverage. Exit **0** means
 fully observed `aligned` or explicitly disabled `not-applicable` governance
@@ -194,22 +224,38 @@ remote import can satisfy `remote-ready`.
 
 ## Bootstrap seed and local baseline
 
-Before commit/push or Phase 0, setup completes, syncs, and archives the generated
-`bootstrap-<project>` OpenSpec seed. It runs only local, applicable checks:
+Before commit/push or Phase 0, OpenSpec setup completes, syncs, and archives the
+generated `bootstrap-<project>` seed. Spec Kit setup instead validates the real
+`specs/000-liftoff-bootstrap/{spec.md,plan.md,tasks.md}` bundle and official
+framework markers, then finalizes the local bootstrap handoff. It never creates
+an OpenSpec tree, invents an archive, or creates a Git branch. Older Spec Kit
+projects without the bundle need separately reviewed seed adoption.
+
+The bundle's exact identity is `000-liftoff-bootstrap`, with B001–B006 each
+appearing once. It is not an active governance change. Dependencies may already
+be installed; installing them requires separate consent, which passing tests
+alone cannot prove. Successful explicit execution commits the checked projection
+with body/full-plan-bound baseline evidence; failed checks leave tasks unchanged.
+
+Both adapters run only local, applicable checks in the declared component roots:
 
 - `liftoff validate`
 - backend tests from the generated README
 - frontend build when a frontend exists
 - `docker compose config -q` when Compose exists
-- `tofu fmt -check -recursive`
-- `tofu init -backend=false`
-- `tofu validate`
-- strict OpenSpec validation
+- `tofu fmt -check -recursive` at `infrastructure/opentofu/azure`, covering modules and roots
+- `tofu init -backend=false` in each selected independent environment root
+- `tofu validate` in each selected independent environment root
+- strict OpenSpec validation, or validation of the real Spec Kit bootstrap bundle
 
 Absent components are recorded as inapplicable. The baseline never starts
 containers, runs a live `tofu plan` or `tofu apply`, deploys, mutates GitHub, or
-requires cloud credentials. A failed check keeps the seed active; rerun
-`/liftoff-setup` after remediation and verified phases are not repeated.
+requires cloud credentials. A failed local check remains unfinished; only
+explicit execution retries it after repair. Read-only status, resume, and
+verification do not advance tasks or rerun checks. Unchanged current proof can
+be reused; changed relevant inputs require fresh evidence.
+Recorded legacy-shared or unknown infrastructure layouts block this baseline
+with migration-required and no commands, even if new-looking directories exist.
 
 If the seed was already archived before setup began, it stays archived.
 Setup still runs the entire applicable local baseline, but strict OpenSpec
@@ -236,6 +282,10 @@ types, destinations, permissions, cost ceiling, destructive scope, policy
 exceptions, expiry, and baseline SHA. Retries inside the same envelope do not
 ask again; expanded resources, destinations, permissions, cost, exceptions, or
 destructive effects require a new approval.
+Its time window must satisfy `approvedAt <= now < expiresAt` and have a valid
+start/end interval. A future, reversed, or expired envelope cannot authorize
+execution. The contract does not imply a public approval-persistence workflow
+exists; an unavailable entry capability remains a blocker.
 
 ## Credentials for runner preflight
 
@@ -243,7 +293,8 @@ When `GITHUB_TOKEN` cannot read required hosted-runner metadata, setup first
 prefers an existing verified selected-repository GitHub App installation with the
 required read permissions. Liftoff does not install or broaden an App.
 
-If no approved App is available, setup guides one fine-grained PAT with exactly:
+If no approved App is available, the normative policy describes this
+fine-grained PAT fallback, not an implemented enrollment command:
 
 | Field | Value |
 | --- | --- |
@@ -256,10 +307,12 @@ If no approved App is available, setup guides one fine-grained PAT with exactly:
 | Writes | none |
 | Workflow/job allowlist | `.github/workflows/bootstrap-import-preflight.yml` job `bootstrap-import-preflight`; `.github/workflows/private-dast-preflight.yml` job `private-dast-preflight` |
 
-Enter the value only through Liftoff's masked input. Never paste or show the
-value in chat, argv, command arguments, logs, evidence, files, or screenshots. A value
-that appears in any of those places is compromised and must be manually revoked
-and rotated before setup can continue.
+This release has no public masked credential-enrollment channel. Stop at the
+reported capability blocker rather than creating a credential or hand-writing
+state to make the phase pass.
+Never paste or show the value in chat, argv, command arguments,
+logs, evidence, files, or screenshots. A disclosed value is
+compromised and must be revoked and rotated through its owner-controlled system.
 
 The recorded credential policy is payload-free: it stores auth kind, display
 name, secret name, owner, repository, expiry, rotation lead, permissions,
@@ -270,9 +323,19 @@ secret value.
 
 Task checkboxes are a projection of phase state, not authority. Evidence
 documents carry repository identity, activation version vector, graph hash, phase
-contract digest, input digest, baseline SHA, phase ID, timestamp, producer, and
-result. Setup and `liftoff governance verify` reject missing, stale,
-contradictory, future-version, or graph-incompatible evidence.
+contract digest, real input/baseline digests, body commitment, phase ID, timestamp,
+producer, and result. The local execution anchor is separate from a verified
+remote repository binding; Phase 0 does not replace the anchor beneath earlier
+local receipts. Digests prove consistency, not an independent signature or
+permission grant. Current valid proof may coexist with informational stale
+history, but equally authoritative contradictory records block execution.
+The current context includes reviewed immutable plans and state evidence
+references. Payload `planDigest` binds semantic plan inputs; `savedPlanDigest`
+binds the full saved plan, including clocks. `bodyDigest` covers the payload and
+normalized readbacks. Consumers use the validated selected payload, not another
+raw record that happens to reuse an ID. Repository publication binds the actual
+reviewed push destination; Phase 0 cannot invalidate earlier local/publication
+receipts by replacing the local anchor.
 
 There may be only one active governance source of truth. An unfinished bootstrap
 seed blocks Phase 0. Exactly one compatible active governance change is resumed.
@@ -283,12 +346,15 @@ Managed updates install new policy, graph, schema, compatibility metadata, and
 setup and assessment integrations without touching user-owned state. Forced update can remove
 exact retired generated setup-alias entries from older manifests. When a policy,
 activation-contract, schema, or graph-hash change affects active work, status
-reports `reconciliation-required`, invalidates only affected descendants, and
-waits for explicit acknowledgement of the current compatible identity and exact
-graph hash.
+reports `reconciliation-required` and identifies affected descendants. Historical
+activation-v1 state and evidence stay byte-preserved and diagnostic-only under
+activation v2. This release has no automatic historical-state reconciliation,
+reset, or conversion workflow; do not acknowledge a new identity by editing JSON.
 
 ## Private staging and bootstrap retention
 
+These are policy requirements for separately implemented production adapters,
+not a claim that this CLI can provision the complete platform.
 Private Staging DAST uses an ephemeral GitHub-hosted larger runner with Azure
 VNet injection only when genuinely applicable. Phase 0 discovers repository,
 subscription, authority, billing, network, DNS, cost, teardown, and capability

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,35 @@ 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.
+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.
 
 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,
+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,6 +130,10 @@ 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 identity is a separate diagnostic-only case:
+safe managed-core maintenance may continue while preserving the recorded
+historical identity, state, and receipts. That maintenance never makes history
+executable or supplies a missing reconciliation workflow.
 
 If automatic rollback itself cannot safely restore a path because another
 process changed it, Liftoff reports the incomplete rollback rather than
@@ -112,6 +142,13 @@ overwriting unknown bytes.
 Update snapshots exist only for rollback after a failed transaction. Liftoff
 does not retain them as backups after success.
 
+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:
@@ -133,6 +170,9 @@ 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.
@@ -142,9 +182,15 @@ Update mode is selected explicitly rather than from terminal interactivity:
 `--force` cannot be combined with `--check` and cannot weaken project-boundary,
 symlink, collision, manifest, or transaction guards.
 
-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.
+Power Apps support is retired. Its manifests are rejected without fetching
+starter source, changing application files, or treating force as conversion
+authority.
+
+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 +199,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 +238,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