xdrs-core 0.33.0 → 0.35.0

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

@@ -15,7 +15,12 @@ Foundational standards, principles, and guidelines.
 - [_core-adr-policy-007](principles/007-plan-standards.md) - **Plan standards** — How to structure ephemeral execution plans that implement decisions
 - [_core-adr-policy-008](principles/008-xdr-standards-structured.md) - **Policy standards - structured** — How to expose individually referenceable numbered rules inside a Policy when external citation by identifier is required
 - [_core-adr-policy-009](principles/009-presentation-standards.md) - **Presentation standards** — How to structure Marp slide presentations that support XDRS documents
-- [_core-adr-policy-010](principles/010-core-scope-naming.md) - **Core scope naming convention** — How to use the `-core` suffix on a scope to separate meta governance content from consumable policies in a domain
+- [_core-adr-policy-010](principles/010-scope-governance.md) - **Scope governance** — How to define custom scope types, scope-local standards, and how all governance mechanisms apply with their precedence chain
+- [_core-adr-policy-011](principles/011-core-scope-type.md) - **core scope type** — Defines the `core` scope type: meta-governance scopes that hold writing standards, templates, and process guidance for a domain
+- [_core-adr-policy-012](principles/012-reference-scope-type.md) - **reference scope type** — Defines the `reference` scope type: blueprints and standards meant to be copied or adapted
+- [_core-adr-policy-013](principles/013-platform-scope-type.md) - **platform scope type** — Defines the `platform` scope type: live services or operational areas consumable directly
+- [_core-adr-policy-014](principles/014-standard-scope-type.md) - **standard scope type** — Defines the `standard` scope type: the default for business areas, products, and teams
+- [_core-adr-policy-015](principles/015-local-scope-type.md) - **_local scope type** — Defines the `_local` scope type: reserved for workspace-local decisions that must never be distributed
 
 ## Skills
 

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

@@ -64,23 +64,23 @@ Policies can be of different kinds, depending on the nature of the decision:
   - `_local` is a reserved scope for XDRS elements created locally to a specific project or repository. XDRS elements in `_local` MUST NOT be shared with or propagated to other contexts. This scope MUST always be placed in the lowest position in the root `index.md` so that its decisions override or extend any decisions from higher-positioned scopes. Shared root `index.md` files MUST NOT include an explicit link to `_local`, because `_local` remains workspace-local and is not distributed with shared packages. Readers, tools, and agents SHOULD still try the default workspace-local path `_local/index.md` when it exists, even without a root-index link. Documents in non-`_local` scopes MUST NEVER link to any document inside `_local`; documents inside `_local` MAY link to other documents inside `_local`.
   - **Types:** `adrs`, `bdrs`, `edrs`
   - there can exist sufixes to the standard scope names (e.g: `business-x-mobileapp`, `business-y-servicedesk`)
