@mriekki/lean 0.2.1 → 0.3.1

package/README.md

@@ -47,7 +47,7 @@ The umbrella package writes `LEAN_BASELINE.json` while preserving component-nati
 - install/update never require private GitHub access.
 - no install/update lifecycle hook mutates a consumer repository; changes occur only when the user invokes the Lean CLI.
 - one preflight plan covers all selected components; an unsafe component blocks the entire apply.
-- package publication is separate from merging this repository and requires an explicit release action.
+- package publication is separate from merging a release PR and requires one explicit exact-version publication action.
 
 ## Current scope
 
@@ -55,7 +55,21 @@ The package currently starts with the `greenfield-poc` consumer profile. Existin
 
 ## Package assembly and release
 
-The public source repository intentionally does not commit generated private-source snapshots. Prepare an auditable release candidate from clean exact canonical checkouts:
+For normal releases in the Lean Platform VS Code workspace, use:
+
+```text
+/release-lean [version | patch | minor | major]
+```
+
+The repo-local skill resolves accepted component commits, prepares the version/pin/descriptor update, runs local verification, creates the release PR, waits for the package-PR merge gate, verifies post-merge `main` CI, then stops once at the exact npm publication gate.
+
+After publication approval it triggers `.github/workflows/npm-publish.yml`. The workflow reconstructs the package from the exact private component pins, runs the deterministic release preparation, publishes the exact tarball directly with npm Trusted Publishing (OIDC), and automatically verifies the registry identity plus a neutral-directory `npx` smoke check.
+
+The normal flow does not use staged npm publication or a long-lived npm publish token. An existing stage-only trusted publisher must be migrated once to allow direct `npm publish` from `npm-publish.yml`; `/release-lean` guides that bounded one-time setup.
+
+Before merging a release PR, verify the local npm maintainer login and trusted-publisher relationship; the release skill explains npm's browser/2FA reauthorization if `npm trust list` returns `EOTP`. GitHub Actions publication uses OIDC, not a manually managed npm token. See `docs/RELEASE_PROCESS.md` for the operator setup.
+
+The underlying release-candidate command remains available for diagnostics:
 
 ```powershell
 Set-Location D:\Projects\lean-platform
@@ -66,6 +80,4 @@ 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 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.2.1",
+  "version": "0.3.1",
   "defaultProfile": "greenfield-poc",
   "profiles": {
     "greenfield-poc": {
@@ -14,8 +14,8 @@
   "components": {
     "core": {
       "repository": "mriekki/lean-agentic-core",
-      "commit": "e3a8a994d1e95923d629af7640d3b3a0a4f098d4",
-      "version": "1.11.1",
+      "commit": "009572aa4c61ad9a45ec5473b6affc984d6faac0",
+      "version": "1.12.0",
       "distribution": "greenfield-workspace",
       "descriptor": "assets/core/distribution.json",
       "sourceRoot": "assets/generated/core",

package/assets/core/distribution.json

@@ -20,7 +20,7 @@
     {"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"},
-    {"source":"core/skills/production-readiness/SKILL.md","destination":".github/skills/production-readiness/SKILL.md"},
+    {"source":"core/skills/deployment-readiness/SKILL.md","destination":".github/skills/deployment-readiness/SKILL.md"},
     {"source":"core/skills/deploy/SKILL.md","destination":".github/skills/deploy/SKILL.md"},
     {"source":"core/skills/tear-down/SKILL.md","destination":".github/skills/tear-down/SKILL.md"},
     {"source":"core/skills/coach/SKILL.md","destination":".github/skills/coach/SKILL.md"},
@@ -28,7 +28,7 @@
     {"source":"core/skills/learning-review/SKILL.md","destination":".github/skills/learning-review/SKILL.md"},
     {"source":"core/process/WORK_ITEM_MODEL.md","destination":"docs/process/WORK_ITEM_MODEL.md"},
     {"source":"core/process/PR_WORKFLOW.md","destination":"docs/process/PR_WORKFLOW.md"},
-    {"source":"core/process/PRODUCTION_ENABLEMENT.md","destination":"docs/process/PRODUCTION_ENABLEMENT.md"},
+    {"source":"core/process/DEPLOYMENT_ENABLEMENT.md","destination":"docs/process/DEPLOYMENT_ENABLEMENT.md"},
     {"source":"core/process/HUMAN_GATES.md","destination":"docs/process/HUMAN_IN_LOOP_GATES.md"},
     {"source":"core/process/GUIDED_NEXT_STEPS.md","destination":"docs/process/GUIDED_NEXT_STEPS.md"},
     {"source":"core/process/INTERACTIVE_SESSION_GUIDE.md","destination":"docs/process/INTERACTIVE_SESSION_GUIDE.md"},

package/assets/generated/ASSEMBLY.json

@@ -1,12 +1,12 @@
 {
   "schemaVersion": 1,
   "package": "@mriekki/lean",
-  "version": "0.2.1",
+  "version": "0.3.1",
   "components": {
     "core": {
       "repository": "mriekki/lean-agentic-core",
-      "commit": "e3a8a994d1e95923d629af7640d3b3a0a4f098d4",
-      "version": "1.11.1",
+      "commit": "009572aa4c61ad9a45ec5473b6affc984d6faac0",
+      "version": "1.12.0",
       "distribution": "greenfield-workspace",
       "files": [
         {
@@ -17,7 +17,7 @@
         {
           "source": "core/agents/reviewer.agent.md",
           "destination": ".github/agents/reviewer.agent.md",
-          "sha256": "7a2c1b52dfb75a2d71da1b82c6d186330b596473689712d65e51a3a9c390a25c"
+          "sha256": "c999281aeab6fd17ea308d581a7e931a06d7b93f33871915605956643c7b22ff"
         },
         {
           "source": "core/agents/coach.agent.md",
@@ -27,7 +27,7 @@
         {
           "source": "core/instructions/lean-workflow.instructions.md",
           "destination": ".github/instructions/lean-workflow.instructions.md",
-          "sha256": "ef6fcd56c5959cfe61a815b8edaabceaa6ca9b7eb4eb7bf8166eb2ea727fb98d"
+          "sha256": "398b4734db1af4139e8395fc30dddd3fd45aaa76b4f5c5ce9c4b286c456d9430"
         },
         {
           "source": "core/instructions/lean-docs.instructions.md",
@@ -57,17 +57,17 @@
         {
           "source": "core/skills/start-work/SKILL.md",
           "destination": ".github/skills/start-work/SKILL.md",
-          "sha256": "dfdb038560871752e7a9e223efec8a807afb786c5f83dc2b46699470d05c883b"
+          "sha256": "43c10278bd715ec95f3aa8d4ed4a2a4b51aa9fc6484e1fda572037381e663de4"
         },
         {
           "source": "core/skills/next-step/SKILL.md",
           "destination": ".github/skills/next-step/SKILL.md",
-          "sha256": "c8b3bc84dbf3f126aa35e5dbc48fd6985de91d9c0f981ec47777e515c01b63ef"
+          "sha256": "0fac7b36f62039341c7536ff1516387efd4b6b32885dceb58d59510480ff9d6b"
         },
         {
           "source": "core/skills/deliver/SKILL.md",
           "destination": ".github/skills/deliver/SKILL.md",
-          "sha256": "f5a16438406571c34cc876242a2aa4d593b028509b78bdeb2b2942529b1a9b6d"
+          "sha256": "bb31e292a57372c6f64f627035652632b474f1ebcaab604eded57d730825af8a"
         },
         {
           "source": "core/skills/cleanup-branches/SKILL.md",
@@ -100,14 +100,14 @@
           "sha256": "9b5968158992681837071b60465682a887540b1fdab510861ed739ffa996fbdb"
         },
         {
-          "source": "core/skills/production-readiness/SKILL.md",
-          "destination": ".github/skills/production-readiness/SKILL.md",
-          "sha256": "adc45c556902f039b918f20bf484a05f9213103d5875b1ba7fa9c58dd0dca4d6"
+          "source": "core/skills/deployment-readiness/SKILL.md",
+          "destination": ".github/skills/deployment-readiness/SKILL.md",
+          "sha256": "5e4f50c9ab696b16e677fc6e4be3f581ac912e7b15c077b376457d00c01c1623"
         },
         {
           "source": "core/skills/deploy/SKILL.md",
           "destination": ".github/skills/deploy/SKILL.md",
-          "sha256": "e9dcf7232505d684c1d8f39b0937c5026223e745df023c84295457e22da1b52a"
+          "sha256": "e34b29d3d19945b6317adb9e5796895dc75f249015ec9708fd256ab7e0ca0c5f"
         },
         {
           "source": "core/skills/tear-down/SKILL.md",
@@ -137,17 +137,17 @@
         {
           "source": "core/process/PR_WORKFLOW.md",
           "destination": "docs/process/PR_WORKFLOW.md",
-          "sha256": "8d1bcabf6d1b72705ca9e7e0cd348b71102805b041dba601fa6dd93d5063b1ed"
+          "sha256": "78859425a8f6efadf33fd2708e940ae2aebe2ce0f4d02d63c8ec0cbdf60f6b20"
         },
         {
-          "source": "core/process/PRODUCTION_ENABLEMENT.md",
-          "destination": "docs/process/PRODUCTION_ENABLEMENT.md",
-          "sha256": "d2580b76144fad0e7d429802f8cdaba3ed022b4580c2e311c01f81b9a5a09bab"
+          "source": "core/process/DEPLOYMENT_ENABLEMENT.md",
+          "destination": "docs/process/DEPLOYMENT_ENABLEMENT.md",
+          "sha256": "a57819ce9e52227df8260d789fb6911721aac0e391a53e711fbb27d7a17b3245"
         },
         {
           "source": "core/process/HUMAN_GATES.md",
           "destination": "docs/process/HUMAN_IN_LOOP_GATES.md",
-          "sha256": "cc8f5c01f7c5ac1c745a87f810493eb9d1a3b1c76b46b64ed27830dd5838f33c"
+          "sha256": "ac6ab2343728679d2ae50e9872b4b2f52a49605a2ea7ed17d806a839da4376c1"
         },
         {
           "source": "core/process/GUIDED_NEXT_STEPS.md",
@@ -157,7 +157,7 @@
         {
           "source": "core/process/INTERACTIVE_SESSION_GUIDE.md",
           "destination": "docs/process/INTERACTIVE_SESSION_GUIDE.md",
-          "sha256": "12c19b70924087824ae49369fdbe7bfb79b699e17285ada27d2f5cd4a5820098"
+          "sha256": "15d47509919e83786ada6df1e5482bd9f73ca4955cda66287f6d6b1f9722c853"
         },
         {
           "source": "core/process/COACHING_GUIDE.md",

package/assets/generated/core/core/agents/reviewer.agent.md

@@ -82,4 +82,4 @@ When implementation is READY and the human accepts the meaningful local diff, ex
 
 Do not vaguely say `merge when ready`.
 
-If the delivered work item owns production deployment, successful engineering delivery may later hand off to `/production-readiness <deployment-enabler-ID> enable`; Reviewer readiness never authorizes production deployment.
+If the delivered work item owns deployment engineering, successful engineering delivery may later hand off to `/deployment-readiness <deployment-enabler-ID> enable [environment]`; Reviewer readiness never authorizes remote or production deployment.

package/assets/generated/core/core/instructions/lean-workflow.instructions.md

@@ -18,10 +18,12 @@ Once a bounded action is authorized, routine mechanics inside that scope should
 
 For implementation, establish the repository-appropriate short-lived work branch as routine setup once implementation itself is authorized; do not add a separate branch-creation gate when branch policy/naming and scope are clear.
 
-Continuous modes such as `/grill-me`, `/grill-with-docs`, `/refine-requirements`, `/coach`, `/learning-review`, and `/production-readiness` continue until stopped or naturally complete.
+Continuous modes such as `/grill-me`, `/grill-with-docs`, `/refine-requirements`, `/coach`, `/learning-review`, and `/deployment-readiness` continue until stopped or naturally complete.
 
 During interactive questioning, prefer concise choice-first options for genuinely bounded human decisions, including `Other / specify` and `Not sure — recommend one` when appropriate. Keep factual/environment-specific values and questions intended to elicit the human's own framing, reasoning, debugging approach, design rationale, or understanding open-ended unless options are later useful as scaffolding.
 
+For deployment readiness, inspect existing non-secret configuration before asking setup questions. Show already-known simple machine facts such as hostname/address, deployment user, port, and target OS for confirmation. Ask only for missing or conflicting facts. Keep deployment-tool implementation identifiers such as logical target names, `targetName`, SSH aliases, profile paths, and trust-file paths internal unless troubleshooting or genuine ambiguity requires them.
+
 Shared managed code keeps its canonical owner. When a consumer contains `CORE_BASELINE.json` or `DEPLOYMENT_BASELINE.json`, treat those baselines as ownership evidence. A temporary edit to a shared-managed consumer file may be used to diagnose or prove a reusable defect, but it is not the canonical deliverable.
 
 Before consumer delivery, run available managed-baseline integrity checks. If Core- or Deployment-Kit-managed files have unexplained local drift, stop before staging/commit/push and route the reusable change through `/upstream-fix`. Fix the owning canonical repository, deliver/merge it there under normal gates, then adopt the exact accepted shared commit back into the consumer through the appropriate sync mechanism and retest in consumer context.

package/assets/generated/core/core/process/DEPLOYMENT_ENABLEMENT.md

@@ -0,0 +1,94 @@
+# Deployment Enablement
+
+Deployment enablement is the guided operational lane between delivered deployment engineering and `/deploy`.
+
+A repository may have multiple named deployment environments, such as Staging and Production. Each environment owns its own confirmed machine/target binding, readiness evidence, data/backup state, credentials, and deployment policy.
+
+Use:
+
+```text
+/deployment-readiness [deployment-enabler-ID] discovery [environment]
+```
+
+to discover environment setup early, and:
+
+```text
+/deployment-readiness [deployment-enabler-ID] enable [environment]
+```
+
+after deployment engineering is reviewed, delivered, merged, and applicable default-branch CI/policy evidence is satisfactory.
+
+For a read-only local overview use:
+
+```text
+/deployment-readiness [deployment-enabler-ID] status [environment]
+```
+
+Omit the environment from `status` to summarize all configured named environments without automatically probing every remote machine.
+
+## Human-facing readiness model
+
+The workflow should ask about simple environment-machine facts before exposing deployment-tool internals.
+
+Human-facing facts normally include:
+
+- environment name/role;
+- hostname or IP address;
+- SSH/deployment user when applicable;
+- non-default SSH port when applicable;
+- target OS when known.
+
+Internal Deployment Kit concepts such as logical target name / `targetName`, SSH alias, profile path, identity path, known-hosts path, address override, and trust-record storage should be discovered, reused, or derived whenever possible. They are not normal first questions.
+
+If existing configuration is present, show the known simple facts and ask the human to confirm them before remote checks. Do not make the human reconstruct already-recorded values.
+
+If setup is partial, show what is known and ask only for the smallest missing fact or authorization.
+
+If setup is absent, start with the selected machine's hostname or IP address, then ask one additional simple fact at a time only when required.
+
+## Discover, confirm, verify
+
+Normal readiness cadence is:
+
+```text
+select environment
+→ inspect existing local/repository setup
+→ show simple known facts
+→ human confirms or corrects them
+→ authorize read-only connectivity/identity verification
+→ run repository/Deployment-Kit doctor/verify checks
+→ reuse working access OR repair only missing setup OR onboard a new workstation
+→ verify remaining runtime/security/data/release prerequisites
+→ environment READY
+→ /deploy <environment>
+```
+
+Remote probing does not occur merely to build the initial local summary.
+
+Address discovery is not host trust. When SSH is used, unknown or changed host identity stops access; readiness must not recover by disabling host-key verification, silently enrolling new trust, scanning/selecting another host, weakening network controls, or redirecting to another environment.
+
+## Existing and new workstations
+
+On an already-configured workstation, successful strict verification means onboarding/setup questions are skipped.
+
+On a partially configured workstation, diagnose the exact missing state and repair only that state after the applicable bounded authorization.
+
+On a fresh workstation, guide the minimum required profile/key/agent/trust/binding setup using the approved repository/Deployment-Kit commands. Reuse an already-valid developer-to-machine relationship across POCs when policy/tooling permits; do not create duplicate credentials simply because a new POC uses the same box.
+
+## Environment independence
+
+Readiness is environment-specific. Readiness of Staging does not prove Production is ready, and failure of one environment must never cause fallback to another environment or machine.
+
+Production remains a role with stronger deployment, artifact, backup, recovery, and Human-in-the-Loop policy where required. It does not use a separate readiness command.
+
+Once the selected environment is ready, the repeatable deployment entry point is:
+
+```text
+/deploy <environment>
+```
+
+`/deploy` verifies the selected environment/target/artifact evidence, dispatches to repository-provided tooling, and presents the applicable write gate immediately before execution.
+
+A Production deployment remains separately authorized and never becomes implicit because readiness passed. A non-production remote deployment still requires the repository/tool's bounded remote-write authorization.
+
+Remote read-only authorization never implies permission for writes. Secret values stay out of tracked documentation and logs. Database restore/destructive recovery remains a separate decision when data safety warrants it.

package/assets/generated/core/core/process/HUMAN_GATES.md

@@ -20,6 +20,8 @@ A human gate is meaningful only when the human understands what is being approve
 
 Do not gate routine mechanics individually after a bounded action is already authorized.
 
+Missing access to GitHub admin policy metadata is not itself a human gate. Use configured workflow/check results, PR mergeability, repository documentation, and any observable enforced policy as evidence. Do not ask the human to open GitHub Settings and transcribe branch-protection/ruleset check names merely to continue; ask only when unavailable policy information creates a material unresolved decision at merge, release, or another consequential action.
+
 ## Implementation branch setup
 
 Once implementation itself is authorized, creating/switching to the repository-appropriate short-lived work branch is routine setup, not a separate decision gate, when branch policy/naming and work-item scope are clear and the operation preserves the worktree without history rewriting.
@@ -50,7 +52,7 @@ Do not separately ask `Create branch?`, `Commit?`, `Push?`, `Create PR?`, or `Ch
 
 ## Combined final acceptance + merge gate
 
