@mriekki/lean 0.4.3 → 0.4.5

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

@@ -1,6 +1,6 @@
 ---
 name: deployment-readiness
-description: Guided readiness for any named deployment environment. Discovers current state, verifies access and pre-deploy prerequisites, repairs only missing setup, and hands environments that are ready to deploy to /deploy.
+description: Guided readiness for any named deployment environment. Resolves logical topology first, verifies only placement-relevant prerequisites, treats deferred deployment as intentional state, and hands ready environments to /deploy.
 argument-hint: "[environment] | status [environment]"
 user-invocable: true
 disable-model-invocation: true
@@ -8,337 +8,291 @@ 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.
+`/deployment-readiness` prepares one named deployment environment without assuming that an environment is a physical computer.
 
-It is not the application deployment executor and it is not production-only. Production is an environment role/policy with stronger gates, not a separate readiness mechanism.
+Logical environment purpose/role, placement, isolation, exposure, and concrete target/provider binding are separate facts.
 
-The normal human-facing invocation is:
+Normal invocation:
 
 ```text
 /deployment-readiness <environment>
 ```
 
-The workflow is state-driven and resumable. It discovers whether the environment is unconfigured, partially configured, access-ready, platform-ready, or ready to deploy, then continues from the furthest safe observed state. Do not require the human to choose `discovery`, `enable`, or `resume` modes.
-
-For a read-only overview, support:
+Read-only overview:
 
 ```text
 /deployment-readiness status [environment]
 ```
 
-For compatibility, if an older invocation includes a deployment-enabler ID and/or the legacy `discovery`, `enable`, or `resume` token, normalize it to the same state-driven workflow rather than forcing the human to restart. Do not advertise those legacy forms as the normal interface.
-
-## 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.
+Production is a policy/authorization role with stronger gates, not a separate readiness mechanism. Do not silently default to Production.
 
-If the invocation does not name an environment and more than one configured environment exists, ask the human to select one. Never silently default to Production.
+## 1. Resolve current repository topology first
 
-## 2. Human-facing information model
+Read `.github/lean-workspace.json` when present plus only the relevant deployment requirements/decisions/readiness record, `POC_BOOTSTRAP.json` deployment topology, release/deployment guidance, current package/deployment baselines, and repository-provided deployment tooling.
 
-Keep the interaction centered on facts a person normally knows about the selected environment's machine:
+Resolve, when repository evidence provides them:
 
 ```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
+environment name
+role / purpose
+placement
+isolation
+exposure
+binding state
+adapter
+target/provider binding
+failure domain
 ```
 
-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.**
+Never infer missing topology merely from an environment name.
 
-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.
+Do not assume:
 
-### Application route/address defaults
+- a second computer exists;
+- the developer is on a trusted/home LAN;
+- Staging or Production exists;
+- Staging and Production use different physical machines;
+- deployment uses SSH;
+- a remote target exists;
+- a managed provider is supported;
+- a deferred binding is broken configuration.
 
-Keep the machine's hostname/address separate from the application's route hostname. A target such as `server.local` may host many POCs, while each application owns its own route aliases.
+If more than one environment exists and the invocation does not select one, ask the human to choose one.
 
-When the repository or installed deployment tooling defines a deterministic application-route convention from stable inputs such as `appSlug + environment`, derive and present that exact conventional set before asking for a free-form hostname. Treat the derived values as recommended defaults for confirmation, not as permission to register or change a route.
+## 2. Placement determines the readiness branch
 
-For example, if the installed trusted-LAN deployment contract defines environment-scoped aliases such as:
+After local read-only discovery, route to exactly one placement branch:
 
 ```text
-<app-slug>-<environment>.local
-<app-slug>.<environment>.local
+workstation
+remote-target
+managed-service
+deferred
 ```
 
-present the concrete derived values in plain language:
+If older repositories lack the richer topology fields, infer the minimum compatible branch only from explicit legacy deployment configuration. For example, an explicit SSH target binding can establish `remote-target`; an environment name alone cannot.
 
