@flancer32/skill-adsm-ctx 0.2.1 → 0.3.0

package/ctx/docs/ai-intro.md

@@ -1,37 +0,0 @@
-# AI Introduction
-
-- Path: `ctx/docs/ai-intro.md`
-- Changed: `20260702`
-
-## Purpose
-
-Introduces this repository to an AI agent as a skill product whose responsibility is managing ADSM project cognitive context lifecycle.
-
-## Repository Identity
-
-This repository provides a generic orchestration skill for ADSM context lifecycle work.
-
-It helps initialize, design, validate, audit, compress, and upgrade project cognitive context.
-
-## Project Boundary
-
-This repository does not define the business or architecture of an external product.
-
-Its product is the skill package itself:
-
-- CLI tooling in `bin/` and `src/`
-- skill payload in `skill/`
-- reusable context templates in `skill/templates/ctx/`
-- working skill templates in `skill/templates/work/`
-- repository cognitive context in `ctx/`
-
-Documentation quality audit and documentation compression are agent-guided skill capabilities, not CLI commands.
-
-Do not treat `ctx/agent/` as part of the ADSM methodology baseline beyond its boundary file `skill/templates/ctx/agent/AGENTS.md`.
-
-## Reading Order
-
-1. Read `ctx/docs/filesystem.md` for repository boundaries.
-2. Read `ctx/docs/product/overview.md` for product meaning and scope.
-3. Read `ctx/docs/code/overview.md` for product-code boundaries.
-4. Read `skill/SKILL.md` when working as an agent using the packaged skill.

package/ctx/docs/architecture/AGENTS.md

@@ -1,98 +0,0 @@
-# Architecture Documentation
-
-- Path: `ctx/docs/architecture/AGENTS.md`
-- Changed: `20260715`
-
-## Purpose
-
-Defines the architecture documentation level.
-
-Documents at this level translate product intent into stable engineering structure, behavior, state ownership, integration boundaries, architectural constraints, durable decisions, and supervision rules.
-
-## Level Map
-
-- `AGENTS.md` — level definition for `ctx/docs/architecture/`.
-- `behavior.md` — major internal lifecycle flows and architectural processing behavior.
-- `checklists.md` — supervision and diagnosis checklists for reviewing agent behavior against architecture expectations.
-- `constraints.md` — non-negotiable architectural restrictions and trust boundaries.
-- `decisions.md` — durable architecture decisions, rejected alternatives, and reasoning.
-- `integration.md` — external integrations and major internal contracts between architectural areas.
-- `overview.md` — architectural style, major areas, and architecture-level orientation.
-- `state.md` — state ownership, sources of truth, derived state, and state-changing authority.
-- `structure.md` — major architectural blocks, runtime areas, and responsibility boundaries.
-- `supervision.md` — human-agent supervision rules, approval boundaries, and drift signals.
-
-## Architecture Knowledge Model
-
-Architecture knowledge is organized as one coordinated model rather than a set of isolated notes.
-
-Each document answers a different architectural question, and the set is intended to be read together:
-
-- `structure.md` — what is structurally built.
-- `behavior.md` — how the system behaves internally.
-- `checklists.md` — how a human quickly checks whether agent work remained inside architecture guardrails.
-- `state.md` — where authoritative state is owned, changed, and derived.
-- `integration.md` — what integrations and internal contracts exist.
-- `constraints.md` — what must not be violated.
-- `decisions.md` — why durable architectural choices were made.
-- `supervision.md` — how human and agents govern architectural consistency.
-- `overview.md` — architecture-level orientation.
-
-If an agent document grows too large to maintain, move operational detail into a natural architecture subdocument or nested subdirectory.
-
-## Local Rules
-
-- Preserve nested architecture subdirectories when they improve maintainability.
-
-## Level Boundary
-
-Defines:
-
-- Major architectural areas, system boundaries, and integration surfaces.
-- Internal behavior, state ownership, and authority distribution.
-- Durable architectural constraints, decisions, and supervision rules.
-
-Does NOT define:
-
-- Product meaning such as roles, domain entities, or use-case outcomes.
-- Deployment procedures, operational workflow routing, or environment-specific runbooks.
-- Source-level implementation details such as files, classes, tables, DTOs, or endpoint definitions.
-
-## Relationship To Product
-
-Architecture depends on product documentation and refines it. It is not an independent source of product truth.
-
-The dependency order is:
-
-```text
-product
-  → architecture
-  → environment
-  → code
-```
-
-Product documentation defines what the product is.
-
-Architecture documentation defines how that product is realized structurally.
-
-Architecture may refine product intent into engineering structure, but must not redefine:
-
-- what the product is;
-- who product roles are;
-- which domain entities exist;
-- which product outcomes matter.
-
-Architecture may add engineering precision, constraints, and internal mechanisms, but must not add new product meaning.
-
-Architecture must not invent new product behavior or silently resolve product contradictions.
-
-If an architectural concept becomes load-bearing for a product capability, invariant, authority boundary, or semantic boundary, that concept must be named in product documentation first.
-
-When product knowledge is missing or contradictory, architecture documents must expose the gap and escalate it instead of creating implicit meaning.
-
-## Authoring Rules
-
-- Keep agent documents dense, explicit, and maintainable.
-- Prefer declarative statements over implementation detail.
-- Respect the dependency order during analysis and change planning.
-- Do not introduce new architectural owners, new persistent state, new external integrations, or new system boundaries without corresponding document updates and human approval.