-When the PR head/diff still exactly represents the implementation the human already accepted locally, Reviewer is READY, required PR CI is green, and repository policy/mergeability are satisfactory, final PR acceptance and merge authorization may be combined into one meaningful choice:
+When the PR head/diff still exactly represents the implementation the human already accepted locally, Reviewer is READY, configured PR CI is green, any additional observable repository-required checks are satisfied, and repository policy/mergeability are satisfactory, final PR acceptance and merge authorization may be combined into one meaningful choice:
 
 ```text
 Merge and finalize delivery [HUMAN ACCEPTANCE + GITHUB/GIT WRITE]
@@ -59,8 +61,8 @@ Merge and finalize delivery [HUMAN ACCEPTANCE + GITHUB/GIT WRITE]
 That explicit choice covers only the observed PR and its normal short-lived delivered branch. It authorizes:
 - final acceptance of the PR as observed,
 - merge using the approved repository strategy,
-- observation/recheck of required post-merge default-branch CI,
-- safe finalization of that delivered short-lived branch after required post-merge CI is green.
+- observation/recheck of applicable post-merge default-branch CI/policy,
+- safe finalization of that delivered short-lived branch after that CI/policy evidence is satisfied.
 
 It does not authorize deleting any other branch, bypassing changed evidence, or deploying to production.
 

package/assets/generated/core/core/process/INTERACTIVE_SESSION_GUIDE.md

@@ -8,7 +8,7 @@ The following modes are continuous after the human explicitly enters them:
 /refine-requirements
 /coach
 /learning-review
-/production-readiness
+/deployment-readiness
 ```
 
 Default cadence:
@@ -42,6 +42,8 @@ Keep questions open-ended when predefined choices would weaken the purpose of th
 
 If an open-ended reasoning question stalls, options/hints may be introduced as scaffolding after the initial attempt. Do not manufacture bounded choices merely to make every question look structured.
 
+For deployment readiness, discover existing local/repository configuration before asking factual questions. Show known simple environment/machine facts for confirmation and ask only for missing or conflicting facts. Do not lead with deployment-tool implementation identifiers such as `targetName`, SSH aliases, profile paths, or trust-file paths when the workflow can discover, reuse, or derive them.
+
 Do not repeatedly ask `Do you want to continue?`.
 
 Stop when:
@@ -53,7 +55,7 @@ Stop when:
 
 Continuous conversation never implies permission for unrelated file, Git, external-system, remote, or production writes.
 
-For modifying sessions such as requirement refinement or production-readiness documentation, one explicit session-level authorization may cover focused updates within the defined scope; do not re-ask after every answer.
+For modifying sessions such as requirement refinement or deployment-readiness documentation, one explicit session-level authorization may cover focused updates within the defined scope; do not re-ask after every answer.
 
 Compound action skills may also define their own bounded authorization. In particular, manually invoking `/deliver` after its prerequisites are satisfied authorizes routine branch/stage/commit/push/PR/CI mechanics within the accepted delivery scope. Do not interrupt that compound action with repeated ceremonial permission prompts. `/deliver` still stops for changed evidence, ambiguity/risk, and the explicit merge/finalize decision.
 