-```text
-STAGING APPLICATION ADDRESS
+### A. Workstation placement
 
-Recommended defaults:
-  <derived alias 1>
-  <derived alias 2>
+A workstation environment is local application deployment, not remote-machine onboarding.
 
-1. Use these defaults — recommended
-2. Choose different hostnames
+For the current reusable `workstation-container` adapter:
+
+```text
+placement: workstation
+isolation: container
+exposure: loopback
 ```
 
-Do not ask `What route hostname(s) should this environment use?` while a repository/tool-owned deterministic default is available and no collision or policy conflict has been observed.
+Readiness should inspect only relevant non-secret local facts such as:
 
-If the installed convention requires multiple compatibility aliases, preserve the complete default set. Do not silently drop one alias. If the convention defines an optional short alias with a larger collision surface, do not infer or add it; present it only when the repository/tool contract calls for an explicit opt-in.
+- compatible Docker CLI/engine availability;
+- repository/materialized `lean-poc-deploy local` support;
+- exact immutable application image/artifact identity when already built/published;
+- requested host/runtime port and health path when project-owned deployment facts exist;
+- local port/Lean-container ownership collision evidence;
+- persistence path/ownership prerequisites when applicable;
+- Production-specific policy if this logical environment is Production.
 
-If the user rejects the defaults, or a read-only collision/policy check shows they cannot be used, ask for the smallest unresolved custom value and validate it through the installed tool's hostname contract.
+Do **not** ask for hostname, SSH user, SSH port, target OS, target profile, host trust, Caddy route, Avahi, or remote credentials for a workstation-container environment.
 
-Selecting or confirming application route hostnames is configuration/readiness work only. It never authorizes DNS changes, route registration, Caddy changes, or another remote write; those retain their repository/tool-specific write gate.
+The current reusable adapter is loopback-only. Readiness must not widen it to LAN/public exposure or suggest that loopback readiness satisfies a shareable/public deployment outcome.
 
-## 3. Discover first, then ask only for missing facts
+A successful workstation readiness handoff may look like:
 
-Invocation begins read-only.
+```text
+ENVIRONMENT READY TO DEPLOY
 
-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.
+Environment: Demo
+Role: non-production
+Placement: workstation
+Isolation: container
+Exposure: loopback
+Docker: READY
+Artifact: <exact immutable identity when required>
+Port ownership: AVAILABLE
+Persistence prerequisites: READY / NOT APPLICABLE
+Security blockers: NONE
 
-Local discovery may inspect, as applicable:
+POST-DEPLOY VALIDATION PENDING
+Loopback route/health evidence is established by /deploy.
 
-- 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.
+NEXT
+/deploy demo
+```
+
+### B. Remote-target placement
 
-Do not probe the remote machine merely to fill in this summary. Remote checks have their own authorization below.
+Use the existing strict remote-target workflow.
 
-Classify the selected environment locally as one of:
+Keep these concepts separate:
 
 ```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
+named environment
+→ environment role/policy
+→ logical target binding
+→ current address/discovery
+→ independently verified host identity
 ```
 
-### Existing configuration
-
-When usable configuration already exists, show the simple known facts and ask for confirmation instead of asking the human to reconstruct them:
+Human-facing machine facts normally include:
 
 ```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
+hostname or IP address
+SSH/deployment user when applicable
+SSH port when non-default or already configured
+target OS when known
 ```
 
-Use the actual selected environment name rather than hardcoding `Staging`.
+Internal target/profile identifiers, SSH aliases, identity-file paths, known-hosts paths, and trust records are implementation details. Do not ask the human to invent or transcribe them when repository/Deployment-Kit tooling can discover, reuse, or derive them.
 
-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.
+A remote machine/profile may be reused by multiple POCs or multiple logical environments. Each POC/environment still retains independent runtime, route, data, evidence, and policy identity.
 
-### Partial configuration
+Before asking questions, inspect available non-secret local state:
 
-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.
+- environment-to-target binding;
+- user-scoped target/profile metadata;
+- address/discovery data;
+- SSH/deployment user/port;
+- expected target OS;
+- key/trust/profile presence without exposing secret contents;
+- prior readiness evidence.
 
-Examples:
+Classify local remote-target setup as:
 
 ```text
