xdrs-core 0.11.0 → 0.11.1

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

@@ -21,29 +21,23 @@ Provides clear ownership by scope, predictable navigation, and reusable decision
 
 ### Implementation Details
 
-- XDRs MUST contain a clear decision about a certain problem or situation. Avoid being too verbose and focus on explaining clearly the context and the decision. Avoid adding contents that are not original. If you have other references that are important to understand the document, add links and references.
-- XDRs are the central artifact of the framework and the authoritative policy for their scope, type, and subject. Supporting artifacts may explain, justify, or operationalize the decision, but they do not replace it.
-- XDRs MAY include a `## Metadata` section, but only when at least one supported metadata field is present. When used, `## Metadata` MUST appear immediately before `## Context and Problem Statement`.
-- Supported XDR metadata fields are:
-  - `Status:` Optional. Defines the lifecycle state of the decision. Allowed values are `Draft`, `Active`, and `Deprecated`. If omitted, the decision is treated as `Active`. Only `Active` decisions may be treated as current policy.
-  - `Valid:` Optional. Defines the time window in which an active decision may be treated as current. Use ISO dates only: `from YYYY-MM-DD`, `until YYYY-MM-DD`, or `from YYYY-MM-DD until YYYY-MM-DD`. If `from` is omitted, the decision takes effect immediately. If `until` is omitted, the decision remains valid indefinitely.
-  - `Applied to:` Optional. A short description of the contexts in which the decision is applicable. Keep it under 40 words. If omitted, the decision should be interpreted as applying to all logically applicable elements according to the decision text itself. Examples: `Only frontend code`, `JavaScript projects`, `Performance-sensitive codebases`
-- Before using, enforcing, or citing an XDR as a current rule, humans and AI agents MUST decide whether the decision is in force for the current case.
-  - Check `Status:` first to determine whether the XDR is eligible to be used now. If `Status:` is omitted, treat it as `Active`. `Draft` and `Deprecated` decisions are background or history, not current policy.
-  - Check `Valid:` next to determine whether the current moment falls inside the decision's active date window. Not-yet-active and expired windows are not current policy.
-  - Check `Applied to:` next to determine whether the active, currently valid decision fits the current codebase, system, workflow, or audience.
-  - Check the decision context and implementation details last to determine any additional boundaries, exceptions, or qualifiers that metadata alone cannot express.
-  - If any check fails, the XDR MAY still be read as background, history, or context, but it MUST NOT be treated as a current requirement for that case.
-- Research documents MAY be added under the same subject to capture the exploration, findings, and proposals that backed a decision. Research is useful during elaboration, discussion, approval, retirement, and updates, but the XDR remains the source of truth.
-- Make it clear if an instruction is mandatory or advisory
-    - Mandatory language: "must", "always", "never", "required", "mandatory"
-    - Advisory language: "should", "recommended", "advised", "preferably", "possibly", "optionally"
-- Always the following folder structure:
+The standards below are split into framework-wide standards and XDR document standards.
+
+#### General framework standards
+
+- Make it clear if an instruction is mandatory or advisory.
+  - Mandatory language: "must", "always", "never", "required", "mandatory"
+  - Advisory language: "should", "recommended", "advised", "preferably", "possibly", "optionally"
+- Always use the following folder structure for XDR documents:
   `.xdrs/[scope]/[type]/[subject]/[number]-[short-title].md`
 - Optional supporting artifacts under the same subject:
   - `.xdrs/[scope]/[type]/[subject]/researches/[number]-[short-title].md`
   - `.xdrs/[scope]/[type]/[subject]/skills/[number]-[skill-name]/SKILL.md`
   - `.xdrs/[scope]/[type]/[subject]/articles/[number]-[short-title].md`
+- Research, skills, and articles are part of the framework, but each has its own concept-specific standards in dedicated XDRs. This XDR defines the shared framework baseline and the decision-record standard.
+  - `_core-adr-003` defines skill standards
+  - `_core-adr-004` defines article standards
+  - `_core-adr-006` defines research standards
 - For simple structure, flow, layout, or relationship indications, documents SHOULD prefer plain Markdown, tables, or ASCII art instead of external assets.
 - Images and other supporting files SHOULD be used only when they are materially necessary to preserve clarity, fidelity, or evidence. When used, they SHOULD live in a sibling `assets/` folder next to the document.
   - XDRs in the subject root use `.xdrs/[scope]/[type]/[subject]/assets/`
