@msn-control/liftoff 0.9.0 → 0.9.2

package/docs/cli-reference.md

@@ -23,13 +23,13 @@ install -> upgrade CLI -> plan -> init or migrate -> validate and doctor -> upda
 | `liftoff plan` | Resolves decisions and previews artifacts and requirements without side effects |
 | `liftoff init [project-name]` | Initializes a named child or the exact current Git root through staged readiness and framework setup |
 | `liftoff migrate <source>` | Creates a new sibling scaffold and filtered source copy without changing the source |
-| `liftoff validate [project]` | Validates manifest identity, durable files, workload metadata, and framework markers |
+| `liftoff validate [project]` | Validates manifest identity, managed-core hashes, project provenance, workload metadata, and framework markers |
 | `liftoff doctor [project]` | Runs read-only workload-derived project and workstation diagnostics |
 | `liftoff upgrade` | Replaces a verified global npm installation with the exact canonical stable release exposed by the configured registry |
 | `liftoff upgrade --check` | Checks installation origin and registry parity without installing; exits 2 when an installable update exists |
-| `liftoff update [project]` | Applies safe managed drift immediately, preserves unforced conflicts and orphans, and records the resulting manifest |
-| `liftoff update --check` | Reports drift without preflight or mutation; exits 0 when clean and 2 when drift exists |
-| `liftoff update --force` | Applies safe changes and overwrites only the exact guarded conflicts reported by update |
+| `liftoff update [project]` | Applies safe managed-core maintenance and authorized create-only component provisioning |
+| `liftoff update --check` | Reports core maintenance and provisioning without mutation; exits 0 when clean and 2 when actionable |
+| `liftoff update --force` | Overwrites only exact guarded managed-core conflicts; project-owned files remain unreachable |
 | `liftoff dev` | Prints workload-appropriate local development commands; it does not execute them |
 | `liftoff infra` | Prints OpenTofu guidance for API workloads and reports infrastructure as not applicable for Power Apps |
 | `liftoff patterns` | Lists GenAI patterns |
@@ -132,32 +132,44 @@ liftoff update --check --json
 ```
 
 Plain `liftoff update` is imperative and prompt-free. It applies safe new,
-missing, untouched-upgrade, clean-move, and recorded-state changes in
-interactive terminals, redirected streams, and automation. Local or user-owned
-conflicts are skipped and reported. Orphans are reported without deletion.
-During legacy governance adoption, preserved unrecorded conflicts remain
-outside manifest ownership and set local state to `handoff-partial` until a
-later update can write or byte-identically adopt every required artifact.
-
-Use `--check` whenever no project bytes may change. Human check mode prints each
-drift state and recommends plain update for safe changes or a reviewed
-`--force` invocation for conflicts. `--check --force` is invalid because check
-mode never authorizes writes.
+missing, untouched-upgrade, clean-move, and recorded-state changes only for
+explicit `managed-core` artifacts. Core conflicts are skipped and core orphans
+are reported without deletion. During legacy governance adoption, preserved
+unrecorded conflicts remain outside managed ownership and set local state to
+`handoff-partial`.
+
+Application source, tests, dependencies and locks, database assets, Docker and
+Compose files, environment files, documentation, Power Apps starter files, and
+OpenTofu topology are `project` artifacts after generation. Update does not
+compare them with newer templates, restore deleted paths, or overwrite them
+under `--force`.
+
+Changing desired state from no frontend to frontend, or adding an environment,
+can authorize one create-only provisioning group. All destinations are
+preflighted together. Absent files are created and byte-identical files are
+adopted as provenance; any differing destination blocks the group even with
+`--force`. Disabling or re-enabling a previously provisioned group never
+recreates or deletes project files.
+
+Use `--check` whenever no project bytes may change. Human check mode prints
+managed-core drift, ownership-only manifest migration, and authorized
+provisioning. It recommends `--force` only for core conflicts. `--check
+--force` is invalid because check mode never authorizes writes.
 
 `--json` selects output format, not safety. `liftoff update --json` applies safe
 changes and emits the versioned apply result. `liftoff update --check --json`
 is the read-only automation gate.
 
 Update never installs dependencies. Transaction snapshots restore a failed
-update, but Liftoff retains no backup after a successful overwrite; commit or
-copy local work before using `--force`. Force does not permit workload, API
-stack, GenAI pattern, framework, selected-agent, or user-supplied Power Apps
-starter identity changes, and it cannot bypass project-boundary, symlink,
-structural-collision, or manifest guards.
+core update, but Liftoff retains no backup after a successful core overwrite.
+Force cannot bypass the ownership, project-boundary, symlink, structural,
+identity, or manifest guards.
 
-For a breaking supported-stack release, inspect `liftoff update --check` before
-plain update. Restore an unwanted applied migration through version control;
-running an older CLI is not a supported automatic downgrade.
+New dependency, runtime, container, database, application, Power Apps starter,
+and infrastructure templates apply to newly generated projects. Existing
+production projects adopt them through a separately reviewed project change.
+The existing `liftoff migrate` command only adopts a non-Liftoff source into a
+fresh target; it is not an in-place template upgrade.
 
 ### Migration from 0.6.x
 
@@ -186,7 +198,9 @@ liftoff update --json
 liftoff update --check --json
 ```
 
