@mriekki/lean 0.1.1 → 0.2.1

package/README.md

@@ -4,13 +4,15 @@
 
 Canonical engineering remains in the private platform repositories. Before publication, a deterministic assembly step verifies exact pinned source commits and distribution descriptors, then copies only those approved consumer mappings into the npm payload. Each published npm release is therefore self-contained; consumers do not need access to the canonical repositories to install or update Lean assets.
 
-## V0.1 profile
+## Current `greenfield-poc` profile
 
-The initial `greenfield-poc` profile bundles:
+The current profile bundles:
 
-- Lean Agentic Core `1.10.0` from commit `e2d64b10f1a30507471755339c20e8b58e62be16`, distribution `greenfield-workspace`;
+- Lean Agentic Core `1.11.1` from commit `e3a8a994d1e95923d629af7640d3b3a0a4f098d4`, distribution `greenfield-workspace`;
 - Lean POC Deployment Kit commit `4c23140576b39608a3ef285cad4abe53dccb9c47`, distribution `greenfield-poc`.
 
+Core `1.11.1` tightens `/lean-update` for Bootstrap-generated package-managed consumers: it keeps `POC_BOOTSTRAP.json`, umbrella/component baselines, exact registry integrity, and generated package-verification surfaces coherent while retaining `/core-sync` as the compatibility/router path for component-only Core consumers.
+
 ## Developer experience
 
 Preview/install:
@@ -27,6 +29,8 @@ Update using the newest published package:
 npx @mriekki/lean@latest update
 ```
 
+For reviewed maintenance operations, prefer resolving and using one exact package version for preview, apply, and final check rather than allowing a moving `@latest` reference to change between those steps.
+
 Inspect or verify:
 
 ```powershell
@@ -47,7 +51,7 @@ The umbrella package writes `LEAN_BASELINE.json` while preserving component-nati
 
 ## Current scope
 
-V0.1 intentionally starts with the greenfield POC consumer profile. Existing-repository Adoption Kit packaging can be added as another profile without changing the one-package developer experience.
+The package currently starts with the `greenfield-poc` consumer profile. Existing-repository Adoption Kit packaging can be added as another profile without changing the one-package developer experience.
 
 ## Package assembly and release
 
@@ -62,6 +66,6 @@ node .\scripts\prepare-release.mjs `
 
 Release preparation verifies exact `origin/main`, runs the complete test suite, refuses dirty canonical source checkouts, assembles and verifies the pinned assets, compares two independent `npm pack` SHA-256 values, and smoke-tests the packed CLI from a clean temporary install. The resulting tarball and `RELEASE_MANIFEST.json` are written under `dist/release/`.
 
-The first npm version is staged manually and requires explicit 2FA approval before it becomes public. After the bootstrap version exists, `.github/workflows/npm-stage.yml` can use npm Trusted Publishing (OIDC) to stage future versions without a long-lived npm publish token; human 2FA approval remains the final publication gate.
+The first npm version was staged manually and required explicit 2FA approval before becoming public. Current releases use `.github/workflows/npm-stage.yml` with npm Trusted Publishing (OIDC) to stage future versions without a long-lived npm publish token; human 2FA approval remains the final publication gate.
 
 See `docs/RELEASE_PROCESS.md` for the full release contract.

package/assets/components.json

@@ -1,7 +1,7 @@
 {
   "schemaVersion": 1,
   "package": "@mriekki/lean",
-  "version": "0.1.1",
+  "version": "0.2.1",
   "defaultProfile": "greenfield-poc",
   "profiles": {
     "greenfield-poc": {
@@ -14,8 +14,8 @@
   "components": {
     "core": {
       "repository": "mriekki/lean-agentic-core",
-      "commit": "e2d64b10f1a30507471755339c20e8b58e62be16",
-      "version": "1.10.0",
+      "commit": "e3a8a994d1e95923d629af7640d3b3a0a4f098d4",
+      "version": "1.11.1",
       "distribution": "greenfield-workspace",
       "descriptor": "assets/core/distribution.json",
       "sourceRoot": "assets/generated/core",

package/assets/core/distribution.json

@@ -16,6 +16,7 @@
     {"source":"core/skills/deliver/SKILL.md","destination":".github/skills/deliver/SKILL.md"},
     {"source":"core/skills/cleanup-branches/SKILL.md","destination":".github/skills/cleanup-branches/SKILL.md"},
     {"source":"core/skills/pull-latest/SKILL.md","destination":".github/skills/pull-latest/SKILL.md"},
+    {"source":"core/skills/lean-update/SKILL.md","destination":".github/skills/lean-update/SKILL.md"},
     {"source":"core/skills/core-sync/SKILL.md","destination":".github/skills/core-sync/SKILL.md"},
     {"source":"core/skills/upstream-fix/SKILL.md","destination":".github/skills/upstream-fix/SKILL.md"},
     {"source":"core/skills/wait-what/SKILL.md","destination":".github/skills/wait-what/SKILL.md"},

package/assets/generated/ASSEMBLY.json

@@ -1,12 +1,12 @@
 {
   "schemaVersion": 1,
   "package": "@mriekki/lean",
-  "version": "0.1.1",
+  "version": "0.2.1",
   "components": {
     "core": {
       "repository": "mriekki/lean-agentic-core",
-      "commit": "e2d64b10f1a30507471755339c20e8b58e62be16",
-      "version": "1.10.0",
+      "commit": "e3a8a994d1e95923d629af7640d3b3a0a4f098d4",
+      "version": "1.11.1",
       "distribution": "greenfield-workspace",
       "files": [
         {
@@ -79,15 +79,20 @@
           "destination": ".github/skills/pull-latest/SKILL.md",
           "sha256": "d49321859fe37afeb5d9e0b39ceac3d8a6709f6e02efd19b6cac37842fe3aa37"
         },
+        {
+          "source": "core/skills/lean-update/SKILL.md",
+          "destination": ".github/skills/lean-update/SKILL.md",
+          "sha256": "8b4bce53b109a5959e862924b0a4afd931233a5094a1aef43c2f3672199108bb"
+        },
         {
           "source": "core/skills/core-sync/SKILL.md",
           "destination": ".github/skills/core-sync/SKILL.md",
-          "sha256": "6b2393639f3cc0581bed0df8667fc67691ae915d137b9f070c60bbdb042148a6"
+          "sha256": "0c1bfbc7678f5ae3239dd2900a12e75584035a5338474181dbd81cb1a0813531"
         },
         {
           "source": "core/skills/upstream-fix/SKILL.md",
           "destination": ".github/skills/upstream-fix/SKILL.md",
-          "sha256": "26d979b8876db4031f7e95887ab16a7c530d1fcd60043410ed8d20c4ea5f5301"
+          "sha256": "d6b77eee298bf387e20156c6ff7b3904e3f925873699f7e1071515d9d69c2f03"
         },
         {
           "source": "core/skills/wait-what/SKILL.md",
@@ -102,7 +107,7 @@
         {
           "source": "core/skills/deploy/SKILL.md",
           "destination": ".github/skills/deploy/SKILL.md",
-          "sha256": "57fca71a95a32f4dd17ed3fba13b9b1ccbd644082de175622960d9c65aaa47a0"
+          "sha256": "e9dcf7232505d684c1d8f39b0937c5026223e745df023c84295457e22da1b52a"
         },
         {
           "source": "core/skills/tear-down/SKILL.md",

package/assets/generated/core/core/skills/core-sync/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: core-sync
-description: Guided Core-to-consumer synchronization that uses a safe local Core checkout when available and otherwise uses configured remote orchestration without requiring a Core clone.
+description: Compatibility Core-to-consumer synchronization for component-only consumers; package-managed consumers are routed to /lean-update so umbrella and component baselines remain coherent.
 argument-hint: "[optional local Core path]"
 user-invocable: true
 disable-model-invocation: true
@@ -8,55 +8,74 @@ disable-model-invocation: true
 
 # Core Sync
 
-`/core-sync` updates a consumer repository to a newer accepted Lean Agentic Core baseline while preserving consumer-owned content and the Human-in-the-Loop delivery boundary.
+`/core-sync` is the compatibility synchronization path for consumers that are managed directly by `CORE_BASELINE.json` **without** an umbrella `LEAN_BASELINE.json`.
 
-A local Core checkout is an optimization, not a prerequisite. Do not clone Core merely to satisfy `/core-sync`.
+For package-managed consumers, `/lean-update` is authoritative.
 
-Invocation starts read-only. One explicit sync choice may authorize the bounded mechanics needed for the selected local or remote path; merge/final acceptance remains separate.
+Invocation starts read-only. Direct component synchronization must never make a package-managed consumer disagree with its recorded Lean package provenance.
 
-## 1. Establish the consumer baseline
+## 1. Classify the consumer before doing anything else
 
-From the consumer repository, read:
+From the consumer repository read, when present:
 
-- `CORE_BASELINE.json`,
-- `.github/lean-workspace.json` when present,
-- `.github/lean-core-sync.json` when present,
+- `LEAN_BASELINE.json`;
+- `CORE_BASELINE.json`;
+- `.github/lean-workspace.json`;
+- `.github/lean-core-sync.json`;
 - current Git status, branch, remotes, and default branch when observable.
 
+### Package-managed consumer
+
+If `LEAN_BASELINE.json` exists:
+
+```text
+PACKAGE-MANAGED LEAN CONSUMER
+Direct Core sync: NOT PERMITTED
+Next: /lean-update
+```
+
+Stop before refreshing a Core checkout, running `tools/package/sync.py`, creating a sync branch, or sending a remote `[sync-core]` request.
+
+The umbrella package updates Core and Deployment components together and refreshes `LEAN_BASELINE.json`, `CORE_BASELINE.json`, and `DEPLOYMENT_BASELINE.json` coherently. A Core-only sync would bypass that contract.
+
+### Component-only Core consumer
+
+If `LEAN_BASELINE.json` is absent and a valid `CORE_BASELINE.json` exists, continue with the compatibility path below.
+
+If neither baseline exists, report `CORE SYNC BLOCKED`; do not invent provenance or initialize a consumer implicitly.
+
+## 2. Establish the component-only Core baseline
+
 Run the repository-local integrity check before planning an update:
 
 ```text
 python tools/lean-core/check-core-baseline.py --root .
 ```
 
-Stop if the current managed overlay already has unexplained local drift, missing managed files, or invalid baseline metadata. Do not treat consumer edits as disposable.
+Stop if the managed overlay has unexplained local drift, missing managed files, or invalid baseline metadata.
 
 Resolve from `CORE_BASELINE.json`:
 
-- canonical Core repository,
-- currently accepted Core commit/version,
-- distribution name,
+- canonical Core repository;
+- currently accepted Core commit/version;
+- distribution name;
 - managed-path ownership/hashes.
 
-## 2. Resolve the Core source automatically
+## 3. Resolve the Core source safely
 
 Check local candidates in this order:
 
-1. an explicit Core path supplied by the human,
-2. an already-open workspace folder that unambiguously resolves to the recorded Core repository,
+1. an explicit Core path supplied by the human;
+2. an already-open workspace folder that unambiguously resolves to the recorded Core repository;
 3. the sibling checkout derived from the Core repository name, normally `../lean-agentic-core`.
 
-Do not broadly scan the developer's filesystem.
-
-A local candidate is usable only when:
+Do not broadly scan the filesystem. A local Core checkout is an optimization, not a prerequisite.
 
-- it is a Git repository,
-- its configured remote resolves to the Core repository recorded in `CORE_BASELINE.json`,
-- its repository state can be inspected safely.
+A local candidate is usable only when it is the recorded Git repository and its state can be inspected safely.
 
-If no usable local Core checkout exists, use the configured remote provider from `.github/lean-core-sync.json` when available. Do not ask the developer to clone Core just because the local candidate is absent.
+If no usable local Core checkout exists, use the configured remote provider from `.github/lean-core-sync.json` when available. Do not ask the developer to clone Core merely to satisfy `/core-sync`.
 
-## 3. Classify a local Core checkout
+## 4. Classify a local Core checkout
 
 Before modifying a local Core checkout inspect:
 
@@ -67,49 +86,35 @@ git -C <core-path> remote -v
 git -C <core-path> branch -vv
 ```
 
