@flancer32/skill-adsm-ctx 0.2.1 → 0.4.0

package/skill/references/document-projections.md

@@ -1,7 +1,7 @@
 # Documentation Projections
 
 - Path: `skill/references/document-projections.md`
-- Changed: `20260715`
+- Changed: `20260917`
 
 Use this reference whenever an agent initializes, designs, validates, audits, compresses, or upgrades ADSM documentation under `ctx/docs/`.
 
@@ -59,71 +59,15 @@ An agent document should reduce ambiguity and statistical guessing by making exp
 
 ## Semantic Skins
 
-A skin is a `*.skin.<lang>.md` document in the same directory as its matching agent document.
+A skin is a `*.skin.<lang>.md` document beside its paired agent document.
 
-Pairing rule:
+`name.md → name.skin.<lang>.md` and `name.skin.<lang>.md → name.md` are reversible pairing rules; an unmarked `name.skin.md` is invalid.
 
-```text
-name.md
-name.skin.en.md
-name.skin.ru.md
-```
-
-Use a lowercase ISO 639-1 language code such as `en`, `ru`, or `es`; use a regional tag only when a real regional distinction is needed. An unmarked `name.skin.md` is invalid.
-
-One agent document and all skins sharing its basename form one document group. A skin represents the same cognitive content for humans, but may reorganize or explain it for its named audience and is not required to be a literal translation.
-
-A skin is not a summary.
-
-A skin is a human-facing semantic layer.
-
-Its job is to help a human quickly restore the correct purpose, mental model, scope, and invariants of the same object described by the paired agent document.
-
-Skins should stay compact and easy to read during supervision.
-
-Recommended skin structure:
-
-```md
-# <Title>
-
-## Purpose
-
-One short sentence.
-
-## Mental Model
-
-One or two short paragraphs.
-
-## Scope
-
-Includes:
-
-- one to three items.
+A skin is a compact skeletal human projection, not a summary or a second operational document. Its purpose is to preserve the documented object's semantic frame for human supervision.
 
-Excludes:
+Use type-appropriate structure rather than a fixed heading template. Do not add an `Agent Document` section: pairing is already unambiguous from the filename.
 
-- one to three items.
-
-## Invariants
-
-- normally no more than five to seven items.
-
-## Agent Document
-
-`name.md`
-```
-
-Equivalent section titles are acceptable when the meaning remains clear.
-
-Do not move detailed operational instructions, verification checklists, implementation workflows, or exhaustive inventories into skins.
-
-Skin compactness is guided first by section budgets and only second by total content words.
-
-For validation, content-word counting ignores headings and document metadata where practical, strips fenced code blocks, and counts the remaining prose and list text.
-
-Deterministic validation treats up to 160 content words as normal, 161 through 240 content words as a warning range, and anything above 240 as an error.
-
-Missing skins are acceptable unless the document is a key human-direction document where preserving human intent is especially important.
+Read [semantic-skins.md](semantic-skins.md) for the projection model, structure examples, naming details, information-budget guidance, and review checklist.
 
 ## Read And Edit Behavior
 
@@ -158,9 +102,9 @@ Validation should report structural drift such as orphan skins.
 
 Audit, compression, and upgrade work should report semantic drift when it can be evidenced from the documents.
 
-## Documentation Levels And Substructure
+## Documentation Levels And Verification Layer
 
-ADSM defines only four top-level documentation levels under `ctx/docs/`:
+ADSM defines exactly four ordered declarative documentation levels under `ctx/docs/`:
 
 ```text
 ctx/docs/product/
@@ -169,32 +113,47 @@ ctx/docs/environment/
 ctx/docs/code/
 ```
 
-Their meanings:
+Their meanings remain:
+
+- `product` — accepted product meaning;
+- `architecture` — accepted engineering structure;
+- `environment` — accepted runtime and deployment conditions;
+- `code` — accepted implementation and engineering constraints.
+
+`ctx/docs/verification/` is an optional cross-cutting documentation block. It relates declarations to observations of reality, but is not a fifth refinement level and does not change declaration authority.
 
-- `product` — product meaning;
-- `architecture` — engineering structure;
-- `environment` — runtime and deployment context;
-- `code` — implementation mapping.
+Create the block only when the project has a durable verification specification. Its root requires `AGENTS.md`; direct categories are optional `product/`, `architecture/`, `environment/`, and `code/`. Create a category only when a durable specification exists beneath it. Do not initialize empty categories or placeholder specifications.
 
