@mriekki/lean 0.2.1 → 0.3.1

package/assets/generated/core/core/skills/deployment-readiness/SKILL.md

@@ -0,0 +1,369 @@
+---
+name: deployment-readiness
+description: Guided readiness for any named deployment environment. Discovers and confirms simple machine facts first, verifies access/trust safely, repairs only missing setup, and hands ready environments to /deploy.
+argument-hint: "[deployment-enabler-ID] [status|discovery|enable|resume] [environment]"
+user-invocable: true
+disable-model-invocation: true
+---
+
+# Deployment Readiness
+
+`/deployment-readiness` is the reusable operational workflow for preparing named deployment environments such as Staging, Production, test, demo, or another repository-approved environment.
+
+It is not a deployment executor and it is not a production-only workflow. Production is an environment role/policy with stronger gates, not a separate readiness mechanism.
+
+Modes:
+
+```text
+status
+discovery
+enable
+resume
+```
+
+## 1. Resolve minimum context
+
+Read `.github/lean-workspace.json` when present plus only the relevant deployment enabler requirements/decisions/readiness record, release/deployment guidance, environment configuration contract, current package/deployment baselines, and repository-provided deployment tooling.
+
+A deployment-enabler ID may be inferred from current repository/work-item context when it is unambiguous. Do not force the human to restate an already-known ID.
+
+Do not assume:
+
+- there is only one deployment environment;
+- an environment named `production` exists;
+- a particular local configuration filename;
+- target OS/runtime/hostname/IP;
+- SSH alias or discovery mechanism;
+- certificate model or hosting environment.
+
+## 2. Human-facing information model
+
+Keep the interaction centered on facts a person normally knows about the selected environment's machine:
+
+```text
+environment name / role
+hostname or IP address
+SSH/deployment user when applicable
+SSH port when non-default or already configured
+target OS when known
+```
+
+Deployment tooling may internally require identifiers and files such as a logical target name, `targetName`, SSH alias, profile path, identity-file path, known-hosts path, address override, or trust record. Those are implementation details.
+
+**Do not ask the human to invent or transcribe `targetName`, an SSH alias, profile filename/path, known-hosts filename/path, or similar deployment-tool plumbing when the workflow can discover, reuse, or derive it.**
+
+Do not lead with questions such as `What is the logical target name?`. If an internal saved-machine/profile identifier must eventually be chosen and cannot be derived safely from existing state or confirmed machine facts, explain it in plain language, recommend a sensible stable value, and ask only at that point.
+
+Never use an application-specific example to imply that a reusable machine identity belongs to one POC. A machine/profile may legitimately be reused by multiple POCs while each POC keeps independent environment bindings, application state, data, routes, and deployment evidence.
+
+## 3. Discover first, then ask only for missing facts
+
+Invocation begins read-only.
+
+Before asking environment-specific setup questions, inspect available non-secret local/repository state to determine whether the selected environment is already configured on this workstation. Use repository-provided readiness helpers and installed deployment tooling when available.
+
+Local discovery may inspect, as applicable:
+
+- configured named environments and their roles;
+- existing environment-to-machine/target binding;
+- user-scoped deployment target/profile metadata;
+- hostname/address/discovery data already recorded;
+- SSH/deployment user and port metadata;
+- expected target OS;
+- existing readiness evidence;
+- whether required key/trust/profile files exist, without exposing secret contents.
+
+Do not probe the remote machine merely to fill in this summary. Remote checks have their own authorization below.
+
+Classify the selected environment locally as one of:
+
+```text
+CONFIGURED — enough local state exists to attempt verification
+PARTIAL — some setup exists but required local state is missing/inconsistent
+NOT CONFIGURED — no usable workstation setup exists for this environment
+```
+
+### Existing configuration
+
+When usable configuration already exists, show the simple known facts and ask for confirmation instead of asking the human to reconstruct them:
+
+```text
+STAGING SETUP FOUND
+
+Hostname/address: <known value>
+SSH user: <known value or not applicable>
+SSH port: <known/non-default value when useful>
+Target OS: <known/expected value when useful>
+Local setup: CONFIGURED
+
+1. Yes — verify connectivity and identity [REMOTE READ ONLY]
+2. Something changed — update the facts
+3. Reconfigure/repair this PC
+4. Stop
+```
+
+Use the actual selected environment name rather than hardcoding `Staging`.
+
+If a hostname and a currently observed/cached IP are both available, they may both be shown. Make clear that an address is connectivity information, not trusted host identity.
+
+### Partial configuration
+
+Show what is already known and identify the smallest missing piece. Do not restart onboarding or ask for values that are already present and internally consistent.
+
+Examples:
+
+```text
+Hostname/address: server.example.local
+SSH user: deploy
+Missing: trusted host identity
+```
+
+or:
+
+```text
+Hostname/address: NOT SET
+SSH user: deploy
+```
+
+Ask only for the next unresolved simple fact or authorization needed to repair that state.
+
+### No configuration
+
+Do not ask for a logical target/profile identifier first. Start with the machine:
+
+```text
+STAGING IS NOT CONFIGURED ON THIS PC
+
+What hostname or IP address should Staging use?
+```
+
+Then ask one material fact at a time, such as the SSH/deployment user, only when it is not already defined by repository policy or reusable workstation configuration.
+
+Once the human-facing machine facts are known, use repository/Deployment-Kit tooling to create the required internal profile/binding. Prefer deriving/reusing a stable internal identifier from confirmed state when the installed tooling supports it. Surface that identifier only when ambiguity or troubleshooting makes it useful.
+
+## 4. Mode boundaries
+
+### status
+
+Read-only overview.
+
+With an environment, summarize that environment's local configuration/readiness state.
+
+Without an environment, summarize all configured named deployment environments without remotely probing every machine:
+
+```text
+Environment   Role            Local setup     Last readiness
+Staging       non-production  CONFIGURED      READY / STALE / UNKNOWN
+Production    production      PARTIAL         NOT READY
+```
+
+Use only evidence that actually exists. `status` does not authorize remote checks or writes.
+
+### discovery
+
+May begin early after the application's foundation/walking skeleton is proven.
+
+Purpose:
+
+- identify intended named deployment environments and their roles;
+- discover/reuse existing workstation setup before asking questions;
+- confirm simple machine facts with the human;
+- discover each selected environment's real target and expected target OS;
+- identify access/security/network/TLS/certificate dependencies;
+- establish the environment-to-target readiness contract without embedding secrets in reusable source;
+- record non-secret facts in the repository-approved place;
+- surface blockers early.
+
+Discovery does not authorize remote writes or application deployment.
+
+### enable
+
+Require evidence that deployment engineering completed the normal delivery path, including applicable requirements/review/merge/default-branch CI and repository-policy evidence.
+
+Enablement prepares the selected environment so `/deploy` can safely use it. It does not itself authorize application deployment.
+
+### resume
+
+Continue from existing environment-specific readiness evidence. Re-discover current local state first and do not re-ask facts that remain valid.
+
+## 5. Select the environment before environment-specific readiness
+
+When more than one configured deployment environment exists, select the environment being discovered or enabled before environment-specific questions or remote checks.
+
+Keep these concepts separate internally even when the human-facing interaction stays simple:
+
+```text
+named environment
+→ environment role/policy
+→ configured machine/target binding
+→ current hostname/address discovery
+→ independently verified host identity
+```
+
+A non-production Staging target and a Production target may use the same deployment implementation while retaining independent target bindings, data, credentials, readiness evidence, and deployment policy.
+
+Never let one environment silently fall back to another because discovery/access/readiness fails.
+
+## 6. Session authorization and cadence
+
+Local read-only discovery is automatic.
+
+When focused readiness-document updates are useful, present one bounded session choice rather than asking after every answer. Never record secret values.
+
+Once a modifying readiness session is authorized:
+
+```text
+discover existing state
+→ show/confirm known simple facts
+→ ask one missing material fact
+→ record permitted non-secret fact
+→ explain impact/blocker
+→ continue
+```
+
+Use concise choices for bounded decisions. Ask factual values such as hostname/IP, username, port, OS/version, path, or observed system state as direct free-form/confirmation questions.
+
+## 7. Verify connectivity and host identity
+
+After the human confirms the selected machine, ask or use the explicit choice:
+
+```text
+Verify connectivity and identity for <environment>? [REMOTE READ ONLY]
+```
+
+Only after authorization may remote inspection occur.
+
+Prefer repository-provided/Deployment-Kit doctor and verify commands over reconstructing SSH commands by hand.
+
+When SSH is the approved transport:
+
+- current hostname/IP is an address, not host identity;
+- preserve strict host-key verification;
+- independently verified host identity/trust is required before readiness;
+- an unknown or changed host key fails closed;
+- DHCP/mDNS/address changes must not cause trust weakening;
+- do not scan the LAN, silently choose another host, disable strict checking, or autoaccept a replacement host key.
+
+Allowed read-only verification may include OS/version, architecture, current identity/groups, approved runtime state, disk/memory, listening ports, and existence/ownership of approved paths when relevant.
+
+## 8. Existing PC, partial setup, and new PC
+
+Follow this decision model:
+
+```text
+local discovery
+│
+├─ configured + strict verify succeeds
+│    → reuse existing access
+│    → skip onboarding/setup questions
+│
+├─ partial/broken
+│    → diagnose exact missing state
+│    → repair only that state after the applicable bounded authorization
+│    → strict verify again
+│
+└─ not configured
+     → ask simple machine facts
+     → create required local profile/key/agent/trust/binding through approved tooling
+     → strict verify
+```
+
+Possible missing state includes profile/binding, key, SSH-agent membership, independently verified trust, target-side public-key authorization, address discovery, or another repository/tool prerequisite.
+
+Do not create duplicate credentials merely because another POC uses the same machine. Reuse an already-valid developer-to-machine relationship when the installed tooling and policy allow it.
+
+## 9. Network, security, DNS, TLS, runtime, and storage
+
+After basic machine/access facts are established, discover/verify only what the selected environment's approved role requires, such as:
+
+- actual target OS/version/architecture;
+- runtime/container support;
+- storage/data/backup paths;
+- inbound/outbound network dependencies;
+- firewall/security approvals;
+- DNS/server name;
+- HTTP/HTTPS and TLS/certificate model;
+- registry/artifact access;
+- migration/readiness/smoke/rollback/recovery prerequisites.
+
+Do not front-load these questions before basic environment/machine identity is understood.
+
+## 10. Bounded setup/provisioning writes
+
+A missing prerequisite is not authorization to change it.
+
+Examples of bounded actions include:
+
+```text
+Create/update local environment binding [LOCAL CONFIG WRITE]
+Create local deployment key [LOCAL KEY WRITE]
+Add key to SSH agent [SSH AGENT WRITE]
+Enroll independently verified host trust [LOCAL TRUST WRITE]
+Authorize public key on target [SECURITY / REMOTE WRITE]
+Install/upgrade runtime [REMOTE WRITE]
+Create data/backup directories [REMOTE WRITE]
+Configure firewall [SECURITY / REMOTE WRITE]
+Configure registry credential [SECRET / REMOTE WRITE]
+Set source-hosting environment variable/secret [SOURCE-HOSTING WRITE]
+```
+
+Use the installed repository/tool's exact authorization phrase when it defines one. Do not weaken or replace that contract with a generic label.
+
+## 11. Environment deployment readiness
+
+Before declaring the selected environment ready for `/deploy`, verify the evidence required by its approved role/policy.
+
+Common evidence includes:
+
+- selected environment and confirmed machine/target binding;
+- strict connectivity/host-identity verification;
+- supported developer-workstation launcher;
+- expected target OS matches actual target OS;
+- approved release/artifact policy;
+- immutable artifact/image digest when applicable;
+- artifact/registry access;
+- independent environment data/backup paths;
+- migration path;
+- deployment lock behavior;
+- readiness and smoke checks;
+- application rollback;
+- explicit database-restore/recovery boundary;
+- unresolved security blockers = none.
+
+A non-production environment may use a less restrictive artifact policy only when approved requirements say so. Do not infer relaxed Staging behavior.
+
+## 12. Readiness handoff
+
+For any selected environment that is ready:
+
+```text
+ENVIRONMENT READY FOR DEPLOYMENT WORKFLOW
+
+Environment: <name>
+Role: <role>
+Hostname/address: <confirmed non-secret value when appropriate>
+Target OS/architecture: <verified>
+Access/host identity: VERIFIED
+Release/artifact policy: <verified>
+Security blockers: NONE
+Readiness/Smoke: READY
+Rollback: READY
+
+NEXT
+/deploy <environment>
+```
+
+For a production-role environment, include the additional production policy/backup/recovery evidence required by the project, but do not change the readiness mechanism or command name.
+
+This is readiness evidence, not deployment authorization. `/deploy` owns the actual deployment write gate for the exact environment, verified target, artifact, and current evidence.
+
+## 13. Post-readiness
+
+Once an environment is ready:
+
+- record non-secret readiness evidence in the repository-approved place;
+- keep readiness independent from other environments;
+- use `/deploy [environment]` for repeatable deployment;
+- return to `/deployment-readiness` when machine binding, address, expected OS/runtime, security posture, credentials, or another material prerequisite changes.
+
+Application rollback, database restore/destructive recovery, and environment tear-down remain separately governed when data safety warrants it.