-A local Core checkout may be automatically refreshed only when all of these are true:
-
-- the worktree is clean,
-- no merge/rebase/cherry-pick is in progress,
-- the checkout is on its normal accepted/default branch,
-- an unambiguous upstream exists,
-- updating can be performed fast-forward-only.
+It may be refreshed automatically only when clean, on its normal accepted/default branch, backed by an unambiguous upstream, and fast-forward-safe.
 
 Never auto-stash, merge, rebase, reset, clean, force-update, or discard Core work.
 
-If the local Core checkout is dirty, ahead, diverged, on an intentional non-default ref, or otherwise ambiguous, preserve it unchanged. When a remote provider is configured, prefer the remote path for the consumer update. Otherwise stop with the observed local state and the missing capability; do not silently use an unaccepted local ref.
-
-## 4. Present one bounded sync choice
+If the checkout is dirty, ahead, diverged, intentionally pinned, or ambiguous, preserve it unchanged and prefer the configured remote provider when available.
 
-### Safe local Core available
+## 5. Present one bounded compatibility-sync choice
 
-Present:
+For a safe local source:
 
 ```text
-CORE SYNC READY
+CORE COMPATIBILITY SYNC READY
 
 Consumer baseline: <commit/version>
 Source: LOCAL <core-path>
-Local Core state: CURRENT | FAST-FORWARDABLE
 Distribution: <distribution>
 
-1. Sync to the accepted Core source [GIT + FILE WRITE] — recommended
+1. Sync the component-only Core baseline [GIT + FILE WRITE] — recommended
 2. Keep inspecting only [READ ONLY]
 3. Stop [NO ACTION]
 ```
 
-Choosing option 1 authorizes only the bounded local-sync mechanics described below: safe Core refresh if needed, consumer sync-branch setup, safe Core overlay application, and verification. It does not authorize `/deliver`, merge, release publication, or production deployment.
-
-### No safe local Core available, remote provider configured
-
-Present:
+For a configured remote source:
 
 ```text
-CORE SYNC READY
+CORE COMPATIBILITY SYNC READY
 
 Consumer baseline: <commit/version>
 Source: REMOTE PROVIDER
-Local Core: NOT REQUIRED
 Provider: <provider repository>
 
 1. Request remote Core sync [REMOTE WRITE] — recommended
@@ -117,70 +122,35 @@ Provider: <provider repository>
 3. Stop [NO ACTION]
 ```
 
