@flancer32/skill-adsm-ctx 0.6.0 → 0.7.0

package/CHANGELOG.md

@@ -2,6 +2,14 @@
 
 All notable changes to this package are documented in this file.
 
+## 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.
+- Make fresh integration of trusted first-party dependencies part of the Rapid Evolution default, subject to accepted security, reproducibility, offline, and deployment requirements.
+- Clarify that failure handling and compatibility require an accepted requirement, demonstrated problem, or meaningful identified risk; align root and architecture templates.
+- Separate bounded product verification from technical test suites and align verification specifications and CI.
+- Clarify Git delivery authorization in generated root instructions and maintain substantive template version dates.
+
 ## 0.6.0 — 2026-11-04
 
 - Use two-part context schema versions aligned to the npm package major and minor; target schema `0.6`, retaining it for package patches.

package/README.md

@@ -60,7 +60,7 @@ This package does not:
 Install the package and then explicitly install its matching agent payload:
 
 ```sh
-npm install --global git+ssh://git@github.com:flancer32/skill-adsm-ctx.git
+npm install --global @flancer32/skill-adsm-ctx
 adsm-ctx install-skill "$HOME/.agents/skills"
 ```
 
@@ -78,11 +78,11 @@ test -f "$HOME/.agents/skills/adsm-ctx/SKILL.md"
 To update, update the global npm package and reinstall its payload:
 
 ```sh
-npm install --global git+ssh://git@github.com:flancer32/skill-adsm-ctx.git
+npm install --global @flancer32/skill-adsm-ctx
 adsm-ctx install-skill "$HOME/.agents/skills"
 ```
 
-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 `skills/adsm-ctx/` bundle. Do not copy only `SKILL.md` manually: the payload also needs its references and templates.
+The public npm registry package is the canonical distribution of both artifacts and does not require GitHub SSH access. Its public `adsm-ctx` launcher runs the package as an explicit TeqFW host; the `install-skill` command copies the version-matched `skills/adsm-ctx/` bundle. Do not copy only `SKILL.md` manually: the payload also needs its references and templates.
 
 For a project-pinned CI or team workflow, install the package locally and invoke the same public launcher with npm:
 
@@ -135,7 +135,7 @@ 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.6` 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.7` creates all five documentation directories, including `ctx/docs/verification/AGENTS.md`, without empty target categories or placeholder specifications.
 
 ### `design`
 
@@ -159,7 +159,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.6` 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.7` 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 +186,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.6`. 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.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.
 
 The bundled architecture templates expect these top-level documents:
 
@@ -249,7 +249,7 @@ Run the fast local project smoke check (context structure and skill/package conv
 npm test
 ```
 
-Run product verification and the remaining suites, or select a focused suite:
+Run bounded product verification and the technical suites separately:
 
 ```sh
 npm run verify
@@ -258,7 +258,7 @@ npm run test:integration
 npm run test:package
 ```
 
-The smoke check does not establish product conformity or semantic context correctness. The verification specifications under `ctx/docs/verification/` identify the observed contracts and their limits. The package installation scenario uses a temporary installation and may skip locally when its offline dependency cache is unavailable; a skip is not evidence of successful installation.
+Project testing checks technical health and engineering correctness; product verification evaluates observable behavior or properties against accepted declarations using applicable specifications. Test level and mechanism do not determine this distinction. The smoke check does not establish product conformity or semantic context correctness. The verification specifications under `ctx/docs/verification/` identify the observed contracts and their limits. The package installation scenario uses a temporary installation and may skip locally when its offline dependency cache is unavailable; a skip is not evidence of successful installation.
 
 ## Changelog
 
@@ -274,15 +274,15 @@ Apache-2.0
 
 ## Versioning And Compatibility
 
-Package `0.6.0` targets context schema `0.6`. Schema versions use major.minor; npm package versions use major.minor.patch with matching major and minor. Package patch `0.6.1` retains schema `0.6`; a new minor establishes a new schema target. Changes in context conventions require a new minor.
+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.
 
