xdrs-core 0.42.0 → 0.43.1

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

@@ -6,7 +6,7 @@ Decisions about how the XDRS framework itself works: structure, standards, docum
 
 Foundational standards, principles, and guidelines.
 
-- [_core-adr-policy-001](principles/001-xdrs-core.md) - **XDRS core** — Types, scopes, subjects, folder structure, and indexes for the XDRS framework
+- [_core-adr-policy-001](principles/001-xdrs-standards.md) - **XDRS standards** — Types, scopes, subjects, folder structure, and indexes for the XDRS framework
 - [_core-adr-policy-002](principles/002-policy-standards.md) - **Policy standards** — How to write individual Policy documents: template, metadata, ID, lifecycle rules
 - [_core-adr-policy-003](principles/003-skill-standards.md) - **Skill standards** — How to author and organize reusable skill packages within XDRS projects
 - [_core-adr-policy-004](principles/004-article-standards.md) - **Article standards** — How to write synthetic views combining Policies, research, and skills

package/.xdrs/_core/adrs/principles/{001-xdrs-core.md → 001-xdrs-standards.md}

@@ -1,11 +1,11 @@
 ---
-name: _core-adr-policy-001-xdrs-core
+name: _core-adr-policy-001-xdrs-standards
 description: Defines the core XDRS framework including types (ADR, BDR, EDR), folder structure, scopes, subjects, and index requirements. Use when structuring or navigating policies.
 apply-to: All XDRS scopes and document types
 valid-from: 2025-01-01
 ---
 
-# _core-adr-policy-001: XDRs core
+# _core-adr-policy-001: XDRS standards
 
 ## Context and Problem Statement
 
@@ -75,7 +75,7 @@ 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. 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 05 and 05b for the full multi-type grammar. Custom scope-type names MUST NOT start with `_`. The five 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)
@@ -86,7 +86,7 @@ ADR and EDR share the same six technical subject names (see [`_core-adr-policy-0
   - **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. MUST match a `{scope-type}-scope-type` policy in any `core`-type scope's `principles/` directory. See `_core-adr-policy-010` for the full governance convention 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 05 and 05b for the full multi-type grammar and `_core-adr-policy-011`, `012`–`015` 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.

package/.xdrs/_core/adrs/principles/002-policy-standards.md

@@ -76,7 +76,7 @@ Policy documents are the authoritative source of truth for their scope, type, an
 - Each policy rule and rule block MUST be unambiguous: it MUST be possible to clearly follow, check, and discuss it without requiring additional interpretation.
 - When the decision defines strong policies or rules that SHOULD be stated explicitly as stable rule blocks, or when other documents, skills, or agents need to cite those rules individually by identifier, the Policy MUST follow the extension [_core-adr-policy-008 - Policy structured standards](008-policy-structured-standards.md) instead of using plain bullet lists for those rules.
 - Conflict handling applies to Policy documents:
-  - For cross-scope overrides, document the decision conflict in the Policy `## Conflicts` section of the Policy that overrides another scope.
+  - For cross-scope and cross-scope-type overrides, document the decision conflict in the Policy `## Conflicts` section of the Policy that overrides another scope or scope-type policy. Local meta-policies (`NNN-core.md` and companion files) and scope-type definition policies MAY include a `## Conflicts` section for this purpose. See `_core-adr-policy-010` rule 19-conflict-declarations for the required structure.
   - **Within-scope conflicts:** Policies within the same type+scope MUST NOT conflict. If two Policies appear to conflict, one SHOULD be updated, removed, or the conflict resolved through a new Policy.
 - When research exists for a decision, the Policy SHOULD mention the related research documents after the `## Considered Options` list.
 - MUST NOT use emojis in contents.
@@ -168,7 +168,7 @@ Question: In the end, state explicitly the question that needs to be answered. E
 
 ## References
 
-- [_core-adr-policy-001 - Policies core](001-xdrs-core.md) - Framework elements: types, scopes, subjects, folder structure
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) - Framework elements: types, scopes, subjects, folder structure
 - [001-review skill](skills/001-review/SKILL.md) - Skill for reviewing code changes against Policies
 - [002-write-policy skill](skills/002-write-policy/SKILL.md) - Skill for creating a new Policy following this standard
 - [_core-adr-policy-003 - Skill standards](003-skill-standards.md)

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

@@ -143,6 +143,6 @@ skills-ref validate .xdrs/[scope]/[type]/[subject]/skills/[number]-[skill-name]
 - [agentskills specification](https://agentskills.io/specification)
 - [agentskills/agentskills repository](https://github.com/agentskills/agentskills)
 - [skills-ref validation library](https://github.com/agentskills/agentskills/tree/main/skills-ref)
-- [_core-adr-policy-001 - XDRS core](001-xdrs-core.md)
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md)
 - [_core-adr-policy-004 - Article standards](004-article-standards.md)
 - [_core-adr-policy-006 - Research standards](006-research-standards.md)

package/.xdrs/_core/adrs/principles/004-article-standards.md

@@ -99,7 +99,7 @@ when referencing an information from those documents.]
 
 ## References
 
-- [_core-adr-policy-001 - Policies core](001-xdrs-core.md)
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md)
 - [_core-adr-policy-003 - Skill standards](003-skill-standards.md)
 - [_core-adr-policy-006 - Research standards](006-research-standards.md)
 - [004-write-article skill](skills/004-write-article/SKILL.md) - Step-by-step instructions for creating a new article

package/.xdrs/_core/adrs/principles/006-research-standards.md

@@ -132,7 +132,7 @@ Prefer tables, bullets, or ASCII art for simple comparisons. Use external figure
 
 ## References
 
-- [_core-adr-policy-001 - XDRS core](001-xdrs-core.md)
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md)
 - [_core-adr-policy-003 - Skill standards](003-skill-standards.md)
 - [_core-adr-policy-004 - Article standards](004-article-standards.md)
 - [005-write-research skill](skills/005-write-research/SKILL.md) - Step-by-step instructions for creating a research document

