@mriekki/lean 0.4.3 → 0.4.5

package/assets/generated/core/core/skills/tear-down/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: tear-down
-description: "Guided destructive environment cleanup for local, Staging, Production, or all supported POC scopes. Preserves exact ownership boundaries, separate Production-data authorization, and delegates deletion mechanics to repository-provided tooling."
-argument-hint: "[local|staging|production|all]"
+description: "Guided destructive cleanup for local state, one exact named logical environment, or all explicitly configured POC environments. Preserves ownership boundaries and separate Production-data authorization."
+argument-hint: "[local|<environment>|all]"
 user-invocable: true
 disable-model-invocation: true
 ---
@@ -10,129 +10,169 @@ disable-model-invocation: true
 
 `/tear-down` is the human-facing destructive cleanup workflow for repository-owned POC environments and local runtime state.
 
-The skill owns scope selection, read-only preflight, destructive preview, and Human-in-the-Loop authorization. Repository-provided deployment tooling owns teardown mechanics.
+The skill owns scope selection, read-only preflight, destructive preview, and Human-in-the-Loop authorization. Repository-provided deployment tooling owns deletion mechanics.
+
+Logical environments are not limited to Staging and Production. A repository may define `demo`, `qa`, `staging`, `production`, or another safe named environment.
 
 Do not implement Docker, filesystem, route, database, registry, or host cleanup directly in the skill when an approved repository command exists.
 
 ## 1. Begin read-only
 
-Invocation starts read-only.
-
 Read only the minimum repository context needed to identify:
 
-- the repository's approved tear-down entry point;
-- the canonical repository/application identity used by that entry point;
-- configured Staging and Production environment-to-target bindings when those scopes are available;
-- the exact local image/package identity used to identify POC-owned local Docker state;
-- the currently supported tear-down scopes and their ownership boundaries.
+- approved tear-down entry point and installed Deployment Kit version/baseline when applicable;
+- canonical repository/application identity;
+- repository-defined logical environments, their roles/purposes, and explicit target bindings;
+- which selected environments are Production-class;
+- exact local image/package identity used for POC-owned workstation Docker cleanup;
+- supported tear-down scopes and ownership boundaries.
+
+Do not assume:
 
-Do not assume script paths, container names, volume names, environment bindings, target addresses, or package coordinates unless the repository establishes them.
+- Staging/Production are the only environments;
+- Staging and Production use separate physical machines;
+- `all` always means exactly local + Staging + Production;
+- a local package exists;
+- remote target addresses/aliases;
+- container/volume names not established by the deterministic tool.
 
-If the repository does not provide an approved deterministic tear-down command for the requested scope, stop. Do not improvise destructive shell commands.
+If the repository does not provide an approved deterministic command for the requested destructive scope, stop. Do not improvise shell commands.
 
-## 2. Select the scope explicitly
+## 2. Select exact scope
 
-Supported generic scope names are:
+Generic scope model:
 
 ```text
 local
-staging
-production
+<one exact repository-defined named environment>
 all
 ```
 
-If the invocation did not name a scope, present only scopes the current repository actually supports and ask the human to select one.
+If no scope is named, present only scopes the current repository actually supports.
 
 Rules:
 
-- never silently default to `production` or `all`;
-- never infer destructive scope from a previous deployment or prior conversation;
-- never widen a requested scope after a failure;
-- `all` means all supported tear-down scopes for this one repository/POC, not machine-wide cleanup;
-- selecting a scope does not itself authorize deletion.
+- never silently default to a Production environment or `all`;
+- never infer destructive scope from a prior deploy/conversation;
+- never widen scope after failure;
+- `all` means all explicitly configured/supplied scopes for this one POC, never machine-wide cleanup;
+- selecting scope never authorizes deletion.
+
+A named environment is independently targetable even when multiple environments share one physical target/failure domain.
+
+If a named environment is unsupported/unconfigured, fail explicitly rather than falling back to another environment on the same host.
 
-If a named scope is unsupported or not configured, fail explicitly.
+## 3. Resolve ownership and Production classification
 