@@ -51,34 +45,98 @@ Provides clear ownership by scope, predictable navigation, and reusable decision
   - Research uses `.xdrs/[scope]/[type]/[subject]/researches/assets/`
   - Skills use `.xdrs/[scope]/[type]/[subject]/skills/[number]-[skill-name]/assets/`
 - **Scopes:** 
+  - Short name that defines a group or a package of xdrs
   - examples: `business-x`, `business-y`, `team-43`, `_core`
   - `_local` is a reserved scope for XDRs created locally to a specific project or repository. XDRs in `_local` must not be shared with or propagated to other contexts. This scope must always be placed in the lowest position in `.xdrs/index.md` so that its decisions override or extend any decisions from all higher-positioned scopes. Shared `.xdrs/index.md` files MUST NOT link `_local` canonical type indexes because `_local` stays workspace-local and is not distributed with shared packages. Readers, tools, and agents SHOULD still try to discover existing workspace-local `_local` canonical indexes by default, even when the shared root index does not link them.
   - **Types:** `adrs`, `bdrs`, `edrs`
   - there can exist sufixes to the standard scope names (e.g: `business-x-mobileapp`, `business-y-servicedesk`)
-- **Subjects:** MUST be one of the following depending on the type of the XDR:
-  - **ADR:** `principles`, `application`, `data`, `integration`, `platform`, `controls`, `operations`
-  - **BDR:** `principles`, `marketing`, `product`, `controls`, `operations`, `organization`, `finance`, `sustainability`
-  - **EDR:** `principles`, `application`, `infra`, `ai`, `observability`, `devops`, `governance`
+- **Subjects:** MUST be one of the following depending on the type of the XDR. Use the subject to indicate the main concern of the decision.
+  - **ADR subjects**
+    - `principles`: Cross-cutting architecture and policy foundations.
+      - Examples: architecture style, interoperability rules, long-term technology direction.
+    - `application`: System and service design decisions at application level.
+      - Examples: modularization strategy, service decomposition, app-level security flows.
+    - `data`: Data architecture and information modeling choices.
+      - Examples: canonical schemas, data ownership boundaries, retention strategies.
+    - `integration`: Decisions about communication between internal/external systems.
+      - Examples: sync vs async patterns, contract strategy, partner integration approach.
+    - `platform`: Platform-level runtime and enabling capabilities.
+      - Examples: cloud/runtime baseline, foundational services, platform tenancy approach.
+    - `controls`: Architecture controls for risk, security, and compliance at a high level.
+      - Examples: encryption baseline, auditability requirements, policy enforcement points.
+    - `operations`: Operational architecture decisions.
+      - Examples: incident model, resilience objectives, operational ownership boundaries.
+  - **BDR subjects**
+    - `principles`: Business principles and decision criteria that guide all business areas.
+      - Examples: customer fairness rules, policy precedence, strategic guardrails.
+    - `marketing`: Go-to-market, communication, and campaign policy decisions.
+      - Examples: campaign approval rules, channel usage standards, positioning constraints.
+    - `product`: Product behavior, lifecycle, and offering decisions.
+      - Examples: feature rollout policy, packaging/tiers, product requirement governance.
+    - `controls`: Business control framework decisions.
+      - Examples: approval segregation, mandatory checks, exception handling policy.
+    - `operations`: Day-to-day business process and procedure decisions.
+      - Examples: support workflows, onboarding/offboarding procedures, SLA operations.
+    - `organization`: Structure, roles, and responsibility model decisions.
+      - Examples: decision rights, team topology, accountability boundaries.
+    - `finance`: Financial and cost-control business decisions.
+      - Examples: budgeting process, pricing governance, investment approval rules.
+    - `sustainability`: Environmental and social responsibility policy decisions.
+      - Examples: sustainability KPIs, reporting cadence, procurement sustainability criteria.
+  - **EDR subjects**
+    - `principles`: Engineering principles and non-functional quality defaults.
+      - Examples: coding standards baseline, testing philosophy, secure-by-default engineering rules.
+    - `application`: Code-level implementation patterns and application conventions.
+      - Examples: framework patterns, layer organization, API implementation conventions.
+    - `infra`: Infrastructure implementation and runtime operations details.
+      - Examples: IaC patterns, environment provisioning, network/runtime hardening details.
+    - `observability`: Telemetry, monitoring, alerting, and diagnostics implementation.
+      - Examples: log/metric/tracing standards, alert routing policy, SLO measurement approach.
+    - `devops`: Delivery pipeline, release automation, and developer workflow decisions.
+      - Examples: CI/CD stages, branch strategy, release promotion gates.
+    - `governance`: Engineering governance, risk controls, and compliance mechanics.
+      - Examples: dependency governance, approval policies, mandatory quality checks.
+- If there is a README.md file in the root of the xdrs folder, always keep it up to date. Never use emojis.
+- **Indexes**
+  - Keep a canonical index with all XDRs of a certain type+scope in `.xdrs/[scope]/[type]/index.md`
+  - Canonical index requirements:
+    - Organize XDRs by subject for easier navigation
+    - Add a short description of what this scope is about (responsibilities, general worries, teams involved, link to discussion process, etc)
+    - Add a list of other scope indexes that this scope might be related to (only add scopes that might be overridden). E.g: "business-x-mobileapp" scope could refer to "business-x" and "sensitive-data" scopes in its index list. XDRs in scopes listed last override XDRs in scopes listed first when addressing the same topic.
+    - Each XDR element entry in the index MUST include a short description of its content in imperative format and with fewer than 10 words. Example: "understand customer communication tone"
+  - Outside the scopes, keep an index pointing to all canonical indexes in `.xdrs/index.md`. Add the text "XDRs in scopes listed last override the ones listed first"
+  - Always verify if indexes are up to date after making changes
+
+#### XDR document standards (decision record source of truth)
+
+- XDRs MUST contain a clear decision about a certain problem or situation. Avoid being too verbose and focus on explaining clearly the context and the decision. Avoid adding contents that are not original. If you have other references that are important to understand the document, add links and references.
+- XDRs are the central artifact of the framework and the authoritative policy for their scope, type, and subject. Supporting artifacts may explain, justify, or operationalize the decision, but they do not replace it.
+- XDRs MAY include a `## Metadata` section, but only when at least one supported metadata field is present. When used, `## Metadata` MUST appear immediately before `## Context and Problem Statement`.
+- Supported XDR metadata fields are:
+  - `Status:` Optional. Defines the lifecycle state of the decision. Allowed values are `Draft`, `Active`, and `Deprecated`. If omitted, the decision is treated as `Active`. Only `Active` decisions may be treated as current policy.
+  - `Valid:` Optional. Defines the time window in which an active decision may be treated as current. Use ISO dates only: `from YYYY-MM-DD`, `until YYYY-MM-DD`, or `from YYYY-MM-DD until YYYY-MM-DD`. If `from` is omitted, the decision takes effect immediately. If `until` is omitted, the decision remains valid indefinitely.
+  - `Applied to:` Optional. A short description of the contexts in which the decision is applicable. Keep it under 40 words. If omitted, the decision should be interpreted as applying to all logically applicable elements according to the decision text itself. Examples: `Only frontend code`, `JavaScript projects`, `Performance-sensitive codebases`
+- Before using, enforcing, or citing an XDR as a current rule, humans and AI agents MUST decide whether the decision is appliable for the current case.
+  - Check `Status:` first to determine whether the XDR is eligible to be used now. If `Status:` is omitted, treat it as `Active`. `Draft` and `Deprecated` decisions are background or history, not current policy.
+  - Check `Valid:` next to determine whether the current moment falls inside the decision's active date window. Not-yet-active and expired windows are not current policy.
+  - Check `Applied to:` next to determine whether the active, currently valid decision fits the current codebase, system, workflow, or audience.
+  - Check the decision context and implementation details last to determine any additional boundaries, exceptions, or qualifiers that metadata alone cannot express.
+  - If any check fails, the XDR MAY still be read as background, history, or context, but it MUST NOT be treated as a current requirement for that case.
+- Research documents MAY be added under the same subject to capture the exploration, findings, and proposals that backed a decision. Research is useful during elaboration, discussion, approval, retirement, and updates of xdrs, but the XDR document remains the source of truth.
 - **XDR Id:** [scope]-[type]-[xdr number unique in scope] (the xdr id must be unique among all XDRs of the same type in the different scopes and always use lowercase)
   - Types in IDs: `adr`, `bdr`, `edr`
   - Define the next number of an XDR by checking what is the highest number present in the type+scope. Don't fill numbering gaps, as they might be old deleted XDRs and we should never reuse numbers of different documents/decisions. Numbering gaps are expected.