package/.xdrs/_core/adrs/principles/007-plan-standards.md

@@ -134,7 +134,7 @@ Due date: YYYY-MM-DD
 
 ## References
 
-- [_core-adr-policy-001 - Policies core](001-xdrs-core.md) - Framework elements: types, scopes, subjects, folder structure
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) - Framework elements: types, scopes, subjects, folder structure
 - [_core-adr-policy-004 - Article standards](004-article-standards.md) - Companion artifact type for synthetic views
 - [_core-adr-policy-006 - Research standards](006-research-standards.md) - Companion artifact type for exploratory evidence
 - [006-write-plan skill](skills/006-write-plan/SKILL.md) - Step-by-step instructions for creating a new plan

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

@@ -70,5 +70,5 @@ Examples:
 
 ## References
 
-- [_core-adr-policy-001 - XDRS core](001-xdrs-core.md)
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md)
 - [_core-adr-policy-002 - Policy standards](002-policy-standards.md)

package/.xdrs/_core/adrs/principles/009-presentation-standards.md

@@ -47,7 +47,7 @@ Presentations are Markdown files in Marp format, stored in the `.assets/` folder
 
 ## References
 
-- [_core-adr-policy-001 - XDRs core](001-xdrs-core.md) - Framework structure and `.assets/` placement rules
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) - Framework structure and `.assets/` placement rules
 - [_core-adr-policy-002 - Policy standards](002-policy-standards.md) - Policy document writing rules
 - [_core-adr-policy-004 - Article standards](004-article-standards.md) - Article standards for multi-document views
 - [007-write-presentation skill](skills/007-write-presentation/SKILL.md) - Skill for creating slide presentations

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

@@ -19,34 +19,38 @@ Without a clear definition of how these mechanisms are authored and how they int
 
 ## Decision Outcome
 
-**Define scope types as policies, scope-local standards as named policies, and a clear precedence chain for governance application.**
+**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 are optional policies named `{scope-name}-core`. Tools and agents apply all applicable standards in a defined order.
+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.
 
-> **Choosing between a scope-local policy and a `-core` sibling scope**: use a `{scope-name}-core` policy (Section B) when the standards apply only to one scope and do not need to be shared. Use a separate `-core` sibling scope (see `_core-adr-policy-011`) when the meta governance needs to be shared with or distributed to other teams, or when it governs a family of scopes sharing the same prefix.
+> **Choosing between a local meta-policy and a `-core` sibling scope**: use a local meta-policy (Section B) when the standards apply only to one scope and do not need to be shared. Use a separate `-core` sibling scope (see `_core-adr-policy-011`) when the meta governance needs to be shared with or distributed to other teams, or when it governs a family of scopes sharing the same prefix.
 
 ### Details
 
-#### Section A — Scope-type definition standards
+**Section A — Scope-type definition standards**
 
-##### 01-def-must-live-in-core-scope
+#### 01-def-must-live-in-core-scope
 
 A scope-type definition policy MUST be placed in a `core`-type scope (i.e., a scope whose `index.md` declares `scope-type: core`).
 
-##### 02-def-naming
+#### 02-def-naming
 
 The policy `name` field MUST end with `{scope-type}-scope-type` (e.g., `security-scope-type`, `business-area-scope-type`). The policy file MUST follow the standard numbered filename convention `NNN-{scope-type}-scope-type.md` and MUST be placed in the `principles` subject of any decision type folder within the `core`-type scope (e.g., `_core/adrs/principles/011-core-scope-type.md`).
 
 Note: this naming applies to the **policy name** only, not to any scope directory name. It is distinct from the `-core` scope-name suffix convention defined in `_core-adr-policy-011`.
 