-## 3. Resolve exact ownership and target evidence
+Before an authorization gate, resolve non-secret ownership/evidence required by the installed tear-down contract.
+
+For local cleanup identify the exact POC-owned local runtime/package boundary.
+
+For each selected remote environment identify:
+
+```text
+environment name
+role/purpose (including Production classification)
+configured logical target
+repository/application identity
+ownership markers required by the deterministic tool
+```
 
-Before presenting an authorization gate, resolve the non-secret ownership evidence required by the repository's tear-down contract.
+The literal environment name `production` should be treated as Production when the installed Deployment Kit does so for compatibility. Repositories may also classify another named environment as Production; pass that classification only through the installed tool's supported contract (for example `--production-environment <name>`).
 
-For local cleanup, this should identify the exact POC-owned local runtime/package boundary. For remote environments, this should identify the exact named environment, configured logical target, repository/application identity, and any ownership markers the deterministic tear-down tool verifies.
+Physical colocation never merges ownership. `staging` cleanup must not remove `production` because both bind to the same VPS.
 
-Preserve the repository's shared-resource boundary. Normal POC tear-down must not broaden into deletion of shared platform infrastructure, unrelated POCs, workstation trust/credentials, or registry packages unless the repository defines a separate explicit lifecycle operation for those resources.
+Preserve shared-resource boundaries. Normal POC tear-down must not broaden into shared platform infrastructure, unrelated POCs/environments, workstation trust/credentials, or registry packages unless a separate explicit lifecycle operation owns those resources.
 
-If ownership is ambiguous, a target binding changed, host identity cannot be verified, or the underlying tool reports mismatched ownership, stop without deletion.
+If ownership is ambiguous, a binding/evidence set changed, host identity cannot be verified where required, or the tool reports mismatched ownership, stop without deletion.
 
-## 4. Present the destructive preview
+## 4. Present exact destructive preview
 
-Before authorization, show what will be removed and what will be preserved using the repository's actual contract.
+Show what will be removed and preserved using current repository/tool evidence.
 
-A typical preview is:
+Example:
 
 ```text
 TEAR-DOWN READY
 
-Scope: <local|staging|production|all>
+Scope: <local|demo|staging|production|other|all>
 Repository/app: <verified identity>
-Staging target: <verified logical target or not selected>
-Production target: <verified logical target or not selected>
-Local package/runtime identity: <exact identity or not selected>
+Selected environments:
+  <env> → <logical target> — <Production/non-Production>
+Local package/runtime: <exact identity or NOT SELECTED>
 
 Will remove:
-  <repository-supported owned resources>
+  <tool/repository-supported owned resources for exactly these scopes>
 
 Will preserve:
-  <shared/unrelated resources established by the repository contract>
+  <shared/unrelated environments/resources>
 ```
 
-For Deployment-Kit consumers, expected behavior includes:
+For current Deployment-Kit consumers:
 
-- `local` — exact-package local containers/images and Docker-managed anonymous volumes attached to those owned containers;
-- `staging` — the owned Staging route, runtime, release/evidence state, persistent application data, and backups;
-- `production` — the owned Production route, runtime, release/evidence state, persistent application data, and backups;
-- `all` — Staging + Production + local for the selected POC only.
+- `local` — exact-package local containers/images and Docker-managed anonymous volumes attached to those exact containers;
+- `<environment>` — only that exact owned route/runtime/release/evidence/persistent-data/backup scope;
+- `all` — all explicitly supplied named environment bindings plus optional exact-package local state when supplied.
 
-Do not promise deletion of named/shared Docker volumes or other resources unless the repository has an independent ownership model that safely proves they belong to this POC.
+Do not promise deletion of named/shared Docker volumes or other resources unless independent ownership can be proven.
 
-## 5. Require the destructive authorization gate
+When selected logical environments share one physical target, say so in the preview so the user can verify that the deletion set remains environment-scoped.
 
-Every modifying tear-down requires one explicit bounded authorization for the exact previewed scope and evidence:
+## 5. Authorization gates
+
+Every modifying tear-down requires:
 
 ```text
 [POC TEAR DOWN]
 ```
 
-For `production` or `all`, persistent Production data is part of the requested destructive scope. Require an additional independent authorization:
+Additionally, whenever **any selected environment is Production-class**, require:
 
 ```text
 [PRODUCTION DATA DELETE]
 ```
 