-- Decisions MUST be concise and reference other XDRs to avoid duplication
+- Decisions MUST be concise and reference other XDRs to avoid duplication.
 - The `### Implementation Details` section SHOULD state relevant boundaries or exceptions and what a reader should do or avoid in common cases. Use `## Metadata` as the first-pass filter for whether the decision should be used at all, then keep nuanced boundaries in the decision text.
 - Use concise rules, examples, or `Do` / `Don't` lists only when they help a reader apply the decision correctly. Keep them short and decision-specific.
+- Conflict handling applies to XDR documents:
+  - For cross-scope overrides, document the decision conflict in the XDR `## Conflicts` section of the XDR that overrides another scope.
+  - **Within-scope conflicts:** XDRs within the same type+scope must not conflict. If two XDRs appear to conflict, one should be updated, deprecated, or the conflict resolved through a new XDR.
 - When research exists for a decision, the XDR SHOULD mention the related research documents after the `## Considered Options` list.
-- Never use emojis in contents
-- Always use file names with lowercase
+- Never use emojis in contents.
+- Always use file names with lowercase.
 - Avoid using lengthy instructions on the XDR. If there are long and detailed instructions related to the XDR, or instructions that are outside the decision, create another file with a guide. If the guide is small, keep it in the XDR itself.