-Choosing option 1 authorizes creation of exactly the configured remote sync request for this consumer. It does not authorize merging the resulting consumer PR.
+The selected choice does not authorize merge, release publication, or deployment.
 
-### Neither source is usable
+## 6. Local compatibility path
 
-Report `CORE SYNC BLOCKED` with the evidence. A missing local Core checkout by itself is not an error; the blocker is the absence of both a safe local source and a configured/usable remote provider.
+After local option 1 is selected:
 
-## 5. Local sync path
-
-After option 1 is selected:
-
-1. Refresh the local Core remote state.
+1. Refresh Core remote state.
 2. Reclassify the accepted/default Core branch.
-3. If behind and fast-forward-safe, update using the equivalent of:
-
-```text
-git -C <core-path> pull --ff-only
-```
-
-4. If Core is ahead, diverged, dirty, or otherwise unsafe after refresh, stop without changing the consumer and prefer the configured remote provider when available.
-5. Run a Core sync preview from the refreshed checkout using the distribution recorded by the consumer baseline.
-6. Stop without apply on any unsafe sync state, including `LOCAL_DRIFT`, `CONFLICT`, `LOCAL_MISSING`, `UNTRACKED_CONFLICT`, or an unaccepted `RETIRED_PATH`.
-7. If the consumer is on its default branch, create/switch to a repository-appropriate short-lived chore branch such as `chore/sync-core-<version-or-short-sha>`. This branch setup is routine inside the selected bounded sync action.
-8. Apply only the safe Core additions/updates and refresh `CORE_BASELINE.json` using Core's canonical `tools/package/sync.py` contract.
+3. Fast-forward it only when safe.
+4. Run canonical Core sync preview using the distribution recorded by the baseline.
+5. Stop on `LOCAL_DRIFT`, `CONFLICT`, `LOCAL_MISSING`, `UNTRACKED_CONFLICT`, or an unaccepted `RETIRED_PATH`.
+6. If the consumer is on its default branch, create/switch to a short-lived branch such as `chore/sync-core-<version-or-short-sha>`.
+7. Apply only safe Core additions/updates and refresh `CORE_BASELINE.json` using canonical `tools/package/sync.py`.
 
-Do not manually copy individual managed files as a substitute for the canonical sync tool.
+Do not manually copy managed files as a substitute for the canonical tool.
 
-## 6. Remote sync path
+## 7. Remote compatibility path
 
-Remote orchestration is consumer configuration, not a hardcoded Core service. Read `.github/lean-core-sync.json` and require:
-
-```json
-{
-  "schemaVersion": 1,
-  "remote": {
-    "type": "github-issue-control-plane",
-    "repository": "owner/control-plane-repo",
-    "titleTemplate": "[sync-core] {owner}/{repository}",
-    "requireEmptyBody": true
-  }
-}
-```
+Remote orchestration is consumer configuration. Read `.github/lean-core-sync.json` and require its configured provider contract, for example `github-issue-control-plane` with an owner/repository title template and an empty body.
 
-Only the placeholders `{owner}` and `{repository}` may be substituted in `titleTemplate`. Resolve them from the consumer's canonical GitHub remote. Do not put product requirements, baseline JSON, source code, secrets, or other private consumer details into the public request.
+Create exactly the configured request. Do not put product requirements, baseline JSON, source code, secrets, or other private consumer details into a public request.
 
-For `github-issue-control-plane`, create exactly one issue in the configured provider repository using the rendered title and an empty body. Use the environment's normal GitHub integration or CLI; never request or expose a long-lived Core credential merely to make the request.
+The provider is expected to validate target authorization, obtain its own short-lived credentials, run canonical Core sync, refuse unsafe drift/conflicts, publish a short-lived consumer branch/PR, and observe consumer CI.
 
-The remote provider is expected to:
+If the provider cannot satisfy that contract, report `REMOTE SYNC UNAVAILABLE`; do not silently clone Core or invent another synchronization mechanism.
 
-- validate requester/target authorization,
-- obtain its own short-lived source/target credentials,
-- resolve the accepted Core source,
-- run the canonical Core sync contract against the target consumer,
-- refuse unsafe consumer drift/conflicts,
-- update exact Core provenance,
-- publish the result on a short-lived consumer branch and PR,
-- run/observe consumer CI.
+## 8. Verification
 
-If the configured provider does not support that contract, report `REMOTE SYNC UNAVAILABLE`; do not silently clone Core or invent a different synchronization mechanism.
-
-## 7. Verification
-
-### Local path
-
-After apply, run:
+For a local apply run:
 
 ```text
 python tools/lean-core/check-core-baseline.py --root .
@@ -189,32 +159,20 @@ git diff --stat
 git diff -- CORE_BASELINE.json
 ```
 
-Confirm:
-
-- managed paths match the refreshed hashes,
-- consumer-owned paths were not overwritten,
-- the baseline records the exact Core commit actually applied,
-- only the intended sync branch changed.
-
-Present the meaningful diff for human review. After acceptance, recommend `/deliver` for normal commit/push/PR/CI mechanics.
-
-### Remote path
-
-Observe the provider result when available. Report the target branch/PR and exact Core commit applied. The human reviews the consumer PR and retains the normal explicit merge/finalize gate.
+Confirm exact Core provenance, managed hashes, consumer-owned preservation, and intended branch scope. Present the meaningful diff and recommend `/deliver` after human acceptance.
 
-If the developer has a local consumer checkout, remind them to use `/pull-latest` after the remote sync PR is merged when their local working state is safe. Do not overwrite unrelated local work.
+For a remote path, report the resulting PR and exact Core commit when observed. Merge remains the normal explicit final gate.
 
-## 8. Boundaries
+## 9. Boundaries
 
 `/core-sync` never:
 
-- requires a local Core clone when a configured remote provider can perform the update,
-- modifies a dirty/diverged/intentional local Core checkout automatically,
-- uses merge/rebase/reset/force operations to refresh Core,
-- treats managed consumer drift as disposable,
-- overwrites consumer-owned paths merely because Core has a similarly named destination,
-- publishes a Core release/tag,
-- merges the consumer sync PR without the normal explicit final gate,
+- directly synchronizes Core when `LEAN_BASELINE.json` exists;
+- uses direct Core sync as a substitute for `/lean-update`;
+- modifies ambiguous local Core state;
+- treats managed consumer drift as disposable;
+- publishes Core or Lean package releases/tags;
+- merges the consumer sync PR;
 - deploys production.
 
-If reusable Core content itself is wrong, fix Core canonically instead of forking the reusable file in the consumer.
+If reusable Core behavior itself is wrong, fix Core canonically through `/upstream-fix`; then adopt it through the update channel appropriate to the consumer's provenance model.

package/assets/generated/core/core/skills/deploy/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: deploy
-description: "Guided deployment orchestration for a configured named environment. Selects and verifies the environment/target, preserves production gates, and delegates deterministic execution to repository-provided platform scripts."
+description: "Guided deployment orchestration for a configured named environment. Verifies package/deployment provenance, selects the exact target/artifact, preserves tool-specific authorization, and delegates deterministic execution to repository-provided deployment tooling."
 argument-hint: "[environment] [release-or-artifact]"
 user-invocable: true
 disable-model-invocation: true
