@flancer32/skill-adsm-ctx 0.2.1 → 0.4.0

package/CHANGELOG.md

@@ -0,0 +1,30 @@
+# Changelog
+
+All notable changes to this package are documented in this file.
+
+## 0.4.0 - 2026-09-23
+
+### Added
+
+- Added optional, capability-based Verification Layer support, with specifications grouped by the primary product, architecture, environment, or code target.
+- Added validation for verification block structure, populated categories, metadata capabilities, and adoption without a declared capability; older and unadopted contexts remain valid.
+- Added guidance for verification evidence, re-verification, Responsible Context, and the Software Evolution Loop across the bundled skill and project context.
+
+### Changed
+
+- Kept the four ordered declarative documentation levels and defined `verification/` as an optional cross-cutting block rather than another authority level.
+- Raised the context metadata baseline to `0.2.0` and updated initialization templates to advertise `verification-layer` without creating empty scaffolding.
+- Updated design, validation, upgrade, audit, and documentation guidance to preserve existing contexts and require explicit, durable verification specifications before adoption.
+- Reconciled product and architecture documents, semantic skins, README, and tests around the boundary between declarative context and operational evidence.
+- Clarified that the package does not execute tests, collect monitoring data, persist feedback state, or coordinate distributed incidents; refreshed the dependency lockfile.
+
+## 0.3.0 - 2026-08-14
+
+### Changed
+
+- Made global npm installation the canonical distribution for the Node.js runtime and agent skill payload.
+- Added the public `adsm-ctx` executable, which launches this package through TeqFW explicit-host mode.
+- Replaced documented `teq adsm-ctx:*` user commands with short `adsm-ctx` commands.
+- Updated the bundled skill installation guidance and cognitive context to describe the version-matched payload workflow.
+
+### Dependencies

package/README.md

@@ -4,7 +4,7 @@ Build and evolve project cognitive context for Agent-Driven Software Management
 
 ## Overview
 
-`@flancer32/skill-adsm-ctx` is a private ADSM skill package for initializing, designing, validating, auditing, compressing, and upgrading project cognitive context.
+`@flancer32/skill-adsm-ctx` is an ADSM skill package for initializing, designing, validating, auditing, compressing, and upgrading project cognitive context.
 
 It manages the lifecycle of project context as its primary object. It does not define business requirements, backend architecture, browser architecture, deployment logic, or domain-specific documentation on its own.
 
@@ -14,7 +14,8 @@ The package includes:
 
 - the `adsm-ctx` CLI for lifecycle operations;
 - the `adsm-ctx` skill payload for AI agents;
-- reusable `ctx/` templates for bootstrapping ADSM-compatible projects.
+- reusable `ctx/` templates for bootstrapping ADSM-compatible projects;
+- optional Verification Layer documentation lifecycle support;
 - working templates for agent-produced reports.
 
 ## Purpose
@@ -26,7 +27,8 @@ Use this package when you need to:
 - validate whether an existing context follows expected ADSM structure;
 - audit a documentation corpus against ADSM documentation quality criteria;
 - compress a documentation corpus while preserving accepted project meaning;
-- upgrade a context when ADSM conventions evolve.
+- upgrade a context when ADSM conventions evolve;
+- design, validate, audit, or compress an optional cross-cutting Verification Layer.
 
 This package acts as an orchestration layer. It provides generic structure, lifecycle guidance, validation, documentation quality audit guidance, documentation compression guidance, and upgrade entry points. When project-specific context is required, it should direct the agent to use specialized skills when they are available.
 
@@ -49,32 +51,45 @@ This package does not:
 ## Requirements
 
 - Node.js with npm.
-- GitHub SSH access to the repository for global installation from GitHub.
+- An agent skills root, normally `~/.agents/skills`.
 
-## Global Installation
+## Installation And Update
 