-The Production-data authorization is required even when Production was previously deployed, tested, approved, or selected. Deployment authorization does not authorize data deletion.
+Do not tie the Production-data gate only to literal scope strings `production` or `all`. It depends on the resolved deletion set and Production classification.
+
+Deployment authorization, prior testing, CI, merge approval, environment selection, and physical colocation do not authorize persistent Production data deletion.
+
+If repository/app identity, selected environments, Production classification, target binding, ownership evidence, or deletion set changes after preview, require renewed review/authorization.
+
+## 6. Execute only repository-provided command
+
+After exact authorization, invoke only the approved tear-down command with the exact selected scopes and resolved inputs.
 
-If the resolved repository/app identity, target binding, ownership evidence, or deletion set materially changes after the preview, stop and require renewed review and authorization.
+For generalized Deployment Kit consumers this may include repeated explicit environment bindings such as:
 
-## 6. Execute only the approved repository command
+```text
+--environment-target demo=<target>
+--environment-target staging=<target>
+--environment-target production=<target>
+```
+
+and, when needed for a non-literal Production environment:
 
-After the required authorization phrase or phrases are explicitly provided, invoke only the repository-approved tear-down command with the exact selected scope and resolved inputs.
+```text
+--production-environment prod-east
+```
 
-Pass authorization through only when the repository command expects the same bounded contract. Do not translate one approval into broader deletion authority.
+Do not manually substitute another binding format if the installed version has a different contract; inspect the distributed tool/help/docs first.
 
-Do not add machine-wide Docker prune, shared-network removal, shared Caddy/Avahi removal, unrelated branch/repository cleanup, registry-package deletion, host reprovisioning, target rebinding, or secret/trust cleanup unless those operations are separately defined and explicitly authorized by the repository.
+Never add machine-wide Docker prune, shared-network/Caddy/Avahi removal, unrelated environment cleanup, registry-package deletion, host reprovisioning, target rebinding, or secret/trust deletion unless separately defined and explicitly authorized.
 
-If the deterministic command stops partway through `all`, report the completed and remaining scopes. Do not compensate by manually deleting the remainder.
+If an aggregate `all` operation stops partway, report completed/remaining scopes. Do not manually compensate by deleting the rest.
 
-## 7. Verify and report the outcome
+## 7. Verify/report outcome
 
-Use repository-provided evidence/status commands when available. Report only what the evidence supports, including:
+Use repository-provided evidence/status commands when available. Report only supported evidence:
 
 - requested scope;
 - repository/application identity;
-- environments/targets actually processed;
-- local runtime state actually processed;
-- whether persistent Production data was included;
+- exact logical environments/targets processed;
+- Production-class environments included;
+- local runtime state processed;
 - removed versus already-absent resources;
-- any failure point or remaining scope after a partial stop;
-- confirmation that shared/unrelated resources were preserved when the repository provides evidence for that claim.
+- failure point/remaining scopes after a partial stop;
+- preservation of shared/unrelated resources only when evidence supports it.
 
-The operation should remain safe to rerun for already-absent owned resources when the repository's tear-down contract says it is idempotent.
+The operation should remain safe to rerun for already-absent owned resources when the installed tear-down contract is idempotent.

package/assets/generated/core/core/templates/ADR_TEMPLATE.md

@@ -0,0 +1,41 @@
+# ADR-NNN — <Decision title>
+
+Status: **PROPOSED**
+
+Date: `<YYYY-MM-DD>`
+
+## Context
+
+What engineering/product constraint or tradeoff requires a durable decision?
+
+## Decision
+
+What was decided?
+
+Do not mark an ADR accepted until the human/repository process has actually accepted the decision.
+
+## Alternatives considered
+
+- `<alternative>` — why it was considered and why it was not selected.
+- `<alternative>` — why it was considered and why it was not selected.
+
+## Tradeoffs / consequences
+
+### Benefits
+
+- `<benefit>`
+
+### Costs / risks
+
+- `<cost or risk>`
+
+## Evidence / links
+
+- Work item: `<ID or link>`
+- Relevant code/config: `<path>`
+- System Lab scenario/component: `<reference when useful>`
+- Other docs: `<link>`
+
+## Follow-up / review trigger
+
+What future condition should cause this decision to be revisited?