-ADSM may provide baseline templates and recommendations, but it must not impose a rigid internal subtree inside those levels.
+A verification specification has one canonical home selected by its **primary verification target**: the declaration or bounded declaration group whose truth it chiefly evaluates. It may link to secondary declarations, executable tests, monitors, environments, dependencies, and other contexts. Mechanism, test framework, source path, CI job, endpoint, reporting context, and current Responsible Context do not determine placement.
 
-Project-specific nested subdirectories are allowed and should be used when they improve maintainability.
+A specification should state, when relevant:
+
+- the primary target and traceability to its declaration;
+- the expected observable corridor;
+- approach and acquisition mode;
+- applicability and prerequisites;
+- bounded interpretation, reach, and blind spots;
+- lifecycle role and follow-up, including re-verification when required; and
+- available access or authority for obtaining the observation.
+
+A verification specification is durable documentation. An evidence record records an actual observation and its provenance. Operational Feedback State retains unresolved routing or continuation state. Do not confuse either operational object with a declaration or durable verification specification.
+
+Project-specific nesting by risk area, product area, subsystem, use case, integration, or operational surface is allowed inside a primary-target category. It must preserve one canonical specification.
 
 Valid examples:
 
 ```text
 ctx/docs/product/domain/ingress.md
-ctx/docs/product/domain/memory.md
 ctx/docs/architecture/runtime/agent-execution.md
 ctx/docs/environment/deployment/vps.md
 ctx/docs/code/modules/orchestrator.md
+ctx/docs/verification/product/authentication.md
+ctx/docs/verification/architecture/boundaries/adapter-isolation.md
 ```
 
-Flat files remain allowed when suitable.
-
-Do not require flat prefixed names such as `domain-ingress.md` when nested directories are clearer.
+Flat files remain allowed when suitable. Do not require flat prefixed names when nested directories are clearer.
 
-Each of the four documentation levels should contain no more than nine direct subdirectories and no more than nine direct ordinary files. The service-control file `AGENTS.md` and all matching `*.skin.<lang>.md` files are excluded, so an agent document and all of its skins count as one document group. This is a maintainability recommendation, not a reason to collapse meaningful structure.
+Each of the four declarative levels should contain no more than nine direct subdirectories and nine direct ordinary files. The service-control file `AGENTS.md` and all matching `*.skin.<lang>.md` files are excluded, so an agent document and all of its skins count as one document group. This is a maintainability recommendation, not a reason to collapse meaningful structure.
 
 When a level deliberately exceeds either value, its own `AGENTS.md` must include a `## Documentation Capacity Exception` section that explicitly records the intentional exception and its reason. Deterministic validation warns about the exceeded recommendation and reports an error when this explicit local declaration is absent.
 
@@ -243,7 +202,7 @@ Do not use `AGENTS.md` as a replacement for agent documents or skins.
 
 Documentation quality audit should:
 
-- recursively include ordinary `*.md` agent documents under the four top-level documentation levels;
+- recursively include ordinary `*.md` agent documents under the four declarative levels and under an adopted `verification/` block;
 - classify `*.skin.<lang>.md` files as human-facing semantic skins;
 - detect agent/skin document groups by same basename and directory;
 - report orphan skins;
@@ -256,11 +215,11 @@ Documentation quality audit should:
 Deterministic validation should:
 
 - require every `*.skin.<lang>.md` file to have a paired non-skin `*.md` document and an explicit valid language marker;
-- require the standard skin sections and the `Agent Document` reference;
-- require both `Includes:` and `Excludes:` blocks inside the skin `Scope` section;
+- require an explicit valid language marker, reversible paired-base resolution, and no redundant `Agent Document` section;
 - verify local markdown document links under `ctx/docs/**`;
+- accept absence of `ctx/docs/verification/`, but when it is present require its `AGENTS.md`, recognized primary-target category directories, and at least one durable specification in every created category;
+- keep verification category placement and evidence sufficiency as semantic audit work rather than claiming them from directory shape;
 - warn when a documentation level contains more than nine direct directories or more than nine direct ordinary files (excluding `AGENTS.md` and paired `*.skin.<lang>.md` files), and require an explicit `Documentation Capacity Exception` in that level's `AGENTS.md`;
