@flancer32/skill-adsm-ctx 0.4.0 → 0.6.0

package/{skill → skills/adsm-ctx}/references/document-projections.md

@@ -1,9 +1,9 @@
 # Documentation Projections
 
-- Path: `skill/references/document-projections.md`
-- Changed: `20260917`
+- Path: `skills/adsm-ctx/references/document-projections.md`
+- Changed: `20261024`
 
-Use this reference whenever an agent initializes, designs, validates, audits, compresses, or upgrades ADSM documentation under `ctx/docs/`.
+Use this reference whenever an agent initializes, designs, validates, audits, compresses, or evolves ADSM documentation under `ctx/docs/`.
 
 ## Core Model
 
@@ -100,7 +100,7 @@ Projection drift includes:
 
 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.
+Audit, compression, and evolution work should report semantic drift when it can be evidenced from the documents.
 
 ## Documentation Levels And Verification Layer
 
@@ -120,9 +120,11 @@ Their meanings remain:
 - `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.
+`ctx/docs/verification/` is a mandatory cross-cutting documentation block. It relates declarations to observations of reality, but is not a fifth refinement level and does not change declaration authority.
 
-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.
+For the distinction between project testing and product verification, evidence limits, and npm command conventions, see [testing-and-verification.md](testing-and-verification.md).
+
+Require the block in schema `0.6`, even when it contains only `AGENTS.md`. 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.
 
 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.
 
@@ -202,7 +204,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 declarative levels and under an adopted `verification/` block;
+- recursively include ordinary `*.md` agent documents under the four declarative levels and under the mandatory `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;
@@ -217,7 +219,7 @@ Deterministic validation should:
 - require every `*.skin.<lang>.md` file to have a paired non-skin `*.md` document and an explicit valid language marker;
 - 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;