-Hostname/address: server.example.local
-SSH user: deploy
-Missing: trusted host identity
+CONFIGURED
+PARTIAL
+NOT CONFIGURED
 ```
 
-or:
+When configured, show known simple facts for confirmation rather than asking the human to reconstruct them. When partial, identify only the smallest missing fact. When absent, start with the actual machine hostname/address—not an internal logical profile name.
 
-```text
-Hostname/address: NOT SET
-SSH user: deploy
-```
-
-Ask only for the next unresolved simple fact or authorization needed to repair that state.
+Only after explicit `[REMOTE READ ONLY]` authorization may remote checks occur.
 
-### No configuration
+When SSH is the approved transport:
 
-Do not ask for a logical target/profile identifier first. Start with the machine:
+- current address is connectivity information, not trusted identity;
+- preserve strict host-key verification;
+- independently verified trust is required;
+- unknown/changed host identity fails closed;
+- never scan the LAN, silently choose another host, disable strict checking, or autoaccept a replacement key.
 
-```text
-STAGING IS NOT CONFIGURED ON THIS PC
+Read-only remote evidence may include OS/version, architecture, identity/groups, runtime state, disk/memory, listening ports, and approved path ownership when relevant.
 
-What hostname or IP address should Staging use?
-```
+#### Route defaults
 
-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.
+Keep machine hostname/address separate from application route hostname.
 
-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.
+If installed tooling defines deterministic route defaults from stable inputs such as `appSlug + environment`, derive and present those defaults before asking for free-form hostnames. Confirmation does not authorize route registration/Caddy/DNS changes.
 
-## 4. State-driven progression
+Trusted-LAN `.local` aliases are relevant only when the selected topology/adapter actually uses that convention. Do not present them for workstation, public-VPS, private-VPN, or provider-managed topologies that do not use it.
 
-Normal readiness cadence is:
+### C. Managed-service placement
 
-```text
-select environment
-→ rediscover current local state
-→ show/confirm known simple facts
-→ verify/reuse access
-→ repair only missing setup when authorized
-→ verify target OS/platform/security prerequisites
-→ verify artifact/registry/data/migration/rollback capability prerequisites
-→ ENVIRONMENT READY TO DEPLOY
-→ /deploy <environment>
-```
+Managed service is adapter-specific.
 
-Each invocation resumes from observed evidence. Do not make the human rerun the command with a different mode merely because discovery completed or a prerequisite was repaired.
+Before provider questions or API calls, require repository/catalog evidence for an implemented provider adapter and its credential/readiness contract.
 
-Readiness may perform bounded environment-enablement writes when they are necessary and separately authorized, such as local profile/key/trust setup, target-side access setup, runtime/platform prerequisite setup, data/backup directory preparation, firewall preparation, or registry credential setup. These are readiness/setup operations, not application deployment.
-
-Application deployment remains owned by `/deploy`.
-
-### Read-only status
-
-`/deployment-readiness status [environment]` is a 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:
+If no such adapter exists:
 
 ```text
-Environment   Role            Local setup     Last readiness
-Staging       non-production  CONFIGURED      READY TO DEPLOY / STALE / UNKNOWN
-Production    production      PARTIAL         NOT READY
-```
+DEPLOYMENT BINDING NOT YET SUPPORTED
 
-Use only evidence that actually exists. `status` does not authorize remote checks or writes.
+Environment: <name>
+Desired placement: managed-service
+Status: CATALOG GAP / PLANNED
 
-## 5. Select the environment before environment-specific readiness
+No provider credentials requested.
+No provisioning attempted.
+```
 
-When more than one configured deployment environment exists, select the environment before environment-specific questions or remote checks.
+Do not improvise provider setup from general model knowledge and do not convert this into generic cloud support.
 
-Keep these concepts separate internally even when the human-facing interaction stays simple:
+If a future repository-provided adapter exists, follow that adapter's exact read-only checks, credential boundary, and write gates.
 
-```text
-named environment
-→ environment role/policy
-→ configured machine/target binding
-→ current hostname/address discovery
-→ independently verified host identity
-```
+### D. Deferred placement
 
-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.
+`placement: deferred` / `bindingState: deferred` is intentional state.
 
-Never let one environment silently fall back to another because discovery/access/readiness fails.
+Return a non-error status such as:
 
