xdrs-core 0.51.0 → 0.52.1

package/.xdrs/_core/adrs/index.md

@@ -27,6 +27,7 @@ Foundational standards, principles, and guidelines.
 - [_core-adr-policy-019](principles/019-compiled-scope-type.md) - **compiled scope type** — Defines the `compiled` scope type: scopes whose policies are compiled from external authoritative sources with strict source traceability and no invented content
 - [_core-adr-policy-020](principles/020-media-and-asset-standards.md) - **Media and asset standards** — Canonical diagram format preference order and non-Markdown asset rules for all XDRS document types
 - [_core-adr-policy-021](principles/021-skill-bundling.md) - **Skill bundling** — Optional per-skill Makefile mechanism to stage a self-contained dist/ output for standalone distribution
+- [_core-adr-policy-022](principles/022-scope-activation.md) - **Scope activation** — How installed scopes are listed in the root index, activated, narrowed, or disabled, and when they become read-only
 
 ## Skills
 

package/.xdrs/_core/adrs/principles/001-xdrs-standards.md

@@ -75,25 +75,26 @@ ADR and EDR share the same six technical subject names (see [`_core-adr-policy-0
   - **Types:** `adrs`, `bdrs`, `edrs`
   - there can exist sufixes to the standard scope names (e.g: `business-x-mobileapp`, `business-y-servicedesk`)
   - The `-core` suffix designates a scope as the meta governance layer for a domain. See `_core-adr-policy-011` for the `core` scope type definition.
-  - **Scope types:** Every scope MUST declare its type via a `scope-type` field in its `index.md` YAML frontmatter. A `scope-type` value is valid when a `{scope-type}-scope-type` policy exists in the `principles` subject of any `core`-type scope in the workspace. Multiple types MAY be declared using a comma-separated list (e.g., `scope-type: compiled, internal-docs`); each element MUST be valid independently. See `_core-adr-policy-010` rules 06 and 07 for the full multi-type grammar. Custom scope-type names MUST NOT start with `_`. The five built-in scope types and their definitions are:
+  - **Scope types:** Every scope MUST declare its type via a `scope-type` field in its `index.md` YAML frontmatter. A `scope-type` value is valid when a `{scope-type}-scope-type` policy exists in the `principles` subject of any `core`-type scope in the workspace. Multiple types MAY be declared using a comma-separated list (e.g., `scope-type: compiled, internal-docs`); each element MUST be valid independently. See `_core-adr-policy-010` rules 06–08 for the full multi-type grammar and naming constraints. The six built-in scope types and their definitions are:
     - `core` — see [`_core-adr-policy-011`](011-core-scope-type.md)
     - `reference` — see [`_core-adr-policy-012`](012-reference-scope-type.md)
     - `platform` — see [`_core-adr-policy-013`](013-platform-scope-type.md)
     - `standard` — see [`_core-adr-policy-014`](014-standard-scope-type.md)
     - `_local` — see [`_core-adr-policy-015`](015-local-scope-type.md)
+    - `compiled` — see [`_core-adr-policy-019`](019-compiled-scope-type.md)
   - Scope name suffixes are unlimited and MAY be used in any scope type.
   - When writing or generating a new XDRS root `index.md`, use the following default ordering (scopes listed later override earlier ones): `core → reference → platform → standard → _local`. Custom-type scopes SHOULD be placed in the `standard` position. This ordering is the **default fallback** for conflict resolution between scopes: `extends:` declarations (Section D of `_core-adr-policy-010`) take precedence over it for policy document inheritance, and `follows:` declarations govern authoring governance rules independently. See `_core-adr-policy-010.36-root-index-ordering-fallback` for the full normative definition.
   - **Scope index frontmatter fields:** Every scope's `index.md` MUST include the following YAML frontmatter. Fields match the Policy frontmatter standard (`_core-adr-policy-002`) in purpose, adjusted for scope-level semantics:
     - `name` (required): The scope identifier, MUST exactly match the scope directory name (e.g., `myteam`, `cloud-platform-aws`). Used by tools to verify scope identity.
     - `description` (required): Short overview of what this scope covers and who the intended audience is. Used by AI agents for discovery and relevance matching. Max 40 words.
-    - `scope-type` (required): Scope classification type. MAY be a comma-separated list of types (e.g., `scope-type: compiled, internal-docs`). Each element MUST match a `{scope-type}-scope-type` policy in any `core`-type scope's `principles/` directory. See `_core-adr-policy-010` rules 06 and 07 for the full multi-type grammar and `_core-adr-policy-011`, `012`–`015` for built-in type definitions.
+    - `scope-type` (required): Scope classification type. MAY be a comma-separated list of types (e.g., `scope-type: compiled, internal-docs`). Each element MUST match a `{scope-type}-scope-type` policy in any `core`-type scope's `principles/` directory. See `_core-adr-policy-010` rules 06 and 07 for the full multi-type grammar and `_core-adr-policy-011`, `012`–`015`, and `019` for built-in type definitions.
     - `apply-to` (required): Declares in which contexts — teams, systems, codebases, or environments — the decisions in this scope are relevant. Max 30 words.
     - `valid-from` (required): ISO date (YYYY-MM-DD) from which this scope became active.
     - `metadata` (optional): Arbitrary key-value map for additional scope metadata.
     - `follows` (optional): Core scope names whose Policies apply as mandatory governance conventions to this scope, beyond `_core`. Last-listed takes precedence on conflicts (e.g., `follows: myarea-core, shared-standards`). All referenced scopes MUST exist in the workspace; if any is absent, READ/WRITE/REVIEW operations MUST fail.
-    - `extends` (optional): Scope names whose **policy documents** (decision records only — not skills, articles, research, or initiatives) are inherited by this scope as if they were authored here. Any scope type except `_local` and `_core` may be referenced. Last-listed extended scope takes precedence on conflicts; the extending scope's own policies always take highest precedence. Depth-first transitive resolution applies: if A extends [B, C] and B extends [D], the effective precedence order is D < B < C < A. `extends:` and `follows:` MUST reference disjoint scope sets. All referenced scopes MUST exist in the workspace; if any is absent, READ/WRITE/REVIEW operations MUST fail. When an extending scope's policy overrides an inherited policy on the same topic, a `## Conflicts` section MUST document the override. Scopes referenced only via `extends:` chains (not entry scopes in the root index) are exempt from the root index link requirement. `extends:` takes precedence over root index ordering for conflict resolution between the scopes involved; root index ordering is the fallback for all other scope pairs. See `_core-adr-policy-010` Section D (rules 27–35) and Section E (rule 36) for full normative rules.
+    - `extends` (optional): Scope names whose **policy documents** (decision records only — not skills, articles, research, or initiatives) are inherited by this scope as if they were authored here. Any scope type except `_local` and `_core` may be referenced. Last-listed extended scope takes precedence on conflicts; the extending scope's own policies always take highest precedence. Depth-first transitive resolution applies: if A extends [B, C] and B extends [D], the effective precedence order is D < B < C < A. `extends:` and `follows:` MUST reference disjoint scope sets. All referenced scopes MUST exist in the workspace; if any is absent, READ/WRITE/REVIEW operations MUST fail. When an extending scope's policy overrides an inherited policy on the same topic, a `## Conflicts` section MUST document the override. Extended scopes are still linked in the root index; tag them `extends-only` to apply them only via `extends:` (see `_core-adr-policy-022.01-root-index-completeness`). `extends:` takes precedence over root index ordering for conflict resolution between the scopes involved; root index ordering is the fallback for all other scope pairs. See `_core-adr-policy-010` Section D (rules 27–35) and Section E (rule 36) for full normative rules.
+    - `extends-only` (optional): See `_core-adr-policy-022.07-extends-only-field`.
     - `license` (optional): SPDX identifier for the scope's content license.
-    - `metadata` (optional): Arbitrary key-value map for additional scope metadata.
 - **Subjects:** The subject folder MUST be chosen per [`_core-adr-policy-016`](016-policy-subjects.md), which defines allowed subjects, full descriptions, examples, and disambiguation tiebreakers.
 - **Policy numbering:** Numbers MUST be assigned within the subject-based block ranges defined in [`_core-adr-policy-017`](017-policy-numbering-ranges.md). Use the lowest available number within the block for the chosen subject. See [`_core-adr-policy-002-policy-standards.01-freeze-reference-exemption`](002-policy-standards.md) for exemptions.
 - MUST NOT use emojis
@@ -107,7 +108,7 @@ ADR and EDR share the same six technical subject names (see [`_core-adr-policy-0
     - Add a short description of what this scope is about (responsibilities, general worries, teams involved, link to discussion process, etc)
     - Add links to related scope indexes that this scope might override or be overridden by (scopes listed last override earlier ones on the same topic).
     - Each XDRS element entry MUST include a short description. SHOULD use an imperative statement or the question it answers (<15 words). Example: "Use this while planning a new feature", "What communication tone we use with our customers?"
-  - Outside the scopes, keep a root index in `[xdrs-root]/index.md` that links to each scope index (`[xdrs-root]/[scope]/index.md`). Add the text "XDRS scopes listed last override the ones listed first" followed by a note that `extends:` and `follows:` declarations in individual scope indexes take precedence over this ordering for their respective resolution concerns (see `_core-adr-policy-010.36-root-index-ordering-fallback`). The root index MUST NOT link directly to type indexes; readers navigate from the scope index to the type indexes. Use the link text pattern `View scope [scope_name]` for each scope link (e.g. `[View scope myteam] linking to (myteam/index.md)`).
+  - Outside the scopes, keep a root index in `[xdrs-root]/index.md` that links to each scope index (`[xdrs-root]/[scope]/index.md`) exactly once (see `_core-adr-policy-022`). Add the text "XDRS scopes listed last override the ones listed first" followed by a note that `extends:` and `follows:` declarations in individual scope indexes take precedence over this ordering for their respective resolution concerns (see `_core-adr-policy-010.36-root-index-ordering-fallback`). The root index MUST NOT link directly to type indexes; readers navigate from the scope index to the type indexes. Use the link text pattern `View scope [scope_name]` for each scope link (e.g. `[View scope myteam] linking to (myteam/index.md)`).
   - MUST verify if indexes are up to date after making changes
 - **Scope index**
   - Each scope folder MUST maintain an `index.md` file at `[xdrs-root]/[scope]/index.md`.

package/.xdrs/_core/adrs/principles/003-skill-standards.md

@@ -164,7 +164,7 @@ Rules:
 - `description` SHOULD stay near 250 characters when the activation trigger can be stated that tightly, even though the hard cap remains 1024 characters — it is loaded into context on every activation scan.
 - `## Overview` SHOULD state the task objective, expected outcome, and relevant prerequisites or tools when they matter, and MUST contain nested subsections, in order, for `### Inputs`, `### Outputs`, `### Halt Conditions`, then the optional `### User Interaction` and `### Runtime Requirements`.
 - `### Inputs` MUST contain `#### Required` (the bare minimum needed to invoke the skill) then `#### Optional` (helpful extra context), in that order.
-- `## Instructions` SHOULD state one clearly recommended approach first when multiple are viable, noting alternatives briefly afterward, and SHOULD include verification steps or acceptance criteria at the end of the task or major phases.
+- `## Instructions` is REQUIRED. It SHOULD state one clearly recommended approach first when multiple are viable, noting alternatives briefly afterward, and SHOULD include verification steps or acceptance criteria at the end of the task or major phases.
 - `## Examples` SHOULD include 2-3 example prompts a user could give as input, alongside a short description of what to expect during execution and as output for each.
 - `### Outputs` covers only end-objective results, not intermediary items, and MUST contain `#### Contents` (generated files or chat-delivered results) then `#### Changes` (external system mutations that are part of the main objective), in that order.
 - `### Halt Conditions` MUST list this skill's specific stop-before-completing triggers, grounded in at least missing required input, dubious/ambiguous input, and insufficient agent confidence — distinct from `## Edge Cases` (activation/boundary conditions) and `## Anti-Patterns` (execution mistakes). A partial or empty result the skill still finishes and returns belongs in `### Outputs`, not `### Halt Conditions`.

package/.xdrs/_core/adrs/principles/008-policy-structured-standards.md

@@ -49,7 +49,7 @@ A rule title SHOULD include a normative keyword when the rule can be stated clea
 
 #### 08-rule-block-must-use-standard-syntax
 
-Each rule MUST be written as a level-4 heading with a two-digit zero-padded sequence number followed by a kebab-case title, and a body paragraph:
+Each rule MUST be written as a level-4 heading with a two-digit zero-padded sequence number followed by a kebab-case title of 12 words or fewer, and a body paragraph:
 
 ```markdown
 #### [NN]-[short-rule-title-in-kebab-case]

package/.xdrs/_core/adrs/principles/010-scope-governance.md

@@ -9,19 +9,20 @@ valid-from: 2026-07-01
 
 ## Context and Problem Statement
 
-XDRS provides three mechanisms that govern what content belongs in a scope and how it should be structured:
+XDRS provides four mechanisms that govern what content belongs in a scope and how it should be structured:
 
 1. **Scope-type standards**: a policy in a `core`-type scope that defines the rules for all scopes of that type.
 2. **`follows:` declarations**: a scope explicitly declares that it follows the standards of a named `core`-type scope.
 3. **Scope-local standards**: a policy inside a scope that defines content rules specific to that one scope.
+4. **`extends:` declarations**: a scope inherits another named scope's policy documents (Section D).
 
 ## Decision Outcome
 
 **Define scope types as policies, local meta-policies as `core`-named policies in `principles/`, and a clear precedence chain for governance application.**
 
-All scope types — both the five built-in types and any custom types — are defined using the same convention: a `{scope-type}-scope-type` policy in a `core`-type scope. Scope-local standards (called _local meta-policies_) are optional policies whose filename title starts with `core` and which are placed in the `principles` subject of the scope. Multiple local meta-policy files are allowed, each distinguished by an optional qualifier. Tools and agents apply all applicable standards in a defined order.
+All scope types — both the six built-in types and any custom types — are defined using the same convention: a `{scope-type}-scope-type` policy in a `core`-type scope. Scope-local standards (called _local meta-policies_) are optional policies whose filename title starts with `core` and which are placed in the `principles` subject of the scope. Multiple local meta-policy files are allowed, each distinguished by an optional qualifier. Tools and agents apply all applicable standards in a defined order.
 
-> **Choosing between a local meta-policy and a `-core` sibling scope**: use a local meta-policy when the standards apply only to one scope. Use a `-core` sibling scope (see `_core-adr-policy-011`) when the governance needs to be shared or governs a family of scopes.
+> **Local meta-policy vs. `-core` sibling scope**: use a local meta-policy for single-scope standards; use a `-core` sibling scope (`_core-adr-policy-011`) when governance is shared across a family of scopes.
 
 ### Details
 
@@ -82,7 +83,7 @@ A scope-type definition policy MAY declare a parent scope type by including a ru
 
 A `scope-type` value in a scope `index.md` is valid if and only if a policy file whose name ends with `{scope-type}-scope-type` exists in the `principles` subject of any `core`-type scope in the workspace. Tools (such as `xdrs-core lint`) MUST enforce this for every element when `scope-type` is an array.
 
-When a scope declares a `scope-type` but any corresponding `{scope-type}-scope-type.md` policy is absent from the workspace, the scope MUST be treated as READ-ONLY: content MUST NOT be added, changed, removed, or reviewed. Tools MUST surface the read-only status and MUST NOT apply changes until the scope-type governance is installed.
+When a scope declares a `scope-type` but any corresponding `{scope-type}-scope-type.md` policy is absent from the workspace or defined only in a `disabled` scope, the scope MUST be treated as READ-ONLY (see `_core-adr-policy-022.06-read-only-dependencies`). Missing types are a lint error for local scopes.
 
 #### 11-def-scope-type-must-be-structured
 
@@ -90,7 +91,7 @@ All `{scope-type}-scope-type.md` policies (primary and companion files) MUST fol
 
 #### 12-def-core-scope-policies-must-be-structured
 
-All policy files in a `core`-type scope (a scope whose `index.md` declares `scope-type: core`) MUST follow the structured format defined in `_core-adr-policy-008` (see rule 11). This requirement applies to ALL policies in the scope, not only scope-type definitions or local meta-policies. The `_core` scope itself is exempt from this requirement until its existing policies are migrated. Tools MUST enforce this for all non-exempt core-type scopes and report an error using code `_core-adr-policy-010-scope-governance.12-def-core-scope-policies-must-be-structured`.
+All policy files in a `core`-type scope (a scope whose resolved scope-type chain, including parent types per rule 09, contains `core`) MUST follow the structured format defined in `_core-adr-policy-008` (see rule 11). This requirement applies to ALL policies in the scope, not only scope-type definitions or local meta-policies. The `_core` scope itself is exempt from this requirement until its existing policies are migrated. Tools MUST enforce this for all non-exempt core-type scopes and report an error using code `_core-adr-policy-010-scope-governance.12-def-core-scope-policies-must-be-structured`.
 
 ---
 
@@ -145,7 +146,7 @@ When adding or reviewing content in a scope, tools and agents MUST:
    a. Search `[type]/principles/` directories of all `core`-type scopes for the `{scope-type}-scope-type.md` primary file.
    b. If found, load the primary and all companion files (`{scope-type}-scope-type-{qualifier}.md`) from the **same directory**, in alphabetical qualifier order.
    c. If the primary contains a rule titled `NN-parent-scope-type`, extract the parent type name and repeat steps a–c. Detect and stop on cycles.
-3. Concatenate all resolved ancestor chains in declaration order to form a flat list (e.g., `scope-type: [reference, platform]` where `reference → standard`, `platform → core`: `[standard, reference, core, platform]`).
+3. Concatenate all resolved ancestor chains in declaration order to form a flat list (e.g., `scope-type: [reference, internal-docs]` where `reference → standard`, `internal-docs → standard`: `[standard, reference, standard, internal-docs]`).
 4. Deduplicate keeping the **first occurrence** of each type.
 5. Apply all policies from the deduplicated list as mandatory conventions. Later entries override earlier entries on same rule number conflicts (see rule 26-conflict-declarations).
 
@@ -188,7 +189,7 @@ A `## Conflicts` section MAY also document cross-scope-type incompatibilities fo
 
 ---
 
-**Section D — Scope extends**
+**Section D — Scope extends** (content-inheritance precedence, distinct from Section C's rule-authoring precedence)
 
 #### 27-extends-declaration
 
@@ -234,7 +235,7 @@ An undeclared conflict MUST be surfaced during review (see `_core-adr-policy-010
 
 #### 35-extends-index
 
-Scopes referenced only via `extends:` chains and not linked in the root `index.md` are **exempt** from the "root index must link all scopes" requirement. If a scope is both referenced via `extends:` AND linked in the root index, tools SHOULD warn of ambiguous dual precedence using warning code `_core-adr-policy-010.35-extends-index`.
+Scopes referenced via `extends:` MUST still be linked in the root `index.md` (see `_core-adr-policy-022.01-root-index-completeness`). Consumers SHOULD tag them `extends-only` when they must apply only through `extends:` chains (see `_core-adr-policy-022.04-extends-only`).
 
 ---
 
@@ -242,6 +243,6 @@ Scopes referenced only via `extends:` chains and not linked in the root `index.m
 
 #### 36-root-index-ordering-fallback
 
-The root `index.md` ordering ("scopes listed last override the ones listed first") is the **default fallback** for policy document conflict resolution. `extends:` takes precedence: when a scope explicitly `extends:` another, the `extends:` chain (Section D, rule 33) governs; root index ordering MUST NOT be used to resolve conflicts between those scopes. For all other scope pairs, agents and tools MUST treat the later-listed scope in the root `index.md` as providing the overriding policy.
+The root `index.md` ordering ("scopes listed last override the ones listed first") is the **default fallback** for policy document conflict resolution. `extends:` takes precedence: when a scope explicitly `extends:` another, the `extends:` chain (Section D, rule 33) governs; root index ordering MUST NOT be used to resolve conflicts between those scopes. For all other pairs of active scopes (not tagged `disabled` or `extends-only`, see `_core-adr-policy-022`), agents and tools MUST treat the later-listed scope in the root `index.md` as providing the overriding policy.
 
-`follows:` is independent of policy document conflict resolution. It governs authoring governance rules only (Section C, rule 24). Agents reading a single scope's `index.md` MUST also read the root `index.md` to determine conflict resolution order absent an `extends:` relationship.
+`follows:` does not affect policy document conflict resolution. Agents reading a scope's `index.md` MUST also read the root `index.md` to determine conflict order absent an `extends:` relationship.

package/.xdrs/_core/adrs/principles/011-core-scope-type.md

@@ -65,12 +65,16 @@ A `core`-type scope MAY be distributed to consumers alongside the companion cons
 
 #### 08-unavailable-core-read-only
 
-A `-core` scope referenced via `follows:` in a companion scope's `index.md` may not be present in the workspace of a consumer of that companion scope. When the referenced `-core` scope is absent, the companion scope MUST be treated as READ-ONLY: content in it MUST NOT be added, changed, or removed. The scope lacks the meta governance that defines how its content MUST be authored, and modifications without those standards would produce non-compliant content. Tools and agents MUST NOT propose or apply changes to a READ-ONLY scope and MUST surface the read-only status to the user when the scope is accessed.
+A `-core` scope referenced via `follows:` in a companion scope's `index.md` may not be present in the workspace of a consumer of that companion scope. When the referenced `-core` scope is absent or tagged `disabled` in the root index, the companion scope MUST be treated as READ-ONLY (see `_core-adr-policy-022.06-read-only-dependencies`): content in it MUST NOT be added, changed, or removed. The scope lacks the meta governance that defines how its content MUST be authored, and modifications without those standards would produce non-compliant content. Tools and agents MUST NOT propose or apply changes to a READ-ONLY scope and MUST surface the read-only status to the user when the scope is accessed.
 
 #### 09-distribution-advisable
 
 Distributing `-core` scopes alongside their companion consumable scope to downstream consumers SHOULD be done when possible. Having the meta governance available locally allows tools, agents, and contributors to reason about authoring standards, validate content, and apply scope-local conventions correctly. Distribution is not mandatory; the companion scope remains valid and usable in READ-ONLY mode when the `-core` scope is absent (see `08-unavailable-core-read-only`).
 
+#### 10-no-type-combination
+
+A scope is core-type when its resolved scope-type chain, including parent types (see `_core-adr-policy-010.09-def-parent-scope-type`), contains `core`. A core-type scope MUST declare exactly one scope type; combining a core-type with any other type (e.g., `scope-type: core, standard`) is a lint error. Core-type scopes hold meta governance only, so mixing them with consumable types would blur rules 04 and 05.
+
 ## References
 
 - [_core-adr-policy-010 - Scope governance](010-scope-governance.md) — full scope governance model including when to prefer a local meta-policy (`NNN-core.md` in `principles/`) vs. this pattern

package/.xdrs/_core/adrs/principles/019-compiled-scope-type.md

@@ -23,7 +23,7 @@ How should a scope that exists solely as a compiled representation of external s
 
 #### 01-scope-type-name
 
-The scope type defined by this policy is `compiled`. A scope MUST declare it by setting `scope-type: compiled` in its `index.md` YAML frontmatter. The `compiled` type MAY be combined with one or more other scope types using a comma-separated list (e.g., `scope-type: compiled, reference`).
+The scope type defined by this policy is `compiled`. A scope MUST declare it by setting `scope-type: compiled` in its `index.md` YAML frontmatter. The `compiled` type MAY be combined with one or more other scope types except core-type ones (see `_core-adr-policy-011.10-no-type-combination`) using a comma-separated list (e.g., `scope-type: compiled, reference`).
 
 #### 02-when-to-use
 

package/.xdrs/_core/adrs/principles/022-scope-activation.md

@@ -0,0 +1,69 @@
+---
+name: _core-adr-policy-022-scope-activation
+description: Defines how installed scopes are listed in the root index, how consumers activate, narrow, or disable them with activation tags, and when a scope becomes read-only because a dependency is missing, disabled, or invalid.
+apply-to: All XDRS workspaces, scope authors, consumers, tools, and agents
+valid-from: 2026-07-20
+---
+
+# _core-adr-policy-022: Scope activation
+
+## Context and Problem Statement
+
+Packages install scope folders into a workspace, but nothing guaranteed that every installed scope was listed in the root `index.md`. Scopes that were meant to be reused only through `extends:` were hidden from the root index, so agents could not discover them, and consumers had no way to switch off a scope they installed but did not want to apply. When a scope depended on another scope that was absent, the result was either a hard lint error or silent misbehaviour.
+
+How does a consumer control which installed scopes apply globally, which apply only through `extends:`, and which are ignored, while keeping every scope discoverable?
+
+## Decision Outcome
+
+**Every installed scope is listed once in the root index; the consumer controls activation with an inline activation tag next to the scope link, and the scope author declares intent with an `extends-only` frontmatter field that lint checks for coherence.**
+
+Policies of listed scopes apply globally by default. An activation tag narrows a scope to `extends-only` or turns it off with `disabled`. Agents rely only on the tags. Scopes whose dependencies are missing, disabled, or invalid become read-only.
+
+### Details
+
+#### 01-root-index-completeness
+
+Every scope folder under the XDRS root that contains an `index.md`, including scopes installed from external packages, MUST be linked exactly once from the root `index.md`. The `_local` scope MUST NOT be linked (see `_core-adr-policy-001`). A scope folder with no link, or a scope linked more than once, is a lint error. Links that resolve to the same scope index (e.g. `./x/index.md` and `x/index.md`) count as the same link. Links inside fenced code blocks are ignored.
+
+#### 02-global-applicability
+
+Policies of a listed scope without an activation tag MUST be applied globally, narrowed by the scope `apply-to` and each policy `apply-to`. Meta-policies (local meta-policies, scope-type definition policies) and all content of core-type scopes are never applied globally; they govern authoring only (see `_core-adr-policy-010` Sections B and C). `_core` always applies globally.
+
+#### 03-activation-tag-syntax
+
+An activation tag is an inline code span placed immediately after a scope link on the same line, optionally separated by spaces or tabs, for example a link to `payments-ref/index.md` followed by `` `extends-only` ``. Allowed values are `extends-only` and `disabled`, lowercase only. A scope link line MUST NOT contain any other inline code: an unknown value, a second tag, or inline code placed elsewhere on the line is a lint error. A tag on the next line is not a tag. `_core` MUST NOT be tagged.
+
+#### 04-extends-only
+
+Policies of a scope tagged `extends-only` MUST be applied only through the `extends:` chain of an active scope (untagged, including read-only scopes, or `_local`). Reach is transitive: if A extends B and B extends C, both B and C apply to A. The root index position of a tagged scope never matters for conflict resolution; `extends:` precedence applies (see `_core-adr-policy-010.33-extends-content-precedence`). Skills, articles, research, and initiatives of the scope remain usable. Tools SHOULD warn when no active scope reaches an `extends-only` scope; reach only through a `disabled` scope does not count.
+
+#### 05-disabled
+
+All content of a scope tagged `disabled` MUST be ignored by agents: its policies, skills, articles, research, and initiatives are not applied, and nothing is inherited from it through `extends:` or `follows:`. The scope is still linted and MAY be edited. Skills of a disabled scope that are symlinked into `.agents/skills` (see `_core-adr-policy-018`) stay loaded by tools and MUST be removed by the consumer.
+
+#### 06-read-only-dependencies
+
+A scope MUST be treated as READ-ONLY when a scope it follows or extends, or the scope that defines one of its scope types (including parent types), is missing, disabled, or invalid, or when it is an external scope and its own `index.md` is invalid. Content in a READ-ONLY scope MUST NOT be added, changed, or removed. For local scopes, missing dependencies and invalid indexes remain lint errors (see `_core-adr-policy-010.32-extends-mandatory-presence`); a disabled dependency only makes the scope read-only. Tools MUST report each cause and how to fix it, citing this rule.
+
+#### 07-extends-only-field
+
+A scope author MAY declare `extends-only: true` or `extends-only: false` in the scope index frontmatter. Only unquoted lowercase `true` and `false` are valid. An invalid value is a lint error in a local scope; in an external scope it makes the scope read-only and the value is treated as absent. `extends-only` (field `true` or tag) on `_core`, `_local`, or a core-type scope is a lint error. Coherence: when the field is `true`, the root index link MUST carry the tag `extends-only` or `disabled`; when the field is `false` or absent, the consumer MAY add either tag (narrowing), and MUST NOT widen a scope beyond what the author declared. The field is a lint aid only.
+
+#### 08-agent-resolution
+
+Agents MUST decide activation only from the root index tags, never from the `extends-only` field:
+
+1. Skip scopes tagged `disabled`.
+2. Apply scopes tagged `extends-only` only through the `extends:` chain of an active scope.
+3. Apply all other listed scopes per rule 02.
+4. Never edit READ-ONLY scopes (rule 06).
+
+#### 09-root-index-ownership
+
+The root `index.md` is owned by the consumer. Packages that ship a root index SHOULD install it without overwriting an existing file, so activation tags survive reinstalls. When any activation tag is used, the root index MUST contain this exact legend line: "Scopes tagged `disabled` MUST be ignored; `extends-only` scopes apply only via extends (see _core-adr-policy-022)".
+
+## References
+
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) — root index and scope index frontmatter
+- [_core-adr-policy-010 - Scope governance](010-scope-governance.md) — `extends:` (Section D) and root index ordering (Section E)
+- [_core-adr-policy-011 - core scope type](011-core-scope-type.md) — core-type scopes and read-only companions

package/.xdrs/_core/adrs/principles/skills/.assets/prerequisites-gate.md

@@ -10,6 +10,7 @@ Read the confirmed scope's `index.md` frontmatter and perform ALL of the followi
 
 - **Follows scopes:** If the scope declares `follows:` entries (e.g., `follows: myarea-core, shared-standards`), verify that each listed scope directory exists in the workspace AND contains an accessible `index.md` (e.g., `.xdrs/[scope-name]/index.md`). If any listed scope is missing or unreadable, output: `FAIL — Cannot proceed: scope \`[scope-name]\` is listed in \`follows\` but its policies are not present in the workspace. Install it before authoring documents in this scope, as the governance constraints cannot be verified.`
 - **Extends scopes:** If the scope declares `extends:` entries, verify that each listed scope directory exists in the workspace AND contains an accessible `index.md`. If any listed scope is missing or unreadable, output: `FAIL — Cannot proceed: scope \`[scope-name]\` is listed in \`extends\` but its policies are not present in the workspace. Install it before authoring documents in this scope, as inherited policies cannot be verified.`
+- **Activation and read-only:** Read the root `index.md`. If a scope listed in `follows:` or `extends:`, or the scope defining one of its scope types, is tagged `disabled`, output: `FAIL — Cannot proceed: scope \`[scope-name]\` depends on disabled scope \`[dependency]\` and is READ-ONLY (see _core-adr-policy-022.06-read-only-dependencies). Enable it in the root index or remove the reference.`
 - **Local meta-policies:** Scan the target scope's `[type]/principles/` directories for all files whose filename title starts with `core` (i.e., `NNN-core.md` or `NNN-core-{qualifier}.md`), excluding scope-type definition files. If any are found but cannot be read, output: `FAIL — Cannot proceed: local meta-policy \`[filename]\` exists in scope \`[scope-name]\` but could not be read. Without it, the [DOCUMENT TYPE] cannot be authored in full compliance with the scope's governance.` Zero matches is valid.
 - **Scope-type:** Read the scope's `scope-type` from its `index.md`. Normalise the value to a list: split on commas and trim whitespace (`scope-type: typeA, typeB` becomes `[typeA, typeB]`). For **each** type in the list, search the `[type]/principles/` directories of all `core`-type scopes in the workspace for a file whose name ends with `{scope-type}-scope-type.md`. If the scope declares any `scope-type` elements but no matching file is found for ANY of them, output: `FAIL — Cannot proceed: scope \`[scope-name]\` declares \`scope-type: [scope-type]\` but no \`[scope-type]-scope-type.md\` policy exists in any \`core\`-type scope in the workspace. The scope is READ-ONLY; install the scope-type governance before authoring documents in this scope.`
 - **Rationale:** Authoring a document without all mandatory governance layers loaded risks producing content that silently violates scope policies. Every governance layer MUST be present before writing begins.

package/.xdrs/_core/adrs/principles/skills/.assets/scope-placement.md

@@ -25,7 +25,7 @@ Determine the appropriate scope-type by matching the content being authored to o
 
 ## Step C — Enumerate and Rank Workspace Scopes
 
-1. Read `.xdrs/index.md` to list all declared scopes.
+1. Read `.xdrs/index.md` to list all declared scopes. Exclude scopes tagged `disabled` or `extends-only` (see `_core-adr-policy-022`) unless the user names them explicitly.
 2. For each scope whose `scope-type` matches the type identified in Step A or B (match if ANY of a scope's declared types fit), read its `index.md` and assess the following signals, in order of weight:
    - **Primary**: Does `apply-to` or `description` describe a domain that covers this content?
    - **Secondary**: Does the scope's `follows:` chain declare a governance relationship relevant to this content area?

package/.xdrs/_core/adrs/principles/skills/compile-scope/SKILL.md

@@ -203,3 +203,8 @@ After writing each policy:
 - **Mistake:** Reading or citing content under `.assets/sources/` as if it were an authoritative policy, or adding a markdown link to it from another document.
   **Why it happens:** The raw source content is readily available and often more detailed than the compiled policy.
   **Instead:** Treat only compiled policies as authoritative per `_core-adr-policy-019` rule 14; source content exists solely to support fetch/diff/recompilation, and linking to it is also forbidden mechanically by lint.
+
+## References
+
+- [_core-adr-policy-019 - Compiled scope type](../../019-compiled-scope-type.md)
+- [_core-adr-policy-008 - Policy structured standards](../../008-policy-structured-standards.md)

package/.xdrs/_core/adrs/principles/skills/review/SKILL.md

@@ -66,6 +66,7 @@ Performs a structured review of code changes or files against the Policies in th
 2. **Prerequisites gate — MUST complete before any review work:** For each scope containing files under review, read its `index.md` frontmatter and check for `follows` and `extends` fields. `_core` Policies always apply to all scopes. Perform ALL of the following checks before proceeding; if ANY check fails, output a FAIL result immediately and do not continue the review:
    - **Follows scopes:** If the scope declares `follows:` entries (e.g., `follows: myarea-core, shared-standards`), verify that each listed scope directory exists in the workspace AND contains an accessible `index.md` (e.g., `.xdrs/[scope-name]/index.md`). If any listed scope is missing or its index is unreadable, output: `FAIL — Review cannot proceed: scope \`[scope-name]\` is listed in \`follows\` but its policies are not present in the workspace. Install it before reviewing, as compliance with its governance cannot be verified.`
    - **Extends scopes:** If the scope declares `extends:` entries, verify that each listed scope directory exists in the workspace AND contains an accessible `index.md`. If any listed scope is missing or its index is unreadable, output: `FAIL — Review cannot proceed: scope \`[scope-name]\` is listed in \`extends\` but its policies are not present in the workspace. Install it before reviewing, as inherited policies cannot be verified.`
+   - **Activation tags:** Read the root `index.md`. Do not apply policies of scopes tagged `disabled`, and apply scopes tagged `extends-only` only through the `extends:` chain of the reviewed scope (see `_core-adr-policy-022.08-agent-resolution`). If a `follows:`/`extends:` dependency or a scope-type-defining scope is tagged `disabled`, the reviewed scope is READ-ONLY (`_core-adr-policy-022.06-read-only-dependencies`): report it and do not propose fixes inside it.
    - **Local meta-policies:** Scan the scope's `[type]/principles/` directories for all files whose filename title starts with `core` (i.e., `NNN-core.md` or `NNN-core-{qualifier}.md`), excluding scope-type definition files. If any are found but cannot be read, output: `FAIL — Review cannot proceed: local meta-policy \`[filename]\` exists in scope \`[scope-name]\` but could not be read. Without it, full compliance cannot be verified.` Zero matches is valid — absence of local meta-policies is not an error.
    - **Rationale:** A review that silently omits mandatory governance layers produces false PASS results. Every governance layer declared by the scope MUST be loaded and applied; if any layer is inaccessible, the review result is unreliable and MUST be rejected.
    - **Scope-type:** Read the scope's `scope-type` from its `index.md`. Normalise the value to a list: split on commas and trim whitespace (`scope-type: typeA, typeB` becomes `[typeA, typeB]`). For **each** type in the list, search the `[type]/principles/` directories of all `core`-type scopes in the workspace for a file whose name ends with `{scope-type}-scope-type.md`. If the scope declares any `scope-type` elements but no matching file is found for ANY of them, output: `FAIL — Review cannot proceed: scope \`[scope-name]\` declares \`scope-type: [scope-type]\` but no \`[scope-type]-scope-type.md\` policy exists in any \`core\`-type scope in the workspace. The scope is READ-ONLY; install the scope-type governance before reviewing.`

package/.xdrs/_core/adrs/principles/skills/write-article/SKILL.md

@@ -94,7 +94,7 @@ If the article spans more than one subject, place it in `principles`.
 
 ### Phase 4: Research Policies and Skills to Synthesize
 
-1. Read all Policies, Research documents, and Skills relevant to the article topic across all scopes listed in the Policy root `index.md`.
+1. Read all Policies, Research documents, and Skills relevant to the article topic across all scopes listed in the Policy root `index.md`, honouring activation tags (skip `disabled` scopes; use `extends-only` scope policies only through an extending scope, see `_core-adr-policy-022.08-agent-resolution`).
 2. Evaluate Policy metadata before synthesizing guidance. All documents present in the collection are considered active. Use `valid-from:` to determine the convergence date for adoption, `apply-to:` to determine whether the decision fits the audience or context being discussed, and the decision text itself for any remaining applicability boundaries.
 3. Identify the key points a reader needs to understand the topic end-to-end.
 4. Collect Policy IDs and file paths for cross-references. Never copy decision text verbatim; link to it.

package/.xdrs/_core/adrs/principles/skills/write-initiative/SKILL.md

@@ -84,7 +84,7 @@ Consult `001-xdrs-standards` while making each choice in this phase. The summari
 
 ### Phase 4: Research Related Artifacts
 
-1. Read all Policies, Research documents, Skills, and existing Initiatives relevant to the initiative topic across all scopes listed in the Policy root `index.md`.
+1. Read all Policies, Research documents, Skills, and existing Initiatives relevant to the initiative topic across all scopes listed in the Policy root `index.md`, honouring activation tags (skip `disabled` scopes; use `extends-only` scope policies only through an extending scope, see `_core-adr-policy-022.08-agent-resolution`).
 2. Evaluate Policy metadata before treating any decision as current context. All documents present in the collection are considered active. `valid-from:` determines the convergence date for adoption, `apply-to:` determines whether the decision fits the intended context, and the decision text defines any remaining boundaries.
 3. Identify Decisions that this initiative implements, Research that informs the planning, and any existing Initiatives that overlap.
 4. Collect artifact IDs and file paths for cross-references.

package/.xdrs/_core/adrs/principles/skills/write-policy/SKILL.md

@@ -50,7 +50,7 @@ Guides the creation of a well-structured Policy by following the standards in `_
 
 ### Phase 1: Understand the Decision
 
-1. Read the XDRS root `index.md` (default: `.xdrs/index.md`) to discover all active scopes and their canonical indexes.
+1. Read the XDRS root `index.md` (default: `.xdrs/index.md`) to discover all active scopes and their canonical indexes. Skip scopes tagged `disabled`; scopes tagged `extends-only` apply only through an extending scope (see `_core-adr-policy-022.08-agent-resolution`).
 2. Read `.xdrs/_core/adrs/principles/001-xdrs-standards.md` in full to internalize structure rules, mandatory language, and the XDRS framework elements.
 3. Read `.xdrs/_core/adrs/principles/002-policy-standards.md` in full to internalize the Policy template and document writing rules.
 4. Treat `001-xdrs-standards` as the canonical source for all core XDRS element definitions (type, scope, subject, numbering, placement). Treat `002-policy-standards` as the canonical source for how to write and structure the document itself.
@@ -87,7 +87,7 @@ Choose a title that clearly states the question this Policy answers, not the ans
 
 ### Phase 4: Research Related Policies
 
-1. Read all existing Policies relevant to the topic across all scopes listed in the Policy root `index.md`. **Additionally**, if the target scope declares an `extends:` field in its `index.md`, resolve its full `extends:` chain depth-first (see `_core-adr-policy-010` rule 33) and treat all policy documents from those extended scopes as if they were authored in the target scope — they MUST be included in the research and conflict check just like policies written directly in the scope.
+1. Read all existing Policies relevant to the topic across all active scopes listed in the Policy root `index.md` (not tagged `disabled` or `extends-only`). **Additionally**, if the target scope declares an `extends:` field in its `index.md`, resolve its full `extends:` chain depth-first (see `_core-adr-policy-010` rule 33) and treat all policy documents from those extended scopes as if they were authored in the target scope — they MUST be included in the research and conflict check just like policies written directly in the scope.
 2. Evaluate Policy metadata before treating any decision as a current constraint. All documents present in the collection are considered active. `valid-from:` determines the convergence date for adoption, `apply-to:` determines whether it fits the current topic, and the decision text defines any remaining boundaries. Treat out-of-window or out-of-scope Policies as background only when assessing overlaps and conflicts.
 3. Identify decisions that already address the topic (full or partial overlap).
 4. Note decisions that might conflict with the intended outcome.
@@ -184,12 +184,12 @@ Check every item before finalizing:
 1. **Length**: Is it under 1300 words? Trim verbose explanations. Move detailed skills to a separate file and link.
 2. **Frontmatter**: Are `apply-to:` and `valid-from:` both present? `apply-to:` must describe the applicable context (use `All scopes` when broadly applicable). `valid-from:` must be set (use today's date if the user did not specify one).
 3. **Normative language**: Does every normative requirement in the Details and Decision Outcome sections use uppercase BCP 14 keywords per `_core-adr-policy-001`? Replace any lowercase `must`/`should`/`may` that express requirements, prohibitions, or permissions with MUST/MUST NOT, SHOULD/SHOULD NOT, or MAY/OPTIONAL respectively. Lowercase forms are only acceptable in Context sections, question statements, or when used with their ordinary English meaning.
-3. **Originality**: Does every sentence add value that cannot be found in a generic web search? Remove obvious advice. Keep only the project-specific decision.
-4. **Clarity**: Is the chosen option unambiguous? Is the "why" clear in one reading?
-5. **Redundancy**: Is the Policy the primary source for the decision itself, with related documents linked instead of duplicated wherever possible?
-6. **Conflicts section**: Is it present and filled if Phase 3 found any conflicts?
-7. **Index entries**: Will the new Policy be added to `[scope]/[type]/index.md` and the Policy root `index.md`?
-8. **Meta-policy compliance**: Run the shared module at `.xdrs/_core/adrs/principles/skills/.assets/meta-policy-compliance.md`. Substitute `[DOCUMENT]` with `policy`.
+4. **Originality**: Does every sentence add value that cannot be found in a generic web search? Remove obvious advice. Keep only the project-specific decision.
+5. **Clarity**: Is the chosen option unambiguous? Is the "why" clear in one reading?
+6. **Redundancy**: Is the Policy the primary source for the decision itself, with related documents linked instead of duplicated wherever possible?
+7. **Conflicts section**: Is it present and filled if Phase 3 found any conflicts?
+8. **Index entries**: Will the new Policy be added to `[scope]/[type]/index.md` and the Policy root `index.md`?
+9. **Meta-policy compliance**: Run the shared module at `.xdrs/_core/adrs/principles/skills/.assets/meta-policy-compliance.md`. Substitute `[DOCUMENT]` with `policy`.
 
 If any check fails, revise and re-run this phase before proceeding.
 
@@ -197,7 +197,7 @@ If any check fails, revise and re-run this phase before proceeding.
 
 1. Create the Policy file at `[xdrs-root]/[scope]/[type]/[subject]/[number]-[short-title].md` (default root: `.xdrs/`).
 2. Add an entry to `[xdrs-root]/[scope]/[type]/index.md` (create the file if it does not exist).
-3. Add or verify the scope entry in the Policy root `index.md`.
+3. Add or verify the scope entry in the Policy root `index.md` (exactly one link per scope; when the scope index declares `extends-only: true`, append the tag `` `extends-only` `` right after the link and make sure the legend line is present, see `_core-adr-policy-022`).
 4. If significant research was produced or already exists, link it from the Policy `## Considered Options` section.
 5. If concise rules, examples, or do/don't bullets help readers apply the decision correctly, add them inside `### Details` without turning the Policy into a long procedure.
 6. Evaluate whether the scope index at `[xdrs-root]/[scope]/index.md` should be updated to reflect the new content. If the scope index does not exist, create it following article standards and the scope index rules in `_core-adr-policy-001`.

package/.xdrs/_core/adrs/principles/skills/write-research/SKILL.md

@@ -86,7 +86,7 @@ Consult `001-xdrs-standards` while making each choice in this phase. The summari
 
 ### Phase 3: Research Existing Artifacts
 
-1. Read relevant Policies across all scopes listed in the Policy root `index.md`.
+1. Read relevant Policies across all scopes listed in the Policy root `index.md`, honouring activation tags (skip `disabled` scopes; use `extends-only` scope policies only through an extending scope, see `_core-adr-policy-022.08-agent-resolution`).
 2. Evaluate Policy metadata before treating any decision as current context. All documents present in the collection are considered active. `valid-from:` determines the convergence date for adoption, `apply-to:` determines whether the decision fits the intended task context, and the decision text defines any remaining boundaries. Keep out-of-window or out-of-scope Policies as background only.
 3. Read existing research documents in the same or overlapping subjects to avoid duplicating the same study.
 4. Read related skills or articles if they contain context, implementation limits, or terminology that must be reflected.

package/.xdrs/_core/index.md

@@ -57,7 +57,7 @@ Slide presentations that support XDRS documents follow [_core-adr-policy-009](ad
 
 ### Scope types
 
-Every XDRS scope declares a `scope-type` in its `index.md` YAML frontmatter. A `scope-type` value is valid when a `{scope-type}-scope-type` policy exists in the `principles` subject of any `core`-type scope in the workspace. Multiple types MAY be declared using a comma-separated list (e.g., `scope-type: compiled, internal-docs`); each element is validated independently — see [_core-adr-policy-010](adrs/principles/010-scope-governance.md) rules 06 and 07. The five built-in scope types are defined by [_core-adr-policy-011](adrs/principles/011-core-scope-type.md) (`core`), [_core-adr-policy-012](adrs/principles/012-reference-scope-type.md) (`reference`), [_core-adr-policy-013](adrs/principles/013-platform-scope-type.md) (`platform`), [_core-adr-policy-014](adrs/principles/014-standard-scope-type.md) (`standard`), and [_core-adr-policy-015](adrs/principles/015-local-scope-type.md) (`_local`). Custom scope types can be defined following [_core-adr-policy-010](adrs/principles/010-scope-governance.md). The recommended root index ordering is `core → reference → platform → standard → _local`.
+Every XDRS scope declares a `scope-type` in its `index.md` YAML frontmatter. A `scope-type` value is valid when a `{scope-type}-scope-type` policy exists in the `principles` subject of any `core`-type scope in the workspace. Multiple types MAY be declared using a comma-separated list (e.g., `scope-type: compiled, internal-docs`); each element is validated independently — see [_core-adr-policy-010](adrs/principles/010-scope-governance.md) rules 06 and 07. The six built-in scope types are defined by [_core-adr-policy-011](adrs/principles/011-core-scope-type.md) (`core`), [_core-adr-policy-012](adrs/principles/012-reference-scope-type.md) (`reference`), [_core-adr-policy-013](adrs/principles/013-platform-scope-type.md) (`platform`), [_core-adr-policy-014](adrs/principles/014-standard-scope-type.md) (`standard`), [_core-adr-policy-015](adrs/principles/015-local-scope-type.md) (`_local`), and [_core-adr-policy-019](adrs/principles/019-compiled-scope-type.md) (`compiled`). Custom scope types can be defined following [_core-adr-policy-010](adrs/principles/010-scope-governance.md). The recommended root index ordering is `core → reference → platform → standard → _local`.
 
 ### Available skills
 

package/.xdrs/index.md

@@ -8,6 +8,8 @@ XDRS scopes listed last override the ones listed first
 
 Default ordering by scope type: `core → reference → platform → standard → _local`
 
+Scopes tagged `disabled` MUST be ignored; `extends-only` scopes apply only via extends (see _core-adr-policy-022)
+
 ### _core
 
 Defines how XDRS framework work

package/AGENTS.md

@@ -18,7 +18,7 @@ This rule has NO exceptions. Simple questions ("which command?", "what pattern?"
    - You MUST search and follow Policies for architecture, engineering and business in the Policy root index (default: [.xdrs/index.md](.xdrs/index.md)) during Informational, Q&A questions, design, plan, implementation, test and review steps etc. This is the source of truth for this agent.
 
 2. **Verify all work with build, tests and linting before completion**
-   - Always run build, lint-fix and test at the end of the implementation when changing code
+   - Always run build, lint and test at the end of the implementation when changing code
    - Fix any issues
 
 3. **Verify if implementation complies with Policies from XDRS**

package/README.md

@@ -124,6 +124,24 @@ Custom scope types can be introduced by adding a `{type}-scope-type` policy to a
 
 See [examples/typed-scope](examples/typed-scope) for a full working example covering all five scope types and a custom `business-area` type.
 
+### Scope activation
+
+Every installed scope MUST be linked exactly once in `.xdrs/index.md`, and its non-meta policies apply globally by default. Consumers narrow that with an activation tag placed right after the link:
+
+```markdown
+Scopes tagged `disabled` MUST be ignored; `extends-only` scopes apply only via extends (see _core-adr-policy-022)
+
+[View scope ecomm-ref-payments](ecomm-ref-payments/index.md) `extends-only`
+[View scope legacy-standards](legacy-standards/index.md) `disabled`
+```
+
+- `extends-only`: the scope's policies apply only through scopes that list it in `extends:`.
+- `disabled`: the scope is ignored; scopes that follow, extend or take their type from it become READ-ONLY.
+- Scope authors declare `extends-only: true` in the scope `index.md` frontmatter when the scope is meant only to be extended; lint requires the root index tag to match.
+- The root index belongs to the consumer: packages ship it unmanaged so tags survive reinstalls.
+
+See [_core-adr-policy-022](.xdrs/_core/adrs/principles/022-scope-activation.md), [_core-adr-policy-010](.xdrs/_core/adrs/principles/010-scope-governance.md) and [_core-adr-policy-011](.xdrs/_core/adrs/principles/011-core-scope-type.md).
+
 ### Subject grouping
 
 Within each scope and type, decisions are grouped by subject (e.g. `application`, `data`, `platform` for ADRs; `product`, `finance` for BDRs). This keeps related decisions together, improves human navigation, and allows AI agents to narrow their search to the relevant subject folder before reading individual records.
@@ -242,6 +260,7 @@ The `lint` command reads `./.xdrs/**` from the given workspace path and checks c
 - initiative `Expected end date:` field presence and ISO date format
 - canonical index presence and link consistency
 - root index coverage for all discovered canonical indexes
+- root index completeness: every scope folder linked exactly once, activation tags (`extends-only`, `disabled`) valid, coherent with the scope's `extends-only` field, and explained by the legend line when used
 - Policy metadata section placement and `valid-from` / `apply-to` field format
 - local markdown links between Policy documents, skills, articles, researches, and initiatives (excluding fenced code blocks)
 - local image and `.assets/` links resolving inside the sibling `.assets/` folder for each document