package/assets/generated/core/core/process/PR_WORKFLOW.md

@@ -24,7 +24,7 @@ Normal delivery is intentionally streamlined:
 → PR CI
 → one MERGE + FINALIZE decision
 → merge
-→ post-merge default-branch CI when configured/required
+→ post-merge default-branch CI when configured, plus any observable enforced checks
 → safe delivered-branch cleanup
 → delivery complete
 ```
@@ -33,6 +33,8 @@ Invoking `/deliver` is the bounded authorization for the routine mechanics throu
 
 Key rules:
 - existing repository branch/PR/CI/merge policy outranks Lean defaults,
+- `required CI` means the configured workflows/checks that apply to the exact commit plus any additional enforced repository policy observable through available tooling,
+- inability to read branch-protection/ruleset admin settings alone is not a human gate and must not be converted into a Settings-page questionnaire; ask only when missing policy data creates a concrete block to merge/release,
 - `/start-work` should establish the short-lived work branch when implementation begins; `/deliver` may recover safely if reviewed work is still on the default branch,
 - PR templates are internal scaffolding and do not require a separate validation ceremony,
 - because implementation was already meaningfully accepted locally, a final PR acceptance prompt does not need to be separate from merge when the PR head/diff still exactly matches that accepted scope,
@@ -40,7 +42,7 @@ Key rules:
 - the explicit `Merge and finalize delivery` choice is both final acceptance of the observed PR and merge authorization,
 - if new commits/material diff changes/conflicts/regressed checks appear, final PR review is required before merge,
 - merge authorization is not production-deployment authorization,
-- for a normal short-lived delivered branch, `Merge and finalize delivery` also authorizes safe local/remote cleanup after required post-merge default-branch CI is observed green,
+- for a normal short-lived delivered branch, `Merge and finalize delivery` also authorizes safe local/remote cleanup after applicable post-merge default-branch CI/policy evidence is satisfied,
 - no second branch-deletion prompt is needed for that delivered branch when the cleanup evidence remains exact and safe,
 - unrelated, accumulated, protected/default, release/integration/environment, policy-retained, changed, or ambiguous branches are preserved,
 - squash/rebase merges require merged-PR/head-SHA evidence before any local force deletion is considered safe,

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

@@ -150,9 +150,17 @@ Stop before/during routine writes for:
 
 Never force-push unless separately and explicitly authorized.
 
-## 7. PR CI
+## 7. PR CI and policy evidence
 
-Inspect repository-required PR checks without asking permission for each recheck.
+Throughout this skill, CI/policy satisfaction means:
+- the repository-configured workflows/checks that apply to the exact PR or default-branch commit have completed successfully; and
+- any additional repository-enforced policy that is observable through available repository/GitHub tooling is also satisfied.
+
+Do not interpret `required` as a mandate to read branch-protection or ruleset admin settings. When those settings are unavailable, use observable workflow/check results, PR mergeability, repository documentation, and any other visible policy evidence.
+
+Do not ask the human to open GitHub Settings and transcribe required-check names merely to continue delivery. Stop only when unavailable policy data creates a concrete ambiguity that actually blocks merge, release, or another consequential action.
+
+Inspect the configured/observable PR CI and checks without asking permission for each recheck.
 
 ### Pending
 
@@ -204,8 +212,8 @@ Mergeable/policy: <observed state>
 Selecting option 1 means:
 - the human accepts the final PR as observed,
 - merge is authorized using the repository-approved strategy,
-- required post-merge default-branch CI may be observed/rechecked automatically,
-- after required post-merge CI is green, the delivered normal short-lived branch may be finalized automatically locally/remotely under the safety rules below.
+- applicable post-merge default-branch CI/policy may be observed/rechecked automatically,
+- after that CI/policy evidence is satisfied, the delivered normal short-lived branch may be finalized automatically locally/remotely under the safety rules below.
 
 Do not present a second `Accept PR?` prompt immediately followed by `Merge?` when the evidence has not changed.
 
@@ -219,9 +227,9 @@ Stop before merge if checks regress, new commits appear, conflicts arise, or pol
 
 ## 9. Post-merge default-branch CI
 
-After authorized merge, inspect the actual configured default branch/workflow automatically.
+After authorized merge, inspect the actual configured default branch/workflows and any observable enforced checks automatically.
 
-If required post-merge CI is pending, use bounded read-only rechecks when practical. If still pending beyond the practical interaction/tool window, report:
+If configured post-merge default-branch CI is pending, use bounded read-only rechecks when practical. If still pending beyond the practical interaction/tool window, report:
 
 ```text
 MERGED — DEFAULT-BRANCH CI PENDING