package/ctx/docs/architecture/behavior.md

@@ -1,68 +0,0 @@
-# Architecture Behavior
-
-- Path: `ctx/docs/architecture/behavior.md`
-- Changed: `20260708`
-
-## Purpose
-
-Defines how the skill behaves internally across its major lifecycle flows.
-
-## Core Flows
-
-- `init` creates a baseline cognitive context, writes starter documentation, and establishes metadata for later supervision.
-- `design` turns product-level intent into justified context branches, including architecture-level structure when the project needs it, and preserves project-defined workflow semantics when organizing workflow documentation.
-- `validate` checks that declared context structure exists and remains mechanically readable by verifying required paths, metadata headers, deterministic agent/skin projection rules, local markdown document links, and lightweight skin-shape heuristics without rewriting project meaning or downgrading project workflow semantics to template placeholders.
-- `quality-audit` guides an agent through evidence-backed review of a documentation corpus against ADSM documentation quality criteria, using a reference prompt and a working report template rather than CLI semantic scoring.
-- `documentation-compression` guides an agent through controlled rewrite of `ctx/docs/` to reduce redundancy and attention cost while preserving accepted project meaning.
-- `upgrade` applies or reports non-destructive migrations while preserving project-specific content.
-- `install-skill` installs the current `skill/` payload into a caller-provided skills root; it supports agent availability and is not a context lifecycle mode.
-
-## Architectural Processing
-
-The product operates through a documentation-first loop:
-
-1. read declared context and repository state;
-2. determine the applicable lifecycle mode;
-3. apply structure, checks, or migration logic;
-4. report gaps, contradictions, or specialization needs explicitly.
-
-Documentation quality audit follows the same documentation-first loop, but its output is an audit report rather than direct context mutation.
-
-`validate` is the deterministic pre-lint stage for `ctx/docs/**`.
-
-It should be run before semantic audit or compression-oriented review.
-
-Documentation compression follows the same documentation-first loop, but its output is a semantically conservative rewrite plus a compression report.
-
-The audit separates:
-
-- editorial fixes that preserve meaning;
-- cross-document consistency fixes;
-- upstream documentation gaps;
-- human decisions required before documentation can be corrected.
-
-Compression may apply editorial rewrites directly when authority is clear. It must report non-editorial uncertainty instead of resolving it.
-
-Validation findings separate:
-
-- hard structural failures such as missing paired agent documents, missing required skin sections, broken local markdown links, or missing `Includes:` / `Excludes:` blocks;
-- heuristic supervision warnings such as skin compactness threshold overrun;
-- semantic review concerns that remain outside deterministic validation and therefore belong to documentation quality audit.
-
-## Drift Handling
-
-When a new architectural concept appears, the expected sequence is:
-
-1. update product or architecture documentation;
-2. confirm supervision boundaries;
-3. change downstream environment or code artifacts.
-
-The architecture level must not be bypassed by direct code invention.
-
-## Escalation Rules
-
-- Missing product meaning must be surfaced to the human.
-- Documentation quality findings that require product or architecture decisions must be reported as human decision points, not resolved by invention.
-- Documentation compression must not invent, weaken, generalize, or silently delete project-specific knowledge.
-- Missing specialized skill coverage must be reported as a specialization gap, not treated as a reason to erase or invalidate project-defined workflow semantics.
-- Contradictions between templates, repository context, and implementation must be treated as drift.