-Each JSON object has a top-level numeric `schemaVersion`.
+Each JSON object has a top-level numeric `schemaVersion`. Update JSON uses
+schema version 2 and includes `scope: "managed-core"`, ownership-migration
+state, and a separate provisioning collection.
 Operational warnings, such as a dirty-worktree warning before JSON apply, are
 written to stderr so stdout remains one parseable JSON object.
 
@@ -194,7 +208,7 @@ Exit codes:
 
 - `0`: success or a clean check.
 - `1`: invalid input, unsafe state, or command failure.
-- `2`: an explicit update check found project drift, or upgrade check found an
+- `2`: an explicit update check found core maintenance or provisioning, or upgrade check found an
   installable CLI release.
 
 Raw installer, framework, and dependency child stdout and stderr are forwarded

package/docs/configuration-and-manifests.md

@@ -9,9 +9,14 @@ machine-rewrite it afterward.
 
 Supported edits are reconciled by `liftoff update`:
 
-- API workloads can add or remove environments and enable applicable generated
-  areas such as the frontend.
-- Power Apps can change the optional Code Apps plugin preference.
+- API workloads can select a previously absent environment or frontend. Update
+  provisions that component once only when its destinations are absent or
+  byte-identical; a differing destination blocks the complete component and
+  cannot be forced.
+- Removing or re-enabling a previously provisioned component never deletes,
+  restores, or overwrites its project-owned files.
+- Power Apps can change the optional Code Apps plugin preference; only manifest
+  intent and applicable managed-core context change.
 
 Workload kind, API stack, GenAI pattern, spec workflow, selected agents, and a
 user-supplied Power Apps starter source change are not ordinary updates.
@@ -34,7 +39,7 @@ workload rather than silently ignored.
 
 ## `liftoff.manifest.json`: CLI-owned compatibility record
 
-New projects use manifest schema v5. Its common project identity includes the
+New projects use manifest schema v6. Its common project identity includes the
 name, spec workflow, selected agents, and applicable Spec Kit default. A
 discriminated `project.workload` object contains only fields valid for one
 workload:
@@ -46,11 +51,14 @@ workload:
 
 The manifest also records:
 
-- Generating Liftoff version.
+- Last manifest-writing Liftoff version.
 - Official framework adapter, state, and tested contract version when known.
-- Durable artifact logical names.
+- `managedArtifacts`: exact Liftoff core logical names, paths, and
+  reconciliation `contentHash` values.
+- `projectArtifacts`: starter provenance with the original path, generating
+  Liftoff version, `generationHash`, and provisioning group. These hashes never
+  authorize update writes.
 - OS-neutral path-part arrays.
