@msn-control/liftoff 0.8.0 → 0.9.1

package/docs/safety-and-consent.md

@@ -1,16 +1,19 @@
 # Safety and consent
 
-Liftoff separates project decisions, file replacement, workstation tools, and
-project dependencies. No one permission implies another.
+Liftoff separates project decisions, file replacement, workstation tools,
+global OpenSpec profile configuration, Copilot cloud setup, and project
+dependencies. No one permission implies another.
 
 ## Consent flags
 
 | Flag | Authorizes | Does not authorize |
 | --- | --- | --- |
-| `--yes` | Project defaults and plan confirmation | File replacement, machine installs, or project dependencies |
-| `--force` | During init, listed regular-file replacements; during update, exact reported conflicts | Manifest guards, symlinks, structural collisions, tools, dependencies, or non-empty migration targets |
-| `--install-tools` | Allowlisted workstation installation commands | Project decisions, overwrites, or project dependencies |
-| `--install-dependencies` | Locked project-local dependency commands after a successful merge | Machine tools, project decisions, or overwrites |
+| `--yes` | Project defaults and plan confirmation | File replacement, machine installs, global OpenSpec changes, Copilot cloud opt-in, or project dependencies |
+| `--force` | During init, listed regular-file replacements; during update, exact reported conflicts | Manifest guards, symlinks, structural collisions, tools, global profile changes, dependencies, or non-empty migration targets |
+| `--install-tools` | Allowlisted workstation installation commands | Project decisions, overwrites, global profile changes, or project dependencies |
+| `--configure-openspec-profile` | The displayed global OpenSpec workflow, delivery, and profile changes | Tools, project files, dependencies, or Copilot cloud opt-in |
+| `--copilot-cloud` / `--no-copilot-cloud` | Enable or disable OpenSpec's project-local hosted Copilot agent files | Global profile changes, tools, dependencies, or unrelated project writes |
+| `--install-dependencies` | Locked project-local dependency commands after a successful merge | Machine tools, global profile changes, project decisions, or overwrites |
 
 Interactive sessions ask separately at the point each permission is needed.
 
@@ -43,14 +46,16 @@ Initialization does not write generated files directly into the destination.
 Liftoff:
 
 1. Resolves and validates a project plan.
-2. Renders Liftoff-owned artifacts into a temporary staging directory.
-3. Runs the official OpenSpec or Spec Kit initializer in staging.
-4. Rejects nested Git metadata, unexpected framework roots, symlinks, and
+2. Verifies the OpenSpec global profile when OpenSpec is selected and separately
+   authorizes any required machine-wide change.
+3. Renders Liftoff-owned artifacts into a temporary staging directory.
+4. Runs the official OpenSpec or Spec Kit initializer in staging.
+5. Rejects nested Git metadata, unexpected framework roots, symlinks, and
    malformed output.
-5. Validates the full staged project.
-6. Computes one immutable destination preflight.
-7. Shows every different regular file that would be replaced.
-8. Applies only an authorized preflight.
+6. Validates the full staged project.
+7. Computes one immutable destination preflight.
+8. Shows every different regular file that would be replaced.
+9. Applies only an authorized preflight.
 
 Unrelated destination files are preserved.
 
@@ -73,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
@@ -89,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
 
@@ -123,6 +133,13 @@ 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.
 
+OpenSpec workflow profile and delivery are global machine preferences. Liftoff
+changes them only after dedicated consent and verifies the result before
+staging. That global choice is not part of the project-file transaction and is
+not automatically rolled back after a later failure. The Copilot cloud choice
+is separate, defaults off, and is persisted by OpenSpec in the generated
+project config.
+
 ## Telemetry boundary
 
 Liftoff sends only a recognized command name, CLI version, and zero/nonzero

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

@@ -9,10 +9,23 @@ Liftoff workload.
 
 OpenSpec 1.11.0 organizes proposed behavior changes as reviewable artifacts
 before implementation. Liftoff runs that pinned official initializer in