package/assets/generated/core/core/skills/next-step/SKILL.md

@@ -146,7 +146,7 @@ After merge:
 For a release/deployment engineering enabler after engineering delivery is complete, recommend:
 
 ```text
-/production-readiness <deployment-enabler-ID> enable [environment]
+/deployment-readiness <deployment-enabler-ID> enable [environment]
 ```
 
 when the selected environment still needs operational discovery/enablement.
@@ -157,7 +157,13 @@ When evidence shows a configured named environment is ready for deployment, reco
 /deploy [environment]
 ```
 
-rather than treating `/production-readiness` as the normal application-deployment executor.
+rather than treating `/deployment-readiness` as the application-deployment executor.
+
+When the user asks for readiness across configured environments, recommend the read-only overview:
+
+```text
+/deployment-readiness <deployment-enabler-ID> status
+```
 
 Do not infer readiness of one environment from another. Production is never an implicit/default environment, and `/next-step` never authorizes a remote or production deployment merely by recommending `/deploy`.
 

package/assets/generated/core/core/skills/start-work/SKILL.md

@@ -47,6 +47,14 @@ If local requirements are DRAFT and carry material behavior, human approval is t
 
 If requirements are already sufficient/approved under the configured model, do not force another refinement cycle.
 
+### CI/policy evidence is not a start-work gate
+
+When requirements say CI/checks must pass before a later merge, release, or deployment action, use repository-configured workflows/checks plus observable repository policy/mergeability as the planning evidence available now.
+
+Do not interpret words such as `required CI` or `required checks` as a mandate to discover GitHub branch-protection/ruleset admin settings before implementation can begin. Those settings may provide additional evidence later when they are observable, but inability to read them is not by itself a blocker.
+
+Do not ask the human to open GitHub Settings and transcribe required-check names merely to proceed with `/start-work`. Stop and ask only when actual evidence conflicts or missing policy information creates a concrete unresolved decision that materially affects implementation or the later consequential action.
+
 ## 3. Classify risk
 
 ### LIGHT
@@ -147,24 +155,26 @@ Stop and ask only when branch policy/naming is materially ambiguous, the intende
 
 For LIGHT work, branch setup is part of the human-selected implementation action. For STANDARD/ELEVATED work, it is part of the approved implementation start after plan approval. Merely inspecting `/start-work` does not authorize implementation before its required gate.
 
-## 7. Production deployment enabler
+## 7. Deployment enabler
 
-When a work item owns production release/deployment, classify it ELEVATED.
+When a work item owns release/deployment engineering or environment enablement, classify it ELEVATED when the change materially affects deployment/recovery/security behavior.
 
-Production target discovery may begin early with:
+Environment discovery may begin early with:
 
 ```text