package/ctx/docs/architecture/checklists.md

@@ -1,48 +0,0 @@
-# Architecture Checklists
-
-- Path: `ctx/docs/architecture/checklists.md`
-- Changed: `20260813`
-
-## Purpose
-
-Provides short recurring document checklists for supervision, diagnosis, and acceptance of architecture-level agent work.
-
-This file remains an agent-facing operational context document.
-
-Human-controlled semantic control belongs in a matching `checklists.skin.en.md` file if such control is needed.
-
-## Drift Diagnosis Checklist
-
-Use this checklist when an agent appears to be working in the wrong architectural direction.
-
-- Is the agent working inside the documented product and architecture boundaries?
-- Does the change stay inside declared architecture boundaries?
-- Does the change introduce a new owner, major area, integration, trust boundary, or durable state?
-- Does the change depend on product meaning that is not explicitly documented upstream?
-- Did the agent treat template guidance as if it overruled project-specific meaning?
-- Did the agent choose a direction that `constraints.md` already forbids?
-
-## Approval Checklist
-
-Use this checklist before allowing architecture expansion.
-
-- Is the proposed expansion named explicitly in product documentation where required?
-- Is the new boundary or owner documented in the appropriate architecture file?
-- Is the approval need already declared in `constraints.md` or `supervision.md`?
-- Does the change increase human supervision burden in a durable way?
-- Is the expansion being justified by real product need rather than by agent convenience?
-
-## Compression Safety Checklist
-
-Use this checklist before accepting compression of architecture documents.
-
-- Does the rewrite preserve the same authoritative meaning?
-- Did any precise rule become a vague summary?
-- Was any durable decision, exclusion, or boundary removed because it looked repetitive?
-- Did the rewrite keep one authoritative home for each load-bearing meaning?
-- Can a human still scan the control documents quickly after compression?
-
-## Related Documents
-
-- Read `constraints.md` next for forbidden directions and approval boundaries.
-- Read `supervision.md` when the question is about ownership of correction and escalation.

package/ctx/docs/architecture/constraints.md

@@ -1,53 +0,0 @@
-# Architecture Constraints
-
-- Path: `ctx/docs/architecture/constraints.md`
-- Changed: `20260813`
-
-## Purpose
-
-Defines non-negotiable architectural restrictions for this skill product.
-
-## Core Constraints
-
-- The product remains generic and orchestration-oriented.
-- Product knowledge precedes architecture, architecture precedes environment, and environment precedes code.
-- New architectural concepts are documented before code-level realization.
-- Templates remain project-neutral and must not guess domain-specific implementation.
-- The root `AGENTS.md` template must prevent agents from reading, loading, printing, searching for, or exposing secret-bearing project data, including `.env` files; non-secret example templates may describe configuration shape only.
-- Template-level workflow constraints must not be reinterpreted as limits on project-defined workflow semantics.
-- Validation, quality audit, and upgrade reporting remain non-destructive by default.
-- Documentation compression may rewrite `ctx/docs/` for density only when accepted meaning and authority are preserved.
-- Architecture agent documents remain dense, explicit, and maintainable.
-- Semantic skins remain short enough for frequent supervision and correction in live human-agent dialogue.
-
-## Boundary Constraints
-
-- Architecture must not redefine product roles, product use cases, or product domain entities.
-- Architecture must not introduce code structure as if it were architecture structure.
-- Architecture must not require project-specific technologies unless the project documentation states them explicitly.
-- Architecture must not downgrade project workflow documents to template-neutral content merely because specialized skill support is absent.
-- Architecture must not treat the absence of a specialized skill as evidence that project-defined workflow semantics are invalid.
-- Architecture must not allow documentation compression to replace precise project rules with vague summaries.
-- Architecture must not hide new persistent state, external integrations, or system boundaries behind implementation changes.
-- Architecture must not treat a control-oriented agent document as a semantic skin unless a matching `*.skin.<lang>.md` file exists.
-- Architecture must not impose a rigid internal tree under `ctx/docs/product/`, `ctx/docs/architecture/`, `ctx/docs/environment/`, or `ctx/docs/code/`.
-
-## Change Constraints
-
-The following changes require corresponding architecture-document updates and explicit human approval:
-
-- new architectural owners;
-- new persistent state;
-- new external integrations;
-- new trust boundaries;
-- new major system areas.
-
-## Review Use
-
-Use this document when the question is:
-
-- "Which architectural direction was forbidden here?"
-- "Did the agent expand the product beyond its declared structural boundary?"
-- "Does this change require approval before any implementation or deeper analysis continues?"
-
-If `constraints.skin.en.md` exists, read it before changing this document.