-- measure skin compactness using only the content of `Purpose`, `Mental Model`, `Scope`, and `Invariants`; exclude metadata, headings, and `Agent Document`; count Unicode-aware words and meaningful list items only; warn above 160 words or 12 list items and fail above 240 words or 20 list items;
 - keep ordinary agent-document shape checks minimal instead of imposing a rigid body template.
 
 ## Compression Rules
@@ -288,3 +247,4 @@ Upgrades should:
 - report orphan skins and agent/skin conflicts;
 - avoid introducing required `README.md` files inside `ctx/docs/`;
 - keep assets under `ctx/assets/**`.
+- preserve primary verification target, applicability, reach, blind spots, and the distinction between specification and evidence when verification documentation is in scope.

package/skill/references/documentation-compression.md

@@ -1,7 +1,7 @@
 # Documentation Compression
 
 - Path: `skill/references/documentation-compression.md`
-- Changed: `20260708`
+- Changed: `20260917`
 
 Use this reference when an agent must compress an existing ADSM cognitive documentation corpus while preserving accepted project meaning.
 
@@ -34,7 +34,7 @@ Follow this method:
 
 The default corpus is `ctx/docs/`.
 
-Documentation compression is intended for declarative project documentation: product, architecture, environment, code, and other project documentation levels under `ctx/docs/`.
+Documentation compression is intended for declarative project documentation under the four ADSM levels: product, architecture, environment, and code, plus an adopted optional Verification Layer when it is in scope.
 
 Do not include operational context outside `ctx/docs/` by default, including `ctx/agent/`, generated reports, prompt assets, workflow configuration, runtime materials, `ctx/assets/**`, or other agent-operation artifacts.
 
@@ -77,6 +77,7 @@ Safe compression may:
 Safe compression preserves:
 
 - product intent and scope;
+- verification primary targets, applicable bounds, blind spots, and the distinction between durable specification, actual evidence, and operational feedback state;
 - domain terms and relationships;
 - role and authority boundaries;
 - architecture boundaries and decisions;

package/skill/references/documentation-quality-audit.md

@@ -1,7 +1,7 @@
 # Documentation Quality Audit
 
 - Path: `skill/references/documentation-quality-audit.md`
-- Changed: `20260708`
+- Changed: `20260917`
 
 Use this reference when an agent must audit an existing documentation corpus as an ADSM cognitive context.
 
@@ -59,24 +59,32 @@ Apply the criteria according to the document's projection role:
 
 ### Skin Documents
 
-Review each `*.skin.<lang>.md` file as a human-facing semantic layer.
+Review each `*.skin.<lang>.md` file as a compact skeletal human projection.
 
 Check whether:
 
-- the paired non-skin document exists when required;
-- both documents describe the same object;
-- the skin preserves purpose, mental model, scope, invariants, and a reference to the paired agent document;
-- the skin adds untracked requirements not present in the paired agent document;
-- the skin contradicts the paired agent document;
-- the skin stays compact, human-readable, and free of excessive operational detail.
+- the paired non-skin document exists and both documents describe the same object;
+- the skin preserves the main meaning and exposes the base document's load-bearing structure;
+- boundaries, key constraints, and likely misreadings are retained;
+- the structure suits the base document's type rather than following a fixed heading set;
+- the skin adds no untracked requirements or facts and does not contradict the base;
+- operational detail and redundant pairing navigation are excluded; and
+- the skin remains small enough for human cognitive use.
 
-The review should answer:
+### Cognitive Information Budget
+
+Use evidence from the skin and its paired base; do not claim universal cognitive limits. Check whether:
+
+- one central thesis is identifiable after one reading;
+- 3–5 meaningful chunks normally organize the frame, and more than 7 is justified by a shared reader schema;
+- each block adds an irreducible distinction rather than formatting, repetition, navigation, or methodology noise;
+- boundaries, key constraints, and dangerous misreadings survive compression;
+- operational detail is excluded; and
+- a longer skin (roughly 300–350 words) is justified by irreducible distinctions, while a shorter one has not made meaning ambiguous.
 
-- does the document work as a human-facing semantic layer;
-- does it preserve the same meaning as the paired agent document;
-- does it avoid operational overload;
-- does it add untracked requirements;
-- what must be changed.
+The ranges are editorial review prompts, not automatic pass/fail thresholds.
+
+The review should distinguish a meaningful skeletal projection from a short operational summary. See [semantic-skins.md](semantic-skins.md) for structure examples.
 
 ### Agent Documents
 