-- `sha256:` content hashes.
 - Repository governance profile, policy version, and local
   `handoff-generated`, `handoff-partial`, or disabled state.
 
@@ -63,7 +71,7 @@ paths, or hashes.
 
 ## Compatibility
 
-Readers support schemas v2, v3, v4, and v5:
+Readers support schemas v2, v3, v4, v5, and v6:
 
 - V2 normalizes the legacy flat API identity and records framework state as
   uncertain without inventing agents.
@@ -71,32 +79,39 @@ Readers support schemas v2, v3, v4, and v5:
 - V4 represents the discriminated workload model, including Power Apps.
 - V5 adds repository-governance handoff identity without claiming live
   enforcement.
+- V6 separates managed-core update authority from project generation
+  provenance.
 
 `liftoff update --check`, including `--check --json`, leaves an old manifest
-byte-for-byte unchanged. A successful plain update writes v5 only after the
-file transaction succeeds. Previously recorded skipped conflicts retain their
-hashes. A preserved unrecorded governance conflict has no artifact entry and
-sets the update-written manifest to `handoff-partial`; resolving every such
-conflict promotes the next manifest to `handoff-generated`.
+byte-for-byte unchanged. A successful plain update writes v6 only after the
+transaction succeeds. V2-v5 backend, frontend, database, dependency, container,
+environment, documentation, Power Apps, and infrastructure entries become
+project provenance without reading or changing current production bytes.
+Intentionally deleted files remain absent. Only exact current core logical
+names retain write authority.
 
 ## Artifact ownership
 
-Durable Liftoff artifacts carry logical names and hashes. That lets validate,
-doctor, and update distinguish:
+Every generated artifact has an explicit lifecycle independent from its
+category or filename:
 
-- Current template bytes.
-- An untouched file with a template upgrade.
-- A developer edit that conflicts with a template change.
-- A named artifact moved by the template.
-- Missing, new, and orphaned artifacts.
+| Lifecycle | Owner after initialization | Update behavior |
+| --- | --- | --- |
+| `managed-core` | Liftoff | Safe reconciliation; reviewed core conflicts may use `--force` |
+| `project` | Developer/project | Provenance only; never compared, restored, moved, or overwritten |
+| `desired-state` | Developer | Read as input and never machine-rewritten |
+| `framework` | Official framework | Validated through framework markers and maintained by that framework |
+| `seed` | Developer/project | Written once and never reconciled |
 
-Framework-owned OpenSpec and Spec Kit files are validated separately and are
-not claimed in durable hashes. One-time seed files are also excluded so they
-can follow their own lifecycle.
+The manifest is a CLI-owned transaction record rather than an ordinary
+template artifact. Current managed core is limited to the exact repository
+governance policy, context, guide, and selected-agent launchers. A name such as
+`config.go`, a `configuration` category, or a path under `.github` does not
+grant update authority.
 
 ## Contract conventions
 
-- Writers use `artifactVersion` 5; readers support v2, v3, v4, and v5.
+- Writers use `artifactVersion` 6; readers support v2, v3, v4, v5, and v6.
 - Artifact logical names and catalog identifiers are append-only.
 - Rendering is deterministic and does not depend on timestamps, host versions,
   or network state.

package/docs/existing-repositories.md