-/production-readiness <deployment-enabler-ID> discovery
+/deployment-readiness <deployment-enabler-ID> discovery [environment]
 ```
 
-Discovery is non-destructive and does not authorize production writes.
+Discovery begins with existing local/repository configuration, shows simple known machine facts for confirmation, and does not authorize remote writes or deployment.
 
-After implementation review/local acceptance, use `/deliver`. After merge and required post-merge default-branch CI is green, hand off to:
+After implementation review/local acceptance, use `/deliver`. After `/deliver` reports the merge, default-branch CI, and applicable repository-policy evidence satisfied, hand off to:
 
 ```text
-/production-readiness <deployment-enabler-ID> enable
+/deployment-readiness <deployment-enabler-ID> enable [environment]
 ```
 
+Production remains a role with stronger policy and deployment authorization; it does not use a separate readiness workflow.
+
 ## 8. Guided ending
 
 Return:

package/package.json

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

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

@@ -1,59 +0,0 @@
-# Production Enablement
-
-Production enablement is a guided operational lane separate from ordinary engineering delivery.
-
-A repository may have multiple named deployment environments, for example a non-production staging/portable environment and a true production environment. Each environment owns its own verified target binding, readiness evidence, data/backup state, credentials, and deployment policy.
-
-Use:
-
-```text
-/production-readiness <deployment-enabler-ID> discovery [environment]
-```
-
-early enough to discover real target dependencies.
-
-After deployment engineering is reviewed, delivered, merged, and required post-merge default-branch CI is green, use:
-
-```text
-/production-readiness <deployment-enabler-ID> enable [environment]
-```
-
-The readiness workflow covers:
-
-- named environment role/policy,
-- actual target OS/version/architecture/host discovery,
-- stable environment-to-target binding,
-- deployment identity/access,
-- SSH host-trust and portable-addressing safety when SSH is used,
-- developer-machine and source-hosting/CI read-only checks,
-- optionally authorized read-only remote target checks,
-- runtime/storage/data/backup readiness,
-- network/firewall/security/DNS/TLS/certificate readiness,
-- external blockers,
-- separately authorized bounded provisioning/configuration,
-- approved release/artifact policy,
-- migration/readiness/smoke/rollback evidence.
-
-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.
-
-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 target.
-
-Once the selected environment is ready, the repeatable deployment entry point is:
-
-```text
-/deploy [environment]
-```
-
-`/deploy` requires explicit environment selection when omitted, verifies the environment/target/artifact evidence, dispatches to the repository-provided platform-appropriate deployment launcher, and presents the applicable write gate immediately before execution.
-
-Production is never an implicit/default deployment target. A production-role deployment requires a distinct `[PRODUCTION WRITE]` authorization for the exact environment, verified target, release/artifact, and current evidence shown by `/deploy`.
-
-A non-production remote deployment still requires bounded `[REMOTE WRITE]` authorization.
-
-Developer workstation OS and deployment target OS are separate dimensions. A repository may provide PowerShell on Windows and shell on macOS/Linux while both invoke equivalent deployment behavior against an approved Ubuntu target. Future Windows/macOS target support requires target-specific implementation/readiness; common SSH transport alone does not establish runtime/deployment parity.
-
-Remote read-only authorization never implies permission for writes.
-
-No requirements approval, Reviewer verdict, PR merge, CI result, environment selection, readiness result, or previous deployment implies production-deployment authorization.
-
-Secret values stay out of tracked documentation and logs. Database restore/destructive recovery remains a separate decision when data safety warrants it.