package/ctx/docs/architecture/constraints.skin.en.md

@@ -1,38 +0,0 @@
-# Architecture Constraints Skin
-
-- Path: `ctx/docs/architecture/constraints.skin.en.md`
-- Changed: `20260813`
-
-## Purpose
-
-This skin preserves the non-negotiable architectural restrictions that keep the skill generic, non-destructive, and context-preserving.
-
-## Mental Model
-
-Architecture may refine structure and control surfaces, but it must not expand product meaning or relax supervision-critical restrictions.
-
-## Scope
-
-Includes:
-
-- non-negotiable architectural restrictions;
-- non-destructive reporting expectations;
-- preservation of accepted meaning during compression.
-
-Excludes:
-
-- detailed code-module layout;
-- project-specific workflow semantics;
-- implementation-only optimizations.
-
-## Invariants
-
-- The product remains generic, orchestration-oriented, and protects secret-bearing project data from agent exposure.
-- Validation, quality audit, and upgrade reporting remain non-destructive by default.
-- Documentation compression must preserve accepted meaning and skin-controlled meaning.
-- Project-specific workflow semantics must not be downgraded because specialized skill support is absent.
-- Control-oriented `*.md` files remain agent documents; semantic control belongs in matching `*.skin.<lang>.md` files when needed.
-
-## Agent Document
-
-`constraints.md`

package/ctx/docs/architecture/decisions.md