-  - The `-core` suffix is a reserved special suffix (e.g., `security-core`, `platform-core`) that designates a scope as the meta governance layer for all scopes sharing the same prefix. See `_core-adr-policy-010` for the full convention.
-  - **Scope types:** Every scope MUST declare its type via a `scope-type` field in its `index.md` YAML frontmatter. Allowed values:
-    - `core`: A meta-policy scope defining governance conventions for a group of scopes. It may set mandatory conventions (naming rules, subject taxonomy, scope ordering) enforced on related scopes. The built-in `_core` is the framework-level instance that applies globally; area-specific `core` scopes (e.g., `myarea-core`) layer governance on top. A scope with this type MUST have `core` in its name (e.g., `_core`, `myarea-core`, `security-core`). Area `core` scopes MUST NOT contradict `_core` structural rules; they may only extend them.
-    - `reference`: A blueprint, standard, or reference architecture meant to be copied or adapted — not a live service. Examples of what belongs here: industry standards (ISO, SOC2, PCI-DSS), vendor best-practice patterns, reference architectures. A scope with this type MUST have the word `reference` somewhere in its name (e.g., `domain1-reference-mobile`, `security-reference-baseline`, `aws-reference-landing-zone`).
-    - `platform`: An existing implementation, live service, or operational area that can be consumed directly without local instantiation. Defines something that exists and can be used, not merely a blueprint. A scope with this type MUST have the word `platform` somewhere in its name (e.g., `domain2-platform-aws`, `domain2-platform-callcenter`, `cloud-platform`).
-    - `domain`: The default type. Any business area, product domain, team, or general-purpose scope that does not fit one of the specific types above. No naming requirement.
-    - `_local`: Workspace-local decisions only. Never shared or distributed outside the local workspace. Reserved exclusively for the `_local` scope.
-  - Scope name suffixes are unlimited and may be used in any scope type. For `reference` and `platform` types only the presence of the keyword in the name is enforced, not its position (e.g., `domain2-reference-people-framework` and `domain2-platform-callcenter` are both valid).
-  - When writing or generating a new XDRS root `index.md`, use the following default ordering (scopes listed later override earlier ones): `core → reference → platform → domain → _local`.
+  - 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:
+    - `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)
+  - 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.
   - **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, see scope types above.
+    - `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.
     - `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 conventions to this scope, beyond `_core`. Last-listed takes precedence on conflicts (e.g., `follows: [myarea-core, shared-standards]`).
+    - `follows` (optional): Core scope names whose Policies apply as mandatory conventions to this scope, beyond `_core`. Last-listed takes precedence on conflicts (e.g., `follows: myarea-core, shared-standards`).
     - `related-scopes` (optional): Scope names of parent, sibling, or child scopes. Use when structural links help verify policy correctness across related scopes.
 - **Subjects:** MUST be one of the following depending on the type of the Policy. Use the subject to indicate the main concern of the decision.
   - **ADR subjects**
@@ -175,6 +175,8 @@ subject/
 ## References
 
 - [_core-adr-policy-002 - Policy standards](002-policy-standards.md) - Standards for writing individual Policy documents
+- [_core-adr-policy-010 - Scope governance](010-scope-governance.md) - Scope-type definition convention, scope-local standards, and governance application model
+- [_core-adr-policy-011 - core scope type](011-core-scope-type.md) - Defines the `core` scope type and meta-governance scope conventions
 - [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

@@ -117,7 +117,7 @@ Rules:
 - `## Overview` SHOULD state the task objective, expected outcome, and relevant prerequisites or tools when they matter.
 - `## Instructions` SHOULD include verification steps or acceptance criteria at the end of the task, or at the end of major phases when partial validation matters.
 - For simple structure, flow, layout, or relationship indications, `SKILL.md` SHOULD prefer plain Markdown, tables, or ASCII art instead of external assets.
-- Any non-Markdown files referenced from `SKILL.md` (schemas, JSON examples, images, diagrams, binaries, or any other data files) SHOULD be used only when they are materially necessary and MUST live in `.assets/` inside the same skill package.
+- Any non-Markdown files referenced from `SKILL.md` SHOULD be used only when they are materially necessary and MUST live in `.assets/` inside the same skill package. See `_core-adr-policy-001` for the canonical `.assets/` path conventions.
 - Keep `SKILL.md` under 6500 words. Move lengthy reference material to `references/`.
 - Use relative paths for all links; never use absolute paths starting with `/`.
 - Always use lowercase file names.

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

@@ -39,7 +39,7 @@ Articles are Markdown documents placed inside a subject folder alongside policie
 - Articles must remain consistent with the Policies, Research documents, and Skills they reference. When a referenced artifact changes, the article must be reviewed and updated.
 - Place an article in the subject folder that best matches its topic using the required list of subjects per type defined in `_core-adr-policy-001`. If an article spans more than one subject, place it in `principles`.
 - For simple structure, flow, layout, or relationship indications, articles SHOULD prefer plain Markdown, tables, or ASCII art instead of external assets.