-`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.6`; 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.7`; 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`, `npm run verify`, context validation, and `npm pack --dry-run`.
+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`.
 
 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.
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flancer32/skill-adsm-ctx",
-  "version": "0.6.0",
+  "version": "0.7.0",
   "description": "Build and evolve project cognitive context for Agent-Driven Software Management (ADSM).",
   "license": "Apache-2.0",
   "type": "module",
@@ -30,7 +30,7 @@
     "test:integration": "find test/integration -name '*.test.mjs' -print0 | xargs -0 -r node --test",
     "test:package": "node --test test/package/*.test.mjs",
     "test": "node bin/adsm-ctx.mjs validate . && node --test test/package/skill.test.mjs",
-    "verify": "npm run test:unit && npm run test:integration && npm run test:package"
+    "verify": "node --test test/integration/schema-050.test.mjs test/integration/cli-init-validate.test.mjs test/integration/cli-install-skill.test.mjs test/package/installation.test.mjs test/package/skill.test.mjs"
   },
   "dependencies": {
     "@teqfw/cli": "^2.2.0",

package/skills/adsm-ctx/SKILL.md

@@ -11,9 +11,11 @@ Humans own direction, accepted meaning, approval, and accountability. Agents ref
 
 ## Development Policy
 
-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 abstractions or defensive machinery for concrete requirements or observed problems. Fail fast and visibly on unexpected conditions and contract violations rather than hiding them with speculative retries, repairs, or fallbacks.
+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 when required. 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 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.
+
+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.
 
 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.
 
@@ -61,7 +63,7 @@ The existing context supplies accepted project meaning; this installed skill sup
 
 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.
 
-The current target is schema `0.6`. 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.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.
 
 ## Resource Ownership
 

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

@@ -1,7 +1,7 @@
 # Agent-Driven Context Evolution
 
 - Path: `skills/adsm-ctx/references/context-evolution.md`
-- Changed: `20261104`
+- Changed: `20261105`
 
 Evolution brings an existing cognitive context into conformance with the installed skill's target conventions through agent inspection and reasoning. The starting point is the actual context, not an assumed version-to-version file transformation. Use this procedure for methodology, organization, authority relationships, projection rules, and schema changes, including contexts predating known schema versions. Evolution is a skill-guided agent activity and has no CLI command.
 
@@ -9,11 +9,11 @@ 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.6`, 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.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 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.6`, assess the rapid-evolution development default and the distinction between project testing and product verification against the actual project instructions, testing documentation, and accepted decisions. 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.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.
 
 ## 1. Discover
 
@@ -27,7 +27,7 @@ Locate authoritative product intent, architecture decisions and rationale, envir
 
 ## 3. Compare
 
-Compare actual structure and meaning with current target conventions, even when the recorded version is unknown or already `0.6`. 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.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.
 
 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,7 +37,7 @@ 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.6`, 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.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.
 
 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.
 
@@ -47,13 +47,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.6`, 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.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.
 
 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.6.1` targets schema `0.6` 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.7.1` targets schema `0.7` 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: `20261024`
+- Changed: `20261104`
 
 `adsm-ctx` manages six lifecycle modes for project cognitive context.
 
@@ -27,7 +27,7 @@ The lifecycle is iterative. A project may return to `design`, `validate`, `quali
 The package-level `adsm-ctx install-skill <skills-root>` command installs the version-matched skill payload into an explicitly supplied agent skills root. After installation or update, run:
 
 ```sh
-npm install --global git+ssh://git@github.com/flancer32/skill-adsm-ctx.git
+npm install --global @flancer32/skill-adsm-ctx
 adsm-ctx install-skill "$HOME/.agents/skills"
 ```
 

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

@@ -1,7 +1,7 @@
 # Documentation Projections
 
 - Path: `skills/adsm-ctx/references/document-projections.md`
-- Changed: `20261024`
+- Changed: `20261105`
 
 Use this reference whenever an agent initializes, designs, validates, audits, compresses, or evolves ADSM documentation under `ctx/docs/`.
 
@@ -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.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.
+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.
 
 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/testing-and-verification.md

@@ -1,7 +1,7 @@
 # Project Testing And Product Verification
 
 - Path: `skills/adsm-ctx/references/testing-and-verification.md`
-- Changed: `20261104`
+- Changed: `20261105`
 
 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.
 
@@ -9,4 +9,12 @@ Product verification assesses a declared product property or behavior through bo
 
 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.
+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.
+
+## Fresh First-Party Integration
+
+Projects inherit this convention from the Rapid Evolution default without separate opt-in: prefer freshly resolved integration of trusted, actively developed first-party libraries to shorten feedback across repositories. Accepted project context and human instructions override this default, including reproducibility, offline, security, integrity, operational, and deployment requirements. It does not prescribe floating third-party dependencies or production and regulated deployments. Releases and deployments may require independently locked, reproducible inputs. Do not rewrite existing consumer repositories without authorization.
+
+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.

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