@@ -197,3 +205,18 @@ The audit must not:
 - mark a corpus incomplete merely because it does not document out-of-scope concerns.
 
 The audit may propose correction order and candidate edits, but it must distinguish proposals from accepted project knowledge.
+
+## Verification Layer Review
+
+When `ctx/docs/verification/` exists, include it in the default corpus. Review it as cross-cutting specification documentation, not a fifth declarative level and not an evidence or incident archive.
+
+Check whether each durable specification:
+
+- names a primary verification target and links to the authoritative declaration;
+- states an observable expectation and applicable state or prerequisites;
+- distinguishes observation method from the declaration being evaluated;
+- identifies reach, blind spots, and limits on the conclusion;
+- avoids duplicated specifications for the same expectation; and
+- distinguishes detection, localization, resolution feedback, and re-verification.
+
+Report a human decision when supervision, acceptable uncertainty, required independence, Responsible Context routing, evidence retention, or operational feedback-state ownership is missing. Do not infer these policies from test framework, directory name, issue tracker, or a passing result.

package/skill/references/orchestration-model.md

@@ -1,7 +1,7 @@
 # Orchestration Model
 
 - Path: `skill/references/orchestration-model.md`
-- Changed: `20260715`
+- Changed: `20260917`
 
 This skill is a router and baseline manager.
 
@@ -12,9 +12,10 @@ It is responsible for:
 - lifecycle guidance;
 - baseline validation;
 - migration entry points;
+- Verification Layer documentation lifecycle support and structural validation;
 - the reserved boundary definition for `ctx/agent/`.
 
-It is not responsible for inventing specialized technical or domain documentation.
+It is not responsible for inventing specialized technical or domain documentation, executing verification, receiving signals, persisting evidence or Operational Feedback State, or coordinating distributed feedback loops.
 
 For `ctx/agent/`, this skill may:
 
@@ -32,7 +33,7 @@ When specialization is needed, the agent should use a matching available skill a
 
 Concrete tool-facing materials belong to project-local documentation, explicit human instruction, or an external specialized skill when one is available and relevant.
 
-Specialized skills may add project-specific nested documentation under the four top-level `ctx/docs` levels, but they must preserve agent/skin pairing rules and keep artifacts under `ctx/assets/**`.
+Specialized skills may add project-specific nested documentation under the four declarative `ctx/docs` levels and may implement concrete verification methods or project-local feedback procedures. They must preserve agent/skin pairing rules, keep artifacts under `ctx/assets/**`, and treat `verification/` as optional cross-cutting documentation rather than a fifth level.
 
 ## Template Boundary
 

package/skill/references/semantic-skins.md

@@ -0,0 +1,65 @@
+# Semantic Skins
+
+- Path: `skill/references/semantic-skins.md`
+- Changed: `20260814`
+
+A semantic skin is a compact skeletal human projection of its paired agent document.
+
+It lets a human recover the documented object's semantic frame without loading operational detail.
+
+A skin is neither a mechanical summary nor a second operational specification.
+
+## Pairing And Naming
+
+A skin is located beside its paired ordinary `*.md` agent document.
+
+`name.md → name.skin.<language>.md`
+
+`name.skin.<language>.md → name.md`
+
+Use lowercase ISO 639-1 language codes such as `en`, `ru`, or `es`; add a regional tag only for a genuine distinction.
+
+The reversible filename convention is the authoritative pairing navigation. Do not add an `Agent Document` section or a redundant link.
+
+## Projection Rule
+
+State the purpose of the documented object, not the purpose of its file or skin.
+
+Preserve the base document's load-bearing meaning: its decisive concepts, boundaries, constraints, relations, and likely misreadings.
+
+Do not add requirements, facts, or decisions absent from the paired agent document. Do not reproduce verification steps, exhaustive inventories, implementation procedure, or agent-routing detail.
+
+## Information Budget
+
+A skin has an information budget, not a universal word budget: a human should restore its semantic frame in one calm reading without loading operations.
+
+A semantic chunk is one meaningful, mutually distinct unit needed to recover that frame. It is not a heading, list item, sentence, or word count.
+
+As soft editorial prompts, prefer 3–5 chunks; more than 7 needs review unless readers share a strong schema. About 120–250 words is often suitable. 300–350 words needs a stated reason: irreducible distinctions, not verbosity. These ranges are not scientific limits and never drive automatic validation.
+
+A longer skin is justified when omitting a load-bearing distinction would mislead. A shorter skin is insufficient when compression makes a required distinction ambiguous.
+
+## Choose The Skeleton
+
+Use the cognitive form of the documented object rather than a universal heading set.
+
+- overview or identity — purpose, mental model, boundaries, invariants;
+- domain model — concepts, levels, key relations, constraints;
+- decision — decision, rationale, consequences, rejected alternatives;
+- process — goal, flow, inputs and outcomes, exceptions;
+- reference or map — navigational structure, terms, governing rules.
+
+Equivalent concise headings are valid. A skin need not use every suggested heading.
+
+## Creation And Review
+
+Read every existing matching skin before changing its agent document.
+
+When creating or reviewing a skin, verify that it:
+
+- preserves the document's main meaning and load-bearing structure;
+- retains boundaries, key constraints, and likely misreadings;
+- uses a skeleton appropriate to the document type;
+- adds no untracked facts or requirements and does not contradict its base;
+- excludes operational detail and redundant navigation; and
+- remains compact enough for human cognitive use.