-- Any non-Markdown files referenced by an article (schemas, JSON examples, images, diagrams, binaries, or any other data files) SHOULD be used only when they are materially necessary and MUST live in `articles/.assets/` next to the article files.
+- Any non-Markdown files referenced by an article SHOULD be used only when they are materially necessary and MUST live in `articles/.assets/` next to the article files. See `_core-adr-policy-001` for the canonical `.assets/` path conventions.
 - Always use lowercase file names.
 - Never use emojis in article content.
 

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

@@ -50,7 +50,7 @@ Research documents are Markdown files placed inside a subject folder alongside p
 - Research documents SHOULD link in `## References` to the Policies, skills, articles, discussions, and external references relevant to the subject or that later cite the work.
 - A 1:1 relationship between one research document and one decision will likely be common in practice, but it is not required.
 - One research document MAY also be referenced by multiple Policies, including a mix of ADRs, BDRs, and EDRs, when the same investigation remains relevant across several decisions.
-- Any non-Markdown files referenced by a research document (schemas, JSON examples, images, diagrams, binaries, or any other data files) SHOULD be used only when they are materially necessary and MUST live in `researches/.assets/` next to the research files.
+- Any non-Markdown files referenced by a research document SHOULD be used only when they are materially necessary and MUST live in `researches/.assets/` next to the research files. See `_core-adr-policy-001` for the canonical `.assets/` path conventions.
 - Research file names MUST be lowercase. Never use emojis.
 - A research document MAY exist before the related Policy is written, or remain after the Policy changes, as long as its status and references stay clear.
 

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

@@ -33,7 +33,7 @@ Plans are Markdown documents placed inside a subject folder alongside policies.
 - Plans MUST include an `Expected end date:` field in ISO format (YYYY-MM-DD) inside the `## Proposed Solution` section.
 - Always use lowercase file names.
 - Never use emojis in plan content.
-- Any non-Markdown files referenced by a plan (schemas, JSON examples, images, diagrams, binaries, or any other data files) SHOULD be used only when they are materially necessary and MUST live in `plans/.assets/` next to the plan files.
+- Any non-Markdown files referenced by a plan SHOULD be used only when they are materially necessary and MUST live in `plans/.assets/` next to the plan files. See `_core-adr-policy-001` for the canonical `.assets/` path conventions.
 
 **Folder layout**
 

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

@@ -0,0 +1,142 @@
+---
+name: _core-adr-policy-010-scope-governance
+description: Defines how scope types and scope-local standards are declared and applied. Covers how to author a custom scope-type policy, how to define scope-local content standards, and how all governance mechanisms (scope-type, follows, scope-local) interact with their precedence chain. Use when defining a new scope type, setting local standards for a scope, or understanding how governance is applied when adding content to a scope.
+apply-to: All XDRS scopes, core scopes defining scope types, and tools/agents processing scope content
+valid-from: 2026-07-01
+---
+
+# _core-adr-policy-010: Scope governance
+
+## Context and Problem Statement
+
+XDRS provides three 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.
+
+Without a clear definition of how these mechanisms are authored and how they interact, tools, agents, and authors cannot reliably determine which standards apply when adding or reviewing content in a scope.
+
+## Decision Outcome
+
+**Define scope types as policies, scope-local standards as named policies, 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.
+
+> **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.
+
+### Details
+
+#### Section A — Scope-type definition standards
+
+##### 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
+
+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
+
+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
+
+A scope-type definition policy SHOULD preferably define:
+
+- Naming conventions for scope instances of this type.
+- What content SHOULD be placed in scopes of this type.
+- What content SHOULD NEVER 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
+
+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`).
+
+##### 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
+
+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.
+
+##### 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.
+
+---
+
+#### Section B — Scope-local standards
+
+##### 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`).
+
+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
+
+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.
+
+##### 11-local-optional
+
+Creating a scope-local standards policy is optional. It is recommended when a scope has specific structural, authoring, or content constraints that differ from `_core` defaults or the scope's declared scope-type standards.
+
+##### 12-local-content
+
+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.
+
+##### 13-local-mandatory-when-present
+
+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.
+
+---
+
+#### Section C — Governance application and precedence
+
+##### 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.
+
+##### 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.
+
+##### 16-application-local
+
+When adding or reviewing content 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.
+
+##### 17-precedence
+
+When multiple standards address the same topic, the following precedence applies (later in the list overrides earlier on conflict):
+
+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
+
+All of the above are subordinate to `_core` structural rules, which cannot be overridden.
+
+##### 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`).
+
+## 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

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