@@ -70,10 +70,10 @@ liftoff update
 ```
 
 Use `--check` first when the invocation must be read-only. Plain update applies
-safe managed changes immediately and without prompting in terminals and
-automation, while preserving conflicts and orphans. Review every reported
-conflict and commit or copy local work before choosing `liftoff update --force`.
-For CI drift gates, use `liftoff update --check --json`.
+safe managed-core changes immediately and preserves core conflicts and orphans.
+`--force` can replace only listed core conflicts. Project-owned production
+files are not compared and remain unreachable from every update mode. For CI
+core-maintenance gates, use `liftoff update --check --json`.
 
 OpenSpec skills and commands remain framework-owned. To give an existing
 project all 12 workflows as both skills and commands, run:
@@ -88,26 +88,26 @@ Select both delivery modes and every workflow in the profile picker. Plain
 hosted Copilot agent later, update `githubCopilot.cloudAgent` through OpenSpec
 and run `openspec update`.
 
-Projects created before manifest schema v5 automatically preview the default
+Projects created before manifest schema v6 automatically preview the default
 repository-governance handoff as new named drift. Plain update safely adopts
 collision-free policy, context, guide, and selected-agent launchers without
 rewriting a configuration that omitted `governanceProfile`. Existing different
-files remain unowned conflicts and the v5 manifest records `handoff-partial`.
+files remain unowned conflicts and the v6 manifest records `handoff-partial`.
 Resolving every conflict promotes a later update to `handoff-generated`.
 Selecting `none` leaves previously managed handoff files as undeleted orphans
 while unrecorded conflicts remain user-owned. No update mode runs an agent or
 activates GitHub settings.
 
-Major supported-stack releases can report many runtime, lock, Docker, provider,
-and framework artifact changes at once. Treat those releases as breaking:
-commit or copy local work, inspect `liftoff update --check`, and apply only after
-reviewing all upgrades and conflicts. Plain update preserves conflicting local
-bytes and never requires `--force` as the default migration path.
+The schema-v6 transition releases every legacy non-core artifact into project
+provenance without writing, restoring, moving, or deleting its path.
+Intentionally removed infrastructure stays absent and production source stays
+byte-for-byte unchanged.
 
-If an applied baseline migration must be reversed, restore the project and
-manifest through version control and reinstall from the restored locks. Liftoff
-does not automatically downgrade generated dependencies and retains no backup
-after a successful update.
+Major supported-stack releases apply to new scaffolds. Existing projects adopt
+runtime, lock, Docker, provider, framework, and application changes through a
+normal reviewed project change. Ordinary update and force cannot perform that
+migration, and the existing `liftoff migrate` command remains a fresh-target
+workflow for non-Liftoff sources.
 
 ## Existing non-Liftoff application
 

package/docs/getting-started.md

@@ -32,8 +32,9 @@ liftoff upgrade
 ```
 
 `upgrade` replaces only the supported global CLI installation. It does not read
-or update a generated project; inspect project template changes separately with
-`liftoff update --check`.
+or update a generated project. Inspect Liftoff-managed core maintenance
+separately with `liftoff update --check`; production template modernization is
+a reviewed project change.
 
 See [prerequisites](prerequisites.md) for the complete plan-derived tool model.
 

package/docs/project-structure.md

@@ -4,6 +4,11 @@ Generated paths are logical examples. Liftoff uses platform-correct filesystem
 handling on Windows, macOS, and Linux, and manifests store path-part arrays
 instead of joined strings.
 
+After initialization, workload paths shown below are project-owned production
+assets. Their manifest entries preserve generation provenance but
+`liftoff update`, including `--force`, cannot compare, restore, move, or replace
+them. Only exact files labeled as managed core retain Liftoff write authority.
+
 ## GenAI and API projects
 
 ```text
@@ -15,7 +20,7 @@ project/
 |-- Dockerfile
 |-- docker-compose.yml
 |-- .liftoff/
-|   `-- governance/             # durable local handoff when enabled
+|   `-- governance/             # managed-core local handoff when enabled
 |       |-- policy.md
 |       |-- context.json
 |       `-- README.md

package/docs/repository-governance.md