@@ -1,7 +1,7 @@
 # Root Level
 
 - Path: `AGENTS.md`
-- Template Version: `20261024`
+- Template Version: `20261105`
 - Changed: `YYYYMMDD`
 
 ## Boundary
@@ -14,10 +14,18 @@ A task may cover multiple repositories. Coordinate affected contracts and consum
 
 ## 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.
+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 justified by accepted requirements, demonstrated problems, or meaningful identified risks. 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.
+
+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.
 
 ## 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.
+
+## Git Delivery
+
+An explicit task instruction to commit and push authorizes delivery of the verified commit to the named repository and branch, or to its configured upstream when the branch is unspecified. Inspect the worktree, branch, and remote before pushing. If sandbox networking blocks Git, use the normal approved escalation path; do not ask for duplicate authorization.
+
+An automated approval rejection is a platform restriction, not evidence that user authorization is missing. Report the specific restriction and request only the approval the gate requires. Keep delivery pending while that approval is required. These instructions do not override platform security or approval controls or applicable repository rules.

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

@@ -1,7 +1,7 @@
 # Cognitive Context
 
 - Path: `ctx/README.md`
-- Template Version: `20260623`
+- Template Version: `20261024`
 - Changed: `YYYYMMDD`
 
 ## Purpose

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

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

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

@@ -1,7 +1,7 @@
 # Architecture Documentation
 
 - Path: `ctx/docs/architecture/AGENTS.md`
-- Template Version: `20260702`
+- Template Version: `20260708`
 - Changed: `YYYYMMDD`
 
 ## Purpose

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

@@ -1,7 +1,7 @@
 # Architecture Behavior
 
 - Path: `ctx/docs/architecture/behavior.md`
-- Template Version: `20260605`
+- Template Version: `20261105`
 - Changed: `YYYYMMDD`
 
 ## Purpose
@@ -14,7 +14,7 @@ This document explains how the system works internally, not which product outcom
 
 Describe the main architectural flows that matter for the system.
 
-Examples may include request handling, synchronization, ingestion, supervision, background processing, or recovery.
+Examples may include request handling, synchronization, ingestion, supervision, or background processing when relevant.
 
 Do not rewrite product use cases here.
 
@@ -27,9 +27,9 @@ For each major flow, clarify:
 - where important decisions are made;
 - where the flow ends or commits durable change.
 
-## Failure And Recovery
+## Failure Behavior
 
-Describe important failure handling, retry, fallback, or degradation behavior at the architectural level.
+Describe visible failure behavior and any handling required by accepted requirements, demonstrated problems, or meaningful identified risks. Do not introduce retries, fallback, recovery, or degradation speculatively. Preserve security, integrity, and accepted invariants.
 
 ## Product Dependency
 

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

@@ -1,7 +1,7 @@
 # Code Documentation
 
 - Path: `ctx/docs/code/AGENTS.md`
-- Template Version: `20260702`
+- Template Version: `20260708`
 - Changed: `YYYYMMDD`
 
 ## Purpose

package/skills/adsm-ctx/templates/ctx/docs/code/testing.md

@@ -1,7 +1,7 @@
 # Testing Overview
 
 - Path: `ctx/docs/code/testing.md`
-- Template Version: `20260605`
+- Template Version: `20261104`
 - Changed: `YYYYMMDD`
 
 ## Purpose

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

@@ -1,7 +1,7 @@
 # Environment Documentation
 
 - Path: `ctx/docs/environment/AGENTS.md`
-- Template Version: `20260702`
+- Template Version: `20260708`
 - Changed: `YYYYMMDD`
 
 ## Purpose

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

@@ -1,7 +1,7 @@
 # Filesystem Structure
 
 - Path: `ctx/docs/filesystem.md`
-- Template Version: `20260605`
+- Template Version: `20260707`
 - Changed: `YYYYMMDD`
 
 ## Purpose

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

@@ -1,7 +1,7 @@
 # Product Documentation
 
 - Path: `ctx/docs/product/AGENTS.md`
-- Template Version: `20260702`
+- Template Version: `20260708`
 - Changed: `YYYYMMDD`
 
 ## Purpose

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.6";
+    this.CONTEXT_VERSION = "0.7";
     this.VERIFICATION_CAPABILITY = "verification-layer";
     this.CONTEXT_CAPABILITIES = Object.freeze([this.VERIFICATION_CAPABILITY]);
     this.VERIFICATION_BLOCK = "verification";