-temporary staging and passes every selected coding agent in stable order.
+temporary staging, passes every selected coding agent in stable order, and
+requires the complete custom profile with both skills and commands:
 
-Generated projects contain `openspec/` plus the selected agent integration
-markers.
+```text
+propose, explore, new, continue, apply, update,
+ff, sync, archive, bulk-archive, verify, onboard
+```
+
+OpenSpec stores profile and delivery preferences globally. Before creating an
+OpenSpec project, Liftoff reads that configuration through the pinned CLI. A
+matching custom/both profile proceeds without a prompt. A different profile is
+blocking until you separately approve the displayed global changes or pass
+`--configure-openspec-profile`. `--yes` and other consent flags do not authorize
+the machine-wide change.
+
+Generated projects contain `openspec/` plus all 12 official workflow skills and
+commands for each selected agent surface that supports them.
 
 ### Spec Kit
 
@@ -65,7 +78,18 @@ Framework files remain owned by the official initializer. Liftoff validates
 them but excludes framework-owned output from durable artifact hashes so a
 framework can manage its own lifecycle.
 
-Repository-governance launchers are separate durable Liftoff files at the exact
+To align an existing OpenSpec project, configure both delivery and all workflows:
+
+```bash
+openspec config profile
+openspec update
+```
+
+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 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
@@ -79,6 +103,21 @@ npm install -g @fission-ai/openspec@1.11.0
 uv tool install specify-cli==1.0.1
 ```
 
+## Optional GitHub Copilot cloud coding agent
+
+When OpenSpec and GitHub Copilot are selected, Liftoff asks whether to configure
+GitHub's hosted coding agent. This is separate from Copilot in an editor or
+terminal and defaults to No.
+
+Opting in writes official OpenSpec-owned files:
+
+- `.github/workflows/copilot-setup-steps.yml`
+- `.github/agents/openspec.agent.md`
+
+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
@@ -101,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

@@ -85,6 +85,43 @@ Review the complete replacement list. Approve interactively or rerun with
 manifest, or a non-empty migration target. Move or rename the structural
 conflict and retry.
 
+## OpenSpec global profile is incompatible
+
+Liftoff OpenSpec projects require profile `custom`, delivery `both`, and all 12
+OpenSpec 1.11 workflows. Review the observed and required values printed by
+Liftoff. Approve the separate interactive prompt or rerun the same command with
+`--configure-openspec-profile` only when the machine-wide change is intended.
+
+`--yes`, `--force`, `--install-tools`, and `--install-dependencies` do not
+authorize this change. If configuration or verification fails, run
+`openspec config list --json`, correct the reported OpenSpec issue, and retry
+before any project files are written.
+
+## OpenSpec wants to replace workflow files immediately
+
+A fresh Liftoff project should already contain all 12 workflows as skills and
+commands. Confirm that the same OpenSpec 1.11.0 binary, selected tools, global
+profile, delivery, and `githubCopilot.cloudAgent` choice are still in effect.
+
+For an older project, use:
+
+```bash
+openspec config profile
+openspec update
+```
+
+Select both delivery modes and every workflow. Do not use `liftoff update
+--force` to manage OpenSpec-owned skills or commands.
+
+## Copilot cloud-agent files are missing
+
+The GitHub-hosted coding agent is default-off and separate from Copilot in an
+editor or terminal. Opt in during new initialization with `--copilot-cloud`.
+For an existing project, set `githubCopilot.cloudAgent: true` in
+`openspec/config.yaml` and run `openspec update`. The expected files are
+`.github/workflows/copilot-setup-steps.yml` and
+`.github/agents/openspec.agent.md`.
+
 ## A handled write failed
 
 Liftoff reports whether rollback completed. Correct the filesystem problem and
@@ -101,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
@@ -128,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.8.0",
+  "version": "0.9.1",
   "description": "Interactive CLI for governed GenAI, API, and Power Apps code app projects.",
   "type": "module",
   "license": "GPL-3.0-only",