-## 6. Session authorization and cadence
-
-Local read-only discovery is automatic.
+```text
+DEPLOYMENT INTENTIONALLY DEFERRED
 
-When focused readiness-document updates are useful, present one bounded session choice rather than asking after every answer. Never record secret values.
+Environment: Demo
+Desired outcome: Shareable demo
+Placement: DEFERRED
+Reason: no supported/selected target or provider binding yet
 
-Once a modifying readiness session is authorized:
+Local development, CI, documentation, and learning are not blocked.
 
-```text
-discover existing state
-→ show/confirm known simple facts
-→ ask one missing material fact
-→ record permitted non-secret fact
-→ explain impact/blocker
-→ continue from the resulting state
+NEXT WHEN READY
+Choose/configure a supported deployment target or provider adapter, then rerun:
+/deployment-readiness demo
 ```
 
-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.
+Do not mark workspace readiness failed. Do not provision infrastructure, guess a provider, or ask for secrets merely to make the status green.
 
-## 7. Verify connectivity and host identity
+## 3. Shared failure domains / colocated environments
 
-After the human confirms the selected machine, ask or use the explicit choice:
-
-```text
-Verify connectivity and identity for <environment>? [REMOTE READ ONLY]
-```
+Multiple logical environments may share one physical target or provider failure domain.
 
-Only after authorization may remote inspection occur.
+When repository/target evidence shows that, keep each environment independently targetable and surface:
 
-Prefer repository-provided/Deployment-Kit doctor and verify commands over reconstructing SSH commands by hand.
+```text
+TOPOLOGY NOTE
 
-When SSH is the approved transport:
+<env-a> and <env-b> are logically isolated but share physical failure
+ domain <name>. This can be appropriate for POC cost/learning goals,
+but it does not demonstrate host-level Production isolation.
+```
 
-- 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.
+If one environment is Production, its stronger backup/recovery/security/deploy/destructive gates remain fully in force.
 
-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.
+Never infer readiness for one logical environment from another merely because they share hardware.
 
-## 8. Existing PC, partial setup, and new PC
+## 4. State-driven cadence
 
-Follow this decision model:
+Normal cadence is:
 
 ```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
+select environment
+→ read topology
+→ rediscover placement-relevant local state
+→ show/confirm already-known facts
+→ perform authorized read-only verification
+→ repair only missing prerequisites under their exact write gates
+→ ENVIRONMENT READY TO DEPLOY
+→ /deploy <environment>
 ```
 
-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.
+For deferred placement, readiness intentionally stops before the verification/repair stages.
 
-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.
+For workstation placement, no remote access stage exists.
 
-## 9. Pre-deploy readiness versus post-deploy validation
+For remote placement, reuse existing access instead of creating duplicate credentials merely because another POC/environment uses the same machine.
 
-Readiness answers: **can `/deploy` safely perform the selected environment's deployment now?**
+## 5. Read-only status
 
-Before declaring the selected environment ready to deploy, verify only evidence that can exist before the deployment of the selected artifact, such as:
-
-- selected environment and confirmed machine/target binding;
-- strict connectivity/host-identity verification;
-- supported developer-workstation launcher;
-- expected target OS matches actual target OS;
-- shared runtime/platform prerequisites;
-- approved release/artifact policy;
-- immutable artifact/image digest when applicable;
-- artifact/registry accessibility or credential readiness;
-- route names validated and collision-free when the installed routing contract supports read-only inventory/plan checks;
-- independent environment data/backup paths or the approved ability to create/use them;
-- migration capability and prerequisites;
-- deployment lock capability;
-- rollback/recovery capability and required boundaries;
-- production-specific backup/recovery prerequisites when applicable;
-- unresolved security blockers = none.
+`/deployment-readiness status [environment]` performs no remote checks or writes.
 
-Do **not** require evidence that can only be produced by deploying the exact selected artifact. On a first deployment, live application route resolution, application health/readiness, smoke results, deployed-release identity, and execution-backed rollback evidence are post-deploy validation, not pre-deploy blockers.
+Without an environment, summarize all known environments with topology-aware columns, for example:
 
-A previously deployed environment may have historical live evidence, but stale evidence for an older artifact does not prove the new artifact's post-deploy behavior.
+```text
+Environment   Role            Placement      Isolation   Exposure   Binding       Last readiness
+Demo          non-production  workstation    container   loopback   configured    READY / UNKNOWN
+Staging       non-production  remote-target  container   public     configured    STALE / READY
+Production    production      remote-target  container   public     deferred      DEFERRED
+```
 
-A non-production environment may use a less restrictive artifact policy only when approved requirements say so. Do not infer relaxed Staging behavior.
+Use only evidence that exists. Do not manufacture a target for deferred rows.
 
-## 10. Bounded setup/provisioning writes
+## 6. Bounded setup/provisioning writes
 
 A missing prerequisite is not authorization to change it.
 
-Examples of bounded readiness actions include:
+Possible readiness writes include:
 
 ```text
 Create/update local environment binding [LOCAL CONFIG WRITE]