@@ -232,7 +240,7 @@ Do not ask the human to authorize observation again.
 
 If post-merge CI fails, report it clearly and inspect/diagnose; do not silently revert, modify production, or delete the delivered branch.
 
-Only after required post-merge CI is observed green may delivered-branch finalization proceed. If the repository has no post-merge CI policy, state that explicitly and proceed using the observed merged/default-branch state.
+Only after configured post-merge default-branch CI and any additional observable repository-required checks are satisfied may delivered-branch finalization proceed. If the repository has no post-merge CI workflow/policy, state that explicitly and proceed using the observed merged/default-branch state.
 
 ## 10. Delivered-branch finalization
 
@@ -294,15 +302,15 @@ DELIVERY COMPLETE — BRANCH CLEANUP PENDING
 
 and preserve the branch.
 
-## 12. Production handoff
+## 12. Deployment handoff
 
-If the delivered work item owns production release/deployment, successful engineering delivery may hand off to:
+If the delivered work item owns release/deployment engineering, successful engineering delivery may hand off to:
 
 ```text
-/production-readiness <deployment-enabler-ID> enable
+/deployment-readiness <deployment-enabler-ID> enable [environment]
 ```
 
-Merge approval never implies production-deployment authorization.
+The readiness workflow is environment-generic. Production remains an environment role with stronger policy; merge approval never implies remote or production-deployment authorization.
 
 ## 13. Relationship to /start-work, /next-step, and /cleanup-branches
 

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