package/skill/references/specialized-skills.md

@@ -1,7 +1,7 @@
 # Specialized Skills
 
 - Path: `skill/references/specialized-skills.md`
-- Changed: `20260708`
+- Changed: `20260917`
 
 Use specialized skills when the project context requires knowledge that should not live in this generic lifecycle skill.
 
@@ -11,6 +11,8 @@ Examples of specialization signals:
 - backend application architecture;
 - data or persistence modeling;
 - deployment and runtime environment design;
+- browser, backend, data, security, monitoring, or other concrete verification methods;
+- signal transport, external-report handling, or distributed feedback procedures;
 - tool-specific agent instructions or workflow design for a concrete execution engine or host platform.
 
 Tool-specific specialization signals include:
@@ -27,5 +29,6 @@ Specialized skills must preserve ADSM's documentation projection model:
 
 - ordinary `*.md` files under `ctx/docs/**` are agent-facing operational context documents;
 - `*.skin.<lang>.md` files are human-facing semantic skins for matching agent documents;
-- nested subdirectories inside the four top-level documentation levels are allowed;
+- nested subdirectories inside the four declarative documentation levels are allowed;
+- an adopted `ctx/docs/verification/` block remains cross-cutting; specifications use a primary declaration target rather than the mechanism or specialized skill that obtains evidence;
 - visual, generated, rendered, and auxiliary artifacts belong under `ctx/assets/**`.

package/skill/references/upgrade-policy.md

@@ -1,19 +1,29 @@
 # Upgrade Policy
 
 - Path: `skill/references/upgrade-policy.md`
-- Changed: `20260708`
+- Changed: `20260917`
 
 Upgrades must be non-destructive by default.
 
+## Verification Layer Compatibility
+
+The `verification-layer` context convention capability is optional. Existing contexts without `capabilities`, with context version `0.1.0`, or without `ctx/docs/verification/` remain valid.
+
+Safe adoption may add `"verification-layer"` to `ctx/adsm.json` and add a structurally complete verification block only when the project has a real durable specification. It must not create `verification/`, empty categories, placeholder specifications, or copied specifications merely because an upgrade ran.
+
+Partial adoption is valid. Structural validation distinguishes absence from malformed adoption. An adopted block requires its root `AGENTS.md`; each created primary-target category must be a directory containing a durable specification. Unknown or unsupported categories and malformed capability metadata are validation findings.
+
+## General Upgrade Boundaries
+
 Safe upgrade behavior includes:
 
-- adding missing files and directories;
-- updating metadata when the migration rules are explicit;
-- preserving project-authored content unless replacement is proven safe.
+- adding missing files and directories only when migration rules explicitly require them;
+- updating metadata when rules are explicit;
+- preserving project-authored content unless replacement is proven safe;
 - detecting agent/skin pairs, orphan skins, and projection drift according to `skill/references/document-projections.md`;
-- preserving project-specific nested subdirectories under `ctx/docs/product/`, `ctx/docs/architecture/`, `ctx/docs/environment/`, and `ctx/docs/code/`;
+- preserving project-specific nested subdirectories and adopted verification specifications;
 - keeping visual, generated, rendered, and auxiliary artifacts under `ctx/assets/**`.
 
 Unsafe cases should be reported for manual follow-up instead of applied automatically.
 