@@ -0,0 +1,69 @@
+---
+name: _core-adr-policy-011-core-scope-type
+description: Defines the `core` scope type — meta-governance scopes that hold writing standards, templates, process guidance, and authoring conventions for a domain. Use when creating or evaluating a scope whose purpose is to govern how content is authored in a group of related scopes.
+apply-to: All XDRS scope authors and maintainers
+valid-from: 2026-06-24
+---
+
+# _core-adr-policy-011: core scope type
+
+## Context and Problem Statement
+
+When teams create shared XDRS scopes, they often mix two kinds of content:
+
+- **Consumable policies**: rules and decisions that other teams or repositories must follow.
+- **Meta governance**: writing standards, structural templates, skill guidance, ownership definitions, and process rules that govern how content is authored within the domain.
+
+Mixing both kinds makes shared scopes harder to consume selectively and causes confusion about which content represents actual rules versus internal governance for scope contributors.
+
+How should a scope that exists to govern how other scopes are authored be defined and identified?
+
+## Decision Outcome
+
+**Use a dedicated scope of type `core` to hold all meta governance content for a domain.**
+
+A scope declared with `scope-type: core` is reserved for the meta organisation of a scope family. It contains content that governs how policies are written and maintained within the domain — not the actual policies themselves.
+
+### Details
+
+#### 01-scope-type-name
+
+The scope type defined by this policy is `core`. A scope declares it by setting `scope-type: core` in its `index.md` YAML frontmatter.
+
+#### 02-when-to-use
+
+Use `scope-type: core` when the scope's purpose is to hold meta governance content for a domain: writing standards, structural templates, process guidance for authoring or reviewing, skill files for domain-specific workflows, and ownership or contact information. Do not use it for scopes that contain actual rules or decisions intended for other teams to follow.
+
+#### 03-naming-convention
+
+A scope of type `core` MUST have "core" somewhere in its name (e.g., `_core`, `myarea-core`, `security-core`). The `-core` suffix is the recommended pattern. The built-in `_core` scope is the only exception to the suffix requirement.
+
+#### 04-allowed-content
+
+Content that belongs in a `core`-type scope:
+
+- Writing standards and templates specific to the domain.
+- Structural conventions for that domain's policies.
+- Process guidance for authoring or reviewing policies within the domain.
+- Skill files for domain-specific review or authoring workflows.
+- Ownership, contact, and governance information for the domain.
+
+#### 05-forbidden-content
+
+Content that MUST NOT be placed in a `core`-type scope:
+
+- Actual rules or constraints for other teams to follow (e.g., security requirements, compliance rules).
+- Any policy intended to be enforced by external teams or repositories.
+
+#### 06-follows-required
+
+A scope that is governed by a `core` scope MUST declare this relationship explicitly using `follows: {core-scope-name}` in its `index.md` frontmatter.
+
+#### 07-distribution
+
+A `core`-type scope MAY be distributed to consumers alongside the companion consumable scope, or kept internal to the team that maintains the domain. When distributed, consumers who extend or contribute to the domain scope locally MUST follow its standards. When not distributed, internal contributors must still comply.
+
+## 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

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