-Install the package globally from GitHub:
+Install the package globally once for the current user:
 
 ```sh
-npm install -g git+ssh://git@github.com/flancer32/skill-adsm-ctx.git
+npm install --global @flancer32/skill-adsm-ctx
 ```
 
-This provides the CLI command:
+Install its matching agent payload into the selected skills root:
 
 ```sh
-adsm-ctx
+adsm-ctx install-skill "$HOME/.agents/skills"
 ```
 
-To install the skill payload for agent use:
+The command replaces only `$HOME/.agents/skills/adsm-ctx`; it does not modify other installed skills.
+
+Verify the runtime and payload:
 
 ```sh
+adsm-ctx --help
+test -f "$HOME/.agents/skills/adsm-ctx/SKILL.md"
+```
+
+To update, update the global npm package and reinstall its payload:
+
+```sh
+npm update --global @flancer32/skill-adsm-ctx
 adsm-ctx install-skill "$HOME/.agents/skills"
 ```
 
-This copies the payload to:
+The npm package is the canonical distribution of both artifacts. Its public `adsm-ctx` launcher runs the package as an explicit TeqFW host; the `install-skill` command copies the version-matched `skill/` bundle. Do not copy only `SKILL.md` manually: the payload also needs its references and templates.
 
-```text
-$HOME/.agents/skills/adsm-ctx
+For a project-pinned CI or team workflow, install the package locally and invoke the same public launcher with npm:
+
+```sh
+npm install --save-dev @flancer32/skill-adsm-ctx
+npm exec -- adsm-ctx validate .
 ```
 
 ## CLI Usage
@@ -121,11 +136,17 @@ Install the bundled skill payload:
 adsm-ctx install-skill <skills-root>
 ```
 
+Advanced TeqFW users may invoke the metadata-declared commands directly when `teq` is installed:
+
+```sh
+teq --host @flancer32/skill-adsm-ctx adsm-ctx:validate .
+```
+
 ## Lifecycle Modes
 
 ### `init`
 
-Creates the minimal ADSM-compatible context structure, starter documents, and `ctx/adsm.json` metadata.
+Creates the minimal ADSM-compatible context structure, starter documents, and `ctx/adsm.json` metadata. The metadata advertises the `verification-layer` convention capability, but initialization does not create `ctx/docs/verification/` or empty categories.
 
 ### `design`
 
@@ -133,7 +154,7 @@ Provides guidance for classifying the project, choosing relevant documentation b
 
 ### `validate`
 
-Checks baseline paths, required documentation levels, required `AGENTS.md` files, metadata, body/skin projection shape, local markdown document links, and lightweight skin-shape heuristics. When the repository provides a deterministic validator, run it and report errors and warnings separately. Validation reports findings without modifying project content.
+Checks baseline paths, required declarative documentation levels, optional Verification Layer structure when adopted, required `AGENTS.md` files, metadata, body/skin pairing, localized skin names, redundant `Agent Document` sections in skins, local markdown document links, and other formal structural projection checks. It does not score semantic-skin length, cognitive load, or human readability; those belong to `quality-audit`. Validation reports findings without modifying project content.
 
 ### `quality-audit`
 
@@ -149,7 +170,7 @@ The default compression corpus is `ctx/docs/`. Operational context such as `ctx/
 
 ### `upgrade`
 
-Reads context metadata and reports or applies non-destructive migrations when available. The initial implementation provides the migration mechanism and reports when no migrations apply.
+Checks whether context metadata exists and reports that no automatic migrations are available. Verification Layer adoption remains optional and non-destructive: upgrade does not create verification scaffolding. The command remains the entry point for future explicit migrations.
 
 ## Workflow
 
@@ -176,6 +197,8 @@ product
 
 Use the architecture level once product meaning is clear enough to define stable engineering guardrails.
 
+`ctx/docs/verification/` is optional and cross-cutting. It is not a fifth declarative level. Create it only when a durable verification specification exists; place that specification below the category of the declaration it primarily evaluates.
+
 The bundled architecture templates expect these top-level documents:
 
 - `overview.md`
@@ -199,7 +222,7 @@ overview.skin.en.md
 overview.skin.ru.md
 ```
 