@@ -1,118 +0,0 @@
-# Architecture Decisions
-
-- Path: `ctx/docs/architecture/decisions.md`
-- Changed: `20260813`
-
-## Purpose
-
-Records durable architecture decisions for the skill product.
-
-## A1. Generic Orchestration First
-
-Decision:
-The skill stays generic and manages cognitive-context lifecycle rather than project-specific implementation domains.
-
-Rejected alternative:
-Encode browser, backend, deployment, or domain-specific architecture directly into the baseline skill.
-
-Reasoning:
-Project specialization belongs in dedicated skills or project context, not in the generic lifecycle baseline.
-
-## A2. Architecture Is A Separate Level
-
-Decision:
-Architecture remains a distinct documentation level between product and environment.
-
-Rejected alternative:
-Fold structural guidance into product documents or jump directly from product documents to code-oriented constraints.
-
-Reasoning:
-The working group needs a stable place for engineering boundaries, state ownership, integrations, and supervision rules.
-
-## A3. Live Context And Installed Templates Stay Separate
-
-Decision:
-This repository's own `ctx/` documents the product, while `skill/templates/ctx/` provides reusable starter context for other projects.
-
-Rejected alternative:
-Treat the repository context and the installable template payload as the same artifact.
-
-Reasoning:
-The product needs self-documentation and reusable output, but those artifacts serve different consumers and change for different reasons.
-
-## A4. Documentation Precedes Structural Change
-
-Decision:
-New architectural concepts are documented before downstream code or environment changes.
-
-Rejected alternative:
-Allow architecture to emerge only from implementation diffs.
-
-Reasoning:
-ADSM uses documentation as an operational interface; architecture drift must be visible before it is encoded.
-
-## A5. Boundary Expansion Requires Human Approval
-
-Decision:
-Agents may refine architecture inside existing guardrails, but expanding owners, persistent state, integrations, or system boundaries requires human approval.
-
-Rejected alternative:
-Permit autonomous architectural expansion when implementation seems straightforward.
-
-Reasoning:
-Those changes alter the supervision burden and must remain under human control.
-
-## A6. Documentation Quality Audit Is Agent-Guided
-
-Decision:
-Documentation quality audit is implemented as agent guidance over the declarative project documentation corpus under `ctx/docs/`, not as CLI semantic scoring.
-
-Rejected alternative:
-Encode documentation quality scoring as an automatic CLI validation command over the whole cognitive context.
-
-Reasoning:
-The quality criteria require semantic reading, evidence-backed findings, and separation of editorial issues from missing human decisions. Operational context such as agent workflows, prompts, and runtime configuration may exist under `ctx/`, but it is not part of the default documentation quality corpus.
-
-## A7. Documentation Compression Is Controlled Rewrite
-
-Decision:
-Documentation compression is implemented as agent guidance over the declarative project documentation corpus under `ctx/docs/`, not as automatic semantic scoring or broad context rewriting.
-
-Rejected alternative:
-Let compression freely summarize the whole cognitive context or treat operational context as part of the default corpus.
-
-Reasoning:
-Compression changes text directly and therefore needs stronger authority discipline than audit. The default scope remains `ctx/docs/`, and accepted project meaning must be preserved while redundancy and low-density wording are reduced.
-
-## A8. Agent/Skin Projection Defines Document Control
-
-Decision:
-Documents under `ctx/docs/**` are agent-facing operational context documents by default, and human semantic control is expressed through optional matching `*.skin.<lang>.md` files.
-
-Rejected alternative:
-Use document metadata markers as the primary semantic-control mechanism.
-
-Reasoning:
-The working model of this product is one human and many agents. Agent-first is the normal operating mode, but human control needs a stronger semantic projection than a metadata marker. A `*.skin.<lang>.md` file provides an explicit control surface for the matching agent document without turning that document into a human-oriented summary.
-
-## A9. The Skill Enforces ADSM Discipline
-
-Decision:
-Project documentation templates should focus on governing a project, while ADSM conformance rules are enforced by the skill itself.
-
-Rejected alternative:
-Embed most ADSM discipline directly into project-facing document templates and make project documents explain the methodology to themselves.
-
-Reasoning:
-Project cognitive context should spend attention on product and architecture control, not on repeated methodological self-description. Installed templates should carry only the minimal bootstrap signal that the context follows ADSM and that structural validation belongs to skill `adsm-ctx`. The skill is the correct place for template discipline, audit logic, compression rules, and other ADSM conformance checks.
-
-## A10. `AGENTS.md` Is A Control Surface, Not A Spec Origin
-
-Decision:
-`AGENTS.md` files are service control files for agent work. Their own requirements originate in declarative documents under `ctx/docs/`, then are operationalized by the skill.
-
-Rejected alternative:
-Let `AGENTS.md` files define the normative rules for the `AGENTS.md` hierarchy, structure, and authoring format by themselves.
-
-Reasoning:
-Allowing `AGENTS.md` to legislate its own format mixes specification with execution control. The specification layer must stay in `ctx/docs/`; the skill may then detail and validate it; individual `AGENTS.md` files only execute that already-declared model in local project work.

package/ctx/docs/architecture/integration.md