-##### 03-def-required-content
+#### 02b-def-companion-files
+
+A scope-type definition MAY be split across multiple policy files. The primary file MUST follow rule 02 above. Each additional companion file MUST be named `NNN-{scope-type}-scope-type-{qualifier}.md` (e.g., `012-business-area-scope-type-writing-style.md`), where `{qualifier}` is a short lowercase kebab-case descriptor. All companion files MUST be placed in the **same** `[type]/principles/` directory as the primary file within the same scope. A companion file MUST NOT exist without a corresponding primary file in the same scope and type folder. Tools and agents MUST apply all companion files for a scope-type as additional mandatory conventions alongside the primary.
+
+#### 03-def-required-content
 
 A scope-type definition policy MUST define:
 
 - The scope type name (the value that instances declare in their `scope-type:` field).
 - When to use this scope type and what kinds of scopes SHOULD declare it.
 
-##### 04-def-preferred-content
+#### 04-def-preferred-content
 
 A scope-type definition policy SHOULD define:
 
@@ -55,88 +59,133 @@ A scope-type definition policy SHOULD define:
 - What content SHOULD NOT be placed in scopes of this type.
 - Special instructions on how to organise or write content in scopes of this type.
 
-##### 05-def-instance-declaration
+#### 05-def-instance-declaration
+
+A scope that is an instance of one or more scope types MUST declare `scope-type` in its `index.md` frontmatter. Two formats are valid:
+
+- **Single type**: `scope-type: business-area`
+- **Multiple types** (comma-separated): `scope-type: compiled, internal-docs, auditable`
+
+When multiple scope types are declared, all rules from all declared types (and their parent chains) apply simultaneously to documents in the scope. A document MUST satisfy the requirements of every applicable type. When two types define a rule with the same rule number but different content, the conflict MUST be declared in a `## Conflicts` section of the overriding scope-type policy (see Section C rule 19-conflict-declarations). An undeclared conflict makes a document impossible to satisfy and MUST be resolved before authoring begins.
+
+#### 05b-def-multi-type-validation
 
-A scope that is an instance of a custom scope type MUST declare `scope-type: {scope-type}` in its `index.md` frontmatter (e.g., `scope-type: business-area`).
+A comma-separated `scope-type` list MUST NOT have empty elements. Each element MUST satisfy the same constraints as a single `scope-type` value (rules 06 and 08). Duplicate values within the same list are NOT allowed.
 
-##### 06-def-no-underscore-prefix
+#### 06-def-no-underscore-prefix
 
 Custom scope-type names MUST NOT start with `_`. The `_` prefix is reserved for built-in scope types defined in `_core` (currently only `_local`).
 
-##### 07-def-parent-scope-type
+#### 07-def-parent-scope-type
+
+A scope-type definition policy MAY declare a parent scope type by including a rule titled `NN-parent-scope-type` in its `### Details` section. The body of that rule MUST reference the parent scope-type name in backticks (e.g., "Instances of this scope type inherit all rules from the `standard` scope type."). This rule MUST appear only in the **primary** file (rule 02), not in a companion file (rule 02b). Tools and agents MUST resolve the full parent chain transitively. Child scope-type standards override parent standards on any conflict.
+
+#### 08-def-valid-iff-policy-exists
+
+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` (single or array) but any corresponding `{scope-type}-scope-type.md` policy is absent from the workspace, the scope MUST be treated as READ-ONLY by all tools and agents: content in it MUST NOT be added, changed, or removed, and its content MUST NOT be reviewed. Tools and agents MUST surface the read-only status to the user and MUST NOT propose or apply any changes until the scope-type governance is installed.
+
+#### 08b-def-scope-type-must-be-structured
 
-A scope-type definition policy MAY declare a parent scope type by including a rule titled `NN-parent-scope-type` in its `### Details` section. The body of that rule MUST reference the parent scope-type name in backticks (e.g., "Instances of this scope type inherit all rules from the `standard` scope type."). Tools and agents MUST resolve the full parent chain transitively. Child scope-type standards override parent standards on any conflict.
+All `{scope-type}-scope-type.md` policies (primary and companion files) MUST follow the structured format defined in `_core-adr-policy-008`: the policy MUST contain a `### Details` section and at least one `#### NN-rulename` rule block within it. This makes individual scope-type rules machine-readable, individually citable, and detectable for conflict analysis. Tools MUST enforce this and report an error using code `_core-adr-policy-010-scope-governance.08b-def-scope-type-must-be-structured`.
 
-##### 08-def-valid-iff-policy-exists
+#### 08c-def-core-scope-policies-must-be-structured
 