-- If there is a README.md file in the root of the xdrs folder, always keep it up to date. Never use emojis
-- Keep a canonical index with all XDRs of a certain type+scope in `.xdrs/[scope]/[type]/index.md`
-  - Organize XDRs by subject for easier navigation
-  - Add a list of other scope indexes that this scope might be related to (only add scopes that might be overridden). E.g: "business-x-mobileapp" scope could refer to "business-x" and "sensitive-data" scopes in its index list. XDRs in scopes listed last override XDRs in scopes listed first when addressing the same topic.
-  - Document decision conflicts in "Conflicts" section for the XDR that is overriding another XDR in other scopes
-  - **Within-scope conflicts:** XDRs within the same type+scope must not conflict. If two XDRs appear to conflict, one should be updated, deprecated, or the conflict resolved through a new XDR.
-  - In the index add a short description of what is this scope about (responsibilities, general worries, teams involved, link to discussion process etc)
-- Outside the scopes, keep an index pointing to all canonical indexes in `.xdrs/index.md`. Add the text "XDRs in scopes listed last override the ones listed first"
-- Always verify if the index is up to date after making changes
-- XDRs should be less than 100 lines long as a rule of thumb
+- XDRs should be less than 100 lines long as a rule of thumb.
   - This is important to make them focused on a clear decision
   - Exceptions can reach 200 lines (templates, more elaborate decision implementations etc)
 - ALWAYS use `_local` scope if the user doesn't explicitelly indicate a specific scope while creating an xdr or skill.

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

@@ -58,7 +58,7 @@ Research documents are Markdown files placed inside a subject folder alongside d
 Examples:
 - `.xdrs/_core/adrs/principles/researches/001-research-and-decision-lifecycle.md`
 - `.xdrs/business-x/adrs/platform/researches/003-api-gateway-options.md`
-- `.xdrs/_local/edrs/ai/researches/002-model-serving-constraints.md`
+- `.xdrs/_local/edrs/application/researches/002-model-serving-constraints.md`
 
 **Research numbering**
 

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

@@ -35,7 +35,7 @@ Consult `001-xdr-standards` while making each choice in this phase. The summarie
 **Subject** — pick one from the allowed list for the chosen type (from `001-xdr-standards`):
 - ADR: `principles`, `application`, `data`, `integration`, `platform`, `controls`, `operations`
 - BDR: `principles`, `marketing`, `product`, `controls`, `operations`, `organization`, `finance`, `sustainability`
