@flancer32/skill-adsm-ctx 0.7.0 → 0.8.0

package/CHANGELOG.md

@@ -2,6 +2,16 @@
 
 All notable changes to this package are documented in this file.
 
+## 0.8.0 — 2026-11-14
+
+- Target context schema `0.8`, including Context Actuality and current decision rationale; older schemas require agent-led review before metadata promotion.
+
+- Define Context Actuality and inherited guidance: preserve the accepted target and current rationale, with history in Git.
+- Select bounded checks and a stopping condition before verification, and report missing prerequisites and remaining risk.
+- Initialize concise CI smoke guidance for existing GitHub Actions projects without replacing local instructions.
+- Use fresh npm resolution without a tracked lockfile and run CI on manual dispatch; select local checks before pushing.
+- Guide dependency reviews to check applicable project policy and deployment boundaries, and distinguish verified violations from trade-offs and evidence gaps.
+
 ## 0.7.0 — 2026-11-05
 
 - Target context schema `0.7`; validate older schema labels as unsupported without changing their contexts. Evolve existing contexts through agent review before updating metadata.

package/README.md

@@ -12,6 +12,8 @@ This package is developed according to the [ADSM methodology](http://fly.wiredge
 
 ADSM defaults to **Rapid Evolution by Default, Reliability by Requirement**: deliver essential functionality in short feedback cycles, fail visibly, avoid unrequired compatibility, and verify according to contracts and risk. Humans control acceptable risk and can set a different project policy; accepted context, security, integrity, and explicit invariants remain binding. New projects receive a concise policy in their root `AGENTS.md`; existing projects are not rewritten. See the bundled [skill guidance](skills/adsm-ctx/SKILL.md#development-policy) for details.
 
+Cognitive context describes the currently accepted target, including approved requirements that are not yet implemented. Current decisions and relevant rationale belong in context; plans, progress reports, evidence, obsolete states, and historical narrative do not. Git preserves the history of declarations. New projects inherit this boundary in their instructions; existing projects adopt it through authorized evolution. See the [Context Actuality Principle](skills/adsm-ctx/SKILL.md#context-actuality-principle).
+
 The package includes:
 
 - the `adsm-ctx` CLI for lifecycle operations;
@@ -135,7 +137,9 @@ teq --host @flancer32/skill-adsm-ctx adsm-ctx:validate .
 
 ### `init`
 
-Creates the minimal ADSM-compatible context structure, starter documents, and `ctx/adsm.json` metadata. Schema `0.7` creates all five documentation directories, including `ctx/docs/verification/AGENTS.md`, without empty target categories or placeholder specifications.
+Creates the minimal ADSM-compatible context structure, starter documents, and `ctx/adsm.json` metadata. Schema `0.8` creates all five documentation directories, including `ctx/docs/verification/AGENTS.md`, without empty target categories or placeholder specifications.
+
+When `.github/workflows/` already contains a `.yml` or `.yaml` workflow, initialization also creates a missing `.github/AGENTS.md` with concise CI smoke guidance. Existing instructions and workflows are preserved; projects without workflow files do not receive this file.
 
 ### `design`
 
@@ -159,7 +163,7 @@ The default compression corpus is `ctx/docs/`. Operational context such as `ctx/
 
 ### Agent-driven evolution
 
-Use [the skill evolution procedure](skills/adsm-ctx/references/context-evolution.md) for existing contexts, including unknown historical states. The agent follows discover → interpret → compare → plan → evolve → validate → finalize, preserving accepted meaning and semantic skins. Humans decide changes to accepted meaning and authority. CLI `validate` supplies deterministic findings; there is no evolution command or automatic schema promotion. The agent records target schema `0.7` only after structural checks and semantic review succeed, then validates again. The package major and minor match the two-part schema version.
+Use [the skill evolution procedure](skills/adsm-ctx/references/context-evolution.md) for existing contexts, including unknown historical states. The agent follows discover → interpret → compare → plan → evolve → validate → finalize, preserving accepted meaning and semantic skins. Humans decide changes to accepted meaning and authority. CLI `validate` supplies deterministic findings; there is no evolution command or automatic schema promotion. The agent records target schema `0.8` only after structural checks and semantic review succeed, then validates again. The package major and minor match the two-part schema version.
 
 ## Workflow
 
@@ -186,7 +190,7 @@ product
 
 Use the architecture level once product meaning is clear enough to define stable engineering guardrails.
 
-`ctx/docs/verification/` is mandatory and cross-cutting in schema `0.7`. It is not a fifth declarative level. Its root may contain only `AGENTS.md`; create primary-target categories only when durable specifications exist; place that specification below the category of the declaration it primarily evaluates.
+`ctx/docs/verification/` is mandatory and cross-cutting in schema `0.8`. It is not a fifth declarative level. Its root may contain only `AGENTS.md`; create primary-target categories only when durable specifications exist; place that specification below the category of the declaration it primarily evaluates.
 
 The bundled architecture templates expect these top-level documents:
 
@@ -274,16 +278,18 @@ Apache-2.0
 
 ## Versioning And Compatibility
 
-Package `0.7.0` targets context schema `0.7`. Schema versions use major.minor; npm package versions use major.minor.patch with matching major and minor. Package patch `0.7.1` retains schema `0.7`; a new minor establishes a new schema target. Changes in context conventions require a new minor.
+Package `0.8.0` targets context schema `0.8`. Schema versions use major.minor; npm package versions use major.minor.patch with matching major and minor. Package patch `0.8.1` retains schema `0.8`; a new minor establishes a new schema target. Changes in context conventions require a new minor.
 
-`adsm-ctx --version` identifies the installed npm package. Read `ctx/adsm.json` for a project's schema; `adsm-ctx validate <project-root>` reports recorded and supported schema versions. Compatibility follows supported requirements, not numerical equality. Current validation supports schema `0.7`; all other versions are unsupported and require investigation.
+`adsm-ctx --version` identifies the installed npm package. Read `ctx/adsm.json` for a project's schema; `adsm-ctx validate <project-root>` reports recorded and supported schema versions. Compatibility follows supported requirements, not numerical equality. Current validation supports schema `0.8`; all other versions are unsupported and require investigation.
 
 Installing or updating the package and explicitly reinstalling its skill do not promote project metadata. An agent compares actual context with the installed skill's target conventions and evolves directly when needed, preserving project meaning and skins. Humans approve changes to accepted meaning. Only after conformance and semantic review does the agent record the target schema; no intermediate CLI migrations are required.
 
 ## Continuous Integration
 
-GitHub Actions runs `.github/workflows/ci.yaml` for pushes and pull requests to `main`, and on manual dispatch. Ubuntu jobs use Node.js 20 (minimum) and 24 (LTS), run `npm ci`, `npm test`, all three technical suites, `npm run verify`, context validation, and `npm pack --dry-run`.
+GitHub Actions runs `.github/workflows/ci.yaml` on manual dispatch. Ubuntu jobs use Node.js 20 (minimum) and 24 (LTS), run `npm install`, `npm test`, all three technical suites, `npm run verify`, context validation, and `npm pack --dry-run`. Local checks should be selected and run before pushing. The repository does not use an npm lockfile, so clean installations can resolve different dependency versions over time.
+
+An authorized GitHub integration can dispatch `ci.yaml` for a chosen branch or tag through the Actions API. The integration must support workflow dispatch and have the required repository permissions; the workflow must exist on the default branch. Dispatch is optional during ordinary development.
 
 Package tests install a real npm archive into an isolated temporary environment, exercise the installed CLI and skill installer, compare the complete payload, and preserve neighboring skills. In CI the installation test uses network-enabled dependency resolution and fails on errors instead of skipping for missing offline cache. Local offline runs may report a skip; that is incomplete installation evidence. CI does not publish packages or prove semantic correctness of project documentation.
 
-Skill resources are separated by purpose: `references/` provides guidance; `templates/AGENTS.md` and `templates/ctx/` feed deterministic, non-destructive initialization; `assets/` provides agent report and semantic-skin patterns. `init` does not copy skill assets into projects. Asset locations do not prescribe output locations; project authority and the task do. Skill assets are distinct from project-owned `ctx/assets/`.
+Skill resources are separated by purpose: `references/` provides guidance; `templates/AGENTS.md`, `templates/ctx/`, and conditional `templates/github/AGENTS.md` feed deterministic, non-destructive initialization; `assets/` provides agent report and semantic-skin patterns. `init` does not copy skill assets into projects. Asset locations do not prescribe output locations; project authority and the task do. Skill assets are distinct from project-owned `ctx/assets/`.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flancer32/skill-adsm-ctx",
-  "version": "0.7.0",
+  "version": "0.8.0",
   "description": "Build and evolve project cognitive context for Agent-Driven Software Management (ADSM).",
   "license": "Apache-2.0",
   "type": "module",

package/skills/adsm-ctx/SKILL.md

@@ -13,12 +13,18 @@ Humans own direction, accepted meaning, approval, and accountability. Agents ref
 
 ADSM defaults to **Rapid Evolution by Default, Reliability by Requirement**. Plan short hypothesis → implementation → execution → feedback cycles around essential functionality. Prefer simple working solutions; add retries, fallbacks, recovery systems, migrations, compatibility layers, or other defensive machinery only for accepted requirements, demonstrated problems, or meaningful identified risks. Fail fast and visibly on unexpected conditions and contract violations rather than hiding them with speculative retries, repairs, or fallbacks.
 
-Accepted cognitive context defines the target; code and tests converge on it, and historical behavior is not independent architectural authority. Breaking software interfaces is acceptable by default; retain compatibility, migrations, or legacy layers only for accepted requirements, demonstrated problems, or meaningful identified risks. Preserve decisions explaining accepted and rejected directions. Verify the happy path and essential contracts with sufficient fast feedback; add regression coverage and stronger checks for observed defects, meaningful risks, or explicit requirements.
+Accepted cognitive context defines the target; code and tests converge on it, and historical behavior is not independent architectural authority. Breaking software interfaces is acceptable by default; retain compatibility, migrations, or legacy layers only for accepted requirements, demonstrated problems, or meaningful identified risks. Preserve current decisions and their relevant rationale. Verify the happy path and essential contracts with sufficient fast feedback; add regression coverage and stronger checks for observed defects, meaningful risks, or explicit requirements.
 
-Fresh integration of trusted, actively developed first-party dependencies is inherited from this default without separate opt-in to expose cross-package incompatibilities early. Accepted requirements or human instructions can override it, including for secure, reproducible, offline, or production use. Investigate failures and fix the responsible contract or implementation instead of masking them. See [testing and verification](references/testing-and-verification.md#fresh-first-party-integration) for applicability and npm details.
+Before running checks, identify the intended outcome, essential happy path or contract, suitable environment, and sufficient evidence. Choose the smallest useful check and stop when that evidence is obtained. Do not expand verification beyond the task's requested scope without an explicit request; follow binding project requirements and limit diagnosis of a failed check to the failure. Report missing prerequisites, remaining coverage, and material risks. See [testing and verification](references/testing-and-verification.md#selecting-checks) for the selection procedure.
+
+Fresh integration of trusted, actively developed first-party dependencies is inherited from this default without separate opt-in to expose cross-package incompatibilities early. Accepted requirements or human instructions can override it, including for secure, reproducible, offline, or production use. Investigate failures and fix the responsible contract or implementation instead of masking them. See [testing and verification](references/testing-and-verification.md#fresh-first-party-integration) for applicability and npm details, and its [review guidance](references/testing-and-verification.md#reviewing-dependency-policy) before assessing dependency configuration.
 
 Humans decide acceptable risks and reliability guarantees; project-specific accepted context can strengthen or replace this default. Never silently compromise security, integrity, or accepted invariants. This software compatibility default does not authorize rewriting consumer contexts or bypassing context-schema evolution and human approval.
 
+## Context Actuality Principle
+
+Cognitive context declares the currently accepted target, including approved requirements not yet implemented. Code and tests may temporarily diverge but must converge toward it. Keep current decisions and rationale relevant to the design; exclude obsolete states, historical narratives, speculation, plans, and progress reports. Operational evidence and work artifacts are not declarative authority. Git preserves the evolution of declarations. Apply changes to existing projects only through authorized context evolution.
+
 ## Start Here
 
 1. Identify the target repository and the requested lifecycle mode.
@@ -61,14 +67,14 @@ The existing context supplies accepted project meaning; this installed skill sup
 
 ## Completion
 
-Finish with explicit validation results, Verification Layer structure and specification presence when relevant, specialization gaps, human decisions, and any preserved project-specific content. Use `templates/AGENTS.md` and `templates/ctx/` for initialization; use skill `assets/` only for authorized agent-guided document or report work.
+Finish with explicit validation results, Verification Layer structure and specification presence when relevant, specialization gaps, human decisions, and any preserved project-specific content. Use `templates/AGENTS.md`, `templates/ctx/`, and the conditional `templates/github/AGENTS.md` for initialization; use skill `assets/` only for authorized agent-guided document or report work.
 
-The current target is schema `0.7`. The npm package major and minor match this two-part schema version; package patches retain the same schema. Package updates and context evolution remain separate. Inspect project metadata and actual conformance against this installed skill; never infer compatibility or promote metadata from package-version equality. See [context evolution](references/context-evolution.md) for the decision procedure.
+The current target is schema `0.8`. The npm package major and minor match this two-part schema version; package patches retain the same schema. Package updates and context evolution remain separate. Inspect project metadata and actual conformance against this installed skill; never infer compatibility or promote metadata from package-version equality. See [context evolution](references/context-evolution.md) for the decision procedure.
 
 ## Resource Ownership
 
 - `references/` contains methodology, instructions, and agent guidance.
-- `templates/AGENTS.md` and `templates/ctx/` are the deterministic, non-destructive project initialization sources.
+- `templates/AGENTS.md`, `templates/ctx/`, and the conditional `templates/github/AGENTS.md` are the deterministic, non-destructive project initialization sources.
 - `assets/` contains supporting [semantic-skin patterns](assets/context/semantic-skin.md), [audit report patterns](assets/report/documentation-quality-audit.md), and [compression report patterns](assets/report/documentation-compression.md). Initialization never copies them into a project. Use them for authorized work; choose the resulting document's location from project rules and the task, not from the asset path.
 
 Skill `assets/` belongs to this skill payload. Project `ctx/assets/` belongs to the managed project's context and holds visual, generated, or auxiliary artifacts. Ownership and purpose distinguish these boundaries; semantic skins themselves belong beside their agent documents under project documentation.

package/skills/adsm-ctx/assets/report/documentation-quality-audit.md

@@ -29,6 +29,8 @@ State whether the corpus is usable as ADSM cognitive context and identify the hi
 
 ## Findings By Criterion
 
+### Actuality
+
 ### Declarativity
 
 ### Consistency
@@ -69,7 +71,7 @@ For each reviewed agent document, state:
 
 - whether it works as agent-facing operational context;
 - whether it reduces guessing;
-- whether current facts, future plans, requirements, prohibitions, and verification are clear;
+- whether accepted targets, requirements, prohibitions, and verification are clear, including approved but unimplemented requirements;
 - whether file references are accurate;
 - whether a missing skin document is acceptable or suspicious.
 

package/skills/adsm-ctx/references/agents-hierarchy.md

@@ -1,7 +1,7 @@
 # AGENTS Hierarchy
 
 - Path: `skills/adsm-ctx/references/agents-hierarchy.md`
-- Changed: `20261104`
+- Changed: `20261114`
 
 This reference operationalizes `AGENTS.md` handling for ADSM contexts.
 
@@ -34,6 +34,8 @@ Repository-root and context-side files are not identical:
 
 The root template states the skill's Rapid Evolution development default concisely and routes agents to the skill for its meaning. Accepted project context may strengthen or replace that default under human authority; deeper instructions must preserve the root's security, integrity, and accepted-context boundaries. Initialization does not overwrite existing root instructions.
 
+When existing GitHub Actions workflows are present, initialization may create missing `.github/AGENTS.md` from the conditional CI template. It inherits the root instructions and project verification requirements and never replaces existing local instructions.
+
 For skill operation:
 
 - interpret `AGENTS.md` as local control files inside already-declared boundaries;

package/skills/adsm-ctx/references/context-evolution.md

@@ -9,11 +9,13 @@ Apply the skill's Rapid Evolution default to planning and verification: work tow
 
 ## Target And Responsibilities
 
-The current target is context schema `adsm-context` version `0.7`, matching the npm package major and minor. Require five documentation directories: `product/`, `architecture/`, `environment/`, `code/`, and `verification/`, each with `AGENTS.md`. Exactly four form the ordered hierarchy product → architecture → environment → code. The cross-cutting verification root may contain only `AGENTS.md`; create primary-target categories only for actual durable specifications. Keep specifications distinct from observations, evidence records, and operational feedback state. Use [document-projections.md](document-projections.md) for projection, links, assets, and capacity conventions.
+The current target is context schema `adsm-context` version `0.8`, matching the npm package major and minor. Require five documentation directories: `product/`, `architecture/`, `environment/`, `code/`, and `verification/`, each with `AGENTS.md`. Exactly four form the ordered hierarchy product → architecture → environment → code. The cross-cutting verification root may contain only `AGENTS.md`; create primary-target categories only for actual durable specifications. Keep specifications distinct from observations, evidence records, and operational feedback state. Use [document-projections.md](document-projections.md) for projection, links, assets, and capacity conventions.
+
+Schema `0.8` also requires Context Actuality: retain the accepted target, including approved unimplemented requirements, and current decisions with relevant rationale; keep obsolete narrative and operational evidence outside declarative context. Review actual documents without discarding accepted meaning.
 
 The skill defines target conventions and this procedure. The agent interprets the existing context, compares, applies authorized changes, checks consistency, and finalizes metadata. CLI `init` creates missing baseline files, including verification routing and initial metadata, without overwriting existing files. CLI `validate` is read-only: it never creates verification files, replaces documents, changes skins, or promotes metadata. There is no CLI evolution command. Humans control accepted project meaning, authority, and approval of changes beyond the agent's existing authorization.
 
-For schema `0.7`, assess the rapid-evolution development default, inherited fresh first-party integration, requirement-driven reliability, and the distinction between project testing and bounded product verification against the actual project instructions, testing documentation, and accepted decisions. Existing `0.6` contexts require this review as well; preserve explicitly accepted reproducibility and security requirements. The default is replaceable by project policy; do not override a project's accepted policy or copy template text blindly. Reconcile testing guidance with the project's ecosystem and existing requirements, with human decisions for changes to accepted meaning.
+For schema `0.8`, assess the rapid-evolution development default, inherited fresh first-party integration, requirement-driven reliability, and the distinction between project testing and bounded product verification against the actual project instructions, testing documentation, and accepted decisions. Existing `0.6` contexts require this review as well; preserve explicitly accepted reproducibility and security requirements. The default is replaceable by project policy; do not override a project's accepted policy or copy template text blindly. Reconcile testing guidance with the project's ecosystem and existing requirements, with human decisions for changes to accepted meaning.
 
 ## 1. Discover
 
@@ -23,11 +25,11 @@ Read `ctx/adsm.json` and compare it with the target conventions above. Run `adsm
 
 ## 2. Interpret
 
-Locate authoritative product intent, architecture decisions and rationale, environment assumptions, implementation constraints, and all matching semantic skins. Read skins before changing their agent documents. Separate durable declarations and specifications from evidence and operational state. Retain project-specific knowledge, nested organization, and relevant historical decisions. Consult [semantic-skins.md](semantic-skins.md) for controlled projections and [specialized-skills.md](specialized-skills.md) when a branch needs specialized interpretation.
+Locate authoritative product intent, architecture decisions and rationale, environment assumptions, implementation constraints, and all matching semantic skins. Read skins before changing their agent documents. Separate durable declarations and specifications from evidence and operational state. Retain accepted project-specific knowledge, nested organization, current decisions, and rationale still relevant to the design. Consult [semantic-skins.md](semantic-skins.md) for controlled projections and [specialized-skills.md](specialized-skills.md) when a branch needs specialized interpretation.
 
 ## 3. Compare
 
-Compare actual structure and meaning with current target conventions, even when the recorded version is unknown or already `0.7`. Inventory structural, documentary, projection, and authority differences. Run `adsm-ctx validate <project-root>` and distinguish mechanical findings from semantic inconsistencies. A current version is not proof of conformance; green structure does not establish semantic correctness, verification coverage, or runtime correctness.
+Compare actual structure and meaning with current target conventions, even when the recorded version is unknown or already `0.8`. Inventory structural, documentary, projection, and authority differences. Run `adsm-ctx validate <project-root>` and distinguish mechanical findings from semantic inconsistencies. A current version is not proof of conformance; green structure does not establish semantic correctness, verification coverage, or runtime correctness.
 
 For example, `0.1.0` and `0.2.0` may lack `verification/AGENTS.md` or describe verification as optional. Inspect their actual documents instead of applying a fixed replacement. Unknown historical layouts require investigation and explicit reporting of what cannot yet be interpreted safely.
 
@@ -37,9 +39,9 @@ Classify proposed changes as structural, editorial, semantic, or requiring human
 
 ## 5. Evolve
 
-Apply authorized changes in documentation dependency order. Add missing required boundaries from canonical templates only after inspecting the destination; adapt routing to the actual project instead of replacing custom instructions. For `0.7`, add missing `verification/AGENTS.md`, update the documentation Level Map, and reconcile optional-adoption wording with accepted declarations and skins. Preserve existing specifications and project directories; create no placeholder specifications or empty target categories.
+Apply authorized changes in documentation dependency order. Add missing required boundaries from canonical templates only after inspecting the destination; adapt routing to the actual project instead of replacing custom instructions. For `0.8`, add missing `verification/AGENTS.md`, update the documentation Level Map, and reconcile optional-adoption wording with accepted declarations and skins. Preserve existing specifications and project directories; create no placeholder specifications or empty target categories.
 
-Restructure or clarify only within authorization. Preserve intent, constraints, rationale, history, and projection meaning. Update linked consumers when moving a document and preserve one canonical authority home. Use deterministic helpers only for bounded, agent-selected operations; they do not decide semantic changes. Reinspect on partial failure, report completed work and unresolved differences, and preserve the previous schema label while work remains incomplete.
+Restructure or clarify only within authorization. Preserve accepted intent, constraints, current decision rationale, and projection meaning. Remove obsolete declarations and historical narrative; move operational evidence and work artifacts out of declarative context as authorized. Git preserves evolution history. Do not discard an approved target merely because implementation is incomplete. Update linked consumers when moving a document and preserve one canonical authority home. Use deterministic helpers only for bounded, agent-selected operations; they do not decide semantic changes. Reinspect on partial failure, report completed work and unresolved differences, and preserve the previous schema label while work remains incomplete.
 
 ## 6. Validate
 
@@ -47,13 +49,13 @@ Run deterministic validation and inspect every error and warning. Assess semanti
 
 ## 7. Finalize
 
-Only after target structural requirements and semantic consistency are satisfied, update `ctx/adsm.json` to version `0.7`, preserving meaningful metadata fields. A version edit records successful evolution; it does not perform it. Do not promote partially evolved contexts. Run validation again against the final metadata; investigate any failure and retain or restore the prior label if conformance is not established. Do not overwrite an unknown future schema based on this package's older target conventions.
+Only after target structural requirements and semantic consistency are satisfied, update `ctx/adsm.json` to version `0.8`, preserving meaningful metadata fields. A version edit records successful evolution; it does not perform it. Do not promote partially evolved contexts. Run validation again against the final metadata; investigate any failure and retain or restore the prior label if conformance is not established. Do not overwrite an unknown future schema based on this package's older target conventions.
 
 Report changes and rationale, preserved content, deterministic results, semantic review scope and limits, remaining warnings, human decisions, and relevant Git histories. On a repeat request, compare the actual state again and make only necessary authorized changes. Repeated CLI validation remain read-only regardless of context state.
 
 
 ## Package Updates And Schema Compatibility
 
-A package update replaces the npm implementation; explicitly rerun `adsm-ctx install-skill <skills-root>` to replace its bundled agent guidance. This does not change any context schema metadata and does not imply context evolution is required. Schema versions describe accepted context conventions; package versions describe implementation releases. Package `0.7.1` targets schema `0.7` unchanged. Never infer compatibility from numerical equality.
+A package update replaces the npm implementation; explicitly rerun `adsm-ctx install-skill <skills-root>` to replace its bundled agent guidance. This does not change any context schema metadata and does not imply context evolution is required. Schema versions describe accepted context conventions; package versions describe implementation releases. Package `0.8.1` targets schema `0.8` unchanged. Never infer compatibility from numerical equality.
 
 Read the current schema from the project's `ctx/adsm.json`; identify this installed skill's target from Target Conventions above, not the npm version shown by `adsm-ctx --version`. Compare actual context with those conventions and use `validate` to check recorded and supported schema labels plus structural findings. If already conforming to the same schema, no evolution is needed merely because the package changed. Classify structural repairs separately from semantic changes; use the seven phases above for needed evolution and obtain human approval for changes to accepted meaning or authority. Unsupported labels require investigation; no version-specific migration is provided. Never relabel an older context based solely on package installation.

package/skills/adsm-ctx/references/context-lifecycle.md

@@ -1,7 +1,7 @@
 # Context Lifecycle
 
 - Path: `skills/adsm-ctx/references/context-lifecycle.md`
-- Changed: `20261104`
+- Changed: `20261114`
 
 `adsm-ctx` manages six lifecycle modes for project cognitive context.
 
@@ -9,9 +9,11 @@ Humans set direction, approve meaning, evaluate results, and retain accountabili
 
 The skill manages generic lifecycle structure. It does not define a project's business requirements, architecture, browser behavior, backend contracts, data model, deployment topology, or tool-specific workflow semantics.
 
+Apply the [Context Actuality Principle](../SKILL.md#context-actuality-principle) throughout maintenance: retain accepted target meaning and relevant rationale, not stale narrative or operational evidence. Existing projects evolve only with appropriate authorization.
+
 ## Modes
 
-- `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.
+- `init` creates the baseline. Create the root `AGENTS.md`, `ctx/` baseline, starter documents, and `ctx/adsm.json` only where they are missing. If `.github/workflows/` already contains a workflow YAML file, create missing `.github/AGENTS.md` from `templates/github/AGENTS.md`; preserve existing instructions and workflows. 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 formal structural integrity without destructive edits. Check baseline paths, context metadata, the four declarative documentation levels, mandatory Verification Layer structure, 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.

package/skills/adsm-ctx/references/document-projections.md

@@ -47,7 +47,7 @@ They are not required to have matching skins.
 An agent document should reduce ambiguity and statistical guessing by making explicit, when relevant:
 
 - the described object;
-- current truth;
+- the currently accepted target, including approved requirements not yet implemented;
 - scope and boundaries;
 - terms;
 - requirements;
@@ -124,7 +124,7 @@ Their meanings remain:
 
 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.7`, 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.
+Require the block in schema `0.8`, 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.
 

package/skills/adsm-ctx/references/documentation-compression.md

@@ -1,7 +1,7 @@
 # Documentation Compression
 
 - Path: `skills/adsm-ctx/references/documentation-compression.md`
-- Changed: `20261024`
+- Changed: `20261105`
 
 Use this reference when an agent must compress an existing ADSM cognitive documentation corpus while preserving accepted project meaning.
 
@@ -22,7 +22,7 @@ Follow this method:
 5. Treat ordinary `*.md` files as agent-facing operational context documents and `*.skin.<lang>.md` files as human-facing semantic skins.
 6. Identify authoritative agent documents, refinement documents, navigation documents, agent/skin pairs, orphan skins, projection drift, and duplicated responsibility areas.
 7. Preserve product intent, domain meaning, architecture boundaries, decisions, constraints, roles, state ownership, environment assumptions, code rules, and skin-controlled meaning.
-8. Remove or reduce only redundant wording, obvious descriptions, repeated definitions, process narration, low-density text, and skill-methodology noise that does not define project meaning.
+8. Remove or reduce redundant wording, obsolete states and historical narrative, obvious descriptions, repeated definitions, process narration, low-density text, and skill-methodology noise that does not define accepted meaning. Keep approved targets even when not implemented.
 9. Move duplicated durable meaning to its authoritative home instead of keeping parallel definitions.
 10. Avoid replacing precise rules with vague summaries.
 11. Avoid inventing, weakening, generalizing, or silently deleting project-specific knowledge.
@@ -93,7 +93,7 @@ Unsafe semantic change includes:
 - inventing missing product facts, requirements, domain entities, architecture boundaries, roles, integrations, state ownership, environment assumptions, or code rules;
 - weakening mandatory language into optional or vague language;
 - generalizing project-specific rules into generic advice;
-- deleting exclusions, constraints, rejected alternatives, or decision rationale because they appear verbose;
+- deleting accepted exclusions, constraints, active rejected-alternative constraints, or currently relevant decision rationale because they appear verbose;
 - choosing between contradictory documents without evidence;
 - hiding uncertainty by writing a confident summary;
 - moving meaning to a document whose level is not authoritative for that meaning;

package/skills/adsm-ctx/references/documentation-quality-audit.md

@@ -1,7 +1,7 @@
 # Documentation Quality Audit
 
 - Path: `skills/adsm-ctx/references/documentation-quality-audit.md`
-- Changed: `20261024`
+- Changed: `20261105`
 
 Use this reference when an agent must audit an existing documentation corpus as an ADSM cognitive context.
 
@@ -20,7 +20,7 @@ Follow this method:
 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.
+6. Evaluate the corpus against the nine ADSM documentation quality criteria and the projection-specific checks below after deterministic validation is clean or warning-only.
 7. Check whether project-facing documents govern the project rather than explaining ADSM methodology to themselves.
 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.
@@ -93,7 +93,7 @@ Review each ordinary `*.md` file as an operational context document for LLM agen
 Check whether the document makes explicit, when relevant:
 
 - the described object;
-- current truth;
+- the currently accepted target;
 - scope and boundaries;
 - terms;
 - requirements;
@@ -107,10 +107,14 @@ The review should answer:
 
 - does the document work as agent-facing operational context;
 - does it reduce guessing;
-- are current facts, future plans, requirements, prohibitions, and verification clear;
+- are accepted requirements, prohibitions, and verification clear, including approved targets not yet implemented;
 - are file references accurate;
 - whether a missing skin document is acceptable or suspicious.
 
+### Actuality
+
+Apply the [Context Actuality Principle](../SKILL.md#context-actuality-principle). Flag obsolete states, historical narration, unapproved future plans, status reports, TODOs, and backlogs in declarative context. Distinguish approved but unimplemented requirements from speculation; retain current decisions and relevant rationale. Check that operational artifacts, including those under `ctx/agent/`, are not presented as authoritative through placement or navigation.
+
 ### Declarativity
 
 Documentation should state stable facts, rules, boundaries, decisions, and invariants.

package/skills/adsm-ctx/references/semantic-skins.md

@@ -45,7 +45,7 @@ Use the cognitive form of the documented object rather than a universal heading
 
 - overview or identity — purpose, mental model, boundaries, invariants;
 - domain model — concepts, levels, key relations, constraints;
-- decision — decision, rationale, consequences, rejected alternatives;
+- decision — current decision, relevant rationale and consequences, and active constraints;
 - process — goal, flow, inputs and outcomes, exceptions;
 - reference or map — navigational structure, terms, governing rules.
 

package/skills/adsm-ctx/references/testing-and-verification.md

@@ -1,13 +1,21 @@
 # Project Testing And Product Verification
 
 - Path: `skills/adsm-ctx/references/testing-and-verification.md`
-- Changed: `20261105`
+- Changed: `20261114`
 
 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.
+## Selecting Checks
+
+Before running checks, state the intended outcome and the essential happy path or contract, then select the smallest useful observation, its suitable environment, and the evidence sufficient to stop. Verify each package under work with its own applicable tests, selected for the changed responsibility and risk. Verify dependencies only as needed for the affected contract unless more is requested or otherwise required. For a user flow across packages, prefer one bounded integrated happy path when it establishes that contract; package boundaries alone do not justify full suites for each dependency.
+
+Do not expand verification beyond the task's requested scope without an explicit request. Follow binding project requirements and, when a focused check fails, limit diagnosis and rechecking to that failure. The availability of tools, test suites, or dependencies, a general desire for thoroughness, or a speculative risk does not justify extra checks. Include focused negative tests where required for a changed security or failure boundary. If prerequisites are absent, stop that check and report the limit; do not construct an unrequested verification environment to compensate. Once sufficient evidence is obtained, stop and report remaining coverage and material risks.
+
+By default, CI is a fast smoke boundary using conditions it actually provides; keep deeper environment-dependent verification in a suitable local or advanced environment. Do not recreate that environment in CI or expand it into full verification without an explicit request or binding requirement. Accepted project context and human instructions determine required guarantees and may override this default.
+
+The same test mechanism can contribute to project testing or product verification when its target and evidence are explicit; test level alone does not decide the distinction. 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 explicitly bounded product verification, not an indiscriminate aggregate of technical suites, 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.
 
@@ -18,3 +26,11 @@ Projects inherit this convention from the Rapid Evolution default without separa
 For applicable npm projects, a dependency such as `"@teqfw/dem-idb": "github:teqfw/dem-idb"` has no ref selector and resolves the repository's default branch on fresh resolution. Avoid maintaining a committed `package-lock.json` by default: set `package-lock=false` in the project `.npmrc` so npm neither consumes nor writes that lockfile, ignore `package-lock.json`, and stop tracking an existing one only as part of an authorized transition. Check for other lock mechanisms, such as `npm-shrinkwrap.json`, and explicit requirements before assuming resolution is fresh.
 
 Use clean CI installations with `npm install` for this integration mode; `npm ci` requires a lockfile and installs its frozen graph. An ordinary `npm install` over existing `node_modules` does not guarantee a newer Git revision: explicitly refresh the dependency or use a clean installation when freshness matters. Do not require npm publication for every first-party iteration. Investigate incompatibilities and fix the responsible contract or implementation instead of silently pinning an older revision, masking failures, or adding speculative compatibility layers.
+
+## Reviewing Dependency Policy
+
+Before judging dependency versions, lockfiles, installation, or build reproducibility, find the applicable project instructions and accepted context, including any referenced canonical policy. Identify which package and phase they govern: development integration, CI, release, and deployment can have different requirements. Apply the generic default only where it is applicable and not overridden; a common ecosystem convention is not itself a project requirement.
+
+Compare the policy with evidence from the relevant manifest, lock and ignore configuration, install and build commands, CI, and deployment process as available. An ignored or untracked lockfile, floating version, or Git dependency without a fixed revision is not by itself a violation: a build may generate or retain a lockfile at a different boundary. Equally, a changing resolved graph is a reproducibility trade-off and may conflict with a requirement at another boundary. Do not infer deployed inputs or a reproducible build from a manifest alone.
+
+Report a violation only with the applicable requirement, observed configuration or behavior, and the connection between them. Describe trade-offs and their scope separately, and identify missing evidence or unresolved policy instead of presenting assumptions as findings. Preserve project authority and raise any proposed change to accepted meaning for human approval.

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

@@ -1,13 +1,15 @@
 # Root Level
 
 - Path: `AGENTS.md`
-- Template Version: `20261105`
+- Template Version: `20261114`
 - 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.
 
+Accepted context declares the current target, including approved requirements not yet implemented; code and tests converge toward it. Obsolete narratives, speculation, plans, and reports are not authoritative declarations.
+
 `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.
@@ -18,10 +20,14 @@ Default to Rapid Evolution by Default, Reliability by Requirement: deliver the e
 
 This default includes fresh integration of trusted, actively developed first-party dependencies without separate opt-in. Accepted requirements or human instructions may override it; preserve required security, integrity, offline operation, and reproducibility, particularly for releases and deployments. Follow the skill's dependency guidance.
 
+When reviewing dependency versions, lockfiles, installation, or reproducibility, assess the applicable project policy and deployment boundaries before reporting a violation. Distinguish demonstrated violations from trade-offs and missing evidence; consult the skill's dependency review guidance.
+
 ## 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.
 
+Before checks, identify the intended outcome, essential happy path or contract, suitable environment, and sufficient evidence. Verify each package under work with its applicable tests; verify dependencies only as needed for the affected contract unless more is requested or required. Choose the smallest useful check; stop when it supplies sufficient evidence. Do not expand verification beyond the task's requested scope without an explicit request; follow binding project requirements and limit diagnosis of a failed check to the failure. If prerequisites are absent, report the limit rather than constructing an unrequested verification environment. Follow the skill's testing and verification guidance.
+
 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.
 
 ## Git Delivery

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

@@ -8,7 +8,9 @@
 
 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.
+`docs/` holds the currently accepted target: product, architecture, environment, and code declarations, plus durable verification specifications. Approved requirements belong there even before implementation; obsolete states, historical narratives, speculative plans, progress reports, and evidence do not. Git preserves the evolution of declarations.
+
+`agent/` holds project-local operations and `assets/` holds supporting materials. Neither placement nor navigation grants their plans, reports, audits, handoffs, or other artifacts authority over `docs/`.
 
 Keep generic ADSM methodology outside the project context.
 

package/skills/adsm-ctx/templates/ctx/adsm.json

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

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

@@ -16,7 +16,7 @@ Documents at this level translate product intent into stable engineering structu
 - `behavior.md` — internal architectural flows and major system behavior, not product use cases.
 - `checklists.md` — recurring supervision, diagnosis, and acceptance checklists.
 - `constraints.md` — non-negotiable architecture restrictions and trust boundaries.
-- `decisions.md` — short ADR-like records of durable decisions, rejected alternatives, and reasoning.
+- `decisions.md` — current decisions, constraints, and relevant rationale.
 - `integration.md` — external integrations and major internal contracts between architectural blocks.
 - `overview.md` — compact architectural overview and navigation index.
 - `state.md` — state ownership, sources of truth, derived state, and state-changing authority.

package/skills/adsm-ctx/templates/ctx/docs/architecture/decisions.md

@@ -6,19 +6,17 @@
 
 ## Purpose
 
-Record durable architecture decisions in a short ADR-like form.
+Record current architecture decisions and constraints with the rationale still relevant to the design.
 
 ## Decision Format
 
 Use short entries that contain:
 
 - the decision;
-- rejected alternatives;
-- reasoning.
+- relevant reasoning;
+- a rejected alternative only when it remains an active design constraint.
 
-Keep only durable architecture decisions here.
-
-Do not use this document as a changelog or backlog.
+Do not retain superseded decisions or chronological ADR diaries, changelogs, and backlogs. Git preserves decision history.
 
 ## Decision Entries
 

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

@@ -0,0 +1,11 @@
+# GitHub Actions
+
+- Path: `.github/AGENTS.md`
+- Template Version: `20261114`
+- Changed: `YYYYMMDD`
+
+Inherit the root `AGENTS.md` and applicable project context, including verification requirements. Accepted project requirements and human instructions can strengthen or replace the default below.
+
+By default, CI is a fast smoke boundary: use conditions actually available in CI to check that the essential project or package can be installed or built and that its key entry point starts or responds. Choose the smallest check that establishes the task's essential contract; expand coverage only when explicitly requested or required by accepted project requirements.
+
+Keep deeper environment-dependent integration and product Happy Path verification in the appropriate local or advanced environment. Do not run every package's full suite by default or recreate the advanced environment in CI merely to run those checks. CI success is bounded evidence and does not establish full product conformity.

package/src/Init/Service.mjs

@@ -7,6 +7,7 @@
 
 const templateRoot = new URL("../../skills/adsm-ctx/templates/ctx/", import.meta.url);
 const rootAgentsTemplate = new URL("../../skills/adsm-ctx/templates/AGENTS.md", import.meta.url);
+const githubAgentsTemplate = new URL("../../skills/adsm-ctx/templates/github/AGENTS.md", import.meta.url);
 
 export default class Service {
   /**
@@ -41,6 +42,7 @@ export default class Service {
       });
       stampCreatedMarkdownDates({created, fs, pathService, projectRoot});
       ensureRootAgents({created, fs, pathService, projectRoot, skipped});
+      ensureGithubAgents({created, fs, pathService, projectRoot, skipped});
       writeMetadata({created, fs, metadata, pathService, projectRoot, skipped});
 
       return {created, ctxRoot, projectRoot, skipped};
@@ -48,6 +50,24 @@ export default class Service {
   }
 }
 
+/**
+ * @param {{created: Array<string>, fs: typeof import("node:fs"), pathService: Fl32_Skill_Adsm_Ctx_Shared_Path, projectRoot: string, skipped: Array<string>}} deps
+ * @returns {void}
+ */
+function ensureGithubAgents({created, fs, pathService, projectRoot, skipped}) {
+  const workflows = pathService.join(projectRoot, ".github", "workflows");
+  if (!fs.existsSync(workflows) || !fs.statSync(workflows).isDirectory()) return;
+  if (!fs.readdirSync(workflows, {withFileTypes: true}).some((entry) => entry.isFile() && /\.ya?ml$/i.test(entry.name))) return;
+  const destination = pathService.join(projectRoot, ".github", "AGENTS.md");
+  if (fs.existsSync(destination)) {
+    skipped.push(".github/AGENTS.md");
+    return;
+  }
+  const date = new Date().toISOString().slice(0, 10).replaceAll("-", "");
+  fs.writeFileSync(destination, fs.readFileSync(githubAgentsTemplate, "utf8").replaceAll("YYYYMMDD", date), {flag: "wx"});
+  created.push(".github/AGENTS.md");
+}
+
 /**
  * @param {object} deps
  * @param {Array<string>} deps.created

package/src/Shared/Constants.mjs

@@ -9,7 +9,7 @@ export default class Constants {
   /** Initializes the supported context constants. */
   constructor() {
     this.CONTEXT_SCHEMA = "adsm-context";
-    this.CONTEXT_VERSION = "0.7";
+    this.CONTEXT_VERSION = "0.8";
     this.VERIFICATION_CAPABILITY = "verification-layer";
     this.CONTEXT_CAPABILITIES = Object.freeze([this.VERIFICATION_CAPABILITY]);
     this.VERIFICATION_BLOCK = "verification";