@@ -10,59 +10,50 @@ disable-model-invocation: true
 
 `/deploy` is the normal human-facing deployment interface once deployment engineering and the selected environment are ready.
 
-The skill owns interaction, validation, target safety, and authorization. Repository-provided scripts own deployment mechanics.
+Core owns interaction, validation, target safety, and Human-in-the-Loop authorization. Repository-provided deployment tooling owns deployment mechanics.
 
-Do not implement application deployment logic directly in the skill when an approved repository script exists.
+Do not implement Docker, SSH, route, migration, or application deployment logic directly in this skill when an approved repository command exists.
 
-## 1. Begin read-only
+## 1. Begin read-only and establish provenance
 
 Invocation starts read-only.
 
 Read only the minimum repository context needed to identify:
 
-- the approved deployment/release requirements,
-- configured named deployment environments,
-- checkout-local environment-to-target bindings when the project uses them,
-- the selected environment's readiness evidence,
-- the approved release/artifact policy,
-- repository-provided deployment entry points,
+- `LEAN_BASELINE.json` when the repository is package-managed;
+- `DEPLOYMENT_BASELINE.json` when present;
+- approved deployment/release requirements;
+- configured named environments and checkout-local target bindings;
+- selected environment readiness evidence;
+- approved release/artifact policy;
+- repository-provided deployment entry point and its authorization contract;
 - expected developer-workstation and target operating systems.
 
-Do not assume configuration file names, script paths, target OS, SSH aliases, container runtime, or release format unless the repository establishes them.
+Do not assume configuration filenames, target OS, SSH aliases, container runtime, or release format unless the repository establishes them.
 
-If deployment engineering is not delivered or the selected environment is not operationally ready, stop and route to the repository's deployment work item or `/production-readiness` as appropriate.
-
-## 2. Select an environment explicitly
-
-If the invocation did not name an environment, enumerate only environments configured for this checkout and ask the human to select one.
-
-Show enough non-secret identity to distinguish them, for example:
+When `DEPLOYMENT_BASELINE.json` identifies the standard Lean POC Deployment Kit and its generated entry point exists, prefer the repository-distributed interface such as:
 
 ```text
-SELECT DEPLOYMENT ENVIRONMENT
+tools/lean-deployment/lean-poc-deploy.py
+```
 
-1. staging
-   Role: non-production
-   Target: portable-ubuntu
-   [REMOTE WRITE]
+over reconstructing Deployment Kit commands by hand or requiring a separate Kit checkout.
 
-2. production
-   Role: production
-   Target: home-production
-   [PRODUCTION WRITE]
+If package/component baseline integrity is already known to be drifted, or deployment engineering/readiness is incomplete, stop and route to `/lean-update`, `/upstream-fix`, the deployment work item, or `/production-readiness` as appropriate.
 
-3. Stop
-```
+## 2. Select an environment explicitly
 
-Environment names and target labels above are examples only.
+If the invocation did not name an environment, enumerate only environments configured for this checkout and ask the human to select one.
+
+Show enough non-secret identity to distinguish them.
 
 Rules:
 
 - never silently default to `production`;
 - never use a remembered prior selection as implicit production authorization;
 - never fall back from one environment to another because discovery, access, readiness, or deployment failed;
-- if an environment is named but is not configured in this checkout, fail explicitly;
-- selecting an environment chooses scope but does not itself authorize the deployment write.
+- if a named environment is not configured, fail explicitly;
+- selecting an environment chooses scope but does not authorize the deployment write.
 
 ## 3. Resolve and verify the target binding
 
@@ -78,66 +69,61 @@ named environment
 
 Address discovery is not host trust.
 
-Before a remote deployment:
+Before remote deployment:
 
 - verify the selected environment resolves to its configured target;
-- use the repository-approved stable target/SSH alias rather than a hard-coded transient address when that is the approved design;
-- preserve enrolled SSH host-key verification independently of the current IP address;
-- stop on an unknown host identity or changed host key;
+- use the repository-approved stable logical target rather than a guessed transient address;
+- preserve enrolled host-key verification independently of current IP;
+- stop on unknown/changed host identity;
 - never bypass host-key checks, silently enroll new trust, scan/select another host, or weaken network controls as recovery;
-- verify the actual target OS is compatible with the environment's approved expected target OS before choosing target-specific deployment behavior.
+- verify actual target OS compatibility before target-specific behavior.
 
-Changing an environment's bound target is configuration/readiness work, not a deployment fallback. Stop and route to the approved rebind/readiness workflow when rebinding is needed.
+Changing an environment's target is readiness/configuration work, not deployment fallback.
 
 Keep private keys, passphrases, credentials, copied trust databases, and other secret values out of repository configuration and logs.
 
-## 4. Select the local launcher by developer workstation OS
+## 4. Resolve the repository-provided launcher
 
-Use repository-provided platform-appropriate deployment entry points.
+Prefer the canonical repository-provided deployment interface established by the current deployment baseline.
 
-Typical dispatch is:
+For package-generated Deployment Kit consumers this normally means the generated Python entry point plus its distributed modules. Do not require a sibling Deployment Kit clone for normal deployment.
 
-```text
-Windows developer workstation → approved PowerShell deployment entry point
-macOS/Linux developer workstation → approved shell deployment entry point
-```
+A repository may additionally provide PowerShell/shell wrappers. Use them only when the repository defines them as the approved interface or when they intentionally wrap the same deterministic contract.
 
-The repository may define different supported launchers. Follow its contract rather than inventing a path.
+Launcher choice may depend on developer workstation OS; target behavior depends on selected target OS. Do not confuse those dimensions.
 
-The launcher choice is based on the developer workstation OS. Target-specific behavior is based on the selected environment's approved target OS. Do not confuse those two dimensions.
+If the approved launcher is absent, locally drifted, or unsupported on the current workstation/target, stop rather than inventing deployment mechanics.
 
-If the developer workstation or target OS is unsupported by the repository's approved deployment implementation, stop with a clear blocker.
+## 5. Resolve release/artifact identity
 
-## 5. Preserve one deployment contract across launchers
+Use the repository's approved policy for the selected environment.
 
-Where a repository provides multiple local launchers, they must preserve equivalent deployment semantics and safety behavior.
+For production require the approved formal release/artifact evidence, including immutable identity when required.
 
-Prefer a common logical contract such as:
+For non-production, use only the broader artifact policy explicitly allowed by the repository. Do not invent relaxed staging semantics.
 
-```text
-environment
-release/version or artifact identity
-immutable digest when required
-dry-run/check mode when supported
-```
+When promoting a tested artifact to production, prefer the exact same immutable artifact/digest rather than rebuilding it.
 
-Do not pass secret values on command lines merely to make launchers symmetric. Use the repository's approved protected credential mechanism.
+## 6. Preserve the deployment tool's exact authorization contract
 
-Environment-specific values are configuration, not reasons to duplicate otherwise equivalent deployment procedures.
+Core may describe consequence classes using labels such as `[REMOTE WRITE]` and `[PRODUCTION WRITE]`, but those labels do not replace a stricter exact authorization phrase required by the repository-provided deployment tool.
 
-## 6. Resolve release/artifact identity
+For example, the standard Deployment Kit may require operation-specific phrases such as:
 
-Use the repository's approved policy for the selected environment.
+```text
+[APP DEPLOY WRITE]
+[PRODUCTION APP DEPLOY]
+```
 
-For a production-role environment, require the approved formal release/artifact evidence, including immutable identity when the project requires it.
+The exact phrase must be resolved from the installed repository/tool contract. Do not hardcode an example phrase when the installed version requires a different one.
 
-For non-production environments, the repository may allow the same formal release policy or a broader immutable CI/commit artifact policy. Do not invent broader permissions when the project has not approved them.
+Authorization applies only to the exact environment, verified target, artifact, plan/evidence, and operation shown. If any materially changes, stop and require renewed review/authorization.
 
-When promoting a tested artifact from a non-production environment to production, prefer deploying the exact same immutable artifact/digest rather than rebuilding it for production.
+No requirements approval, code review, PR merge, CI pass, environment selection, prior deployment, or readiness result implicitly authorizes a deployment write.
 
-## 7. Present the deployment preview and authorization gate
+## 7. Present the deployment preview and gate
 
-Before running the modifying deployment script, show the resolved non-secret facts:
+Before the modifying command show the resolved non-secret facts:
 
 ```text
 DEPLOYMENT READY