-Upgrade must not introduce required `README.md` files inside `ctx/docs/` and must not automatically rewrite human-controlled skins when agent/skin meaning is unclear.
+Upgrade must not introduce required `README.md` files inside `ctx/docs/`, automatically rewrite human-controlled skins when meaning is unclear, or claim that adoption provides verification coverage or runtime conformity.

package/skill/templates/ctx/adsm.json

@@ -1,6 +1,9 @@
 {
   "schema": "adsm-context",
-  "version": "0.1.0",
+  "version": "0.2.0",
+  "capabilities": [
+    "verification-layer"
+  ],
   "notes": [
     "Initial context created from the canonical adsm-ctx template set."
   ]

package/skill/templates/ctx/docs/AGENTS.md

@@ -21,6 +21,7 @@ The installed template should describe the project, not restate detailed ADSM me
 - `code/` — code-level constraints and testing guidance.
 - `environment/` — runtime and infrastructure assumptions.
 - `product/` — product meaning, roles, and use cases.
+- `verification/` — optional cross-cutting verification specifications; create it only with a real durable specification.
 - `AGENTS.md` — entry note for `ctx/docs/`.
 - `ai-intro.md` — compact agent orientation for the concrete project.
 - `filesystem.md` — top-level repository map.
@@ -31,6 +32,7 @@ Defines:
 
 - The declarative documentation boundary for the project.
 - The documentation dependency chain from product to code.
+- The optional Verification Layer as a cross-cutting relation, never a fifth declarative level.
 - The local entry points used to orient agents within `ctx/docs/`.
 
 Does NOT define:
@@ -50,6 +52,7 @@ Does NOT define:
 - Read a matching skin before changing an agent document.
 - Report a human decision if a requested agent-document change would violate the matching skin.
 - Keep project-specific nested subdirectories inside `product/`, `architecture/`, `environment/`, and `code/` when they improve maintainability.
+- Create `verification/` only when it contains a durable specification. Its root requires `AGENTS.md`; create primary-target categories only on demand.
 - Keep each documentation level to no more than nine direct directories and nine direct ordinary files, excluding `AGENTS.md` and paired `*.skin.<lang>.md` files, where practical.
 - When a level deliberately exceeds either value, add a `## Documentation Capacity Exception` section to that level's `AGENTS.md` that states the exception and its reason.
 - Put visual, generated, rendered, or auxiliary artifacts under `ctx/assets/**`.

package/skill/templates/ctx/docs/code/testing.md

@@ -11,3 +11,7 @@ Describe the test boundary for the project.
 ## Test Structure
 
 List the main test layers, directories, and intended verification scope.
+
+## Verification Target Boundary
+
+Keep executable test organization, framework conventions, fixtures, and isolation in this code-level document. When a project adopts `ctx/docs/verification/`, its durable specification states the observed declared expectation and primary target; the executable mechanism remains governed here.

package/skill/templates/work/context/semantic-skin.md

@@ -1,27 +1,16 @@
-# <Title>
+# <Document Title>
 
-## Purpose
+- Path: `ctx/docs/{{subdir}}/<name>.skin.<lang>.md`
+- Changed: `YYYYMMDD`
 
-One short sentence.
+Use a compact, type-appropriate skeleton that lets a human recover the documented object's meaning.
 
-## Mental Model
+Do not describe this file or skin. Do not include an `Agent Document` link: its paired base is derived from the filename.
 
-One or two short paragraphs that restore the human frame.
+Choose only the relevant sections, for example:
 
-## Scope
-
-Includes:
-
-- one to three items.
-
-Excludes:
-
-- one to three items.
-
-## Invariants
-
-- normally no more than five to seven items.
-
-## Agent Document
-
-`name.md`
+- overview — purpose, mental model, boundaries, invariants;
+- domain model — concepts, relations, constraints;
+- decision — decision, rationale, consequences;
+- process — goal, flow, outcomes, exceptions;
+- reference — map, terms, governing rules.

package/src/Cli/Command/Design.mjs

@@ -0,0 +1,17 @@
+// @ts-check
+
+import processModule from "node:process";
+
+/** @namespace Fl32_Skill_Adsm_Ctx_Cli_Command_Design */
+export default class Design {
+  constructor({config, design}) {
+    this.id = "adsm-ctx:design";
+    this.summary = "Show ADSM context design guidance.";
+    this.lifetime = "finite";
+    this.execute = async function ({args}) {
+      processModule.stdout.write(`${await design.execute({targetPath: args["target-path"] ?? config.cwd})}\n`);
+    };
+  }
+}
+
+export const __deps__ = Object.freeze({default: Object.freeze({config: "TeqFw_Cli_Config$", design: "Fl32_Skill_Adsm_Ctx_Design_Service$"})});

package/src/Cli/Command/Init.mjs

@@ -0,0 +1,22 @@
+// @ts-check
+
+import processModule from "node:process";
+
+/** @namespace Fl32_Skill_Adsm_Ctx_Cli_Command_Init */
+export default class Init {
+  constructor({config, init}) {
+    this.id = "adsm-ctx:init";
+    this.summary = "Initialize an ADSM context.";
+    this.lifetime = "finite";
+    this.execute = async function ({args}) {
+      const result = await init.execute({targetPath: args["target-path"] ?? config.cwd});
+      processModule.stdout.write(`${formatInitReport(result)}\n`);
+    };
+  }
+}
+
+function formatInitReport(result) {
+  return [`Initialized ADSM context in ${result.ctxRoot}`, ...result.created.map((entry) => `Created: ${entry}`), ...result.skipped.map((entry) => `Skipped: ${entry}`)].join("\n");
+}
+
+export const __deps__ = Object.freeze({default: Object.freeze({config: "TeqFw_Cli_Config$", init: "Fl32_Skill_Adsm_Ctx_Init_Service$"})});

package/src/Cli/Command/InstallSkill.mjs

@@ -0,0 +1,18 @@
+// @ts-check
+
+import processModule from "node:process";
+
+/** @namespace Fl32_Skill_Adsm_Ctx_Cli_Command_InstallSkill */
+export default class InstallSkill {
+  constructor({installer}) {
+    this.id = "adsm-ctx:install-skill";
+    this.summary = "Install the bundled agent skill payload.";
+    this.lifetime = "finite";
+    this.execute = async function ({args}) {
+      const targetDir = await installer.execute({targetRoot: args["skills-root"]});
+      processModule.stdout.write(`Installed skill payload to ${targetDir}\n`);
+    };
+  }
+}
+
+export const __deps__ = Object.freeze({default: Object.freeze({installer: "Fl32_Skill_Adsm_Ctx_Skill_Installer$"})});

package/src/Cli/Command/Upgrade.mjs

@@ -0,0 +1,19 @@
+// @ts-check
+
+import processModule from "node:process";
+
+/** @namespace Fl32_Skill_Adsm_Ctx_Cli_Command_Upgrade */
+export default class Upgrade {
+  constructor({config, upgrade}) {
+    this.id = "adsm-ctx:upgrade";
+    this.summary = "Upgrade an ADSM context.";
+    this.lifetime = "finite";
+    this.execute = async function ({args}) {
+      const result = await upgrade.execute({targetPath: args["target-path"] ?? config.cwd});
+      processModule.stdout.write(`${result.message}\n`);
+      if (!result.ok) throw new Error(result.message);
+    };
+  }
+}
+
+export const __deps__ = Object.freeze({default: Object.freeze({config: "TeqFw_Cli_Config$", upgrade: "Fl32_Skill_Adsm_Ctx_Upgrade_Service$"})});

package/src/Cli/Command/Validate.mjs

@@ -0,0 +1,19 @@
+// @ts-check
+
+import processModule from "node:process";
+
+/** @namespace Fl32_Skill_Adsm_Ctx_Cli_Command_Validate */
+export default class Validate {
+  constructor({config, validate}) {
+    this.id = "adsm-ctx:validate";
+    this.summary = "Validate an ADSM context.";
+    this.lifetime = "finite";
+    this.execute = async function ({args}) {
+      const result = await validate.execute({targetPath: args["target-path"] ?? config.cwd});
+      processModule.stdout.write(`${validate.format({result})}\n`);
+      if (!result.ok) throw new Error("ADSM context validation failed.");
+    };
+  }
+}
+
+export const __deps__ = Object.freeze({default: Object.freeze({config: "TeqFw_Cli_Config$", validate: "Fl32_Skill_Adsm_Ctx_Validate_Service$"})});