-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.
+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 08b). 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.08c-def-core-scope-policies-must-be-structured`.
 
 ---
 
-#### Section B — Scope-local standards
+**Section B — Local meta-policies**
 
-##### 09-local-naming
+#### 09-local-naming
 
-When a scope wishes to define local content standards specific to itself, it MUST do so in a policy whose `name` field ends with `{scope-name}-core` (e.g., scope `my-team` → policy name ending in `my-team-core`).
+The word `core` as a hyphen-delimited segment in a policy filename title is reserved for local meta-policies. A local meta-policy is identified by its filename title starting with `core`: either `NNN-core.md` (primary, no qualifier) or `NNN-core-{qualifier}.md` (companion, where `{qualifier}` is a short lowercase kebab-case descriptor). A policy filename title MUST NOT use `core` as a word segment unless it is a valid local meta-policy (see rule 10). Scope-type definition files (`NNN-{scope-type}-scope-type.md`) are exempt from this restriction even when their title begins with `core`.
 
-Note: this is a **policy name suffix** inside a scope, not a scope directory name. It is distinct from the `-core` scope-name suffix convention in `_core-adr-policy-011`, which refers to a sibling scope directory.
+#### 10-local-placement
 
-##### 10-local-placement
+Local meta-policy files MUST be placed in the `principles` subject of any type folder within the scope they govern (e.g., `my-team/adrs/principles/001-core.md`). They apply implicitly to that scope — no declaration in `index.md` is required. Local meta-policies MUST NOT be placed in any other subject folder; a file whose title starts with `core` in a non-`principles` subject is a lint error.
 
-A scope-local standards policy MUST be placed in the `principles` subject of any type folder within the same scope (e.g., `my-team/adrs/principles/001-my-team-core.md`). Only one such policy per scope is allowed.
+#### 10b-local-primary-required
 
-##### 11-local-optional
+A companion local meta-policy (`NNN-core-{qualifier}.md`) MUST NOT exist in a type folder unless a primary local meta-policy (`NNN-core.md`) also exists in the **same** type folder. Tools MUST enforce this constraint.
 
-Creating a scope-local standards policy is optional. It SHOULD be created when a scope has specific structural, authoring, or content constraints that differ from `_core` defaults or the scope's declared scope-type standards.
+#### 10c-local-unique-qualifier
 
-##### 12-local-content
+Each qualifier (including the blank qualifier of the primary) MUST be unique across all type folders within the same scope. For example, a scope MUST NOT have both `adrs/principles/001-core.md` and `bdrs/principles/001-core.md` — the blank qualifier would appear twice.
 
-A scope-local standards policy SHOULD define the same kinds of instructions as a scope-type definition policy (rules 03–04 above): naming conventions for content in the scope, allowed content, forbidden content, and organisation rules. These instructions apply only to this one scope.
+#### 11-local-optional
 
-##### 13-local-mandatory-when-present
+Creating a local meta-policy is optional. It SHOULD be created when a scope has specific structural, authoring, or content constraints that differ from `_core` defaults or the scope's declared scope-type standards.
 
-When a scope-local standards policy exists, tools and agents MUST apply its instructions as mandatory conventions for any content addition or update within that scope.
+#### 12-local-content
+
+A local meta-policy SHOULD define the same kinds of instructions as a scope-type definition policy (rules 03–04 above): naming conventions for content in the scope, allowed content, forbidden content, and organisation rules. These instructions apply only to policy documents authored in this one scope; they do not govern non-policy artifacts (skills, articles, plans, research). Local meta-policies and their companion files MAY include a `## Conflicts` section to declare that one of their rules overrides a conflicting rule from a scope-type policy or `follows:` scope policy (see Section C rule 19-conflict-declarations).
+
+#### 12b-local-must-be-structured
+
+All local meta-policy files (`NNN-core.md` and `NNN-core-{qualifier}.md`) MUST follow the structured format defined in `_core-adr-policy-008` (see rule 08b). Tools MUST enforce this and report an error using code `_core-adr-policy-010-scope-governance.12b-local-must-be-structured`.
+
+#### 13-local-mandatory-when-present
+
+When one or more local meta-policies exist in a scope, tools and agents MUST load and apply ALL of them as mandatory conventions when authoring or reviewing **policy documents** in that scope. If any found local meta-policy file is unreadable, tools MUST halt and report an error before proceeding.
 
 ---
 
-#### Section C — Governance application and precedence
+**Section C — Governance application and precedence**
 
-##### 14-application-follows
+#### 14-application-follows
 
-A scope's `follows:` frontmatter field lists `core`-type scope names whose policies apply as mandatory conventions to this scope, in addition to `_core`. The last-listed scope takes precedence on conflicts when the same topic is addressed by multiple `follows:` scopes.
+Tools and agents MUST apply the policies of all scopes listed in a scope's `follows:` frontmatter as mandatory conventions, in addition to `_core`. When the same topic is addressed by multiple `follows:` scopes, the last-listed scope MUST take precedence on conflicts.
 
-##### 15-application-scope-type
+#### 15-application-scope-type
 
 When adding or reviewing content in a scope, tools and agents MUST:
 