@@ -1,31 +0,0 @@
-# Architecture Integration
-
-- Path: `ctx/docs/architecture/integration.md`
-- Changed: `20260707`
-
-## Purpose
-
-Defines the major integration boundaries of the skill product.
-
-## External Integrations
-
-- local project filesystem — target of context initialization, validation, and upgrade work;
-- package installation environment — distribution surface for the CLI and reusable templates;
-- agent skill host — installation target for the bundled skill payload;
-- source-control workflow — durable channel for reviewing and propagating template changes.
-
-## Internal Contracts
-
-- lifecycle operations consume declared repository context before making structure decisions;
-- reusable templates provide the baseline artifact set for initialized projects;
-- skill installation connects the CLI `install-skill` command, the source `skill/` payload, and the caller-provided skills root;
-- documentation quality audit guidance connects the source prompt in `skill/references/documentation-quality-audit.md`, the working report template in `skill/templates/work/report/`, and agent-produced audit reports;
-- documentation compression guidance connects the source prompt in `skill/references/documentation-compression.md`, the working report template in `skill/templates/work/report/`, and agent-produced compression reports;
-- repository `ctx/` documents the product and governs changes to templates and implementation;
-- specialization routing hands project-specific architecture work to dedicated skills when they exist.
-
-## Integration Boundaries
-
-- This document defines contract surfaces, not endpoint schemas or DTOs.
-- External integrations must remain explicit in architecture before they appear in implementation.
-- New integrations that affect project boundaries require supervision updates and human approval.

package/ctx/docs/architecture/overview.md

@@ -1,76 +0,0 @@
-# Architecture Overview
-
-- Path: `ctx/docs/architecture/overview.md`
-- Changed: `20260708`
-
-## Purpose
-
-Defines architecture-level orientation for this skill product.
-
-## Architecture Role
-
-At this level, product intent is translated into stable engineering structure.
-
-This level answers:
-
-- what is structurally built;
-- how the system behaves internally;
-- where state is owned;
-- what integrations exist;
-- what constraints must not be violated;
-- why key architectural decisions were made;
-- how human and agents supervise architectural consistency.
-
-This document answers those questions briefly and identifies the related architecture documents that hold more detail.
-
-## Architectural Style
-
-The product uses a documentation-first lifecycle architecture with separate surfaces for lifecycle execution, guidance, reusable templates, and supervision.
-
-## Major Areas
-
-- lifecycle orchestration for `init`, `design`, `validate`, `quality-audit`, `documentation-compression`, and `upgrade`;
-- skill payload installation for agent skill hosts;
-- agent-facing audit and compression guidance;
-- semantic-skin-ready control surfaces for orientation, constraints, and checklists;
-- reusable product-level and architecture-level context templates;
-- reserved `ctx/agent/` boundary for project-local materials outside ADSM methodology;
-- repository context that governs the package itself;
-- migration and validation boundaries that preserve project-specific content;
-- specialization routing boundary.
-
-## Related Bodies
-
-- Read `structure.md` when the question is "what are the main architectural areas and boundaries?"
-- Read `behavior.md` when the question is "how do those areas work together through major internal flows?"
-- Read `checklists.md` when the question is "which fast human checks should I run before concluding that agent work drifted?"
-- Read `state.md` when the question is "where is authoritative state owned, persisted, changed, and derived?"
-- Read `integration.md` when the question is "which external systems and internal contract boundaries matter?"
-- Read `constraints.md` when the question is "which architectural options are forbidden or non-negotiable?"
-- Read `decisions.md` when the question is "why was this architecture chosen over other durable alternatives?"
-- Read `supervision.md` when the question is "what may agents change, what requires approval, and what signals drift?"
-
-## Product Dependency
-
-This level depends on product documentation.
-
-Product documentation defines what this skill is and what it is responsible for.
-
-Architecture defines how that product intent is realized structurally.
-
-The expected dependency is:
-
-```text
-product
-  → architecture
-  → environment
-  → code
-```
-
-Architecture must not redefine product meaning, invent missing product behavior, or normalize product contradictions silently.
-
-## Human-Agent Use
-
-The architecture level is an operational interface between one human and many agents.
-
-The human owns direction and guardrails. Agents may refine architecture within those guardrails and must report drift instead of deciding past the declared boundary.

package/ctx/docs/architecture/state.md