@@ -146,48 +132,45 @@ Environment: <name>
 Role: <production|non-production>
 Target: <verified logical target>
 Target OS: <verified>
-Launcher: <repository-provided script>
-Release/artifact: <verified identity>
+Launcher: <repository-provided command>
+Deployment baseline: <exact commit/distribution when present>
+Release/artifact: <verified immutable identity>
+Required authorization: <exact tool phrase or repository gate>
 Readiness blockers: NONE
 ```
 
-For a non-production remote deployment ask for one bounded authorization such as:
+For a non-production deployment ask for one bounded authorization covering the exact reviewed plan and required tool phrase.
 
-```text
-Authorize deployment to <environment>? [REMOTE WRITE]
-```
-
-For a production-role environment require the project's explicit production deployment gate:
+For production require the project's explicit production deployment gate and the exact installed tool phrase. Keep the consequence visible as:
 
 ```text
-Authorize deployment to <environment>? [PRODUCTION WRITE]
+[PRODUCTION WRITE]
 ```
 
-Production authorization applies only to the exact environment, verified target, release/artifact, and evidence shown. If any of those materially changes, stop and require renewed review/authorization.
-
-No requirements approval, code review, PR merge, CI pass, environment selection, prior deployment, or readiness result implicitly authorizes this deployment.
+Do not translate a generic `approve` into a broader tool-specific phrase unless the user clearly authorized the exact reviewed deployment operation represented by that phrase.
 
 ## 8. Execute only the approved script contract
 
-After authorization, invoke the repository-provided launcher with the explicitly selected environment and approved release/artifact inputs.
+After authorization invoke only the repository-provided launcher with the explicitly selected environment and approved artifact inputs.
 
-Do not perform unrelated host provisioning, target rebinding, firewall changes, credential creation, destructive recovery, or other out-of-band remote writes as part of `/deploy` unless they are explicitly part of the already-approved deployment script contract and authorization scope.
+Do not perform unrelated host provisioning, target rebinding, firewall changes, credential creation, destructive recovery, database restore, or other out-of-band writes as part of `/deploy` unless they are explicitly inside the reviewed deterministic deployment contract.
 
-If the script reports missing prerequisites, identity mismatch, unexpected target OS, lock contention, migration failure, readiness failure, or another blocker, stop according to the repository's deployment contract. Never redirect the deployment to another environment or host.
+If the script reports missing prerequisites, identity mismatch, unexpected target OS, lock contention, migration failure, readiness failure, stale plan/evidence, or another blocker, stop according to the repository contract. Never redirect to another environment or host.
 
 ## 9. Verify and record outcome
 
-After the script completes, use repository-provided readiness/smoke checks and evidence recording when available.
+After execution, use repository-provided readiness/smoke/evidence commands when available.
 
-Report at least the non-secret outcome supported by evidence:
+Report only evidence-backed outcomes:
 
-- selected environment,
-- verified target identity/label,
-- release/artifact identity,
-- deployment result,
-- readiness/smoke result,
-- rollback outcome when applicable.
+- selected environment;
+- verified target identity/label;
+- deployment baseline/tool identity when relevant;
+- release/artifact identity;
+- deployment result;
+- readiness/smoke result;
+- rollback/recovery outcome when applicable.
 
-Do not report success merely because a command returned or a container/process started if the repository requires stronger readiness evidence.
+Do not report success merely because a command returned or a container/process started if stronger readiness evidence is required.
 
-Application rollback and database restore/destructive recovery remain separate decisions when the project contract makes them separate.
+Application rollback, database restore, destructive recovery, and environment tear-down remain separate decisions when the repository contract makes them separate.

package/assets/generated/core/core/skills/lean-update/SKILL.md

@@ -0,0 +1,224 @@
+---
+name: lean-update
+description: Guided whole-profile update for package-managed Lean consumers using the exact published @mriekki/lean artifact while preserving Core, Deployment, umbrella, and generated-consumer provenance integrity.
+argument-hint: "[optional exact package version]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Lean Update
+
+`/lean-update` is the normal update workflow for consumers that contain `LEAN_BASELINE.json` and were installed/generated from the public Lean package.
+
+The governing rule is:
+
+```text
+package-managed consumer
+→ update the whole Lean profile through the published package
+→ keep LEAN_BASELINE.json + component baselines coherent
+→ when the consumer is Bootstrap-generated, keep approved generation metadata and generated package-verification surfaces coherent too
+```
+
+Do not replace this with direct Core-only or Deployment-Kit-only synchronization when `LEAN_BASELINE.json` is present.
+
+Invocation starts read-only. One explicit update choice may authorize safe branch setup plus the exact package apply, generated-consumer companion metadata updates when applicable, and verification. `/deliver`, merge, release publication, and production deployment remain separate.
+
+## 1. Establish package-managed provenance
+
+From the consumer root read:
+
+- `LEAN_BASELINE.json`;
+- `CORE_BASELINE.json` when present;
+- `DEPLOYMENT_BASELINE.json` when present;
+- `POC_BOOTSTRAP.json` when present;
+- current Git status, branch, remotes, and default branch when observable.
+
+Require `LEAN_BASELINE.json` to identify:
+
+- package name;
+- installed package version;
+- profile;
+- recorded Core component commit/version/distribution;
+- recorded Deployment component commit/distribution when that component is present.
+
+If `LEAN_BASELINE.json` is absent, report `NOT A PACKAGE-MANAGED LEAN CONSUMER` and stop. A Core-only consumer may use `/core-sync`; another component-only consumer must use that component's canonical compatibility path.
+
+Do not synthesize or repair missing umbrella provenance by hand.
+
+### Bootstrap-generated consumers
+
+If `POC_BOOTSTRAP.json` exists, treat it as approved generated-consumer provenance, not unrelated product data.
+
+Before planning an update, require `generation.lean.package`, `generation.lean.version`, and `generation.lean.profile` to agree exactly with the installed `LEAN_BASELINE.json`. Require `generation.lean.integrity` to be a non-empty exact registry integrity value for that installed package/version. Verify that integrity read-only from the registry when registry access is available.
+
+If those values disagree before the update, report `GENERATED LEAN METADATA DRIFT` and stop. Do not use `/lean-update` to silently reconcile an already-incoherent generated consumer.
+
+Also inspect generated package-verification surfaces such as `.github/workflows/ci.yml` when present. If they duplicate the approved package version/integrity literally, record that current shape as companion generated metadata that must remain coherent with `POC_BOOTSTRAP.json` during the update. Do not rewrite locally customized or unrecognized generated surfaces by guesswork.
+
+## 2. Verify the installed package baseline first
+
+Before planning an update, verify that the current managed state still matches the exact installed package version recorded in `LEAN_BASELINE.json`.
+
+For the standard package this is equivalent to:
+
+```text
+npx --yes @mriekki/lean@<installed-version> check
+```
+
+Use the package identity recorded by the baseline rather than silently substituting another package.
+
+If the exact installed package cannot be obtained, or `check` reports stale/drifted Core, Deployment, or umbrella metadata, stop. Do not use an update as a way to overwrite unexplained managed drift.
+
+Also inspect Git state. Preserve unrelated consumer work; never auto-stash, reset, clean, rebase, force-update, or discard it.
+
+## 3. Resolve one exact target package
+
+If the human supplied an exact version, use that exact version after confirming it exists.
+
+Otherwise resolve the registry's current published version first, then pin that exact value for the remainder of the operation. For the standard package, typical read-only evidence is:
+
+```text
+npm view @mriekki/lean@latest version --json
+npm view @mriekki/lean@<resolved-version> dist.integrity --json
+```
+
+Capture the target package's full exact `dist.integrity` together with the resolved version. For a Bootstrap-generated consumer, that exact integrity is part of the reviewed companion metadata update.
+
+Do not use a moving `@latest` reference for the modifying apply after preview. Use the same exact package version for preview, apply, and final check.
+
+If the resolved version equals the installed version and the exact-version check passes, report `LEAN ALREADY CURRENT` and stop without creating a branch or commit.
+
+If the resolved target is semantically older than the installed package, report `LEAN DOWNGRADE REQUESTED` and stop. Normal `/lean-update` does not authorize a downgrade or rollback; that requires a separate explicit recovery/rollback decision with repository-specific evidence.
+
+## 4. Preview the whole-profile update
+
+Run the target package's update command without `--apply` and inspect the complete plan. For the standard package:
+
+```text
+npx --yes @mriekki/lean@<target-version> update
+```
+
+Do not approve the package's interactive apply prompt during preview. When needed, invoke preview in the environment's non-interactive/read-only form so the printed plan is observed without applying it.
+
+The preview must cover every component in the installed profile together. A managed conflict/drift in any component blocks the whole update.
+
+Stop on unsafe states such as:
+
+- `LOCAL_DRIFT`;
+- `CONFLICT`;
+- `LOCAL_MISSING`;
+- `UNTRACKED_CONFLICT`;
+- path collisions/conflicts;
+- unaccepted Core `RETIRED_PATH`.
+
+Core retired paths are an ownership-transfer decision. Never auto-add `--accept-retired core:<path>` merely to make the update pass. Explain the retired path and require a separate explicit ownership decision before re-previewing it.
+
+For a Bootstrap-generated consumer, also preview the companion generated-consumer changes:
+
+- `POC_BOOTSTRAP.json` keeps the same package/profile but changes `generation.lean.version` and `generation.lean.integrity` to the exact reviewed target;
+- generated package-verification surfaces should consume `POC_BOOTSTRAP.json` dynamically when the accepted Bootstrap contract supports that form;
+- a recognized older Bootstrap-generated verification block may be migrated only when its embedded old package/version/integrity exactly match the currently approved manifest metadata;
+- an unrecognized or locally modified generated verification surface is a stop condition, not permission to reconstruct Bootstrap output by hand.
+
+## 5. Present one bounded update choice
+
+When the exact target package plan and any generated-consumer companion plan are safe, present:
+
+```text
+LEAN UPDATE READY
+
+Installed: <package>@<installed-version>
+Target: <package>@<target-version>
+Target integrity: <exact dist.integrity>
+Profile: <profile>
+Core: <old> → <new>
+Deployment: <old> → <new> / unchanged
+Generated consumer metadata: <not present / coherent update planned>
+Managed drift/conflicts: NONE
+
+1. Apply the exact Lean package update [GIT + FILE WRITE] — recommended
+2. Keep inspecting only [READ ONLY]
+3. Stop [NO ACTION]
+```
+
+Choosing option 1 authorizes only:
+
+- creation/switch to one repository-appropriate short-lived update branch when needed;
+- exact target package apply;
+- when `POC_BOOTSTRAP.json` is present, update of its exact `generation.lean.version` and `generation.lean.integrity` to the reviewed target while preserving package/profile;
+- migration of a recognized Bootstrap-generated package-verification block from duplicated current literals to the accepted manifest-driven form, only when the existing block still exactly matches the current approved metadata;
+- package/baseline/generated-consumer verification;
+- inspection of the resulting meaningful diff.
+
+It does not authorize `/deliver`, merge, npm/Core/Deployment/Bootstrap release publication, arbitrary regeneration, or deployment.
+
+## 6. Apply only the exact previewed package
+
+If the consumer is on its default branch, create/switch to a short-lived branch such as:
+
+```text
+chore/update-lean-<target-version>
+```
+
+Branch setup is routine inside the selected bounded update action when safe and unambiguous.
+
+Apply using the same exact package version that was previewed, for example:
+
+```text
+npx --yes @mriekki/lean@<target-version> update --apply
+```
+
+If explicit Core retired-path ownership transfer was separately approved, pass only the exact reviewed paths using the package's `--accept-retired core:<path>` contract. Never widen that set implicitly.
+
+For a Bootstrap-generated consumer, complete the reviewed companion metadata changes in the same bounded update before declaring success. Preserve every unrelated `POC_BOOTSTRAP.json` field. Never change package identity or profile as an incidental version update.
+
+Do not run direct `tools/package/sync.py`, Deployment Kit sync, or a remote `[sync-core]` request as part of a package-managed update.
+
+## 7. Verify all baselines, generated metadata, and the diff
+
+After apply, run the exact target package check:
+
+```text
+npx --yes @mriekki/lean@<target-version> check
+```
+
+Then inspect:
+
+```text
+git status --short --branch
+git diff --stat
+git diff -- LEAN_BASELINE.json CORE_BASELINE.json DEPLOYMENT_BASELINE.json POC_BOOTSTRAP.json .github/workflows/ci.yml
+```
+
+Confirm:
+
+- `LEAN_BASELINE.json` records the exact target package/version/profile;
+- component baseline commits/distributions match the umbrella baseline;
+- package check passes for the whole profile;
+- when `POC_BOOTSTRAP.json` exists, its package/version/profile agree with `LEAN_BASELINE.json` and its integrity equals the exact reviewed target registry integrity;
+- when the repository contains `tools/lean-package/check-managed-baselines.py`, that generated baseline checker passes after all companion metadata changes;
+- generated package-verification surfaces no longer contradict the approved manifest metadata;
+- consumer-owned content was not overwritten;
+- only intended package-managed changes, reviewed generated-consumer companion changes, and reviewed ownership transfers occurred.
+
+If generated CI still embeds a different package version/integrity after the update, report `GENERATED LEAN VERIFICATION DRIFT` and stop before delivery.
+
+Present the meaningful diff for human review. After acceptance, recommend `/deliver` for normal commit/push/PR/CI mechanics.
+
+## 8. Boundaries
+
+`/lean-update` never:
+
+- updates only Core or only Deployment when `LEAN_BASELINE.json` manages them together;
+- uses a different package version for apply than the reviewed preview;
+- performs a downgrade/rollback as an ordinary update;
+- overwrites unexplained managed drift;
+- auto-accepts Core retired-path ownership transfer;
+- silently repairs a pre-existing mismatch between `POC_BOOTSTRAP.json` and `LEAN_BASELINE.json`;
+- changes a generated consumer's package identity/profile or regenerates the repository as an incidental version update;
+- guesses at locally modified/unrecognized Bootstrap-generated verification logic;
+- publishes npm/Core/Deployment/Bootstrap releases or tags;
+- merges the consumer PR;
+- deploys an environment.
+
+If reusable shared content is wrong rather than merely outdated, route the defect through `/upstream-fix` first. Package-managed adoption of the accepted fix happens only after an accepted Lean package release contains that upstream commit.

package/assets/generated/core/core/skills/upstream-fix/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: upstream-fix
-description: Route reusable bugs discovered in a consumer to the canonical shared repository, allow bounded upstream implementation, and return adoption to exact baseline sync.
+description: Route reusable bugs discovered in a consumer to the canonical shared repository, allow bounded upstream implementation, and return adoption through the consumer's actual provenance/update boundary.
 argument-hint: "[optional problem summary]"
 user-invocable: true
 disable-model-invocation: true
@@ -13,32 +13,26 @@ disable-model-invocation: true
 The governing rule is:
 
 ```text