@@ -0,0 +1,59 @@
+---
+name: _core-adr-policy-012-reference-scope-type
+description: Defines the `reference` scope type — scopes that hold blueprints, standards, regulations, or reference models meant to be adopted or adapted, not consumed as live services. Covers technical architectures, business procedures, compliance frameworks, and operational standards.
+apply-to: All XDRS scope authors declaring reference-type scopes
+valid-from: 2026-07-01
+---
+
+# _core-adr-policy-012: reference scope type
+
+## Context and Problem Statement
+
+Some XDRS scopes exist to publish standards, regulations, or reference models that teams can adopt or adapt. These include technical blueprints, industry compliance frameworks, business procedure standards, and operational guidelines.
+
+These scopes are structurally different from scopes representing live services or active teams: they describe how something should be done or built, not what is currently running or actively managed.
+
+How should a scope that exists as a reference model or standard be identified?
+
+## Decision Outcome
+
+**Declare `scope-type: reference` for any scope that holds models, standards, or procedures to be adopted or adapted — not live operational content.**
+
+### Details
+
+#### 01-scope-type-name
+
+The scope type defined by this policy is `reference`. A scope declares it by setting `scope-type: reference` in its `index.md` YAML frontmatter.
+
+#### 02-when-to-use
+
+Use `scope-type: reference` when the scope contains:
+
+- Industry standards or compliance frameworks to be adopted or mapped against (e.g., ISO 27001, SOC2, PCI-DSS, GDPR, financial regulations, accounting standards).
+- Vendor best-practice patterns or recommended architectures.
+- Reference architectures or canonical system blueprints meant to be instantiated or adapted locally.
+- Business area procedure standards: how sales processes should be conducted, how customer data must be handled, how marketing communications must comply with applicable regulations.
+- Operational compliance guidelines: finance controls, accounting procedures, public communication standards, customer data management rules.
+
+Do not use `scope-type: reference` for scopes that represent a live service, an active team, or a production system. Use `scope-type: platform` for those.
+
+#### 03-naming-convention
+
+A scope of type `reference` MUST have the word "reference" somewhere in its name. The position of the word is not enforced. Examples: `domain1-reference-mobile`, `security-reference-baseline`, `aws-reference-landing-zone`, `sales-reference-procedures`, `finance-reference-compliance`, `marketing-reference-standards`.
+
+#### 04-content-guidance
+
+Content in a `reference`-type scope describes how something should or could be done — whether that is building a system, running a business process, or complying with a regulation. It should not describe what is currently deployed or actively managed.
+
+Policies, decisions, and standards here are to be read, adopted, adapted, or mapped — not consumed directly as live service or operational documentation. Examples include:
+
+- Architectural blueprints and system design patterns.
+- Sales procedure standards and customer engagement guidelines.
+- Accounting, finance, and compliance regulations to be followed by specific teams.
+- Marketing and public communication standards, including legal and regulatory constraints.
+- Customer data management policies establishing rules for data classification, retention, and handling.
+
+## 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

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

