@msn-control/liftoff 0.10.3 → 0.11.1

package/docs/repository-governance.md

@@ -14,9 +14,17 @@ 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
+and secure credential enrollment through the command-only setup flow. Missing
+capabilities stop with a blocker; they are not completed by assessment or by
+hand-editing evidence. See the [developer follow-up plan](../DEVELOPER.md#activation-completeness-and-separate-follow-up-plan)
+for the remaining activation work.
 
 ## Managed files and user-owned state
 
@@ -31,6 +39,8 @@ Enabled governance adds managed-core files:
 .liftoff/governance/credential-policy.schema.json
 .github/prompts/liftoff-setup.prompt.md                # Copilot selected
 .claude/commands/liftoff-setup.md                      # Claude selected
+.github/prompts/liftoff-governance-assess.prompt.md    # Copilot selected
+.claude/commands/liftoff-governance-assess.md           # Claude selected
 ```
 
 Older generated setup aliases are retired. Use `liftoff update --force` after
@@ -52,6 +62,126 @@ The complete policy is packaged at
 Policy version 6 treats numbered policy sections as capability chapters, not
 execution order. The managed phase graph is the sole execution-order authority.
 
+## Read-only governance assessment
+
+`/liftoff-governance-assess` is separate from `/liftoff-setup`, which remains the
+primary post-init path. Both OpenSpec and Spec Kit receive only their selected
+agents' assessment integrations when governance is enabled. Initialization never
+runs assessment. It needs no commit, push, activation, or cloud credentials:
+
+```bash
+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,
+declared project configuration, and observed enforcement. Each finding includes
+expected and observed values, scope, provenance and capture metadata, impact,
+and ownership-aware advisory remediation. Matching CLI versions or generated
+hashes alone do not prove alignment.
+The project policy version is shown when available. JSON observations may also
+retain optional normalized `facts` alongside evaluator predicate values so a
+predicate result does not hide observed configuration. Raw provider payloads are
+not retained.
+
+The default is **local-only with no network access** or registry lookup.
+All assessment invocations, including `--live` and `--help`, skip telemetry and
+disclosure entirely. Local Git reads inspect only repository root, HEAD, and
+origin metadata, never `git status`, which can execute clean filters.
+Applicable live proof stays unobserved. Only an explicit live-read request
+allows the agent wrapper to substitute:
+
+```bash
+liftoff governance assess --live --json
+```
+
+Live mode performs bounded read-only GitHub/Azure metadata access with existing
+permissions and verified repository/environment/resource bindings. Runner
+organization metadata is limited to already-bound assignment IDs. Azure reads
+do not guess a default subscription or search unrelated resources. Neither mode
+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. 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.
+
+| Finding | Meaning |
+| --- | --- |
+| `aligned` | All required proof layers are available, fresh, and match the target |
+| `outdated` | A recognized older baseline or recorded managed artifact differs from the target |
+| `missing` | Complete authoritative observation proves an applicable requirement absent |
+| `conflicting` | Known settings contradict the target, or declared and observed layers disagree |
+| `approved-exception` | An exact, catalog-permitted, valid, unexpired approval covers the difference |
+| `inapplicable` | Validated workload facts establish that the control does not apply |
+| `not-observed` | Applicability or required proof is unknown, stale, denied, unsupported, or incomplete |
+
+Coverage counts unknown applicability, unobserved live proof, and unsupported
+evaluators explicitly. A local workflow declaration is not proof that its check
+is enforced. Denied access, masked 404s, incomplete pagination, and timeouts are
+not proof of absence. Single-maintainer expectations follow the canonical
+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
+(not an alignment claim). Exit **2** means `partial` coverage or `differences`,
+including approved exceptions. Exit **1** means `error`: invalid/unsafe input
+or an invalid packaged catalog prevents a trustworthy report. Local-only runs
+normally return partial coverage. Exit 2 is advisory, not proof that governance
+is broken or permission to remediate.
+
+Reports go to stdout only, never activation state or evidence. Assessment cannot
+complete Phase 0, satisfy an approval gate, or advance any phase. The wrapper
+explains the CLI's classifications without inventing findings or executing
+recommendations. Neither installing the integration nor running it activates,
+updates, upgrades, or migrates the project.
+
+Older supported inventories without assessment entries remain readable. Use
+`liftoff update --check`, then normal guarded `liftoff update` to install the
+selected integrations. Unowned conflicting destinations remain unowned even with
+`--force`; only already-managed modifications follow reviewed force rules.
+Unsupported activation tuples can still receive safe identity and coverage
+diagnostics, but no migration is available without an explicit supported mapping.
+Force cannot bypass compatibility or overwrite project-owned configuration.
+A future governance upgrade must reobserve facts and obtain its own reviewed
+plan and approvals; an assessment report supplies no mutation authority.
+
 ## Canonical phase graph
 
 The activation graph is packaged as `.liftoff/governance/phase-graph.json` and
@@ -94,22 +224,46 @@ 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
+validation targets the synchronized spec set with `openspec validate --all
+--strict`, not the inactive bootstrap change name. The expected main capability
+must exist with a concrete Purpose. A failed archived baseline can be retried
+after repair: `resume` reports readiness without rewriting stored state, and
+`apply-next --json --execute` reruns the checks before saving verified evidence.
 
 ## Questions and approval envelopes
 
@@ -128,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
 
@@ -135,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 |
 | --- | --- |
@@ -148,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,
@@ -162,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.
@@ -172,15 +343,18 @@ Multiple overlapping changes require a schema-valid supersession or archive
 record before any phase advances.
 
 Managed updates install new policy, graph, schema, compatibility metadata, and
-setup integrations without touching user-owned state. Forced update can remove
+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
@@ -219,7 +393,16 @@ evidence-ready, approved phase. Here, approved means its approval status is
 fail before project discovery or mutation. Verification reports consistency
 separately from setup completion: a valid not-started or in-progress state may
 have `ok: true` and `verificationStatus: "consistent"` while `complete` remains
-false.
+false. An intact bootstrap seed awaiting baseline verification or archive is
+also incomplete rather than inconsistent. Missing or overlapping seeds, or an
+active seed contradicting recorded archive completion, still fail verification.
+
+Apply-next reports `selectedPhase` for the attempted transition and
+`executedPhase` only when execution succeeds (otherwise `null`). Its legacy
+`nextReadyPhase` field is not post-transition readiness; use the subsequent
+status or verify response for the next phase. OpenSpec failures include bounded
+diagnostics with terminal controls removed; credential-shaped output is
+withheld rather than copied into state or command output.
 
 ## Existing projects
 

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
 

package/docs/telemetry.md

@@ -7,7 +7,7 @@ the CLI to work. It creates no persistent installation or session identifier.
 
 ## Event contract
 
-Each recognized command can send at most one event after it finishes:
+Each telemetry-eligible command can send at most one event after it finishes:
 
 ```json
 {
@@ -21,8 +21,14 @@ Each recognized command can send at most one event after it finishes:
 
 `outcome` is `success` for exit code zero and `failure` for every nonzero exit
 code. It is an exit-status class, not an error diagnosis. Help requests are
-recorded as `help`, and rejected input that never resolves to a recognized
-command is not recorded.
+recorded as `help`, except assessment help as described below. Rejected input
+that never resolves to a recognized command is not recorded.
+
+`liftoff governance assess` skips telemetry and disclosure entirely, including
+`--live` and `--help`. It sends no telemetry event, displays no disclosure notice,
+and writes no disclosure state, regardless of the default telemetry setting.
+Opting into live assessment authorizes only its scoped read-only observations,
+not telemetry delivery.
 
 `upgrade` is recorded only as the aggregate command value. Check/apply mode,
 target or configured-registry details, installation origin, paths, npm output,