-- EDR: `principles`, `application`, `infra`, `ai`, `observability`, `devops`, `governance`
+- EDR: `principles`, `application`, `infra`, `observability`, `devops`, `governance`
 
 **XDR ID** — format: `[scope]-[type]-[next available number]`
 - Scan `.xdrs/[scope]/[type]/` for the highest existing number in that scope+type and increment by 1.

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

@@ -40,7 +40,7 @@ Quick test:
 **Subject** — pick the most specific match for the chosen type (see `003-skill-standards`):
 - ADR subjects: `principles`, `application`, `data`, `integration`, `platform`, `controls`, `operations`
 - BDR subjects: `principles`, `marketing`, `product`, `controls`, `operations`, `organization`, `finance`, `sustainability`
-- EDR subjects: `principles`, `application`, `infra`, `ai`, `observability`, `devops`, `governance`
+- EDR subjects: `principles`, `application`, `infra`, `observability`, `devops`, `governance`
 
 **Skill number** — scan `.xdrs/[scope]/[type]/[subject]/skills/` for the highest existing number and increment by 1. Never reuse numbers from deleted skills.
 

package/README.md

@@ -76,7 +76,7 @@ Main exports:
 
 - `testPrompt(config, inputPrompt, judgePrompt)` runs the task prompt, evaluates the result in a fresh judge session, and returns an empty string on success or a markdown bullet list on failure.
 - `runPromptTest(config, inputPrompt, judgePrompt)` returns the structured result object when you need access to captured output and the agent-reported changed file list.
-- `copilotCmd(workspaceRoot)` returns a ready-to-use `promptCmd` template for the Copilot CLI. The library uses that same command template for both the task and judge phases. If `workspaceRoot` is omitted it defaults to the current git repository root.
+- `copilotCmd(workspaceRoot)` returns a ready-to-use `promptCmd` template for the Copilot CLI in headless mode (`--autopilot`, full tool/url permissions, and `--no-ask-user`). The library uses that same command template for both the task and judge phases. If `workspaceRoot` is omitted it defaults to the current git repository root.
 - `config.workspaceRoot`, when set, is the authoritative workspace under test. If omitted, the library uses the current git repository root.
 
 Execution model:

package/lib/lint.js

@@ -13,7 +13,7 @@ const TYPE_TO_ID = {
 const ALLOWED_SUBJECTS = {
   adrs: new Set(['principles', 'application', 'data', 'integration', 'platform', 'controls', 'operations']),
   bdrs: new Set(['principles', 'marketing', 'product', 'controls', 'operations', 'organization', 'finance', 'sustainability']),
-  edrs: new Set(['principles', 'application', 'infra', 'ai', 'observability', 'devops', 'governance'])
+  edrs: new Set(['principles', 'application', 'infra', 'observability', 'devops', 'governance'])
 };
 
 const TYPE_NAMES = new Set(Object.keys(TYPE_TO_ID));

package/lib/testPrompt.js

@@ -88,6 +88,10 @@ function copilotCmd(workspaceRoot = findGitRoot(process.cwd())) {
 	return [
 		'copilot',
 		`--add-dir=${path.resolve(workspaceRoot)}`,
+		'--autopilot',
+		'--allow-all-tools',
+		'--allow-all-urls',
+		'--no-ask-user',
 		'--allow-all',
 		'-p',
 		'{PROMPT}'

package/lib/testPrompt.test.js

@@ -81,6 +81,12 @@ test('copilotCmd defaults to the git repository root', () => {
 	const addDirArgument = command.find((entry) => entry.startsWith('--add-dir='));
 
 	expect(addDirArgument).toBe(`--add-dir=${path.resolve(__dirname, '..')}`);
+	expect(command).toEqual(expect.arrayContaining([
+		'--autopilot',
+		'--allow-all-tools',
+		'--allow-all-urls',
+		'--no-ask-user'
+	]));
 	const promptIndex = command.indexOf('-p');
 	expect(command[promptIndex + 1]).toBe('{PROMPT}');
 });

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "xdrs-core",
-  "version": "0.11.0",
+  "version": "0.11.1",
   "description": "A standard way to organize Decision Records (XDRs) across scopes, subjects, and teams so that AI agents can reliably query and follow them.",
   "repository": {
     "type": "git",