@@ -0,0 +1,47 @@
+---
+name: _core-adr-policy-013-platform-scope-type
+description: Defines the `platform` scope type — scopes that represent existing implementations, live services, or operational areas consumable directly without local instantiation. Use when declaring a scope that documents something that already exists and can be used.
+apply-to: All XDRS scope authors declaring platform-type scopes
+valid-from: 2026-07-01
+---
+
+# _core-adr-policy-013: platform scope type
+
+## Context and Problem Statement
+
+Some XDRS scopes represent existing, live infrastructure or services that teams can consume directly — cloud platforms, shared services, call centres, operational areas. These differ from reference architectures (blueprints to adapt) and from domain scopes (business areas or teams): they define something that already exists and is ready to be used.
+
+How should a scope that documents a live, consumable platform or service be identified?
+
+## Decision Outcome
+
+**Declare `scope-type: platform` for any scope that represents an existing implementation or operational area that can be consumed directly.**
+
+### Details
+
+#### 01-scope-type-name
+
+The scope type defined by this policy is `platform`. A scope declares it by setting `scope-type: platform` in its `index.md` YAML frontmatter.
+
+#### 02-when-to-use
+
+Use `scope-type: platform` when the scope documents:
+
+- An existing cloud or runtime environment that teams can deploy to directly.
+- A shared foundational service available for consumption (e.g., a payment platform, a data platform, a messaging service).
+- An operational area or live capability that can be used without local instantiation.
+
+Do not use `scope-type: platform` for blueprints or reference architectures. Use `scope-type: reference` for those. Do not use it for business domains, products, or teams — use `scope-type: standard` for those.
+
+#### 03-naming-convention
+
+A scope of type `platform` MUST have the word "platform" somewhere in its name. The position of the word is not enforced. Examples: `domain2-platform-aws`, `domain2-platform-callcenter`, `cloud-platform`.
+
+#### 04-content-guidance
+
+Content in a `platform`-type scope describes what is available, how to access it, what decisions govern its use, and what constraints or service levels apply. It documents a live service — not a blueprint to copy.
+
+## 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

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

@@ -0,0 +1,48 @@
+---
+name: _core-adr-policy-014-standard-scope-type
+description: Defines the `standard` scope type — the default type for business areas, product domains, teams, or any general-purpose scope that does not fit the more specific types. Use when declaring any scope that is not a meta-governance scope, a reference model, a live platform, or workspace-local.
+apply-to: All XDRS scope authors declaring standard-type scopes
+valid-from: 2026-07-01
+---
+
+# _core-adr-policy-014: standard scope type
+
+## Context and Problem Statement
+
+Most XDRS scopes represent a business area, a product, a team, or a general grouping of decisions that does not fit the characteristics of the more specific scope types (`core`, `reference`, `platform`, `_local`). A default scope type is needed for these general-purpose scopes.
+
+## Decision Outcome
+
+**Declare `scope-type: standard` for any scope that represents a business area, product domain, team, or general grouping of decisions.**
+
+`standard` is the default scope type. When no other type fits, use `standard`.
+
+### Details
+
+#### 01-scope-type-name
+
+The scope type defined by this policy is `standard`. A scope declares it by setting `scope-type: standard` in its `index.md` YAML frontmatter.
+
+#### 02-when-to-use
+
+Use `scope-type: standard` for:
+
+- Business areas, business units, or product lines.
+- Product or feature team scopes.
+- Cross-cutting engineering or architecture scopes that are not a platform or reference model.
+- Any scope that does not fit `core`, `reference`, `platform`, or `_local`.
+
+This is the default scope type. When uncertain, use `standard`.
+
+#### 03-naming-convention
+
+There is no naming requirement for `standard`-type scopes. Any valid scope name is acceptable (e.g., `business-x`, `team-43`, `mobile-app`, `checkout`).
+
+#### 04-ordering
+
+In the root `index.md`, `standard`-type scopes are placed after `platform` scopes and before `_local`. Custom scope types should also be placed in this position. Scopes listed later override scopes listed earlier on the same topic.
+
+## 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

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