-discover in the consumer
-→ diagnose/prove in the consumer
-→ fix in the owning canonical repository
+discover in consumer
+→ diagnose/prove in consumer
+→ fix in owning canonical repository
 → deliver there
-→ sync the accepted shared commit back into the consumer
-→ verify again in the consumer
+→ adopt through the consumer's recorded distribution boundary
+→ verify again in consumer
 ```
 
-A temporary edit to a shared-managed file inside the consumer may be useful as diagnosis/proof, but it is never the canonical delivered fix.
+A temporary edit to a shared-managed file inside a consumer may be useful as diagnosis/proof, but it is never the canonical delivered fix.
 
 ## 1. Invocation authorization
 
 Invoking `/upstream-fix` authorizes:
 
 - read-only ownership/provenance inspection in the consumer;
-- classification of the problem to the owning layer;
+- classification to the smallest canonical owner;
 - inspection of already-available local canonical repository candidates;
-- when ownership and the intended patch are clear and a canonical checkout is safe, routine creation/use of one short-lived canonical work branch and application of only the bounded equivalent fix plus its focused tests/docs.
+- when ownership and the bounded patch are clear and a canonical checkout is safe, routine creation/use of one short-lived canonical work branch and application of only that bounded fix plus focused tests/docs.
 
-Invocation does **not** authorize:
-
-- commit, push, PR creation, merge, release publication, or deployment;
-- rewriting/discarding consumer work;
-- changing more than one canonical repository in the same bounded fix;
-- broad filesystem scans or cloning shared repositories merely to satisfy the helper;
-- treating a temporary consumer patch as accepted shared implementation.
+Invocation does **not** authorize commit, push, PR creation, merge, release publication, package publication, deployment, rewriting/discarding consumer work, or changing multiple canonical repositories in one bounded fix.
 
 Normal review and `/deliver` occur later while focused on the owning canonical repository.
 
@@ -46,20 +40,16 @@ Normal review and `/deliver` occur later while focused on the owning canonical r
 
 From the consumer root inspect, when present:
 
+- `LEAN_BASELINE.json`;
 - `CORE_BASELINE.json`;
 - `DEPLOYMENT_BASELINE.json`;
 - `.github/lean-workspace.json`;
 - current Git branch/status/diff;
 - the files involved in the reported problem or temporary proof.
 
-Run repository-local managed-baseline checks when available:
-
-```text
-python tools/lean-core/check-core-baseline.py --root .
-python tools/lean-deployment/check-deployment-baseline.py
-```
+Run repository-local managed-baseline checks when available.
 
-Do not assume every generated-looking file is shared-owned. Use baseline managed-path records as the primary ownership evidence.
+Do not assume every generated-looking file is shared-owned. Use baseline managed-path records as the primary ownership evidence, and use `LEAN_BASELINE.json` to determine whether component baselines are managed together by an umbrella package.
 
 ## 3. Classify the owner
 
@@ -67,7 +57,7 @@ Use the smallest owning layer that would need the same fix for another consumer.
 
 ### Consumer-owned
 
-Examples: application domain logic, UI behavior, app-specific configuration, product tests, consumer architecture.
+Application domain logic, UI behavior, app-specific configuration, product tests, and consumer architecture normally remain consumer-owned.
 
 Result:
 
@@ -76,13 +66,11 @@ CONSUMER FIX
 Owner: current repository
 ```
 