-Use lowercase ISO 639-1 codes (`en`, `ru`, `es`); add a regional tag only for a genuine regional distinction. `overview.skin.md` is invalid. All skins with the same basename form one group with the canonical document, and may adapt the presentation for people rather than be literal translations.
+Use lowercase ISO 639-1 codes (`en`, `ru`, `es`); add a regional tag only for a genuine regional distinction. `overview.skin.md` is invalid. All skins with the same basename form one group with the canonical document, and may adapt the presentation for people rather than be literal translations. A skin uses a compact structure appropriate to its document type; its paired base is derived from the filename, so it does not need an `Agent Document` link.
 
 For `AGENTS.md` authoring, `Level Boundary` sections should stay compact and guardrail-oriented. They are intended to prevent likely scope drift, not to become exhaustive specifications.
 
@@ -228,7 +251,7 @@ When no specialized skill is available, this package should create only generic
 Run the CLI directly from the repository:
 
 ```sh
-node ./bin/cli.mjs --help
+npm exec -- adsm-ctx --help
 ```
 
 Run the tests:
@@ -237,6 +260,10 @@ Run the tests:
 npm test
 ```
 
+## Changelog
+
+See [CHANGELOG.md](CHANGELOG.md) for the prepared, unpublished 0.4.0 release notes.
+
 ## Status
 
 This repository contains a working skeleton intended as a foundation for future ADSM context lifecycle tooling.

package/bin/adsm-ctx.mjs

@@ -0,0 +1,44 @@
+#!/usr/bin/env node
+// @ts-check
+
+import {spawnSync} from "node:child_process";
+import {createRequire} from "node:module";
+import path from "node:path";
+import processModule from "node:process";
+import {fileURLToPath} from "node:url";
+
+const require = createRequire(import.meta.url);
+const packageRoot = path.resolve(path.dirname(fileURLToPath(import.meta.url)), "..");
+const teqPath = require.resolve("@teqfw/cli/bin/teq.mjs");
+const hostName = "@flancer32/skill-adsm-ctx";
+const commandNames = new Set(["init", "design", "validate", "upgrade", "install-skill"]);
+
+const args = normalizeArgs(processModule.argv.slice(2));
+const result = spawnSync(processModule.execPath, [
+  teqPath,
+  "--host", hostName,
+  "--host-root", packageRoot,
+  ...args,
+], {
+  cwd: processModule.cwd(),
+  env: processModule.env,
+  stdio: "inherit",
+});
+
+if (result.error) {
+  throw result.error;
+}
+processModule.exitCode = typeof result.status === "number" ? result.status : 1;
+
+/**
+ * Maps the public command surface onto the metadata-declared TeqFW commands.
+ *
+ * @param {string[]} input
+ * @returns {string[]}
+ */
+function normalizeArgs(input) {
+  if (input.length === 0 || input[0] === "--help" || input[0] === "-h") return ["help"];
+  if (input[0] === "--version" || input[0] === "-v") return ["version"];
+  if (commandNames.has(input[0])) return [`adsm-ctx:${input[0]}`, ...input.slice(1)];
+  return input;
+}

package/migrations/README.md

@@ -1,9 +1,13 @@
 # Migrations
 
-This directory is reserved for future context migrations.
+This directory is reserved for explicit context migrations. The `verification-layer` convention is capability-based and optional: it does not require a migration, `ctx/docs/verification/`, empty categories, or placeholder specifications. `adsm-ctx upgrade` therefore preserves existing contexts and reports that no automatic migrations are available.
 
 Each migration should be:
 
 - versioned;
 - non-destructive by default;
 - explicit about prerequisites and post-upgrade manual steps.
+
+## Verification Layer Compatibility
+
+Contexts without `capabilities`, with context version `0.1.0`, or without `ctx/docs/verification/` remain valid. A project may add a structurally complete Verification Layer when it has a durable specification; it should then advertise the `verification-layer` capability in `ctx/adsm.json`. Malformed adopted structure is a validation error, while absence is not.

package/package.json

@@ -1,33 +1,87 @@
 {
   "name": "@flancer32/skill-adsm-ctx",
-  "version": "0.2.1",
+  "version": "0.4.0",
   "description": "Build and evolve project cognitive context for Agent-Driven Software Management (ADSM).",
   "license": "Apache-2.0",
   "type": "module",
   "engines": {
     "node": ">=20"
   },
+  "types": "types.d.ts",
+  "files": [
+    "skill/",
+    "bin/",
+    "src/",
+    "migrations/",
+    "jsconfig.json",
+    "README.md",
+    "LICENSE",
+    "CHANGELOG.md",
+    "types.d.ts"
+  ],
   "bin": {
-    "adsm-ctx": "bin/cli.mjs"
+    "adsm-ctx": "bin/adsm-ctx.mjs"
   },
-  "types": "types.d.ts",
   "scripts": {
-    "start": "node ./bin/cli.mjs",
-    "install:skill": "node ./bin/cli.mjs install-skill \"$HOME/.agents/skills\"",
+    "start": "adsm-ctx",
+    "init": "adsm-ctx init",
+    "design": "adsm-ctx design",
+    "validate": "adsm-ctx validate",
+    "upgrade": "adsm-ctx upgrade",
+    "install:skill": "adsm-ctx install-skill \"$HOME/.agents/skills\"",
     "test:unit": "find test/unit -name '*.test.mjs' -print0 | xargs -0 -r node --test",
     "test:integration": "find test/integration -name '*.test.mjs' -print0 | xargs -0 -r node --test",
     "test": "npm run test:unit && npm run test:integration"
   },
   "dependencies": {
+    "@teqfw/cli": "^2.2.0",
     "@teqfw/di": ">=2.5.1 <3.0.0"
   },
   "teqfw": {
-    "namespaces": [
-      {
-        "prefix": "Fl32_Skill_Adsm_Ctx_",
-        "path": "./src",
-        "ext": ".mjs"
+    "fw": {
+      "di": {
+        "namespaces": [
+          {
+            "prefix": "Fl32_Skill_Adsm_Ctx_",
+            "path": "./src",
+            "ext": ".mjs"
+          }
+        ]
+      },
+      "cli": {
+        "commands": [
+          {
+            "id": "adsm-ctx:init",
+            "summary": "Initialize an ADSM context.",
+            "arguments": [{"name": "target-path", "kind": "string", "description": "Project root; defaults to the current working directory."}],
+            "component": "Fl32_Skill_Adsm_Ctx_Cli_Command_Init$"
+          },
+          {
+            "id": "adsm-ctx:design",
+            "summary": "Show ADSM context design guidance.",
+            "arguments": [{"name": "target-path", "kind": "string", "description": "Project root; defaults to the current working directory."}],
+            "component": "Fl32_Skill_Adsm_Ctx_Cli_Command_Design$"
+          },
+          {
+            "id": "adsm-ctx:validate",
+            "summary": "Validate an ADSM context.",
+            "arguments": [{"name": "target-path", "kind": "string", "description": "Project root; defaults to the current working directory."}],
+            "component": "Fl32_Skill_Adsm_Ctx_Cli_Command_Validate$"
+          },
+          {
+            "id": "adsm-ctx:upgrade",
+            "summary": "Upgrade an ADSM context.",
+            "arguments": [{"name": "target-path", "kind": "string", "description": "Project root; defaults to the current working directory."}],
+            "component": "Fl32_Skill_Adsm_Ctx_Cli_Command_Upgrade$"
+          },
+          {
+            "id": "adsm-ctx:install-skill",
+            "summary": "Install the bundled agent skill payload.",
+            "arguments": [{"name": "skills-root", "kind": "string", "required": true, "description": "Directory that contains installed agent skills."}],
+            "component": "Fl32_Skill_Adsm_Ctx_Cli_Command_InstallSkill$"
+          }
+        ]
       }
-    ]
+    }
   }
 }

package/skill/SKILL.md

@@ -13,7 +13,7 @@ Humans own direction, accepted meaning, approval, and accountability. Agents ref
 
 1. Identify the target repository and the requested lifecycle mode.
 2. Read the applicable `AGENTS.md` hierarchy. If `ctx/` exists, read `ctx/AGENTS.md` and `ctx/docs/filesystem.md` before deeper context work.
-3. Read [document-projections.md](references/document-projections.md) for any work under `ctx/docs/`.
+3. Read [document-projections.md](references/document-projections.md) for any work under `ctx/docs/`; for skin work, also read [semantic-skins.md](references/semantic-skins.md).
 4. Use the routing table below, then load only the references needed for the requested mode.
 
 ## Route The Request
@@ -22,6 +22,7 @@ Humans own direction, accepted meaning, approval, and accountability. Agents ref
 | --- | --- |
 | `init` baseline | [context-lifecycle.md](references/context-lifecycle.md); use the `templates/ctx/` baseline. |
 | `design` or new branch | [context-lifecycle.md](references/context-lifecycle.md), [design-questionnaire.md](references/design-questionnaire.md), and [specialized-skills.md](references/specialized-skills.md). |
+| Verification Layer or Software Evolution Loop | [document-projections.md](references/document-projections.md), [context-lifecycle.md](references/context-lifecycle.md), [documentation-quality-audit.md](references/documentation-quality-audit.md), and [specialized-skills.md](references/specialized-skills.md). |
 | `validate` structure | [context-lifecycle.md](references/context-lifecycle.md), [document-projections.md](references/document-projections.md), and the repository-provided deterministic validator when available. Report errors and warnings separately. |
 | `quality-audit` | Run `validate` first; then load [documentation-quality-audit.md](references/documentation-quality-audit.md). Report findings; do not rewrite project meaning. |
 | `documentation-compression` | Load [documentation-compression.md](references/documentation-compression.md). Rewrite only with authorization and preserve accepted meaning. |
@@ -30,7 +31,7 @@ Humans own direction, accepted meaning, approval, and accountability. Agents ref
 | `ctx/agent/`, templates, or generic ownership boundary | Load [orchestration-model.md](references/orchestration-model.md). |
 | Browser, backend, data, deployment, or concrete tool workflow | Load [specialized-skills.md](references/specialized-skills.md), then use a matching available specialized skill. |
 
-`install-skill` installs this payload into a skills root; it is not a lifecycle mode.
+`adsm-ctx install-skill <skills-root>` installs this payload from the globally installed npm package into a skills root; it is not a lifecycle mode.
 
 ## Non-Negotiable Boundaries
 
@@ -39,9 +40,9 @@ Humans own direction, accepted meaning, approval, and accountability. Agents ref
 - Read a matching `*.skin.<lang>.md` before editing its agent document. Report projection drift or a required human decision instead of silently changing skin-controlled meaning.
 - Keep `ctx/agent/` project-local: install only its boundary `AGENTS.md`; do not impose tool-specific structure, labels, prompts, roles, or executable profiles.
 - Keep assets under `ctx/assets/**`; they may illustrate, but never define, authoritative meaning.
-- Use only the four ADSM top-level documentation levels under `ctx/docs/`; allow justified nested project structure within them.
+- Preserve the four ordered declarative documentation levels under `ctx/docs/`: `product`, `architecture`, `environment`, and `code`. Allow an optional cross-cutting `verification/` block only as defined in [document-projections.md](references/document-projections.md); it is never a fifth level.
 - 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; an intentional excess must be stated explicitly in that level's `AGENTS.md`.
 
 ## Completion
 
-Finish with explicit validation results, specialization gaps, human decisions, and any preserved project-specific content. Use the relevant templates under `templates/ctx/` for initialization and `templates/work/` only when a working report is requested.
+Finish with explicit validation results, Verification Layer adoption state when relevant, specialization gaps, human decisions, and any preserved project-specific content. Use the relevant templates under `templates/ctx/` for initialization and `templates/work/` only when a working report is requested.

package/skill/references/context-lifecycle.md

@@ -1,7 +1,7 @@
 # Context Lifecycle
 
 - Path: `skill/references/context-lifecycle.md`
-- Changed: `20260715`
+- Changed: `20260917`
 
 `adsm-ctx` manages six lifecycle modes for project cognitive context.
 
@@ -13,10 +13,10 @@ The skill manages generic lifecycle structure. It does not define a project's bu
 
 - `init` creates the baseline. Create the root `AGENTS.md`, `ctx/` baseline, starter documents, and `ctx/adsm.json` only where they are missing. Use `templates/ctx/`; create placeholders rather than project facts when context is unknown.
 - `design` shapes context for the actual project. Classify the project, choose justified generic branches and nested structure, decide whether semantic skins are needed, and route specializations. Use [design-questionnaire.md](design-questionnaire.md) and [specialized-skills.md](specialized-skills.md).
-- `validate` checks structural integrity without destructive edits. Check baseline paths, context metadata, the four top-level documentation levels, local `AGENTS.md` placement, document headers, agent/skin pairs, required skin structure, local document links, and `ctx/assets/**` exclusion.
+- `validate` checks formal structural integrity without destructive edits. Check baseline paths, context metadata, the four declarative documentation levels, optional Verification Layer adoption, local `AGENTS.md` placement, document headers, agent/skin pairs, reversible skin naming, redundant `Agent Document` sections, local document links, and `ctx/assets/**` exclusion. Do not score semantic compactness, cognitive load, or word counts.
 - `quality-audit` guides semantic documentation review. It is report-only by default; use [documentation-quality-audit.md](documentation-quality-audit.md) after validation.
 - `documentation-compression` guides controlled documentation rewrite that preserves accepted meaning. Use [documentation-compression.md](documentation-compression.md); do not treat it as an automatic semantic rewrite.
-- `upgrade` migrates context non-destructively. Read metadata first, preserve project-specific content, and use [upgrade-policy.md](upgrade-policy.md) for safe boundaries.
+- `upgrade` is the non-destructive migration entry point. The current implementation checks for metadata and reports that no automatic migrations are available; preserve project-specific content and use [upgrade-policy.md](upgrade-policy.md) when explicit migrations exist.
 
 The lifecycle is iterative. A project may return to `design`, `validate`, `quality-audit`, `documentation-compression`, and `upgrade` many times after initialization.
 
@@ -24,24 +24,32 @@ The lifecycle is iterative. A project may return to `design`, `validate`, `quali
 
 `documentation-compression` is an agent-guided rewrite mode. It is not a CLI semantic scoring command and must not change project meaning.
 
-The package-level `install-skill` command installs the skill payload into an agent skills root.
+The package-level `adsm-ctx install-skill <skills-root>` command installs the version-matched skill payload into an agent skills root.
 
 It is not a context lifecycle mode.
 
 All lifecycle modes that operate on `ctx/docs/` use the documentation projection model in [document-projections.md](document-projections.md).
 
-The lifecycle must preserve ADSM's four top-level documentation levels under `ctx/docs/` while allowing project-specific nested subdirectories inside those levels.
+The lifecycle must preserve ADSM's four ordered declarative documentation levels under `ctx/docs/` while allowing project-specific nested subdirectories inside them and an optional cross-cutting Verification Layer as defined in [document-projections.md](document-projections.md).
 
 Validation, audit, compression, and upgrade work must recognize agent documents, semantic skins, agent/skin pairs, orphan skins, projection drift, and `ctx/assets/**` as non-authoritative artifact space.
 
 When a repository provides a deterministic validation command, validation work must discover and run it. Report errors and warnings separately; warning-only output is not a clean result. Clear structural errors before a quality audit.
 
+## Verification Layer And Software Evolution
+
+Verification defines the relation between an accepted declaration and a bounded observation of reality. A signal may arise from an active check, passive runtime observation, or an external report. It becomes an observation only after enough context identifies what was observed, against which applicable expectation, and in what relevant state.
+
+An observation supports an assessment such as conformity, deviation, ambiguity, contradiction, or insufficient evidence. A deviation is not a cause. Localization hypotheses remain revisable until targeted evidence supports them. A Responsible Context advances the loop within its authority; resolution feedback alone does not close it. Where closure is required, obtain a new applicable re-verification of the relevant original expectation.
+
+The Software Evolution Loop is broader than Verification. Architecture defines boundaries and ownership; supervision defines acceptable uncertainty and required independence; project-local workflow owns routing and operational feedback state; specialized skills provide concrete verification, monitoring, transport, or distributed feedback procedures. `adsm-ctx` provides methodology and documentation lifecycle support, not a runtime coordination system.
+
 ## Shared Boundaries
 
 - Establish product meaning before architecture, then architecture before environment or code constraints. Lower levels refine but do not create upstream meaning.
 - Keep `ctx/docs/filesystem.md` limited to root-level repository navigation. Describe lower structure only in the appropriate local `AGENTS.md` files.
 - Preserve project-local materials under `ctx/agent/`; this skill defines only its boundary `AGENTS.md` and never invents tool instructions, workflows, labels, events, prompts, profiles, or agent roles.
-- Use only `product/`, `architecture/`, `environment/`, and `code/` as ADSM top-level documentation levels. Nested structure within them remains project-specific.
+- Use only `product/`, `architecture/`, `environment/`, and `code/` as ordered ADSM declarative levels. `verification/` may be an optional cross-cutting documentation block, never a fifth level; nested structure remains project-specific.
 - Keep each documentation level within 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, its local `AGENTS.md` must explicitly record a `Documentation Capacity Exception` and the reason.
 - Place visual, generated, rendered, and auxiliary artifacts under `ctx/assets/**`; they cannot introduce authoritative project meaning.
 - Read a matching semantic skin before changing its agent document. Report projection drift or a required human decision when a change would alter skin-controlled meaning.

package/skill/references/design-questionnaire.md

@@ -1,7 +1,7 @@
 # Design Questionnaire
 
 - Path: `skill/references/design-questionnaire.md`
-- Changed: `20260610`
+- Changed: `20260917`
 
 Use this questionnaire at the start of `design` mode to classify the project and decide which specialized ADSM skills may be relevant.
 
@@ -42,3 +42,15 @@ Use this questionnaire at the start of `design` mode to classify the project and
 - If the project includes a browser-based web application, look for a browser documentation skill such as `skill-adsm-doc-web-browser`.
 - If the project includes other specialized areas, choose the matching skill when available.
 - If a relevant specialized skill is unavailable, still create the justified ADSM structure, preserve any project-defined semantics, and record the missing specialization as a gap instead of inventing unsupported details.
+
+## Verification Questions
+
+11. Which declared outcomes, boundaries, conditions, or code properties have high practical consequence if wrong?
+12. Which broad observations provide useful early detection, and which blind spots need narrower diagnostics?
+13. Which signals may arrive actively, passively, or from external reporters, and what provenance is available?
+14. Which observations can the current agent perform directly, and which require another Responsible Context, human action, or specialized tooling?
+15. Does supervision require independent evidence or an independent actor for any concern?
+
+## Verification Design Guidance
+
+Do not create `ctx/docs/verification/` merely because these questions were asked. When a durable specification is justified, place it under the category of its primary declaration target, link secondary targets instead of duplicating it, and route concrete test execution, monitoring, signal transport, or distributed feedback work to a specialized skill or project-local design.