@@ -0,0 +1,41 @@
+---
+name: _core-adr-policy-015-local-scope-type
+description: Defines the `_local` scope type — reserved exclusively for the `_local` scope, which holds workspace-local decisions that must never be distributed or shared outside the current repository. Use when understanding what the `_local` scope type means.
+apply-to: All XDRS workspace authors
+valid-from: 2026-07-01
+---
+
+# _core-adr-policy-015: _local scope type
+
+## Context and Problem Statement
+
+Every XDRS workspace may need project-specific overrides or local decisions that are not applicable elsewhere. These decisions must be kept in the workspace and never distributed or shared. A reserved scope type is needed to identify and enforce this boundary.
+
+## Decision Outcome
+
+**Reserve `scope-type: _local` exclusively for the `_local` scope, which holds workspace-local decisions that must never leave the repository.**
+
+### Details
+
+#### 01-scope-type-name
+
+The scope type defined by this policy is `_local`. A scope declares it by setting `scope-type: _local` in its `index.md` YAML frontmatter.
+
+#### 02-when-to-use
+
+Use `scope-type: _local` only for the built-in `_local` scope. This scope type is reserved and MUST NOT be used for any other scope.
+
+The `_local` scope holds project-specific decisions, local overrides, and workspace-specific content that applies only to the current repository. Examples: local tooling decisions, workspace-specific process overrides, temporary decisions during a transition.
+
+#### 03-exclusive-reservation
+
+The value `scope-type: _local` is reserved exclusively for the single scope named `_local`. No other scope may use this scope type.
+
+#### 04-never-distributed
+
+Content in the `_local` scope MUST NOT be shared with or propagated to any other context. It is workspace-local only and is never packaged for distribution.
+
+## 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)

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

@@ -30,7 +30,11 @@ Performs a structured review of code changes or files against the Policies in th
    - Check `valid-from:` first. If a date is present and has not yet been reached, the decision SHOULD be adopted for new implementations but is not enforced during reviews.
    - Check `apply-to:` second. Keep only Policies whose stated scope fits the files, systems, or workflows under review.
    - Check the decision text itself last for additional boundaries or exceptions that metadata does not encode.
-2. **Meta-policy scopes:** For each scope containing files under review, read its `index.md` frontmatter and check for a `follows` field. `_core` Policies always apply to all scopes. If a scope declares `follows:` with additional core scope names (e.g., `follows: [myarea-core, shared-standards]`), verify that each listed scope directory exists in the workspace (e.g., `.xdrs/[scope-name]/index.md`). If any listed scope is missing, STOP immediately — do not proceed with the review — and tell the user: "Scope `[scope-name]` is listed in `follows` but not found in the workspace. Install it before proceeding." Once all `follows` scopes are confirmed present, load their Policies and apply them as mandatory governance. Last-listed scope in `follows` takes precedence when the same topic is addressed by multiple scopes.
+2. **Meta-policy scopes:** For each scope containing files under review, read its `index.md` frontmatter and check for a `follows` field. `_core` Policies always apply to all scopes. If a scope declares `follows:` with additional core scope names (e.g., `follows: myarea-core, shared-standards`), verify that each listed scope directory exists in the workspace (e.g., `.xdrs/[scope-name]/index.md`). If any listed scope is missing, STOP immediately — do not proceed with the review — and tell the user: "Scope `[scope-name]` is listed in `follows` but not found in the workspace. Install it before proceeding." Once all `follows` scopes are confirmed present, load their Policies and apply them as mandatory governance. Last-listed scope in `follows` takes precedence when the same topic is addressed by multiple scopes.
+   - **Scope-type standards:** Read the scope's `scope-type` from its `index.md`. 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 found, apply its rules as mandatory conventions. 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 for the parent; continue until no more parents are declared. Detect and stop on cycles. See `_core-adr-policy-010` rules 15 and 17 for the full application model.
+   - **Scope-local standards:** Search the scope's own `[type]/principles/` directories for a policy file whose name ends with `{scope-name}-core.md`. If found, apply its rules as mandatory conventions; scope-local standards take precedence over scope-type standards on any conflict. See `_core-adr-policy-010` rules 16 and 17.
+   - **Scope-type standards:** Read the scope's `scope-type` from its `index.md`. 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 found, apply its rules as mandatory conventions. 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 for the parent; continue until no more parents are declared. Detect and stop on cycles. See `_core-adr-policy-010` rules 15 and 17 for the full application model.
+   - **Scope-local standards:** Search the scope's own `[type]/principles/` directories for a policy file whose name ends with `{scope-name}-core.md`. If found, apply its rules as mandatory conventions; scope-local standards take precedence over scope-type standards on any conflict. See `_core-adr-policy-010` rules 16 and 17.
 3. Filter relevance based on file types, domains, and architectural patterns in scope.
 
 ### Phase 3: Policy Review

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