@@ -72,9 +72,9 @@ liftoff update --check
 liftoff update
 ```
 
-Check mode previews the schema-v5 manifest and new named artifacts without
+Check mode previews the schema-v6 manifest and new named core artifacts without
 writing. Plain update applies collision-free files; differing existing files
-remain conflicts unless individually reviewed with `--force`. An unrecorded
+remain managed-core conflicts unless individually reviewed with `--force`. An unrecorded
 conflict remains outside Liftoff ownership and produces `handoff-partial`.
 After every conflict is removed or matches the current artifact, the next
 update records the full artifact set as `handoff-generated`.

package/docs/safety-and-consent.md

@@ -78,10 +78,10 @@ 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 all affected paths and applies generated file,
-move, delete, and manifest mutations as one rollback-capable transaction.
-Schema upgrades are committed only after the other mutations succeed. A
-corrected retry converges from the restored state.
+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.
 
 If automatic rollback itself cannot safely restore a path because another
 process changed it, Liftoff reports the incomplete rollback rather than
@@ -94,30 +94,35 @@ does not retain them as backups after success.
 
 Update mode is selected explicitly rather than from terminal interactivity:
 
-- Clean generated files remain unchanged.
+- 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 without prompting,
-  including with redirected input or output.
+  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.
-- Developer edits that also differ from the current template are conflicts.
-- Default update skips conflicts and lists them by portable relative path.
-  After reviewing every listed overwrite, `liftoff update --force` extends the
-  transaction only to those guarded conflicts.
+- 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
+  conflicts.
+- Project source, dependencies, schemas, containers, environments,
+  documentation, and infrastructure cannot be restored or overwritten by any
+  update mode.
+- 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.
 - 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 may be updated, but update never installs
-  dependencies.
+- 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.
 
-Power Apps reconciliation reads only the packaged immutable starter. It does
-not fetch the upstream repository. Workload kind and user-edited starter
-repository, template path, or commit changes are rejected before artifact
-access.
+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.
 
 ## Framework and seed ownership
 

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

@@ -89,7 +89,7 @@ Select **Both (skills + commands)** and every workflow in the profile picker.
 Plain `liftoff update` intentionally does not regenerate these framework-owned
 files.
 
-Repository-governance launchers are separate durable Liftoff files at the exact
+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
@@ -140,6 +140,7 @@ invoke `/create-code-app`. The plugin's connector and deployment skills remain
 available for post-creation work.
 
 Changing the valid plugin preference in `liftoff.config.json` is reconciled by
-plain `liftoff update`; it immediately updates generated guidance and manifest
-intent without creating API or infrastructure artifacts. Use
-`liftoff update --check` to inspect that drift without writing.
+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.

package/docs/supported-stack.md

@@ -60,8 +60,8 @@ commit workflow. Do not edit Microsoft-owned starter files independently.
 
 ## Existing generated projects
 
-Upgrade the globally installed Liftoff CLI, then inspect project-managed changes
-as a separate operation:
+Upgrade the globally installed Liftoff CLI, then inspect Liftoff core
+maintenance as a separate operation:
 
 ```bash
 liftoff upgrade --check