-1. Read the scope's `scope-type` from its `index.md`.
-2. 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`.
-3. If found, apply its rules as mandatory conventions.
-4. If the scope-type policy contains a rule titled `NN-parent-scope-type`, extract the parent type name (backtick-quoted identifier in the rule body) and repeat steps 2–4 for the parent. Continue until no more parents are declared. Detect and stop on cycles.
+1. Read the scope's `scope-type` from its `index.md`. Normalise the value to a list: split on commas and trim whitespace; a single value with no comma becomes a one-element list.
+2. For each declared type in list order, resolve its full ancestor chain:
+   a. Search the `[type]/principles/` directories of all `core`-type scopes in the workspace 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**. Companions are loaded in alphabetical order by qualifier.
+   c. If the primary contains a rule titled `NN-parent-scope-type`, extract the parent type name (backtick-quoted identifier in the rule body) and repeat steps a–c for the parent. Continue until no more parents are declared. Detect and stop on cycles.
+3. Concatenate all resolved ancestor chains in declaration order to form a single flat list (e.g., for `scope-type: [reference, platform]` where `reference → standard` and `platform → core`: `[standard, reference, core, platform]`).
+4. Deduplicate the flat list keeping the **first occurrence** of each type (preserves the ancestor semantics of whichever type introduced the parent earliest).
+5. Apply all policies from the deduplicated list as mandatory conventions. Later entries in the list override earlier entries when the same rule number appears with different content, provided the override is declared (see rule 19-conflict-declarations).
 
-##### 16-application-local
+#### 16-application-local
 
-When adding or reviewing content in a scope, tools and agents MUST:
+When adding or reviewing **policy documents** in a scope, tools and agents MUST:
 
-1. Search the scope's own `[type]/principles/` directories for a policy file whose name ends with `{scope-name}-core.md`.
-2. If found, apply its rules as mandatory conventions for content in that scope.
+1. Search the scope's own `[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 whose title ends with `-scope-type`.
+2. If any are found, read and apply ALL of them as mandatory conventions. If a found file is unreadable, halt with an error before proceeding.
+3. If none are found, continue without error — absence of local meta-policies is valid.
 
-##### 17-precedence
+#### 17-precedence
 
-When multiple standards address the same topic, the following precedence applies (later in the list overrides earlier on conflict):
+When multiple governance layers define a rule with the same rule number, the later entry in the following ordered chain takes precedence (lowest to highest):
 
-1. Parent scope-type standards (resolved transitively from the declared scope-type's parent chain)
-2. Declared scope-type standards
-3. `follows:` scope standards (last-listed `follows:` scope wins among themselves)
-4. Scope-local `{scope-name}-core` policy standards
+1. All scope-types in the deduplicated ancestor chain (rule 15), in chain order — earlier entries are overridden by later entries.
+2. `follows:` scope policies (applied in `follows:` list order; last-listed scope wins among themselves).
+3. Local meta-policies (`NNN-core.md` and companions in alphabetical qualifier order).
+
+In all cases, an override is valid only if the overriding policy contains a `## Conflicts` section that explicitly declares the conflict with the overridden rule (see rule 19-conflict-declarations). A conflict that is not declared MUST be surfaced as an error by tools and agents; the content cannot be validated until the conflict is resolved.
 
 All of the above are subordinate to `_core` structural rules, which MUST NOT be overridden.
 
-##### 18-ordering-custom-types
+#### 18-ordering-custom-types
 
 Custom-type scopes SHOULD be placed in the `standard` position in the root `index.md` ordering (i.e., after `platform` scopes and before `_local`).
 
+#### 19-conflict-declarations
+
+When a policy (scope-type definition, local meta-policy, or companion) overrides a rule defined by a lower-precedence policy in the governance chain, the overriding policy MUST include a `## Conflicts` section that declares:
+
+- The rule number and short identifier being overridden (e.g., `#### NN-rulename`).
+- The policy file where the original rule is defined.
+- A short explanation of why the override is required for this scope or type.
+
+A `## Conflicts` section MAY also document cross-scope-type incompatibilities for informational purposes — cases where two declared scope types define the same rule number differently and the content author needs to know which definition wins. Tools and agents MUST detect undeclared conflicts at review time (rules with the same number defined differently in the loaded chain) and surface them as errors. Semantic conflict detection (two rules with different numbers that are logically incompatible) is the responsibility of the authoring agent, not the lint tool.
+
 ## References
 
 - [_core-adr-policy-011 - core scope type](011-core-scope-type.md) — defines the `core` scope type and when to use a `-core` sibling scope vs. a scope-local policy
-- [_core-adr-policy-001 - XDRS core](001-xdrs-core.md) — scope structure, `follows:` field definition, scope index frontmatter fields
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) — scope structure, `follows:` field definition, scope index frontmatter fields

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

@@ -65,7 +65,7 @@ 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: no content in it MUST 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, 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.
 
 #### 09-distribution-advisable
 
@@ -73,5 +73,5 @@ Distributing `-core` scopes alongside their companion consumable scope to downst
 
 ## References
 
-- [_core-adr-policy-010 - Scope governance](010-scope-governance.md) — full scope governance model including when to prefer a `{scope-name}-core` policy (scope-local) vs. this pattern
-- [_core-adr-policy-001 - XDRS core](001-xdrs-core.md) — scope structure, `follows:` field, scope index frontmatter
+- [_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
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) — scope structure, `follows:` field, scope index frontmatter

package/.xdrs/_core/adrs/principles/012-reference-scope-type.md

@@ -56,4 +56,4 @@ Policies, decisions, and standards here are to be read, adopted, adapted, or map
 ## References
 
 - [_core-adr-policy-010 - Scope governance](010-scope-governance.md) — scope-type definition convention and governance application model
-- [_core-adr-policy-001 - XDRS core](001-xdrs-core.md) — scope structure and `scope-type` field definition
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) — scope structure and `scope-type` field definition

