xdrs-core 0.14.4 → 0.14.5

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

@@ -39,6 +39,8 @@ Place a skill under the XDR type that matches the nature of the activity the ski
 - **ADR skills** - architectural evaluation, pattern compliance checks, technology selection guidance (e.g. how to review an architecture diagram, how to assess API design)
 - **BDR skills** - business process execution, market analysis, operations procedures, business rules
 
+The `[subject]` component in the folder path MUST be one of the allowed subjects for the chosen type. The required list of allowed subjects per type is defined in `_core-adr-001`.
+
 Quick test:
 - "Is the skill about *how to implement or operate* something?" → EDR.
 - "Is the skill about *how to evaluate or decide on* architecture?" → ADR.

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

@@ -21,7 +21,7 @@ Articles are Markdown documents placed inside a subject folder alongside decisio
 - In more complex cases, an article may be an index of links to other articles, grouping related documentation into a single entry point that guides readers across a set of related topics.
 - When an article tells readers which decisions to follow, it SHOULD check `Valid:` first to determine the convergence date, `Applied to:` second to determine context fit, and the decision text itself last. All documents present in the collection are considered active; articles must not present out-of-window or out-of-scope XDRs as current rules for the discussed context.
 - Articles must remain consistent with the XDRs, 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. If an article spans more than one subject, place it in `principles`.
+- Place an article in the subject folder that best matches its topic using the required list of subjects per type defined in `_core-adr-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.
 - Images and other local resource files referenced by an article SHOULD be used only when they are materially necessary and SHOULD live in `articles/assets/` next to the article files.
 - Always use lowercase file names.

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

@@ -18,6 +18,7 @@ Research documents are Markdown files placed inside a subject folder alongside d
 - `Research` is the artifact name. `researches/` is only the folder name used alongside `skills/` and `articles/`.
 - Research documents MUST live under `researches/` inside the relevant subject folder:
   `.xdrs/[scope]/[type]/[subject]/researches/[number]-[short-title].md`
+- The `[subject]` component MUST be one of the allowed subjects for the chosen type. The required list of allowed subjects per type is defined in `_core-adr-001`.
 - Research documents SHOULD stay focused on one investigated problem, comparison, or hypothesis.
 - Research documents MUST state clearly what problem or question is being investigated, the relevant system or domain context, and why the subject matters in practice.
 - Research documents MUST follow this section order: `Abstract`, `Introduction`, `Methods`, `Results`, `Discussion`, `Conclusion`, `References`.

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

@@ -22,7 +22,8 @@ Plans are Markdown documents placed inside a subject folder alongside decision r
 - A plan can be high level, describing only one milestone, or more complex, describing a WBS (work breakdown structure) along with owners, multiple milestones in a tactical sequence, and checklists to verify completeness. Actual tasks performed by actors should normally be tracked in specialized software such as GitHub or Azure DevOps.
 - The total time to deliver a plan should not be more than 2 years. If more time is needed, create a new plan later with what was learned.
 - Plans MUST live under `plans/` inside the relevant subject folder: `.xdrs/[scope]/[type]/[subject]/plans/[number]-[short-title].md`
-- Plans MUST include an `Expected end date:` field in ISO format (YYYY-MM-DD).
+- The `[subject]` component MUST be one of the allowed subjects for the chosen type. The required list of allowed subjects per type is defined in `_core-adr-001`.
+- 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.
 - Images and other local resource files referenced by a plan SHOULD live in `plans/assets/` next to the plan files.
@@ -70,12 +71,12 @@ E.g.: Our checkout abandon rate is 50%, and it's increasing over time.]
 [Required. What we expect to achieve to solve the problem described above. Under 200 words.
 E.g.: Reduce payment time in our App by 30% and fix the 3 most impactful bugs.]
 
+Expected end date: YYYY-MM-DD
+
 ## Acceptance Criteria
 
 [Optional. Used to make it clear what the expected result is and to create a way to verify when the goal is achieved. May include a short checklist. Under 100 words.]
 
-Expected end date: YYYY-MM-DD
-
 ## Approach
 
 [Optional. High level description about how to achieve the result and the strategy used, including how to engage people, projects, organize the work, how to learn unknowns, deal with risks, and distribute workload. May include a WBS with the hierarchy of the work. Under 300 words.]

package/.xdrs/_core/adrs/principles/skills/002-write-xdr/002-write-xdr.test.int.report

@@ -2,13 +2,13 @@
   "Create a very small XDR deciding to use -8b1a2ddd": {
     "result": "success",
     "contextFiles": [
+      ".xdrs/_core/adrs/index.md",
       ".xdrs/_core/adrs/principles/001-xdrs-core.md",
       ".xdrs/_core/adrs/principles/002-xdr-standards.md",
-      ".xdrs/_local/bdrs/index.md",
-      ".xdrs/_local/bdrs/operations/001-agent-behavior-validation-procedure.md",
+      ".xdrs/_core/adrs/principles/skills/002-write-xdr/SKILL.md",
       ".xdrs/index.md",
       "AGENTS.md"
     ],
-    "contextHash": "5ceaa69409aa5eff1728d3a4212865a0"
+    "contextHash": "8d030307248237f1775ab38126d354db"
   }
 }

package/.xdrs/_core/adrs/principles/skills/003-write-skill/003-write-skill.test.int.report

@@ -2,13 +2,13 @@
   "Create a skill with instructions on how -a7079882": {
     "result": "success",
     "contextFiles": [
+      ".xdrs/_core/adrs/index.md",
       ".xdrs/_core/adrs/principles/001-xdrs-core.md",
       ".xdrs/_core/adrs/principles/003-skill-standards.md",
-      ".xdrs/_local/bdrs/index.md",
-      ".xdrs/_local/bdrs/operations/001-agent-behavior-validation-procedure.md",
+      ".xdrs/_core/adrs/principles/skills/003-write-skill/SKILL.md",
       ".xdrs/index.md",
       "AGENTS.md"
     ],
-    "contextHash": "738b99bad5adfe36fa14191c6c31ddab"
+    "contextHash": "0bbe5ae297e8b1978c7020a7bb8779c1"
   }
 }

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

@@ -37,7 +37,7 @@ Quick test:
 
 **Scope** — use `_local` unless the user explicitly names another scope.
 
-**Subject** — pick the most specific match for the chosen type (see `003-skill-standards`):
+**Subject** — pick the most specific match for the chosen type (required list per type is in `_core-adr-001`):
 - ADR subjects: `principles`, `application`, `data`, `integration`, `platform`, `controls`, `operations`
 - BDR subjects: `principles`, `marketing`, `product`, `controls`, `operations`, `organization`, `finance`, `sustainability`
 - EDR subjects: `principles`, `application`, `infra`, `observability`, `devops`, `governance`

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

@@ -48,7 +48,7 @@ If the topic spans multiple types, use `adrs`. Use the same rules as `002-write-
 - **ADR**: system context, integration pattern, overarching architectural choice
 - **EDR**: specific tool/library, coding practice, testing strategy, project structure, pipelines
 