@@ -72,18 +72,15 @@ liftoff validate
 liftoff doctor
 ```
 
-Untouched managed files and new lockfiles can be updated automatically.
-Locally modified files remain conflicts unless explicitly reviewed with
-`liftoff update --force`. Liftoff never installs the updated project
-dependencies during `update`; run the generated `npm ci`, `uv sync --frozen`,
-or `go mod download` command afterward. CLI upgrade does not discover or modify
-the project.
-
-This baseline is a breaking release boundary: it raises the Node.js, Python, Go,
-and OpenTofu floors and includes major framework, provider, frontend, container,
-and dependency migrations. Commit or otherwise preserve local work, run
-`liftoff update --check`, and review every named upgrade and conflict before
-applying. Do not use an older Liftoff release as an automatic downgrade tool.
-After a successful update, recover unwanted changes through version control and
-then reinstall from the restored locks; Liftoff does not retain a post-success
-backup.
+Only explicit Liftoff core files are updated automatically. Package manifests,
+locks, runtime files, containers, and providers are project-owned after
+generation; ordinary update and force do not replace them. Liftoff also never
+installs project dependencies during update. CLI upgrade does not discover or
+modify the project.
+
+This baseline is a breaking generation boundary: it raises the Node.js, Python,
+Go, and OpenTofu floors and includes major framework, provider, frontend,
+container, and dependency migrations for new scaffolds. Existing production
+projects adopt those changes through separately reviewed project work, not
+`liftoff update` or `--force`. Do not use an older Liftoff release as an
+automatic downgrade tool.

package/docs/troubleshooting.md

@@ -138,25 +138,27 @@ Restore `liftoff.manifest.json` from version control or regenerate the project
 with the matching Liftoff version. Do not weaken path validation or retain a
 hand-edited unsafe path.
 
-## Update reports conflicts or orphans
+## Update reports managed-core conflicts or orphans
 
-`liftoff update` applies safe managed changes immediately and skips conflicts.
+`liftoff update` applies safe managed-core changes immediately and skips core
+conflicts.
 
 - Use `liftoff update --check` for a read-only human report or
   `liftoff update --check --json` for an automation drift gate.
-- Local or user-owned conflicts remain untouched by default.
+- 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
-  deciding that each overwrite is intended.
-- Orphans are never deleted automatically.
-- Update reports dependency-definition impact but does not install
-  dependencies.
+  deciding that each core overwrite is intended. Force cannot cross into
+  project files or component-provisioning collisions.
+- Managed-core orphans are never deleted automatically.
+- 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.
 
 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
-governance merely to make update pass. The schema-v5 manifest records
+governance merely to make update pass. The schema-v6 manifest records
 `handoff-partial` and no ownership entry for each preserved unrecorded conflict.
 Run `liftoff update --check` to inspect the remaining paths. Once each path is
 absent or matches the current artifact, plain update promotes the handoff to
@@ -165,6 +167,12 @@ managed handoff files into preserved orphans rather than deleting them; an
 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,
+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.
+
 ## Governance handoff exists but nothing is enforced
 
 That is the expected initial state. The manifest records `handoff-generated`,

package/docs/workloads.md

@@ -93,7 +93,7 @@ environment, API frontend, Docker, or OpenTofu selection.
 - React, Vite, TypeScript, Tailwind, and the Power Apps SDK and Vite plugin.
 - Locked root `package.json` and `package-lock.json`.
 - Project-local `power-apps` CLI supplied by the generated dependency graph.
-- `liftoff.config.json`, schema-v5 `liftoff.manifest.json`, starter provenance,
+- `liftoff.config.json`, schema-v6 `liftoff.manifest.json`, starter provenance,
   and third-party attribution.
 - Official OpenSpec or Spec Kit output and every selected agent marker.
 - The common local governance policy and selected-agent launcher, with backend,
@@ -131,11 +131,12 @@ created the application.
 
 ## Change workload later
 
-`liftoff update` reconciles supported desired-state changes within the recorded
-workload. It does not convert among GenAI, API, and Power Apps or change an API
-stack, GenAI pattern, or user-supplied starter identity. Initialize a fresh
-project or use a supported migration flow instead.
+`liftoff update` maintains explicit Liftoff core files and can provision a
+previously absent frontend or environment once after a corresponding desired
+state edit. It does not convert workloads, change API stacks or GenAI patterns,
+transition a Power Apps starter, or modernize production project templates.
 
-Plain update applies safe changes immediately for every workload. Use
-`liftoff update --check` for read-only inspection and review all reported
-conflicts before using `liftoff update --force`; orphans remain untouched.
+Plain update applies safe core changes immediately. Use `liftoff update
+--check` for read-only inspection. `--force` applies only to listed
+managed-core conflicts; project-owned source, dependencies, schemas,
+containers, environments, documentation, and infrastructure remain untouched.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@msn-control/liftoff",
-  "version": "0.9.0",
+  "version": "0.9.2",
   "description": "Interactive CLI for governed GenAI, API, and Power Apps code app projects.",
   "type": "module",
   "license": "GPL-3.0-only",