package/.xdrs/_core/adrs/principles/013-platform-scope-type.md

@@ -44,4 +44,4 @@ Content in a `platform`-type scope SHOULD describe what is available, how to acc
 ## References
 
 - [_core-adr-policy-010 - Scope governance](010-scope-governance.md) — scope-type definition convention and governance application model
-- [_core-adr-policy-001 - XDRS core](001-xdrs-core.md) — scope structure and `scope-type` field definition
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) — scope structure and `scope-type` field definition

package/.xdrs/_core/adrs/principles/014-standard-scope-type.md

@@ -45,4 +45,4 @@ In the root `index.md`, `standard`-type scopes are placed after `platform` scope
 ## References
 
 - [_core-adr-policy-010 - Scope governance](010-scope-governance.md) — scope-type definition convention and governance application model
-- [_core-adr-policy-001 - XDRS core](001-xdrs-core.md) — scope structure and `scope-type` field definition
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) — scope structure and `scope-type` field definition

package/.xdrs/_core/adrs/principles/015-local-scope-type.md

@@ -38,4 +38,4 @@ Content in the `_local` scope MUST NOT be shared with or propagated to any other
 ## References
 
 - [_core-adr-policy-010 - Scope governance](010-scope-governance.md) — scope-type definition convention and governance application model
-- [_core-adr-policy-001 - XDRS core](001-xdrs-core.md) — `_local` structural rules (placement, linking restrictions, root index behaviour)
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) — `_local` structural rules (placement, linking restrictions, root index behaviour)

package/.xdrs/_core/adrs/principles/016-policy-subjects.md

@@ -126,6 +126,6 @@ When a document could plausibly fit more than one subject, authors MUST apply th
 
 ## References
 
-- [_core-adr-policy-001 - XDRS core](001-xdrs-core.md) — Framework structure, scopes, types, and subject folder placement
+- [_core-adr-policy-001 - XDRS standards](001-xdrs-standards.md) — Framework structure, scopes, types, and subject folder placement
 - [_core-adr-policy-002 - Policy standards](002-policy-standards.md) — How to write Policy documents
 - [_core-adr-policy-017 - Policy numbering ranges](017-policy-numbering-ranges.md) — Reserved number block per subject

package/.xdrs/_core/adrs/principles/017-policy-numbering-ranges.md

@@ -60,6 +60,6 @@ When `freeze-reference: true` is set in a policy's frontmatter, numbering range
 
 ## References
 
-- [`_core-adr-policy-001`](001-xdrs-core.md) — XDRS core framework: numbering and folder structure
+- [`_core-adr-policy-001`](001-xdrs-standards.md) — XDRS standards framework: numbering and folder structure
 - [`_core-adr-policy-002`](002-policy-standards.md) — Policy standards: freeze-reference exemption semantics
 - [`_core-adr-policy-016`](016-policy-subjects.md) — Policy subjects: allowed subjects and taxonomy per type

package/.xdrs/_core/adrs/principles/018-external-path-symlinks.md

@@ -11,7 +11,7 @@ valid-from: 2026-07-10
 
 Some external tools and runtime environments require files at specific paths outside the `.xdrs/` folder. Examples include AI agent runtimes that expect skills in `.agents/skills/`, documentation generators that read from `docs/`, or CI tooling that references scripts from a fixed project-root path. Without a rule, contributors may duplicate files, breaking the single-source-of-truth guarantee that the `.xdrs/` root provides.
 
-This policy extends [`_core-adr-policy-001`](001-xdrs-core.md), which already prohibits creating or modifying XDRS documents via symlinked paths.
+This policy extends [`_core-adr-policy-001`](001-xdrs-standards.md), which already prohibits creating or modifying XDRS documents via symlinked paths.
 
 How should XDRS files be made accessible from paths outside the `.xdrs/` root without duplicating their content?
 