+- require `ctx/docs/verification/AGENTS.md`, accept an AGENTS-only root, and require recognized primary-target categories with 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`;
 - keep ordinary agent-document shape checks minimal instead of imposing a rigid body template.
@@ -238,9 +240,9 @@ When compressing an agent document with a matching skin, preserve the skin's pur
 
 When an agent document contains human-facing semantic framing that should be preserved independently for human supervision, recommend extracting a matching skin unless the human has not authorized that migration.
 
-## Upgrade Rules
+## Evolution Rules
 
-Upgrades should:
+Follow [the agent evolution procedure](context-evolution.md). Deterministic CLI checks do not change context or metadata. Agent evolution should:
 
 - preserve existing agent documents and project-specific nested subdirectories;
 - add or recommend skins only where human semantic control is clear;

package/{skill → skills/adsm-ctx}/references/documentation-compression.md

@@ -1,7 +1,7 @@
 # Documentation Compression
 
-- Path: `skill/references/documentation-compression.md`
-- Changed: `20260917`
+- Path: `skills/adsm-ctx/references/documentation-compression.md`
+- Changed: `20261024`
 
 Use this reference when an agent must compress an existing ADSM cognitive documentation corpus while preserving accepted project meaning.
 
@@ -16,7 +16,7 @@ Compress the project cognitive documentation corpus under `ctx/docs/`.
 Follow this method:
 
 1. Read the applicable `AGENTS.md` hierarchy from the repository root to the target documentation scope. For the default scope, this means the hierarchy from the repository root to `ctx/docs/`.
-2. Read `skill/references/document-projections.md` for agent/skin classification and projection drift rules.
+2. Read [document-projections.md](document-projections.md) from this installed skill for agent/skin classification and projection drift rules.
 3. Use `ctx/docs/` as the default corpus unless the human explicitly provides another scope.
 4. Exclude operational context outside `ctx/docs/` by default, including `ctx/agent/`, workflow configuration, prompt assets, generated reports, runtime materials, and `ctx/assets/**`.
 5. Treat ordinary `*.md` files as agent-facing operational context documents and `*.skin.<lang>.md` files as human-facing semantic skins.
@@ -28,13 +28,13 @@ Follow this method:
 11. Avoid inventing, weakening, generalizing, or silently deleting project-specific knowledge.
 12. Update `Changed` attributes for every modified context document.
 13. Report non-editorial uncertainty and skin contradictions as human decisions instead of resolving them by rewrite.
-14. Use `templates/work/report/documentation-compression.md` as the report structure when a file report is requested.
+14. Use [the compression report template](../assets/report/documentation-compression.md) as the report structure when a file report is requested.
 
 ## Corpus Selection
 
 The default corpus is `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.
+Documentation compression is intended for declarative project documentation under the four ADSM levels: product, architecture, environment, and code, plus the mandatory 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.
 

package/{skill → skills/adsm-ctx}/references/documentation-quality-audit.md

@@ -1,7 +1,7 @@
 # Documentation Quality Audit
 
-- Path: `skill/references/documentation-quality-audit.md`
-- Changed: `20260917`
+- Path: `skills/adsm-ctx/references/documentation-quality-audit.md`
+- Changed: `20261024`
 
 Use this reference when an agent must audit an existing documentation corpus as an ADSM cognitive context.
 
@@ -16,8 +16,8 @@ Audit the documentation corpus of this project against the ADSM documentation qu
 Follow this method:
 
 1. Read the applicable `AGENTS.md` hierarchy from the repository root to `ctx/docs/`, unless the user explicitly gives another documentation scope.
-2. Read `skill/references/document-projections.md` for agent/skin classification and projection drift rules.
-3. Identify the audit corpus under `ctx/docs/`, including nested documentation under `product/`, `architecture/`, `environment/`, and `code/`.
+2. Read [document-projections.md](document-projections.md) from this installed skill for agent/skin classification and projection drift rules.
+3. Identify the audit corpus under `ctx/docs/`, including nested documentation under `product/`, `architecture/`, `environment/`, `code/`, and the mandatory cross-cutting `verification/` boundary.
 4. Classify ordinary `*.md` files as agent-facing operational context documents, `*.skin.<lang>.md` files as human-facing semantic skins, and `AGENTS.md` files as local agent routing instructions.
 5. Build a compact documentation map that shows source-of-truth agent documents, refinement relationships, agent/skin pairs, orphan skins, projection drift, and duplicated responsibility areas.
 6. Evaluate the corpus against the eight ADSM documentation quality criteria and the projection-specific checks below after deterministic validation is clean or warning-only.
@@ -25,7 +25,7 @@ Follow this method:
 8. Report only evidence-backed findings, with file references and the violated criterion.
 9. Separate findings that can be fixed editorially from findings that require cross-document synchronization, upstream documentation changes, projection-drift resolution, or human decisions.
 10. Do not invent missing product facts, architecture boundaries, authority rules, workflow semantics, or implementation behavior.
-11. Use `templates/work/report/documentation-quality-audit.md` as the report structure when a file report is requested.
+11. Use [the audit report template](../assets/report/documentation-quality-audit.md) as the report structure when a file report is requested.
 
 ## Corpus Selection
 
@@ -208,7 +208,7 @@ The audit may propose correction order and candidate edits, but it must distingu
 
 ## 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.
+Include mandatory `ctx/docs/verification/` in the default corpus; an AGENTS-only root contains no specifications to audit. Review it as cross-cutting specification documentation, not a fifth declarative level and not an evidence or incident archive.
 
 Check whether each durable specification:
 

package/{skill → skills/adsm-ctx}/references/orchestration-model.md

@@ -1,7 +1,7 @@
 # Orchestration Model
 
-- Path: `skill/references/orchestration-model.md`
-- Changed: `20260917`
+- Path: `skills/adsm-ctx/references/orchestration-model.md`
+- Changed: `20261024`
 
 This skill is a router and baseline manager.
 
@@ -11,7 +11,7 @@ It is responsible for:
 - the agent/skin documentation projection model;
 - lifecycle guidance;
 - baseline validation;
-- migration entry points;
+- agent-driven evolution guidance and read-only Deterministic CLI checks;
 - Verification Layer documentation lifecycle support and structural validation;
 - the reserved boundary definition for `ctx/agent/`.
 
@@ -20,9 +20,11 @@ It is not responsible for inventing specialized technical or domain documentatio
 For `ctx/agent/`, this skill may:
 
 - install only `ctx/agent/AGENTS.md` as the boundary file;
-- state that project-local subdirectories there are outside ADSM methodology;
+- explain that this branch is part of project cognitive context while its project-specific workflows are outside the reusable ADSM baseline;
 - preserve project-local materials that humans or agents maintain there for concrete tools or relationships.
 
+Operational materials organize authorized work within accepted declarations in `ctx/docs/` and applicable supervision constraints. They do not independently establish product or architecture authority or override human approval and escalation requirements. Preserve existing local materials and maintain navigation against the actual filesystem; add structure only for concrete project needs.
+
 For `ctx/agent/`, this skill must not:
 
 - define or require a template-managed subdirectory structure;
@@ -33,10 +35,10 @@ 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 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.
+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 mandatory cross-cutting documentation rather than a fifth level.
 
 ## Template Boundary
 
 `templates/ctx/` is the reusable initialization baseline. It may establish generic structure, starter documents, and the `ctx/agent/AGENTS.md` boundary, but it must not add project-specific facts or detailed ADSM methodology to project-facing documents.
 
-Keep only the minimal bootstrap signal needed to identify an ADSM context and route methodology work to this skill. Use `templates/work/` only as working material for agent operations; do not install those reports or optional semantic-skin patterns into project context by default.
+Keep only the minimal bootstrap signal needed to identify an ADSM context and route methodology work to this skill. Use `assets/` only as working material for agent operations; do not install those reports or optional semantic-skin patterns into project context by default.

package/{skill → skills/adsm-ctx}/references/semantic-skins.md

@@ -1,6 +1,6 @@
 # Semantic Skins
 
-- Path: `skill/references/semantic-skins.md`
+- Path: `skills/adsm-ctx/references/semantic-skins.md`
 - Changed: `20260814`
 
 A semantic skin is a compact skeletal human projection of its paired agent document.
@@ -63,3 +63,5 @@ When creating or reviewing a skin, verify that it:
 - 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.
+
+Use the [semantic-skin asset](../assets/context/semantic-skin.md) as an optional authoring pattern for authorized work. It is not an initialization template and does not determine the output location; place the resulting skin beside its paired project document.

package/{skill → skills/adsm-ctx}/references/specialized-skills.md

@@ -1,6 +1,6 @@
 # Specialized Skills
 
-- Path: `skill/references/specialized-skills.md`
+- Path: `skills/adsm-ctx/references/specialized-skills.md`
 - Changed: `20260917`
 
 Use specialized skills when the project context requires knowledge that should not live in this generic lifecycle skill.
@@ -30,5 +30,5 @@ 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 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;
+- the mandatory `ctx/docs/verification/` boundary 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/skills/adsm-ctx/references/testing-and-verification.md

@@ -0,0 +1,12 @@
+# Project Testing And Product Verification
+
+- Path: `skills/adsm-ctx/references/testing-and-verification.md`
+- Changed: `20261104`
+
+Project testing checks technical health and engineering conventions of the project and its artifacts, such as context structure, types, module conventions, dependency boundaries, and packaging. A passing project check is not evidence that the product satisfies all its declared requirements. In particular, structural context validation cannot establish semantic correctness.
+
+Product verification assesses a declared product property or behavior through bounded observations guided by applicable specifications under `ctx/docs/verification/`. Specifications identify the target, applicable state, approach, and interpretation limits; actual evidence and its provenance remain separate. Explain what each scenario establishes and what it does not: a controlled collaborator can support a bounded contract check, but does not prove live interoperability. The Verification Layer is cross-cutting and cannot redefine accepted product meaning.
+
+Choose checks proportionally to the change and risk. Include focused negative tests when security or failure boundaries change. The same test mechanism can contribute to either concern when its target and evidence are explicit; test level alone does not decide the distinction. Humans and accepted project context determine required guarantees. Projects own their scenarios, mechanisms, and evidence; do not invent them in generic templates.
+
+For npm projects, `npm test` should be a very fast local project smoke check: no network, temporary installations, or end-to-end scenarios. Use focused `test:*` commands where useful for other project checks. Use `npm run verify` for product verification and optional `verify:*` commands for selected scopes; document their coverage, prerequisites, skips, and limits. Do not prescribe a universal suite or mandatory end-to-end setup. These are npm conventions, not requirements to use npm in other ecosystems; keep existing contexts intact and evolve project commands only within the authorized scope.

package/skills/adsm-ctx/templates/AGENTS.md

@@ -0,0 +1,23 @@
+# Root Level
+
+- Path: `AGENTS.md`
+- Template Version: `20261024`
+- Changed: `YYYYMMDD`
+
+## Boundary
+
+This file controls repository work. `ctx/` owns project meaning and is authoritative for product and implementation decisions; consult `ctx/AGENTS.md` and task-relevant context for design or code changes. If implementation conflicts with accepted context, follow the context and report any proposed change to accepted meaning for human approval rather than silently rewriting it. Read navigation documents only when needed and avoid rereading unchanged instructions within a session. Use the `adsm-ctx` skill when available for context lifecycle work.
+
+`ctx/` may be part of this repository or a separately mounted repository. Detect its Git boundary before editing, preserve separate histories, and never remove, replace, relocate, or unmount it. If absent, create `ctx/` only when bootstrap is within the assigned scope. Deeper `AGENTS.md` files refine local rules without overriding root invariants.
+
+A task may cover multiple repositories. Coordinate affected contracts and consumers, verify their integration, and keep each Git history separate. Do not expand into unrelated repositories. The human defines scope and approves changes to accepted meaning.
+
+## Development Policy
+
+Default to Rapid Evolution by Default, Reliability by Requirement: deliver the essential happy path for fast feedback, fail visibly on unexpected conditions, and avoid speculative defenses and backward compatibility unless required. Verify essential contracts and increase verification when risk or observed defects justify it. Accepted context defines the target; humans determine acceptable risk and may strengthen or replace this default. Preserve security, integrity, and explicit invariants. Consult the `adsm-ctx` skill for the policy.
+
+## Efficient Execution
+
+Classify the task before reading context or running checks. Git-only work needs Git-state checks, not product-context scans or tests. For code or context changes, inspect only relevant owners; run deterministic checks chosen by changed responsibility and risk. Capture verbose output outside the model context and inspect logs on failure or when evidence is needed. Report results, omitted coverage, and material risks concisely.
+
+Do not modify, replace, delete, or relocate this file without explicit human instruction. Do not read, search, or expose secret-bearing files or credentials; non-secret examples may describe configuration shape. If a secret is accidentally exposed, do not repeat it; notify the human that it should be rotated or revoked.

package/skills/adsm-ctx/templates/ctx/AGENTS.md

@@ -0,0 +1,46 @@
+# Cognitive Context
+
+- Path: `ctx/AGENTS.md`
+- Template Version: `20261024`
+- Changed: `YYYYMMDD`
+
+## Purpose
+
+This directory contains the project's cognitive context.
+
+`docs/` holds authoritative project definitions, `agent/` holds project-local agent operations, and `assets/` holds non-authoritative supporting materials.
+
+Keep generic ADSM methodology outside the project context.
+
+## Level Map
+
+- `agent/` — project-local agent and tool materials.
+- `assets/` — visual, generated, and auxiliary documentation assets.
+- `docs/` — authoritative project documentation and constraints.
+- `AGENTS.md` — context boundary and navigation rules.
+- `README.md` — introductory context information.
+- `adsm.json` — context metadata and versioning.
+
+## Level Boundary
+
+Defines:
+
+- The boundary of the project's cognitive context.
+- Separation of authoritative documentation, agent operations, and supporting assets.
+- Navigation to the appropriate context branch.
+
+Does NOT define:
+
+- Product, architecture, environment, or code meaning; these belong under `docs/`.
+- Project-local agent workflows; these belong under `agent/`.
+- Generic ADSM methodology; use the `adsm-ctx` skill when available.
+
+## Local Reading Map
+
+- For initial project orientation, read `docs/ai-intro.md` when needed.
+- For repository topology, consult `docs/filesystem.md`.
+- For product, architecture, environment, or code work, follow `docs/AGENTS.md` and read only task-relevant documentation.
+- For project-local agent operations, follow `agent/AGENTS.md`.
+- For context lifecycle work, use the `adsm-ctx` skill when available.
+
+Read `README.md` only when additional orientation is needed. Avoid rereading unchanged context within a session.

package/{skill → skills/adsm-ctx}/templates/ctx/README.md

@@ -15,7 +15,7 @@ Detailed ADSM validation and methodology rules are intentionally kept out of thi
 ## Entry Points
 
 - Read `AGENTS.md` for cognitive-context structure and governance rules.
-- Use skill `adsm-ctx` when you need ADSM validation, upgrade, or methodology guidance.
+- Use skill `adsm-ctx` when you need ADSM validation, evolution, or methodology guidance.
 - Read `docs/filesystem.md` for the top-level repository map.
 - Read `docs/` for declarative project documentation.
 - Read `agent/` only when working with repository-local agent operations or workflow assets.

package/{skill → skills/adsm-ctx}/templates/ctx/adsm.json

@@ -1,6 +1,6 @@
 {
   "schema": "adsm-context",
-  "version": "0.2.0",
+  "version": "0.6",
   "capabilities": [
     "verification-layer"
   ],

package/skills/adsm-ctx/templates/ctx/agent/AGENTS.md

@@ -0,0 +1,32 @@
+# Agent Operations
+
+- Path: `ctx/agent/AGENTS.md`
+- Template Version: `20261024`
+- Changed: `YYYYMMDD`
+
+## Purpose
+
+This branch holds project-specific operational materials used by agents and their tools, such as instructions, prompts, workflow definitions, reports, or tool documentation. These are optional examples, not required document types or directories.
+
+## Level Map
+
+- `AGENTS.md` — agent operations boundary and local navigation.
+
+## Level Boundary
+
+Defines:
+
+- The project-local home for organizing and performing authorized agent work.
+- A project-specific structure beneath this branch; only this file belongs to the reusable initialization baseline.
+
+Does NOT define:
+
+- Authoritative product, architecture, environment, or code declarations; these belong under `ctx/docs/`.
+- A standard workflow, tool choice, agent role, or required operational subdirectory.
+
+## Working Rules
+
+- Follow the applicable `AGENTS.md` hierarchy and task-relevant materials listed in the Level Map before acting.
+- Keep operational instructions consistent with accepted declarations in `ctx/docs/` and applicable supervision constraints. They cannot grant authority to change accepted meaning or bypass approval and escalation requirements; surface conflicts to the human.
+- Preserve existing project-specific materials. Add materials only for concrete project needs, without speculative directory scaffolding.
+- Keep the Level Map synchronized with the actual filesystem, listing directories first and sorting each group alphabetically. Follow local instructions in the relevant subdirectory.

package/skills/adsm-ctx/templates/ctx/docs/AGENTS.md

@@ -0,0 +1,64 @@
+# Project Documentation
+
+- Path: `ctx/docs/AGENTS.md`
+- Template Version: `20261024`
+- Changed: `YYYYMMDD`
+
+## Purpose
+
+This directory contains authoritative project declarations and navigation documents.
+
+ADSM defines four ordered declarative levels: product → architecture → environment → code. Lower levels refine upstream meaning without redefining it. Accepted declarations constrain every valid implementation.
+
+A mandatory cross-cutting Verification Layer relates declarations to bounded observations of reality. It is not a fifth declarative level and does not establish independent authority over project meaning.
+
+## Level Map
+
+- `architecture/` — system structure, behavior, state ownership, and integration boundaries.
+- `code/` — implementation constraints and engineering conventions.
+- `environment/` — runtime conditions, infrastructure, and deployment constraints.
+- `product/` — product meaning, domain, roles, and expected outcomes.
+- `verification/` — durable verification specifications; cross-cutting, outside the authority chain.
+- `AGENTS.md` — documentation boundary and working rules.
+- `ai-intro.md` — initial project orientation for agents.
+- `filesystem.md` — top-level repository navigation.
+
+Keep this map aligned with the actual project structure. Add optional branches only when adopted.
+
+## Level Boundary
+
+Defines:
+
+- Accepted project declarations and their dependency order.
+- Rules for reading, refining, and maintaining declarative knowledge.
+- Boundaries between declarations, verification specifications, and supporting materials.
+
+Does NOT define:
+
+- Agent operations and workflows under `ctx/agent/`.
+- Executable product artifacts, runtime state, or operational evidence.
+- Generic ADSM methodology; use the `adsm-ctx` skill when available.
+
+## Local Reading Map
+
+- For unfamiliar projects, consult `ai-intro.md`.
+- For repository topology, consult `filesystem.md` when needed.
+- For project declarations, follow the relevant level's `AGENTS.md` and read its task-relevant documents.
+- For lower-level changes, consult the upstream declarations needed to establish their meaning and constraints.
+- For Verification Layer work, follow `verification/AGENTS.md`.
+- For context lifecycle, validation, audit, compression, or evolution, use the `adsm-ctx` skill when available.
+
+Avoid unnecessary full-context scans and repeated reading of unchanged documents.
+
+## Documentation Rules
+
+- Preserve the authority order: product → architecture → environment → code. Report missing or conflicting upstream meaning rather than inventing or silently changing it downstream.
+- Keep each durable declaration in its appropriate authoritative document. Preserve consistency across dependent levels.
+- Ordinary `*.md` documents are agent-facing and written in English by default. Optional `*.skin.<lang>.md` files provide human-facing semantic projections.
+- Before editing an agent document, read all matching skins. Preserve their meaning and invariants; report projection drift or required human decisions instead of silently resolving conflicts.
+- Keep documents explicit, focused, and maintainable. Preserve meaningful nested structure and do not sacrifice requirements or precision for brevity.
+- Keep each declarative level within nine direct directories and nine direct ordinary files where practical, excluding `AGENTS.md` and matching skins. Record intentional excess under `## Documentation Capacity Exception` in that level's `AGENTS.md`.
+- Require `verification/AGENTS.md`; the root may contain only this file. Create primary-target categories only for actual durable specifications.
+- Place verification specifications under their primary declarative targets and link secondary declarations. Keep specifications distinct from actual evidence and operational feedback state. Neither evidence nor assessments may redefine accepted meaning.
+- Keep visual, generated, rendered, and auxiliary artifacts under `ctx/assets/**`; they must not introduce authoritative project meaning.
+- Maintain `Path` and `Changed` attributes in stable documents. Delegate detailed methodology and lifecycle procedures to the `adsm-ctx` skill.

package/{skill → skills/adsm-ctx}/templates/ctx/docs/code/testing.md

@@ -14,4 +14,6 @@ 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.
+Keep executable test organization, framework conventions, fixtures, and isolation in this code-level document. When a project adds a durable specification under the mandatory `ctx/docs/verification/` boundary, that specification states the observed declared expectation and primary target; the executable mechanism remains governed here.
+
+Distinguish project health checks from product verification and document each command's scope and limits. Apply the `adsm-ctx` skill's testing and verification guidance to the project's ecosystem and risk.

package/skills/adsm-ctx/templates/ctx/docs/verification/AGENTS.md

@@ -0,0 +1,31 @@
+# Verification Layer
+
+- Path: `ctx/docs/verification/AGENTS.md`
+- Changed: `20261024`
+
+## Purpose
+
+This mandatory cross-cutting boundary holds durable verification specifications. It is not a fifth declarative authority level. Product → architecture → environment → code remains the ordered hierarchy; humans control accepted meaning.
+
+## Level Map
+
+- `AGENTS.md` — verification boundary and local routing.
+
+## Navigation And Editing
+
+The root may contain only `AGENTS.md` when no specifications exist. Create `product/`, `architecture/`, `environment/`, or `code/` only when an actual durable specification belongs there. Route each specification by its primary declarative target, linking secondary targets rather than duplicating it. Preserve useful project-specific nesting and add local routing instructions as needed.
+
+Read applicable declarations and matching semantic skins before editing. Preserve traceability, applicability, interpretation bounds, and blind spots. Escalate conflicting accepted meaning to the human.
+
+## Level Boundary
+
+Defines:
+
+- The home and primary-target routing of durable verification specifications.
+- Specification applicability, traceability, and interpretation limits.
+
+Does NOT define:
+
+- A fifth declarative authority level or changes to accepted declarations.
+- Actual observations, evidence records, or operational feedback state; keep these outside this boundary.
+- Verification coverage or runtime correctness merely from structural conformance.

package/src/Cli/Command/Init.mjs

@@ -1,13 +1,25 @@
 // @ts-check
 
-import processModule from "node:process";
-
-/** @namespace Fl32_Skill_Adsm_Ctx_Cli_Command_Init */
+/**
+ * @namespace Fl32_Skill_Adsm_Ctx_Cli_Command_Init
+ * @description Initializes project context via the CLI.
+ */
 export default class Init {
-  constructor({config, init}) {
+  /**
+   * @param {object} deps
+   * @param {Fl32_Skill_Adsm_Ctx_Cli_Config} deps.config
+   * @param {Fl32_Skill_Adsm_Ctx_Init_Service} deps.init
+   * @param {typeof import("node:process")} deps.processModule
+   */
+  constructor({config, init, processModule}) {
     this.id = "adsm-ctx:init";
     this.summary = "Initialize an ADSM context.";
     this.lifetime = "finite";
+    /**
+     * @param {object} deps
+     * @param {Record<string, string>} deps.args
+     * @returns {Promise<void>}
+     */
     this.execute = async function ({args}) {
       const result = await init.execute({targetPath: args["target-path"] ?? config.cwd});
       processModule.stdout.write(`${formatInitReport(result)}\n`);
@@ -15,8 +27,12 @@ export default class Init {
   }
 }
 
+/**
+ * @param {Fl32_Skill_Adsm_Ctx_Init_Result} result
+ * @returns {string}
+ */
 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$"})});
+export const __deps__ = Object.freeze({default: Object.freeze({processModule: "node:process", config: "TeqFw_Cli_Config$", init: "Fl32_Skill_Adsm_Ctx_Init_Service$"})});

package/src/Cli/Command/InstallSkill.mjs

@@ -1,13 +1,24 @@
 // @ts-check
 
-import processModule from "node:process";
-
-/** @namespace Fl32_Skill_Adsm_Ctx_Cli_Command_InstallSkill */
+/**
+ * @namespace Fl32_Skill_Adsm_Ctx_Cli_Command_InstallSkill
+ * @description Installs the skill payload via the CLI.
+ */
 export default class InstallSkill {
-  constructor({installer}) {
+  /**
+   * @param {object} deps
+   * @param {Fl32_Skill_Adsm_Ctx_Skill_Installer} deps.installer
+   * @param {typeof import("node:process")} deps.processModule
+   */
+  constructor({installer, processModule}) {
     this.id = "adsm-ctx:install-skill";
     this.summary = "Install the bundled agent skill payload.";
     this.lifetime = "finite";
+    /**
+     * @param {object} deps
+     * @param {Record<string, string>} deps.args
+     * @returns {Promise<void>}
+     */
     this.execute = async function ({args}) {
       const targetDir = await installer.execute({targetRoot: args["skills-root"]});
       processModule.stdout.write(`Installed skill payload to ${targetDir}\n`);
@@ -15,4 +26,4 @@ export default class InstallSkill {
   }
 }
 
-export const __deps__ = Object.freeze({default: Object.freeze({installer: "Fl32_Skill_Adsm_Ctx_Skill_Installer$"})});
+export const __deps__ = Object.freeze({default: Object.freeze({processModule: "node:process", installer: "Fl32_Skill_Adsm_Ctx_Skill_Installer$"})});

package/src/Cli/Command/Validate.mjs

@@ -1,13 +1,25 @@
 // @ts-check
 
-import processModule from "node:process";
-
-/** @namespace Fl32_Skill_Adsm_Ctx_Cli_Command_Validate */
+/**
+ * @namespace Fl32_Skill_Adsm_Ctx_Cli_Command_Validate
+ * @description Validates project context via the CLI.
+ */
 export default class Validate {
-  constructor({config, validate}) {
+  /**
+   * @param {object} deps
+   * @param {Fl32_Skill_Adsm_Ctx_Cli_Config} deps.config
+   * @param {typeof import("node:process")} deps.processModule
+   * @param {Fl32_Skill_Adsm_Ctx_Validate_Service} deps.validate
+   */
+  constructor({config, processModule, validate}) {
     this.id = "adsm-ctx:validate";
     this.summary = "Validate an ADSM context.";
     this.lifetime = "finite";
+    /**
+     * @param {object} deps
+     * @param {Record<string, string>} deps.args
+     * @returns {Promise<void>}
+     */
     this.execute = async function ({args}) {
       const result = await validate.execute({targetPath: args["target-path"] ?? config.cwd});
       processModule.stdout.write(`${validate.format({result})}\n`);
@@ -16,4 +28,4 @@ export default class Validate {
   }
 }
 
-export const __deps__ = Object.freeze({default: Object.freeze({config: "TeqFw_Cli_Config$", validate: "Fl32_Skill_Adsm_Ctx_Validate_Service$"})});
+export const __deps__ = Object.freeze({default: Object.freeze({processModule: "node:process", config: "TeqFw_Cli_Config$", validate: "Fl32_Skill_Adsm_Ctx_Validate_Service$"})});