@msn-control/liftoff 0.8.0 → 0.9.1

package/dist/types.d.ts

@@ -115,6 +115,8 @@ export interface ProjectOptions {
     agents?: string[];
     defaultAgent?: string;
     codeAppsPlugin?: boolean;
+    copilotCloud?: boolean;
+    configureOpenSpecProfile?: boolean;
     governanceProfile?: string;
     configPath?: string;
     yes?: boolean;
@@ -156,6 +158,7 @@ export interface ProjectPlanBase {
     specWorkflow: SpecWorkflowDefinition;
     agents: CodingAgentDefinition[];
     defaultAgent?: CodingAgentDefinition;
+    copilotCloud: boolean;
     framework: FrameworkDefinition;
     governanceProfile: GovernanceProfileDefinition;
     approvedStack: string[];
@@ -165,18 +168,36 @@ export type GenAiProjectPlan = ProjectPlanBase & GenAiWorkloadPlan;
 export type StandardApiProjectPlan = ProjectPlanBase & StandardApiWorkloadPlan;
 export type ApiProjectPlan = GenAiProjectPlan | StandardApiProjectPlan;
 export type PowerAppsCodeAppProjectPlan = ProjectPlanBase & PowerAppsCodeAppWorkloadPlan;
-export interface GeneratedArtifact {
+export type ArtifactLifecycle = 'managed-core' | 'project' | 'desired-state' | 'framework' | 'seed' | 'manifest';
+export type ProjectProvisioningGroup = 'base' | 'frontend' | `environment:${EnvironmentId}` | 'power-apps-starter';
+interface GeneratedArtifactBase {
     logicalName: string;
     category: string;
     pathParts: string[];
     content: string;
 }
-export interface ManifestArtifact {
+export type GeneratedArtifact = (GeneratedArtifactBase & {
+    lifecycle: 'project';
+    provisioningGroup: ProjectProvisioningGroup;
+}) | (GeneratedArtifactBase & {
+    lifecycle: Exclude<ArtifactLifecycle, 'project'>;
+    provisioningGroup?: never;
+});
+export interface ManifestManagedArtifact {
     logicalName: string;
     category: string;
     pathParts: string[];
     contentHash: string;
 }
+export interface ManifestProjectArtifact {
+    logicalName: string;
+    category: string;
+    pathParts: string[];
+    generatedBy: string;
+    generationHash: string;
+    provisioningGroup: ProjectProvisioningGroup;
+}
+export type ManifestArtifact = ManifestManagedArtifact;
 export interface ManifestGenAiWorkload {
     kind: 'genai';
     apiStack: ApiStackId;
@@ -206,7 +227,7 @@ export interface ManifestGovernance {
     policyVersion?: string;
 }
 export interface LiftoffManifest {
-    artifactVersion: 2 | 3 | 4 | 5;
+    artifactVersion: 2 | 3 | 4 | 5 | 6;
     generatedBy: 'Mission Control Liftoff';
     liftoffVersion: string;
     project: {
@@ -222,7 +243,8 @@ export interface LiftoffManifest {
         contractVersion?: string;
     };
     governance: ManifestGovernance;
-    artifacts: ManifestArtifact[];
+    managedArtifacts: ManifestManagedArtifact[];
+    projectArtifacts: ManifestProjectArtifact[];
 }
 export interface ParsedArgs {
     command?: string;
@@ -230,3 +252,4 @@ export interface ParsedArgs {
     positional: string[];
     flags: Record<string, string | boolean | string[]>;
 }
+export {};

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 |
@@ -63,6 +63,8 @@ Common noninteractive inputs include:
 --default-agent copilot|claude
 --governance single-maintainer-gitflow|none
 --code-apps-plugin | --no-code-apps-plugin
+--copilot-cloud | --no-copilot-cloud
+--configure-openspec-profile
 ```
 
 Power Apps rejects API, pattern, cloud, region, frontend, and API environment
@@ -73,6 +75,17 @@ Repository governance defaults to `single-maintainer-gitflow`. It generates a
 local policy handoff only; `none` omits it. See
 [repository governance](repository-governance.md).
 
+OpenSpec projects use all 12 OpenSpec 1.11 workflows with both skills and
+commands. `--copilot-cloud` opts into the GitHub-hosted coding-agent workflow and
+agent definition; omission and `--no-copilot-cloud` keep it disabled.
+
+OpenSpec stores workflow profile and delivery globally. If the observed profile
+does not match Liftoff's complete contract, interactive runs request separate
+consent. Noninteractive `init` and `migrate` require
+`--configure-openspec-profile` to authorize the displayed
+`openspec config set` commands. The flag has no effect during `plan`, which
+never inspects or changes machine configuration.
+
 ## CLI upgrade modes
 
 ```bash
@@ -119,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
 
@@ -173,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.
 
@@ -181,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

@@ -42,12 +42,13 @@ from unexpectedly treating that subdirectory as the repository root.
 Liftoff never blindly replaces a target tree. It:
 
 1. Renders Liftoff-owned files in temporary staging.
-2. Runs the official OpenSpec or Spec Kit initializer in staging.
-3. Rejects unexpected roots, nested Git metadata, and unsafe paths.
-4. Compares every destination before writing.
-5. Lists different regular files as one replacement set.
-6. Requires explicit overwrite permission before replacing that set.
-7. Applies the authorized merge transactionally and rolls back handled
+2. Verifies or separately configures the required global OpenSpec profile.
+3. Runs the official OpenSpec or Spec Kit initializer in staging.
+4. Rejects unexpected roots, nested Git metadata, and unsafe paths.
+5. Compares every destination before writing.
+6. Lists different regular files as one replacement set.
+7. Requires explicit overwrite permission before replacing that set.
+8. Applies the authorized merge transactionally and rolls back handled
    failures.
 
 Unrelated existing files are preserved. Structural collisions, symlinks,
@@ -69,31 +70,44 @@ 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`.
 
-Projects created before manifest schema v5 automatically preview the default
+OpenSpec skills and commands remain framework-owned. To give an existing
+project all 12 workflows as both skills and commands, run:
+
+```bash
+openspec config profile
+openspec update
+```
+
+Select both delivery modes and every workflow in the profile picker. Plain
+`liftoff update` does not regenerate OpenSpec integrations. To change the
+hosted Copilot agent later, update `githubCopilot.cloudAgent` through OpenSpec
+and run `openspec update`.
+
+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
 
@@ -105,8 +119,9 @@ liftoff migrate ../legacy-app --region eastus --agents copilot,claude --yes
 ```
 
 Migration requires a new or empty sibling target, runs the same readiness and
-framework pipeline, and leaves the source byte-for-byte unchanged. `--force`
-does not permit a non-empty migration target.
+framework pipeline, including separate global OpenSpec profile authorization,
+and leaves the source byte-for-byte unchanged. `--force` does not permit a
+non-empty migration target.
 
 Arbitrary existing Power Apps application migration is not currently
 supported.

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.
 
@@ -54,13 +55,18 @@ The guided flow asks for:
 4. OpenSpec or Spec Kit.
 5. One or both coding agents. On a real TTY, Space toggles agents and Enter
    confirms the selection.
-6. A Spec Kit default agent when both agents are selected.
-7. The optional Preview Code Apps plugin preference for Power Apps projects.
-8. Plan confirmation, workstation readiness, and any separate install or
+6. Whether to configure the default-off GitHub-hosted Copilot coding agent when
+   OpenSpec and GitHub Copilot are selected.
+7. A Spec Kit default agent when both agents are selected.
+8. The optional Preview Code Apps plugin preference for Power Apps projects.
+9. Plan confirmation, workstation readiness, and any separate install or
    overwrite permissions that are needed.
 
 Liftoff renders into temporary staging, runs the official framework initializer
 there, validates the complete result, and only then merges it into the target.
+OpenSpec projects use all 12 OpenSpec 1.11 workflows as both skills and commands.
+If the global OpenSpec profile differs, Liftoff displays the exact global change
+and asks separately before staging.
 Governance activation is a later selected-agent action after commit and push;
 see [repository governance](repository-governance.md).
 
@@ -110,8 +116,12 @@ liftoff plan --type power-apps-code-app --spec openspec --agents copilot
 
 Automation can pass the same options to `liftoff init`. Use `--yes` for project
 defaults and confirmation only. It does not authorize file replacement,
-machine-level tools, or project dependency installation. Those permissions
-remain independent.
+machine-level tools, global OpenSpec profile changes, Copilot cloud opt-in, or
+project dependency installation. Those permissions remain independent.
+
+Use `--configure-openspec-profile` only after reviewing the machine-wide change.
+Use `--copilot-cloud` to opt into the hosted agent or `--no-copilot-cloud` to
+record the safe default explicitly.
 
 See the [CLI reference](cli-reference.md) and
 [safety and consent](safety-and-consent.md) before automating initialization.

package/docs/prerequisites.md

@@ -29,6 +29,7 @@ Blocking checks must be ready before initialization can safely complete:
 - Required runtime and minimum version.
 - Selected spec framework CLI.
 - Every selected coding agent.
+- For OpenSpec, global profile `custom`, delivery `both`, and all 12 workflows.
 
 Advisory checks describe useful but deferrable capabilities:
 
@@ -69,6 +70,22 @@ An install that changes `PATH` is re-probed when possible and may require a new
 terminal. Do not treat installer success as readiness until the corresponding
 probe passes.
 
+## OpenSpec global profile consent
+
+OpenSpec 1.11 stores workflow selection and delivery globally rather than in a
+project. Liftoff requires all workflows with both skills and commands so a fresh
+project does not immediately drift when OpenSpec is rerun.
+
+Profile inspection is read-only. When the profile differs, interactive runs
+show the observed values, required values, and exact `openspec config set`
+commands before asking. Noninteractive runs stop unless
+`--configure-openspec-profile` is present. This authorization is independent of
+`--yes`, `--force`, and tool or dependency installation.
+
+The authorized change is verified before project staging. Because it is a
+machine-wide user preference, Liftoff reports it separately and does not restore
+an older profile if a later project phase fails.
+
 ## Project dependency consent
 
 Project-local dependency setup is separate from workstation tools and requires

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
@@ -34,6 +39,10 @@ project/
 |       `-- azure/
 |           `-- .terraform.lock.hcl
 |-- openspec/ or .specify/
+|-- .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
+|-- .github/agents/openspec.agent.md                       # optional hosted agent
 |-- .github/prompts/liftoff-repository-governance.prompt.md
 |   or .claude/commands/liftoff-repository-governance.md
 |-- frontend/                  # only when selected
@@ -63,6 +72,9 @@ project/
   state configuration, and a remote-state example.
 - `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
+  for supported selected-agent surfaces. The two hosted Copilot agent files are
+  generated only after explicit opt-in.
 
 ### Conditional areas
 

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`.