@@ -39,7 +39,7 @@ tools/lean-deployment/lean-poc-deploy.py
 
 over reconstructing Deployment Kit commands by hand or requiring a separate Kit checkout.
 
-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.
+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 `/deployment-readiness` as appropriate.
 
 ## 2. Select an environment explicitly
 
@@ -52,17 +52,17 @@ 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 a named environment is not configured, fail explicitly;
+- if a named environment is not configured, fail explicitly and route to `/deployment-readiness`;
 - selecting an environment chooses scope but does not authorize the deployment write.
 
-## 3. Resolve and verify the target binding
+## 3. Resolve and verify the machine/target binding
 
-Treat these as separate concepts:
+Keep the human-facing identity simple while preserving the stronger internal model:
 
 ```text
 named environment
-→ configured target binding
-→ stable logical/SSH identity
+→ confirmed machine hostname/address
+→ configured target/profile binding
 → current address discovery
 → independently verified host identity
 ```
@@ -71,14 +71,15 @@ Address discovery is not host trust.
 
 Before remote deployment:
 
-- verify the selected environment resolves to its configured target;
-- use the repository-approved stable logical target rather than a guessed transient address;
+- verify the selected environment resolves to the configured machine/target established by readiness;
+- show the confirmed hostname/address when appropriate rather than asking the human to reconstruct an internal `targetName`;
+- use the repository-approved stable internal target/profile 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 actual target OS compatibility before target-specific behavior.
 
-Changing an environment's target is readiness/configuration work, not deployment fallback.
+Changing an environment's machine/target binding 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.
 
@@ -130,7 +131,7 @@ DEPLOYMENT READY
 
 Environment: <name>
 Role: <production|non-production>
-Target: <verified logical target>
+Machine: <confirmed hostname/address>
 Target OS: <verified>
 Launcher: <repository-provided command>
 Deployment baseline: <exact commit/distribution when present>
@@ -139,6 +140,8 @@ Required authorization: <exact tool phrase or repository gate>
 Readiness blockers: NONE
 ```
 
+Include an internal target/profile label only when it materially helps disambiguate the exact machine or tool plan. Do not make that identifier the primary human-facing identity.
+
 For a non-production deployment ask for one bounded authorization covering the exact reviewed plan and required tool phrase.
 
 For production require the project's explicit production deployment gate and the exact installed tool phrase. Keep the consequence visible as:
@@ -164,7 +167,7 @@ After execution, use repository-provided readiness/smoke/evidence commands when
 Report only evidence-backed outcomes:
 
 - selected environment;
-- verified target identity/label;
+- verified machine/target identity;
 - deployment baseline/tool identity when relevant;
 - release/artifact identity;
 - deployment result;