-Stop upstream routing and continue through the consumer's normal `/start-work` / implementation / review / `/deliver` flow.
+Return to the consumer's normal `/start-work` / implementation / review / `/deliver` flow.
 
 ### Core-owned
 
-Evidence includes a changed/problematic path managed by `CORE_BASELINE.json`, or behavior defined by canonical Lean workflow skills/agents/instructions.
-
-Result:
+Evidence includes a path managed by `CORE_BASELINE.json` or behavior defined by reusable Core workflow assets.
 
 ```text
 CORE BUG
@@ -91,26 +79,33 @@ Owner: <repository recorded by CORE_BASELINE.json>
 
 ### Deployment-Kit-owned
 
-Evidence includes a changed/problematic path managed by `DEPLOYMENT_BASELINE.json`, or reusable deployment behavior owned by the pinned Deployment Kit.
-
-Result:
+Evidence includes a path managed by `DEPLOYMENT_BASELINE.json` or reusable deployment mechanics owned by that recorded Kit.
 
 ```text
 DEPLOYMENT BUG
 Owner: <repository recorded by DEPLOYMENT_BASELINE.json>
 ```
 
+### Package assembly / Lean Platform-owned
+
+When canonical component source is correct but the published package bytes, component pins, package engine, or umbrella baseline behavior is wrong:
+
+```text
+LEAN PLATFORM BUG
+Owner: package/platform repository supported by evidence
+```
+
 ### Generator/control-plane owned
 
-If generated output is wrong but the managed payload itself is correct, classify the generator/orchestrator rather than patching the generated consumer. Resolve ownership from repository/project evidence; do not guess between Bootstrap and a control plane when evidence is insufficient.
+If the package payload is correct but generation/publication/orchestration materializes it incorrectly, classify Bootstrap/control-plane ownership from evidence rather than patching a generated consumer.
 
-If ownership is genuinely ambiguous, stop at `UPSTREAM OWNER UNCLEAR` and present the competing evidence. Do not write to multiple repositories speculatively.
+If ownership is genuinely ambiguous, stop at `UPSTREAM OWNER UNCLEAR`. Do not write to multiple repositories speculatively.
 
 ## 4. Temporary consumer proof
 
-A temporary consumer edit to a shared-managed path is allowed for diagnosis when it helps prove the fix in the real application context.
+A temporary consumer edit to a shared-managed path is allowed for diagnosis when it proves the fix in real application context.
 
-Clearly report it as:
+Report it explicitly:
 
 ```text
 TEMPORARY SHARED-MANAGED PROOF