@@ -45,5 +45,5 @@ The parent directory of the external symlink path MUST exist before the symlink
 
 ## References
 
-- [`_core-adr-policy-001`](001-xdrs-core.md) — XDRS core framework: folder structure and the rule prohibiting modifications via symlinked paths
+- [`_core-adr-policy-001`](001-xdrs-standards.md) — XDRS standards framework: folder structure and the rule prohibiting modifications via symlinked paths
 - [`_core-adr-policy-008`](008-policy-structured-standards.md) — Policy structured standards: numbered rule block format used in this document

package/.xdrs/_core/adrs/principles/articles/.assets/001-xdrs-overview-slides.md

@@ -227,7 +227,7 @@ This creates `AGENTS.md` and `.xdrs/index.md` with the `_core` scope pre-loaded.
 # References
 
 - [XDRS Overview article](../001-xdrs-overview.md)
-- [_core-adr-policy-001 - XDRS core](../../001-xdrs-core.md)
+- [_core-adr-policy-001 - XDRS standards](../../001-xdrs-standards.md)
 - [_core-adr-policy-002 - Policy standards](../../002-policy-standards.md)
 - [_core-adr-policy-003 - Skill standards](../../003-skill-standards.md)
 - [_core-adr-policy-004 - Article standards](../../004-article-standards.md)

package/.xdrs/_core/adrs/principles/articles/001-xdrs-overview.md

@@ -28,7 +28,7 @@ without starting from a raw Decision Record.
   record the adopted direction. They are the central policy artifact of the framework for the
   scope and topic they cover. Three policy types exist: **ADR** for architectural and
   technical decisions, **BDR** for business and operational decisions, and **EDR** for engineering
-  implementation decisions. See [_core-adr-policy-001](../001-xdrs-core.md).
+  implementation decisions. See [_core-adr-policy-001](../001-xdrs-standards.md).
 - **Research** captures exploration before or around a decision: constraints, findings, options,
   pros, and cons. Research supports elaboration, discussion, and updates,
   but it is not the final rule. A single Research document may inform multiple downstream ADRs,
@@ -150,7 +150,7 @@ guidance, and the explanatory overview close together without collapsing them in
 
 ### Guidelines
 
-Follow [_core-adr-policy-001](../001-xdrs-core.md) and [_core-adr-policy-002](../002-policy-standards.md) strictly. Key rules:
+Follow [_core-adr-policy-001](../001-xdrs-standards.md) and [_core-adr-policy-002](../002-policy-standards.md) strictly. Key rules:
 
 - Use uppercase BCP 14 keywords: MUST/MUST NOT for non-negotiable rules, SHOULD/SHOULD NOT for strong recommendations, MAY/OPTIONAL for optional choices.
 - Before citing a Policy as a requirement, check `Valid` first, then `Applied to`, and finally the decision text to confirm the decision is in scope for the current case.