-**Subject** — pick the subject that best matches the article's topic (see `004-article-standards`).
+**Subject** — pick the subject that best matches the article's topic (required list per type is in `_core-adr-001`).
 If the article spans more than one subject, place it in `principles`.
 
 ### Phase 3: Assign a Number and Name

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

@@ -42,7 +42,7 @@ Consult `001-xdrs-core` while making each choice in this phase. The summaries be
 - **ADR**: system context, integration pattern, overarching architectural choice
 - **EDR**: specific tool/library, coding practice, testing strategy, project structure, pipelines
 
-**Subject** — pick the most specific subject that matches the problem domain.
+**Subject** — pick the most specific subject that matches the problem domain (required list per type is in `_core-adr-001`).
 
 **Research number** — scan `.xdrs/[scope]/[type]/[subject]/researches/` for the highest existing number and increment by 1. Never reuse numbers from deleted research documents.
 

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

@@ -39,7 +39,7 @@ Consult `001-xdrs-core` while making each choice in this phase. The summaries be
 - **ADR**: system context, integration pattern, overarching architectural choice
 - **EDR**: specific tool/library, coding practice, testing strategy, project structure, pipelines
 
-**Subject** — pick the subject that best matches the plan's topic. If the plan spans more than one subject, place it in `principles`.
+**Subject** — pick the subject that best matches the plan's topic (required list per type is in `_core-adr-001`). If the plan spans more than one subject, place it in `principles`.
 
 ### Phase 3: Assign a Number and Name
 
@@ -75,12 +75,12 @@ Use the mandatory template from `007-plan-standards`:
 
 [Required. What we expect to achieve. Under 200 words.]
 
+Expected end date: YYYY-MM-DD
+
 ## Acceptance Criteria
 
 [Optional. Expected result and how to verify the goal is achieved. Under 100 words.]
 
-Expected end date: YYYY-MM-DD
-
 ## Approach
 
 [Optional. Strategy and high-level how. Under 300 words.]
@@ -110,7 +110,7 @@ Rules to apply while drafting:
 
 - Focus on the problem, solution, and approach. Avoid bloating with generic project management content.
 - Link to Decisions the plan implements, Research that informs it, and Skills that guide execution.
-- The Expected end date must be in ISO format (YYYY-MM-DD) and should not be more than 2 years from the plan creation date.
+- The Expected end date must be in ISO format (YYYY-MM-DD), placed inside the `## Proposed Solution` section, and should not be more than 2 years from the plan creation date.
 - If the plan scope is too large for 2 years, break it into multiple plans.
 - Remember that this plan must be deleted after full implementation. Write it with that ephemeral nature in mind.
 - Prefer plain Markdown, tables, or ASCII art for structure and flow.

package/lib/testPrompt.js

@@ -670,7 +670,11 @@ async function runPrompt(config, inputPrompt, judgePrompt, id, verbose) {
 function computeContextHash(model, inputPrompt, judgePrompt, contextFiles, workspaceRoot) {
 	const parts = [model, inputPrompt, judgePrompt];
 	for (const filePath of contextFiles) {
-		parts.push(fs.readFileSync(path.join(workspaceRoot, filePath), 'utf8'));
+		try {
+			parts.push(fs.readFileSync(path.join(workspaceRoot, filePath), 'utf8'));
+		} catch {
+			console.warn(`computeContextHash: file not found, ignoring: ${path.join(workspaceRoot, filePath)}`);
+		}
 	}
 	return crypto.createHash('md5').update(parts.join('\n')).digest('hex');
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "xdrs-core",
-  "version": "0.14.4",
+  "version": "0.14.5",
   "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",