@@ -159,6 +159,8 @@ Check every item before finalizing:
 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**: Check the target scope's `index.md` for a `follows` frontmatter field. `_core` Policies always apply to all scopes. If `follows` lists additional core scope names (e.g., `follows: [myarea-core]`), verify that each listed scope directory exists in the workspace (e.g., `.xdrs/[scope-name]/index.md`). If any listed scope is missing, STOP immediately and tell the user: "Scope `[scope-name]` is listed in `follows` but not found in the workspace. Install it before proceeding." Once all `follows` scopes are confirmed present, verify the document satisfies all requirements from those Policies. Scopes are applied in order; last-listed scope in `follows` takes precedence when the same topic is covered by multiple scopes.
+   - **Scope-type standards:** Read the target scope's `scope-type`. Search the `[type]/principles/` directories of all `core`-type scopes for a file ending in `{scope-type}-scope-type.md`. Apply its rules as requirements for the new Policy. Resolve any `NN-parent-scope-type` rule transitively. See `_core-adr-policy-010` rules 15 and 17.
+   - **Scope-local standards:** Search the target scope's own `[type]/principles/` for a file ending in `{scope-name}-core.md`. If found, apply its rules as requirements; they override scope-type standards on conflict. See `_core-adr-policy-010` rules 16 and 17.
 
 If any check fails, revise and re-run this phase before proceeding.
 

package/.xdrs/_core/index.md

@@ -43,13 +43,15 @@ Each artifact type has its own writing standard:
 
 Slide presentations that support XDRS documents follow [_core-adr-policy-009](adrs/principles/009-presentation-standards.md). Slides use the Marp Markdown format, live in `.assets/` next to the document they support, and must maintain bidirectional links with the parent document.
 
-### Domain scope meta governance
+### Standard scope meta governance
 
-[_core-adr-policy-010](adrs/principles/010-core-scope-naming.md) defines the `-core` suffix naming convention for XDRS scopes. A scope named `[domain]-core` (e.g., `security-core`) holds meta governance content — writing standards, templates, ownership, and process guidance — for all scopes sharing the same prefix. It must not contain consumable policies, and all contributors to same-prefix scopes must follow its standards.
+[_core-adr-policy-010](adrs/principles/010-scope-governance.md) defines the full scope governance model: how to define a custom scope type using `{scope-type}-scope-type` policies, how to define scope-local content standards using a `{scope-name}-core` policy, and how all governance mechanisms (`follows:`, scope-type standards, scope-local standards) apply with their precedence chain.
+
+[_core-adr-policy-011](adrs/principles/011-core-scope-type.md) defines the `core` scope type — meta-governance scopes named with the `-core` suffix (e.g., `security-core`) that hold writing standards, templates, ownership, and process guidance for a group of related scopes. They must not contain consumable policies, and all contributors to governed scopes must follow their standards via an explicit `follows:` declaration.
 
 ### Scope types
 
-Every XDRS scope declares a `scope-type` in its `index.md` YAML frontmatter. [_core-adr-policy-001](adrs/principles/001-xdrs-core.md) defines five allowed types: `core` (reserved for this scope), `reference` (blueprints and standards to be copied or adapted), `platform` (live services or areas usable directly), `domain` (the default for business areas, products, or teams), and `_local` (reserved for workspace-local decisions). The recommended root index ordering is `core → reference → platform → domain → _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. 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`.
 
 ### Available skills
 

package/.xdrs/index.md

@@ -6,7 +6,7 @@ This index points to all type- and scope-specific XDRS indexes. It covers Archit
 
 XDRS scopes listed last override the ones listed first
 
-Default ordering by scope type: `core → reference → platform → domain → _local`
+Default ordering by scope type: `core → reference → platform → standard → _local`
 
 ### _core