@@ -192,7 +192,7 @@ Follow [_core-adr-policy-001](../001-xdrs-core.md) and [_core-adr-policy-002](..
 ## References
 
 - [Presentation slides](.assets/001-xdrs-overview-slides.md) - Marp slide deck overview of this article
-- [_core-adr-policy-001](../001-xdrs-core.md) - XDRS elements: types, scopes, subjects, folder structure
+- [_core-adr-policy-001](../001-xdrs-standards.md) - XDRS elements: types, scopes, subjects, folder structure
 - [_core-adr-policy-002](../002-policy-standards.md) - Policy document standards and mandatory template
 - [_core-adr-policy-003](../003-skill-standards.md) - Skill standards and co-location rules
 - [_core-adr-policy-004](../004-article-standards.md) - Article standards

package/.xdrs/_core/adrs/principles/skills/.assets/conflict-detection.md

@@ -0,0 +1,76 @@
+# Shared Module: Conflict Detection Between Governance Layers
+
+## Purpose
+
+This module provides LLM-agent instructions for detecting semantic and structural conflicts between `#### NN-rulename` rule blocks across all governance policies loaded for a scope. It is invoked from within skills (001-review, 002-write-policy, etc.) after all governance layers have been loaded and before any authoring or review work begins.
+
+Lint tools enforce *structural* conflicts only (duplicate rule numbers with different content). This module handles *semantic* conflicts: two rules with different numbers that are logically incompatible.
+
+## Instructions
+
+### Step 1: Build the Governance Policy Map
+
+For each governance layer loaded in precedence order (scope-type chain → follows-meta → local-meta), extract every `#### NN-rulename` rule block into a flat map:
+
+```
+policy_rules[rule_id] = {
+  rule_id:      "NN-rulename"     # e.g., "01-file-naming"
+  body:         <text after #### heading until next heading>
+  source_file:  <path to policy file>
+  precedence:   <integer; higher = later in chain = overrides earlier>
+  declared_conflict_targets: [<list of rule_ids from ## Conflicts section>]
+}
+```
+
+If two entries share the same `rule_id`, the one with higher precedence wins for authoring and review purposes.
+
+### Step 2: Detect Structural Conflicts (Same Rule Number)
+
+For every rule_id that appears more than once across the loaded policies:
+
+1. Compare the bodies of all occurrences.
+2. If any two occurrences have substantially different content:
+   a. Check whether the higher-precedence policy's `## Conflicts` section lists the lower-precedence `rule_id`.
+   b. **Declared conflict**: if listed → the override is valid; note it as an informational finding only.
+   c. **Undeclared conflict**: if NOT listed → report as ERROR: `CONFLICT — Rule \`NN-rulename\` is defined differently in \`[source A]\` and \`[source B]\`. The override in \`[higher-precedence file]\` must declare this in its \`## Conflicts\` section before this scope's documents can be validated.`
+
+### Step 3: Detect Semantic Conflicts (Different Rule Numbers)
+
+For every pair of rules across all loaded policies:
+
+1. Read each rule's body carefully.
+2. Flag a SEMANTIC CONFLICT if the rules are logically incompatible — meaning a document that satisfies rule A cannot also satisfy rule B as written. Examples:
+   - Rule A: "MUST NOT include a References section" / Rule B: "MUST include a References section"
+   - Rule A: "filenames MUST be uppercase" / Rule B: "filenames MUST be lowercase"
+3. Check whether the higher-precedence policy's `## Conflicts` section declares the pair.
+4. **Declared semantic conflict**: if declared → note as informational finding.
+5. **Undeclared semantic conflict**: report as WARNING: `SEMANTIC CONFLICT — Rule \`NN-ruleA\` in \`[file A]\` may be incompatible with rule \`NN-ruleB\` in \`[file B]\`. Review whether both can be satisfied simultaneously. If one overrides the other, add a \`## Conflicts\` declaration to the overriding policy.`
+
+### Step 4: Report Findings
+
+Summarise all detected conflicts before proceeding with the skill's main task:
+
+```
+### Conflict Analysis
+
+**Undeclared structural conflicts (ERRORS — must fix before proceeding):**
+- Rule `NN-rulename`: defined in `[file A, line N]` and `[file B, line N]` with different content. Declare the override in [file B]'s ## Conflicts section.
+
+**Undeclared semantic conflicts (WARNINGS — review recommended):**
+- Rules `NN-ruleX` (file A) and `NN-ruleY` (file B) may be incompatible: [brief reason].
+
+**Declared overrides (informational):**
+- Rule `NN-rulename` overridden by `[file B]` as declared in its ## Conflicts section.
+```
+
+If there are undeclared **structural** conflicts (ERRORs), halt the skill and do NOT continue until the conflicts are declared. Semantic conflicts are warnings; the skill may continue but must flag them to the user.
+
+### Step 5: Apply Override Resolution
+
+When a declared structural conflict exists (rule_id appears in both A and B, override is declared):
+- Use the body from the higher-precedence policy for all authoring and review decisions.
+- Cite the lower-precedence policy as "overridden by [file B] — see its ## Conflicts section".
+
+When a declared semantic conflict exists:
+- Apply both rules as written; the later-in-chain rule takes precedence on any direct contradiction.
+- Note both rules as constraints in the authoring or review context.

package/.xdrs/_core/adrs/principles/skills/001-review/001-review.test.int.js

@@ -30,8 +30,8 @@ test('001-review outputs the required review template', async () => {
 			workspaceMode: 'copy',
 			...copilotCmd(REPO_ROOT),
 		},
-		'Review XDRS Policy 001-xdrs-core',
-		'Verify that the skill 001-review was used, contains "## Findings", and "## Summary", includes an "Outcome: PASS", and that it read file 001-review/SKILL.md and 001-xdrs-core.md.',
+		'Review XDRS Policy 001-xdrs-standards',
+		'Verify that the skill 001-review was used, contains "## Findings", and "## Summary", includes an "Outcome: PASS", and that it read file 001-review/SKILL.md and 001-xdrs-standards.md.',
 		null,
 		true
 	);

package/.xdrs/_core/adrs/principles/skills/001-review/001-review.test.int.report

@@ -1,10 +1,10 @@
 {
-  "Review XDRS Policy 001-xdrs-core-ac1c8339": {
+  "Review XDRS Policy 001-xdrs-standards-ac1c8339": {
     "result": "success",
     "contextFiles": [
       ".github/skills/001-lint/SKILL.md",
       ".xdrs/_core/adrs/index.md",
-      ".xdrs/_core/adrs/principles/001-xdrs-core.md",
+      ".xdrs/_core/adrs/principles/001-xdrs-standards.md",
       ".xdrs/_core/adrs/principles/002-xdr-standards.md",
       ".xdrs/_local/adrs/index.md",
       ".xdrs/index.md",