@@ -119,48 +114,38 @@ Canonical owner: <repo>
 Do not deliver this consumer copy.
 ```
 
-Do not silently revert/discard the proof, because it may contain useful evidence. Do not stage/commit it as ordinary consumer implementation. Adoption later replaces the private proof with the accepted shared baseline.
+Do not silently discard the proof and do not stage/commit it as ordinary consumer implementation.
 
-## 5. Resolve a canonical local checkout
+## 5. Resolve a safe canonical checkout
 
-For the classified owner, consider local candidates in this order:
+For the classified owner consider, in order:
 
-1. explicit path supplied by the human;
-2. an already-open workspace folder whose Git remote unambiguously matches the recorded canonical repository;
+1. an explicit path supplied by the human;
+2. an already-open workspace folder with the expected Git remote;
 3. a normal sibling checkout derived from the canonical repository name.
 
-Do not broadly scan the filesystem. A multi-root maintainer workspace is a convenience, not a requirement.
-
-A candidate is safe for bounded upstream implementation only when:
+Do not broadly scan the filesystem and do not clone automatically merely to continue.
 
-- it is the expected Git repository;
-- Git state can be inspected;
-- no merge/rebase/cherry-pick is in progress;
-- unrelated local work is absent;
-- branch state does not require reset/rebase/force/stash/discard operations.
-
-If no safe local canonical checkout exists, report the exact canonical repository and the proven consumer evidence. Do not clone automatically just to continue.
+A candidate is safe only when it is the expected repository, has no merge/rebase/cherry-pick in progress, has no unrelated local work, and does not require stash/reset/rebase/force/discard operations.
 
 ## 6. Port the bounded fix upstream
 
-When the safe local canonical checkout exists and the equivalent fix is clear:
-
-1. inspect the canonical implementation and tests before editing;
-2. create/use a repository-appropriate short-lived branch tied to the upstream issue/work item when needed;
-3. reproduce the root cause against canonical code where practical;
-4. apply the reusable fix in the canonical source, not by copying consumer-specific names/configuration;
-5. add/update focused canonical tests that would have caught the defect;
-6. update canonical docs only when the contract changed;
-7. run relevant local checks when available;
-8. show the canonical meaningful diff and observed validation.
+When a safe canonical checkout exists and the equivalent reusable fix is clear:
 
-Preserve consumer specificity. A shared fix must not hard-code the consumer name, target, data, environment, route, or product requirement merely because that consumer exposed the bug.
+1. inspect canonical implementation/tests before editing;
+2. create/use one repository-appropriate short-lived branch;
+3. reproduce the root cause canonically where practical;
+4. apply the reusable fix without consumer-specific names/configuration;
+5. add/update focused tests that would have caught the defect;
+6. update canonical docs when the contract changed;
+7. run relevant local checks;
+8. show the meaningful canonical diff and observed validation.
 
-If the consumer proof cannot be generalized safely, stop and reclassify or ask for a narrower canonical design rather than forcing the patch upstream.
+If the consumer proof cannot be generalized safely, stop and reclassify rather than forcing it upstream.
 
 ## 7. Handoff to canonical delivery
 
-After the upstream implementation is ready, report:
+When the upstream implementation is ready:
 
 ```text
 UPSTREAM FIX READY
@@ -172,23 +157,53 @@ Validation: <observed checks>
 Next: focus the canonical repository and run /deliver
 ```
 
-`/upstream-fix` does not commit/push/open/merge the canonical PR itself. `/deliver` retains the normal reviewed-diff and merge/finalize gates in exactly one repository.
+`/upstream-fix` does not commit/push/open/merge the canonical PR itself.
+
+## 8. Adopt the accepted fix through the right boundary
+
+After the canonical PR is merged and required default-branch CI is green, re-read the consumer provenance before choosing adoption.
+
+### Package-managed consumer (`LEAN_BASELINE.json` present)
+
+Do **not** direct-sync Core or Deployment Kit into the consumer.
+
+The accepted component fix must first become part of an accepted published Lean package:
+
+```text
+canonical Core/Deployment fix merged
+→ Lean Platform pins the exact accepted component commit
+→ Lean Platform PR + CI
+→ explicit package publication gate
+→ published exact @mriekki/lean version
+→ consumer /lean-update <version>
+```
+
+Until that package exists, report:
+
+```text
+PACKAGE RELEASE REQUIRED
+Consumer adoption is blocked on a Lean package that contains the accepted upstream commit.
+```
+
+Do not silently patch `LEAN_BASELINE.json`, `CORE_BASELINE.json`, or `DEPLOYMENT_BASELINE.json` to pretend the package contains the new component.
+
+### Component-only Core consumer (`LEAN_BASELINE.json` absent)
+
+A Core-owned fix may return through `/core-sync` using the exact accepted Core commit/distribution.
 
-## 8. Adopt the accepted fix back into the consumer
+### Component-only Deployment consumer (`LEAN_BASELINE.json` absent)
 
-After the canonical PR is merged and its accepted default-branch CI is green:
+A Deployment-owned fix may return through the canonical Deployment Kit compatibility sync and refresh `DEPLOYMENT_BASELINE.json`.
 
-- Core-owned fixes return through `/core-sync` using the exact accepted Core commit/distribution;
-- Deployment-Kit-owned fixes return through the canonical Deployment Kit consumer-sync capability and refresh `DEPLOYMENT_BASELINE.json`;
-- generator/control-plane fixes are validated by regenerating or using that platform's canonical update path, not by manually editing generated managed files.
+### Generator/control-plane fix
 
-Then rerun the original consumer reproduction and baseline checks.
+Validate through that platform's canonical regeneration/update path, never by manually editing generated managed files.
 
-A successful consumer retest is evidence that the shared fix works in context; it does not turn the consumer copy into the canonical source.
+Then rerun the original reproduction and baseline checks in the consumer.
 
 ## 9. Consumer delivery guard
 
-If `/deliver` is invoked in a consumer with unexplained Core- or Deployment-Kit-managed file drift, stop before staging/commit/push. Route reusable managed-file changes through `/upstream-fix` and accepted baseline sync first.
+If `/deliver` is invoked in a consumer with unexplained Core-, Deployment-, or Lean-package-managed drift, stop before staging/commit/push. Route reusable managed-file changes through `/upstream-fix` and then through the appropriate accepted update boundary.
 
 Consumer-owned changes may be delivered normally when managed baselines are clean.
 
@@ -197,10 +212,10 @@ Consumer-owned changes may be delivered normally when managed baselines are clea
 `/upstream-fix` never:
 
 - merges changes;
-- publishes releases/tags;
+- publishes releases/tags/packages;
 - deploys production;
-- commits one change across multiple repositories;
+- commits one bounded fix across multiple repositories;
 - auto-stashes, resets, rebases, force-pushes, or discards work;
-- turns a maintainer multi-root workspace into generated repository content;
 - requires ordinary consumer users to clone shared repositories;
-- treats a temporary shared-managed consumer edit as a legitimate permanent fork.
+- treats a temporary managed consumer edit as a permanent fork;
+- bypasses `LEAN_BASELINE.json` with component-only sync.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@mriekki/lean",
-  "version": "0.1.1",
+  "version": "0.2.1",
   "description": "Public consumer distribution and updater for Lean engineering assets.",
   "type": "module",
   "bin": {