@@ -1,50 +0,0 @@
-# Architecture State
-
-- Path: `ctx/docs/architecture/state.md`
-- Changed: `20260707`
-
-## Purpose
-
-Defines state ownership and sources of truth for the skill product.
-
-## Sources Of Truth
-
-- `ctx/` is the declarative source of truth for this repository as a product.
-- `skill/` is the source of truth for the installed agent skill payload.
-- `skill/templates/ctx/` is the source of truth for installed starter context artifacts and their minimal ADSM bootstrap markers.
-- `skill/templates/work/` is the source of truth for working templates used by agents during skill operations.
-- `ctx/adsm.json` is the durable metadata source for context versioning and upgrade eligibility.
-
-## State Categories
-
-- authoritative durable state — versioned context documents, templates, metadata, and repository content that define the product and its reusable baseline;
-- derived state — installed copies, validation findings, and generated reports that are produced from authoritative durable state;
-- transient state — process-local execution data used during a command or agent run.
-
-## Ownership Boundaries
-
-- `ctx/` owns the declared meaning and architectural rules of this repository as a product.
-- `skill/` owns the installable agent-consumed skill payload.
-- `skill/templates/ctx/` owns the reusable baseline to be installed into downstream projects, including the minimal markers that route structural validation back to the skill.
-- `skill/templates/work/` owns reusable working output structures that are not installed into project `ctx/` by default.
-- `ctx/adsm.json` owns durable context-version metadata and upgrade eligibility.
-
-Derived and transient state may reflect those sources, but they do not replace them as sources of truth.
-
-## Ownership Rules
-
-- The human owns product direction, architectural guardrails, and approval for boundary expansion.
-- Agents may refine durable documentation within existing boundaries.
-- Agents must not create new persistent state categories or new state owners without updating architecture documents and obtaining human approval.
-
-## State Authority
-
-- Authoritative state may be changed only through deliberate repository updates under the declared supervision model.
-- Derived state may be regenerated, but must stay traceable to an authoritative source.
-- Persistence responsibility must stay explicit whenever durable state is introduced or reorganized.
-
-## State Change Discipline
-
-- Product documents establish meaning.
-- Architecture documents establish ownership and authority.
-- Environment and code documents may refine realization details without taking ownership away from architecture.

package/ctx/docs/architecture/structure.md

@@ -1,38 +0,0 @@
-# Architecture Structure
-
-- Path: `ctx/docs/architecture/structure.md`
-- Changed: `20260707`
-
-## Purpose
-
-Defines the major architectural blocks and responsibility boundaries of the skill product.
-
-## Architectural Blocks
-
-- lifecycle orchestration surface — exposes the `init`, `design`, `validate`, `quality-audit`, `documentation-compression`, and `upgrade` capabilities as the main system behavior boundary;
-- skill payload installation surface — copies the current `skill/` bundle into a caller-provided skills root as the `adsm-ctx` payload;
-- `AGENTS.md` control surface — provides the service-control hierarchy used by agents during project work, while remaining subordinate to the declarative specifications in `ctx/docs/`;
-- reusable template bundle — provides starter `ctx/` artifacts for downstream projects, including product and architecture documentation templates with only minimal ADSM bootstrap markers;
-- documentation quality audit guidance boundary — provides the agent-facing audit prompt and working report template for evaluating documentation corpora without adding CLI-based semantic scoring;
-- documentation compression guidance boundary — provides the agent-facing rewrite prompt and working report template for reducing `ctx/docs/` corpus size without changing accepted project meaning;
-- `ctx/agent/` boundary definition — provides only the reserved branch boundary file for project-local materials that sit outside ADSM methodology;
-- repository self-documentation — keeps the skill product governed by its own cognitive context;
-- migration and validation boundary — checks structural conformance and applies safe convention upgrades;
-- specialization routing boundary — identifies when project-specific skills must take over narrower documentation branches.
-
-## Responsibility Boundaries
-
-- Product documentation defines the meaning and scope of the skill.
-- Architecture defines stable engineering areas and their contracts.
-- `AGENTS.md` files carry operational control inside those declared boundaries but do not define the boundaries on their own.
-- Environment defines runtime prerequisites.
-- Code defines implementation of the declared structure.
-
-## Structural Exclusions
-
-This document does not list:
-
-- source files or directories as architecture blocks;
-- classes, functions, or modules;
-- database tables or DTOs;
-- endpoint-level API details.