@@ -346,55 +300,74 @@ 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]
+Install/upgrade runtime/platform [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.
+Use repository/tool exact authorization phrases when defined.
+
+Do not hide application deployment inside readiness. In particular, readiness must not start/replace the application runtime, register the final application route, migrate the selected release, or perform release-specific smoke validation. Those belong to `/deploy`.
+
+## 7. Pre-deploy versus post-deploy evidence
+
+Readiness answers: **can `/deploy` safely perform the selected environment's deployment now?**
+
+Verify only evidence that can exist before deploying the selected artifact.
+
+Across placements this may include:
+
+- selected logical environment/role/topology;
+- adapter implementation availability;
+- exact target/provider binding when required;
+- local Docker or strict remote identity/access depending on placement;
+- expected target OS/runtime where applicable;
+- artifact policy and immutable artifact identity;
+- registry/artifact accessibility;
+- route/port ownership availability;
+- data/backup/migration prerequisites;
+- deployment lock/recovery capability;
+- Production-specific backup/recovery/security prerequisites;
+- unresolved security blockers = none.
+
+Do not require first-deployment live route, application health, smoke, deployed-release identity, or execution-backed rollback evidence before deployment. Those are post-deploy validation.
+
+## 8. Production policy
+
+Production is logical policy, not hardware count.
+
+A Production environment may be on a dedicated host, a shared VPS, or another supported placement. None of those choices weakens Production authorization.
+
+Readiness must include project-required Production backup/recovery/security evidence and explicitly report any shared physical failure domain.
 
-Do not register the application route, deploy the application container/process, migrate the selected release, or run release-specific live smoke validation as a hidden readiness side effect. Those belong to `/deploy` when the repository deployment contract includes them.
+Readiness itself never authorizes Production deployment.
 
-## 11. Readiness handoff
+## 9. Final handoff
 
-For any selected environment that has satisfied its pre-deploy requirements:
+When pre-deploy requirements are satisfied, report the topology and only placement-relevant evidence:
 
 ```text
 ENVIRONMENT READY TO DEPLOY
 
 Environment: <name>
 Role: <role>
-Hostname/address: <confirmed non-secret value when appropriate>
-Target OS/architecture: <verified>
-Access/host identity: VERIFIED
+Purpose: <purpose when known>
+Placement: <workstation|remote-target|managed-service>
+Isolation: <...>
+Exposure: <...>
+Binding: VERIFIED / LOCAL / provider-specific
+Access/identity: VERIFIED / NOT APPLICABLE
 Platform prerequisites: READY
-Route identity/plan: VALID / AVAILABLE when applicable
-Release/artifact: <verified immutable identity when required>
-Registry/artifact access: READY when applicable
-Persistence/migration capability: READY
-Rollback/recovery capability: READY
+Artifact: <verified immutable identity when required>
+Persistence/recovery prerequisites: READY / NOT APPLICABLE
 Security blockers: NONE
 
 POST-DEPLOY VALIDATION PENDING
-Live route/health/smoke/release-specific rollback evidence is established by /deploy.
 
 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 pre-deploy readiness evidence, not deployment authorization. `/deploy` owns the actual deployment write gate for the exact environment, verified target, artifact, and current evidence.
-
-## 12. Post-readiness
-
-Once an environment is ready to deploy:
-
-- record non-secret readiness evidence in the repository-approved place when useful;
-- keep readiness independent from other environments;
-- use `/deploy <environment>` for the application deployment and release-specific live validation;
-- return to `/deployment-readiness <environment>` when machine binding, address, expected OS/runtime, security posture, credentials, registry access, data prerequisites, or another material pre-deploy prerequisite changes.
-
-Application rollback execution, database restore/destructive recovery, and environment tear-down remain separately governed when data safety warrants it.
+This is evidence, not deployment authorization. `/deploy` owns the actual deployment write gate for the exact environment, placement, target/provider, artifact, and current evidence.