xdrs-core 0.13.0 → 0.14.2

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

@@ -50,7 +50,7 @@ Quick test:
 
 1. List `.xdrs/[scope]/[type]/[subject]/skills/` for existing skills. If one already covers the goal, extend or reference it instead of creating a duplicate.
 2. Read all XDRs relevant to the skill's domain to collect rules and cross-references.
-3. Evaluate XDR metadata before operationalizing those rules. `Status:` decides whether a decision is eligible to be used, and omitted `Status:` means `Active`; `Valid:` decides whether that active decision is in force at the current moment, `Applied to:` decides whether it fits the intended task context, and the decision text defines any remaining boundaries. Keep inactive, out-of-window, or out-of-scope XDRs as background only.
+3. Evaluate XDR metadata before operationalizing those rules. All documents present in the collection are considered active. `Valid:` determines the convergence date for adoption, `Applied to:` determines whether the decision fits the intended task context, and the decision text defines any remaining boundaries. Keep out-of-window or out-of-scope XDRs as background only.
 4. Decide whether the skill is merely guidance or is being referenced by an XDR as a mandatory procedure. Do not encode policy in the skill unless it comes from a referenced XDR.
 
 ### Phase 4: Write the SKILL.md

package/.xdrs/_core/adrs/principles/skills/004-write-article/004-write-article.test.int.js

@@ -0,0 +1,24 @@
+'use strict';
+
+const path = require('path');
+const { copilotCmd, testPrompt } = require('xdrs-core');
+
+const REPO_ROOT = path.resolve(__dirname, '..', '..', '..', '..', '..', '..');
+
+jest.setTimeout(300000);
+
+test('004-write-article creates a local principles article', async () => {
+	const err = await testPrompt(
+		{
+			workspaceRoot: REPO_ROOT,
+			workspaceMode: 'copy',
+			...copilotCmd(REPO_ROOT),
+		},
+		'Create a short article for new users explaining the overall principles of xdrs, element types and the role of each document in adrs',
+		'Verify that an article markdown file was created under .xdrs/_local/adrs/principles/articles/ and that it has references to 001-xdrs-core.md',
+		null,
+		true
+	);
+
+	expect(err).toBe('');
+});

package/.xdrs/_core/adrs/principles/skills/004-write-article/004-write-article.test.int.report

@@ -0,0 +1,17 @@
+{
+  "Create a short article for new users exp-73060d4f": {
+    "result": "success",
+    "contextFiles": [
+      ".xdrs/_core/adrs/index.md",
+      ".xdrs/_core/adrs/principles/001-xdrs-core.md",
+      ".xdrs/_core/adrs/principles/004-article-standards.md",
+      ".xdrs/_core/adrs/principles/articles/001-xdrs-overview.md",
+      ".xdrs/_local/bdrs/index.md",
+      ".xdrs/_local/bdrs/operations/001-agent-behavior-validation-procedure.md",
+      ".xdrs/index.md",
+      "AGENTS.md",
+      "README.md"
+    ],
+    "contextHash": "75745a424155326ee56008bcf923999e"
+  }
+}

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

@@ -47,7 +47,7 @@ If the article spans more than one subject, place it in `principles`.
 ### Phase 4: Research XDRs and Skills to Synthesize
 
 1. Read all XDRs, Research documents, and Skills relevant to the article topic across all scopes listed in `.xdrs/index.md`.
-2. Evaluate XDR metadata before synthesizing guidance. Use `Status:` to determine whether a decision is eligible to be current guidance, treating omitted `Status:` as `Active`; use `Valid:` to determine whether that active decision is in force for the article's time horizon, `Applied to:` to determine whether it fits the audience or context being discussed, and the decision text itself for any remaining applicability boundaries.
+2. Evaluate XDR metadata before synthesizing guidance. All documents present in the collection are considered active. Use `Valid:` to determine the convergence date for adoption, `Applied to:` to determine whether the decision fits the audience or context being discussed, and the decision text itself for any remaining applicability boundaries.
 3. Identify the key points a reader needs to understand the topic end-to-end.
 4. Collect XDR IDs and file paths for cross-references. Never copy decision text verbatim; link to it.
 

package/.xdrs/_core/adrs/principles/skills/005-write-research/005-write-research.test.int.js

@@ -5,23 +5,7 @@ const { copilotCmd, testPrompt } = require('xdrs-core');
 
 const REPO_ROOT = path.resolve(__dirname, '..', '..', '..', '..', '..', '..');
 
-jest.setTimeout(300000);
-
-test('check', async () => {
-	const err = await testPrompt(
-		{
-			workspaceRoot: REPO_ROOT,
-			workspaceMode: 'in-place',
-			...copilotCmd(REPO_ROOT),
-		},
-		'Reply ONLY with "READY" after checking if SKILL 001 has any contents',
-		'Verify that the final output is ONLY "READY" and that it read file 001-lint/SKILL.md',
-		null,
-		true
-	);
-
-	expect(err).toBe('');
-});
+jest.setTimeout(600000);
 
 test('005-write-research creates an IMRAD research document in copy mode', async () => {
 	const err = await testPrompt(
@@ -30,8 +14,8 @@ test('005-write-research creates an IMRAD research document in copy mode', async
 			workspaceMode: 'copy',
 			...copilotCmd(REPO_ROOT),
 		},
-		'Create a very small research document with the following data: We measured the installation time in our monorepo and pnpm is 3.5x faster than Yarn when installing dependencies. We recommend using PNPM in our monorepo to speed up our productivity as it seems very easy to use and have a better internal hoisting mechanism.',
-		'Verify that a research file was created under .xdrs/_local/edrs/devops/researches/, that it contains the sections Abstract, Introduction, Methods, Results, Discussion, Conclusion, and References, and that the content contains all the provided data in input prompt, and doesn\'t contain more than 20% of additional information outside the central topic.',
+		'Create a very small research document with the following data: Java vs Python for datascience projects. Java has much less libraries and community momentum than Python. Java is faster, but in general our DS applications doesn\'t require high performance. Is some cases we could use Spark for data and very specific ETL and transformations, but in general Python should be the norm for Data Science projects, especially in the early phases.',
+		'Verify that a research file was created under .xdrs/_local/edrs/application/researches/, that it contains the sections Abstract, Introduction, Methods, Results, Discussion, Conclusion, and References, have the right ratio of words on the sections (not worse than 50% in deviation) and that the content contains all the provided data in input prompt, and doesn\'t contain more than 20% of additional information outside the central topic. Check also if there is at least one comparison table between the options, ',
 		null,
 		true
 	);

package/.xdrs/_core/adrs/principles/skills/005-write-research/005-write-research.test.int.report

@@ -1,22 +1,15 @@
 {
-  "Reply ONLY with \"READY\" after checking i-a61b0904": {
-    "result": "success",
-    "contextFiles": [
-      ".xdrs/_core/adrs/principles/skills/001-lint/SKILL.md",
-      "AGENTS.md"
-    ],
-    "contextHash": "3dcbcc0a03f4d3b2a797c28165f6f68a"
-  },
-  "Create a very small research document wi-ea3740cd": {
+  "Create a very small research document wi-7896a781": {
     "result": "success",
     "contextFiles": [
+      ".github/skills/005-write-research/005-write-research.test.int.js",
+      ".xdrs/_core/adrs/index.md",
       ".xdrs/_core/adrs/principles/001-xdrs-core.md",
       ".xdrs/_core/adrs/principles/006-research-standards.md",
-      ".xdrs/_local/bdrs/index.md",
-      ".xdrs/_local/edrs/devops/researches/001-pnpm-vs-yarn-install-speed-monorepo.md",
+      ".xdrs/_local/edrs/languages/researches/001-java-vs-python-for-datascience.md",
       ".xdrs/index.md",
       "AGENTS.md"
     ],
-    "contextHash": "a8ffde30ac3757f1185fee620f526720"
+    "contextHash": "2f06eb73c19194e53321d4b75c0fc214"
   }
 }

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

@@ -45,7 +45,7 @@ Consult `001-xdrs-core` while making each choice in this phase. The summaries be
 ### Phase 3: Research Existing Artifacts
 
 1. Read relevant XDRs across all scopes listed in `.xdrs/index.md`.
-2. Evaluate XDR metadata before treating any decision as current context. `Status:` decides whether a decision is eligible to be used, and omitted `Status:` means `Active`; `Valid:` decides whether that active decision is in force at the current moment, `Applied to:` decides whether it fits the intended task context, and the decision text defines any remaining boundaries. Keep inactive, out-of-window, or out-of-scope XDRs as background only.
+2. Evaluate XDR metadata before treating any decision as current context. All documents present in the collection are considered active. `Valid:` determines the convergence date for adoption, `Applied to:` determines whether the decision fits the intended task context, and the decision text defines any remaining boundaries. Keep out-of-window or out-of-scope XDRs as background only.
 3. Read existing research documents in the same or overlapping subjects to avoid duplicating the same study.
 4. Read related skills or articles if they contain context, implementation limits, or terminology that must be reflected.
 5. Collect links that should appear in the final `## References` section.

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

@@ -0,0 +1,151 @@
+---
+name: 006-write-plan
+description: >
+  Creates a new plan document following XDR plan standards: selects scope, type, subject, and number;
+  then writes a focused execution plan with problem context, proposed solution, approach, milestones, and deliverables.
+  Activate this skill when the user asks to create, add, or write a plan, project plan, or execution plan within an XDR project.
+metadata:
+  author: flaviostutz
+  version: "1.0"
+---
+
+## Overview
+
+Guides the creation of a well-structured plan document by following `_core-adr-007`, consulting `xdr-standards` for every core element definition, researching related XDRs and existing plans, and producing a focused execution document that connects to the decisions, research, and skills it relates to.
+
+## Instructions
+
+### Phase 1: Understand the Plan Goal
+
+1. Read `.xdrs/_core/adrs/principles/007-plan-standards.md` in full to internalize the template, placement rules, numbering rules, and the constraint that plans are ephemeral and must be deleted after implementation.
+2. Read `.xdrs/_core/adrs/principles/001-xdrs-core.md` in full before defining the plan's core elements. Treat it as the canonical source for how to choose and write type, scope, subject, numbering, naming, and folder placement.
+3. Identify the problem being solved, the proposed solution, and the expected timeline from user input or context. Do NOT proceed without a clear problem statement and proposed solution. Ask the user if these are not clear.
+
+
+### Phase 2: Select Scope, Type, and Subject
+
+Consult `001-xdrs-core` while making each choice in this phase. The summaries below are orientation only; when any detail is unclear, the standard decides.
+
+**Scope** — use `_local` unless the user explicitly names another scope.
+
+**Type** — match the type of the XDRs the plan primarily implements or relates to (`adrs`, `bdrs`, or `edrs`).
+- **BDR**: business process, product policy, strategic rule, operational procedure
+- **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`.
+
+### Phase 3: Assign a Number and Name
+
+1. List `.xdrs/[scope]/[type]/[subject]/plans/` (create the folder if it does not exist).
+2. Find the highest existing plan number in that namespace and increment by 1. Never reuse numbers.
+3. Choose a short lowercase kebab-case title that describes the initiative clearly.
+   - Good: `checkout-performance`, `onboarding-redesign`, `api-migration-v2`
+   - Avoid: `plan`, `project`, `misc`
+
+### Phase 4: Research Related Artifacts
+
+1. Read all XDRs, Research documents, Skills, and existing Plans relevant to the plan topic across all scopes listed in `.xdrs/index.md`.
+2. Evaluate XDR metadata before treating any decision as current context. All documents present in the collection are considered active. `Valid:` determines the convergence date for adoption, `Applied to:` determines whether the decision fits the intended context, and the decision text defines any remaining boundaries.
+3. Identify Decisions that this plan implements, Research that informs the planning, and any existing Plans that overlap.
+4. Collect artifact IDs and file paths for cross-references.
+
+### Phase 5: Write the Plan
+
+Use the mandatory template from `007-plan-standards`:
+
+```markdown
+# [scope]-plan-[number]: [Short Title]
+
+## Executive Summary
+
+[Required. Bullet points summarizing all sections below. Under 500 words.]
+
+## Context and Problem Statement
+
+[Required. Why are we executing this plan? What is the impact? Who is impacted? Under 200 words.]
+
+## Proposed Solution
+
+[Required. What we expect to achieve. Under 200 words.]
+
+## 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.]
+
+## Key Deliverables
+
+[Optional. Main outputs needed. Under 300 words.]
+
+## Key Resources
+
+[Optional. Equipment, people, budget, dependencies. Under 100 words.]
+
+## Milestones
+
+[Optional. Goals with acceptance criteria, owners, and due dates. Under 1000 words per milestone.]
+
+## Risks Identified
+
+[Optional. Risks with description and mitigation strategy. Under 1000 words.]
+
+## References
+
+- [Related XDR or artifact](relative/path.md) - Brief description of relevance
+```
+
+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.
+- 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.
+- If the plan genuinely needs local images or supporting files, store them in `.xdrs/[scope]/[type]/[subject]/plans/assets/` and link with a relative path.
+- Use lowercase file names. Never use emojis.
+
+### Phase 6: Place and Register
+
+1. Save the file at `.xdrs/[scope]/[type]/[subject]/plans/[number]-[short-title].md`.
+2. Add a link to the plan in the canonical index for that scope+type (`.xdrs/[scope]/[type]/index.md`).
+3. Add back-references in the XDRs, Research documents, and Skills that the plan relates to, under their `## References` section.
+
+### Phase 7: Verify with Lint
+
+1. Run the CLI lint utility from the repository root:
+   ```
+   npx -y xdrs-core lint .
+   ```
+2. Fix all reported errors before considering the task complete.
+
+## Examples
+
+**Input:** "Create a plan for migrating our API to v2."
+
+**Expected actions:**
+1. Read `007-plan-standards.md`.
+2. Topic: API v2 migration. Scope: `_local`.
+3. Type: `adrs` (architectural). Subject: `integration` or `application`.
+4. Research related XDRs about API design and integration patterns.
+5. Draft the plan with clear problem, solution, milestones, and expected end date.
+6. Save, register in canonical index, and lint.
+
+## Edge Cases
+
+- If a plan is too large (more than 2 years), split it into multiple smaller plans. Each plan should be independently actionable and produce its own deliverables.
+- If a plan spawns sub-plans during implementation, each sub-plan is a separate plan document in the appropriate subject folder. Link them in the References section.
+- If a plan is fully implemented, delete it and confirm that all lasting outputs (Decisions, Skills, Articles, etc.) are properly linked and indexed.
+- If the user asks for a plan that is really just a decision, guide them to create an XDR instead.
+
+## References
+
+- [_core-adr-001 - XDRs core](../../001-xdrs-core.md)
+- [_core-adr-007 - Plan standards](../../007-plan-standards.md)
+- [_core-adr-002 - XDR standards](../../002-xdr-standards.md)

package/README.md

@@ -12,12 +12,13 @@ This project defines a standard for organizing XDRs that satisfies the following
 
 ## XDR elements
 
-Every XDR package contains four types of documents:
+Every XDR package contains five types of documents:
 
 - **Decision Records (XDRs)** — Architectural (ADR), Business (BDR), or Engineering (EDR) records that capture a single decision, its rationale, and the rules that follow from it. They are the source of truth.
 - **Research** — Exploratory documents that capture the problem being investigated, constraints or requirements, findings, and option tradeoffs that back a decision during its lifecycle. One research document may inform multiple downstream decisions, but it is not a replacement for the Decision Record.
 - **Skills** — Step-by-step procedural guides that can be followed by humans, AI agents, or both. Skills are task-based artifacts with a concrete outcome and should include enough detail to verify the task was completed correctly. A skill may start as a fully manual procedure and evolve toward partial or full AI automation over time.
 - **Articles** — Synthetic explanatory texts that combine information from multiple XDRs, Research documents, and Skills around a specific topic or audience. They never replace XDRs as source of truth.
+- **Plans** — Ephemeral execution documents that describe a problem, proposed solution, and the approach and activities needed to solve it. Plans have a clear start and end and must be deleted after full implementation. Lasting outputs are captured as Decisions, Skills, Articles, or other artifacts.
 
 ## Getting started
 
@@ -65,7 +66,7 @@ The folder layout, file naming, and document format are designed so that AI agen
 - Each XDR is a small, focused Markdown file (target under 1300 words), covering one decision.
 - The canonical index per scope and type lists all XDRs with short descriptions, enabling agents to identify relevant records without reading every file.
 - The root index at `.xdrs/index.md` provides a single entry point for discovery.
-- XDR metadata gives agents a first-pass filter: check `Status` first, treating an omitted `Status` as `Active`; then check `Valid`, then `Applied to`, and finally the decision text itself to confirm the decision should be used in the current context.
+- XDR metadata gives agents a first-pass filter: check `Valid` for the convergence date, then check `Applied to`, and finally the decision text itself to confirm the decision should be used in the current context. All documents present in the collection are considered active.
 - Decisions cross-reference each other by XDR ID rather than duplicating content, keeping individual files concise.
 - Subject folders reduce the search space when a query maps to a known domain.
 
@@ -96,6 +97,9 @@ This is especially important for BDRs: because business rules govern decisions t
         articles/                   # optional synthetic views over XDRs, Research, and Skills
           [number]-[short-title].md
           assets/
+        plans/                      # optional ephemeral execution plans
+          [number]-[short-title].md
+          assets/
 ```
 
 Document types:
@@ -106,6 +110,7 @@ Document types:
 - **Research** - Exploratory support material used while evaluating or updating a decision. Research captures constraints, findings, options, and proposal tradeoffs, but it is not the source of truth.
 - **Skills** - Step-by-step procedural guides that can be followed by humans, AI agents, or both. Must comply with Decision Records, but add the execution detail they lack. Skills are not mandatory by themselves unless referenced by an XDR or another policy artifact. A skill may start as a fully manual human procedure and evolve incrementally toward partial or full AI automation without being restructured. Co-located with the XDRs they implement inside `skills/` sub-directories.
 - **Articles** - Synthetic views that explain concepts or combine information from multiple Decision Records, Research documents, and Skills into a coherent text for a specific topic or audience. Articles are not the source of truth; Decision Records take precedence when there is a conflict. Useful as navigational indexes that link related artifacts around a specific aspect.
+- **Plans** - Ephemeral execution documents that describe a problem, proposed solution, and the approach and activities needed to solve it. Plans have a clear start and end and must be deleted after full implementation. Lasting outputs are captured as Decisions, Skills, Articles, or other artifacts. Co-located with XDRs inside `plans/` sub-directories.
 
 See [.xdrs/index.md](.xdrs/index.md) for the full list of active decision records.
 
@@ -157,9 +162,11 @@ The `lint` command reads `./.xdrs/**` from the given workspace path and checks c
 - skill numbering uniqueness per `scope/type/subject/skills`
 - article numbering uniqueness per `scope/type/subject/articles`
 - research numbering uniqueness per `scope/type/subject/researches`
+- plan numbering uniqueness per `scope/type/subject/plans`
+- plan `Expected end date:` field presence and ISO date format
 - canonical index presence and link consistency
 - root index coverage for all discovered canonical indexes
-- XDR metadata section placement and `Status` / `Valid` / `Applied to` field format
+- XDR metadata section placement and `Valid` / `Applied to` field format
 - local image and `assets/` links resolving inside the sibling `assets/` folder for each document
 
 Examples:

package/lib/lint.js

@@ -21,7 +21,7 @@ const RESERVED_SCOPES = new Set(['_core', '_local']);
 const NUMBERED_FILE_RE = /^(\d{3,})-([a-z0-9-]+)\.md$/;
 const NUMBERED_DIR_RE = /^(\d{3,})-([a-z0-9-]+)$/;
 const REQUIRED_ROOT_INDEX_TEXT = 'XDRs in scopes listed last override the ones listed first';
-const SUBJECT_ARTIFACT_DIRS = new Set(['skills', 'articles', 'researches']);
+const SUBJECT_ARTIFACT_DIRS = new Set(['skills', 'articles', 'researches', 'plans']);
 const RESOURCE_DIR_NAME = 'assets';
 const IMAGE_EXTENSIONS = new Set(['.png', '.jpg', '.jpeg', '.gif', '.svg', '.webp', '.bmp']);
 
@@ -206,6 +206,10 @@ function lintSubjectDirectory(xdrsRoot, scopeName, typeName, subjectName, xdrNum
         artifacts.push(...lintResearchDirectory(xdrsRoot, scopeName, typeName, subjectName, entryPath, errors));
         continue;
       }
+      if (entry.name === 'plans') {
+        artifacts.push(...lintPlansDirectory(xdrsRoot, scopeName, typeName, subjectName, entryPath, errors));
+        continue;
+      }
 
       errors.push(`Unexpected directory under ${scopeName}/${typeName}/${subjectName}: ${toDisplayPath(entryPath)}`);
       continue;
@@ -277,11 +281,10 @@ function lintXdrMetadata(content, filePath, errors) {
         start: metadataLine + 1,
         end: (headingLines.find((lineIndex) => lineIndex > metadataLine) ?? lines.length) - 1
       };
-  const statusLineNumbers = findFieldLines(lines, ignoredLines, 'Status:');
   const appliedLineNumbers = findFieldLines(lines, ignoredLines, 'Applied to:');
   const validLineNumbers = findFieldLines(lines, ignoredLines, 'Valid:');
 
-  if (!metadataRange && (statusLineNumbers.length > 0 || appliedLineNumbers.length > 0 || validLineNumbers.length > 0)) {
+  if (!metadataRange && (appliedLineNumbers.length > 0 || validLineNumbers.length > 0)) {
     errors.push(`XDR metadata fields require a ## Metadata section immediately before Context and Problem Statement: ${toDisplayPath(filePath)}`);
     return;
   }
@@ -290,18 +293,13 @@ function lintXdrMetadata(content, filePath, errors) {
     return;
   }
 
-  const metadataStatus = statusLineNumbers.filter((lineIndex) => isLineInsideRange(lineIndex, metadataRange));
   const metadataApplied = appliedLineNumbers.filter((lineIndex) => isLineInsideRange(lineIndex, metadataRange));
   const metadataValid = validLineNumbers.filter((lineIndex) => isLineInsideRange(lineIndex, metadataRange));
 
-  if (metadataStatus.length === 0 && metadataApplied.length === 0 && metadataValid.length === 0) {
+  if (metadataApplied.length === 0 && metadataValid.length === 0) {
     errors.push(`XDR metadata section must be omitted when no metadata fields are defined: ${toDisplayPath(filePath)}`);
   }
 
-  if (metadataStatus.length > 1) {
-    errors.push(`XDR metadata must not repeat Status: ${toDisplayPath(filePath)}`);
-  }
-
   if (metadataApplied.length > 1) {
     errors.push(`XDR metadata must not repeat Applied to: ${toDisplayPath(filePath)}`);
   }
@@ -310,7 +308,7 @@ function lintXdrMetadata(content, filePath, errors) {
     errors.push(`XDR metadata must not repeat Valid: ${toDisplayPath(filePath)}`);
   }
 
-  for (const lineIndex of [...statusLineNumbers, ...appliedLineNumbers, ...validLineNumbers]) {
+  for (const lineIndex of [...appliedLineNumbers, ...validLineNumbers]) {
     if (!isLineInsideRange(lineIndex, metadataRange)) {
       errors.push(`XDR metadata fields must be declared inside ## Metadata: ${toDisplayPath(filePath)}`);
       break;
@@ -326,28 +324,22 @@ function lintXdrMetadata(content, filePath, errors) {
     if (trimmed === '') {
       continue;
     }
-    const currentFieldOrder = trimmed.startsWith('Status:')
+    const currentFieldOrder = trimmed.startsWith('Valid:')
       ? 0
-      : trimmed.startsWith('Valid:')
+      : trimmed.startsWith('Applied to:')
         ? 1
-        : trimmed.startsWith('Applied to:')
-          ? 2
-          : -1;
+        : -1;
     if (currentFieldOrder === -1) {
-      errors.push(`XDR metadata section only supports Status:, Valid:, and Applied to: fields: ${toDisplayPath(filePath)}`);
+      errors.push(`XDR metadata section only supports Valid: and Applied to: fields: ${toDisplayPath(filePath)}`);
       break;
     }
     if (currentFieldOrder < previousFieldOrder) {
-      errors.push(`XDR metadata fields must be ordered as Status:, Valid:, Applied to: ${toDisplayPath(filePath)}`);
+      errors.push(`XDR metadata fields must be ordered as Valid:, Applied to: ${toDisplayPath(filePath)}`);
       break;
     }
     previousFieldOrder = currentFieldOrder;
   }
 
-  if (metadataStatus.length === 1) {
-    lintStatusField(lines[metadataStatus[0]], filePath, errors);
-  }
-
   if (metadataApplied.length === 1) {
     const value = lines[metadataApplied[0]].slice('Applied to:'.length).trim();
     if (value === '') {
@@ -362,32 +354,18 @@ function lintXdrMetadata(content, filePath, errors) {
   }
 }
 
-function lintStatusField(line, filePath, errors) {
-  const value = line.slice('Status:'.length).trim().replace(/\.$/, '');
-
-  if (value !== 'Draft' && value !== 'Active' && value !== 'Deprecated') {
-    errors.push(`XDR Status: must be Draft, Active, or Deprecated: ${toDisplayPath(filePath)}`);
-  }
-}
-
 function lintValidField(line, filePath, errors) {
   const value = line.slice('Valid:'.length).trim().replace(/\.$/, '');
 
-  const validMatch = value.match(/^(?:from\s+(\d{4}-\d{2}-\d{2})(?:\s+until\s+(\d{4}-\d{2}-\d{2}))?|until\s+(\d{4}-\d{2}-\d{2}))$/);
+  const validMatch = value.match(/^from\s+(\d{4}-\d{2}-\d{2})$/);
   if (!validMatch) {
-    errors.push(`XDR Valid: must be from YYYY-MM-DD, until YYYY-MM-DD, or from YYYY-MM-DD until YYYY-MM-DD: ${toDisplayPath(filePath)}`);
+    errors.push(`XDR Valid: must be from YYYY-MM-DD: ${toDisplayPath(filePath)}`);
     return;
   }
 
   const fromDate = validMatch[1];
-  const untilDate = validMatch[2] ?? validMatch[3];
-  if ((fromDate && !isIsoDate(fromDate)) || (untilDate && !isIsoDate(untilDate))) {
+  if (!isIsoDate(fromDate)) {
     errors.push(`XDR Valid: must use ISO dates in YYYY-MM-DD format: ${toDisplayPath(filePath)}`);
-    return;
-  }
-
-  if (fromDate && untilDate && fromDate > untilDate) {
-    errors.push(`XDR Valid: from date must be on or before until date: ${toDisplayPath(filePath)}`);
   }
 }
 
@@ -541,6 +519,76 @@ function lintResearchDirectory(xdrsRoot, scopeName, typeName, subjectName, resea
   return artifacts;
 }
 
+function lintPlansDirectory(xdrsRoot, scopeName, typeName, subjectName, plansPath, errors) {
+  const artifacts = [];
+  const planNumbers = new Map();
+  const entries = safeReadDir(plansPath, errors, `read plans directory ${scopeName}/${typeName}/${subjectName}/plans`);
+
+  for (const entry of entries) {
+    const entryPath = path.join(plansPath, entry.name);
+    if (entry.isDirectory() && entry.name === RESOURCE_DIR_NAME) {
+      continue;
+    }
+
+    if (!entry.isFile()) {
+      errors.push(`Unexpected directory in plans folder: ${toDisplayPath(entryPath)}`);
+      continue;
+    }
+
+    const match = entry.name.match(NUMBERED_FILE_RE);
+    if (!match) {
+      errors.push(`Invalid plan file name: ${toDisplayPath(entryPath)}`);
+      continue;
+    }
+
+    artifacts.push(entryPath);
+
+    const number = match[1];
+    const previous = planNumbers.get(number);
+    if (previous) {
+      errors.push(`Duplicate plan number ${number} in ${scopeName}/${typeName}/${subjectName}/plans: ${toDisplayPath(previous)} and ${toDisplayPath(entryPath)}`);
+    } else {
+      planNumbers.set(number, entryPath);
+    }
+
+    if (entry.name !== entry.name.toLowerCase()) {
+      errors.push(`Plan file name must be lowercase: ${toDisplayPath(entryPath)}`);
+    }
+
+    const content = fs.readFileSync(entryPath, 'utf8');
+    const expectedHeader = `# ${scopeName}-plan-${number}:`;
+    const firstLine = firstNonEmptyLine(content);
+    if (!firstLine.startsWith(expectedHeader)) {
+      errors.push(`Plan title must start with "${expectedHeader}": ${toDisplayPath(entryPath)}`);
+    }
+
+    lintPlanExpectedEndDate(content, entryPath, errors);
+    lintDocumentResourceLinks(entryPath, errors);
+  }
+
+  return artifacts;
+}
+
+function lintPlanExpectedEndDate(content, filePath, errors) {
+  const lines = content.split(/\r?\n/);
+  const ignoredLines = findIgnoredMarkdownLines(lines);
+  const expectedEndDateLines = findFieldLines(lines, ignoredLines, 'Expected end date:');
+
+  if (expectedEndDateLines.length === 0) {
+    errors.push(`Plan must include an Expected end date: field: ${toDisplayPath(filePath)}`);
+    return;
+  }
+
+  if (expectedEndDateLines.length > 1) {
+    errors.push(`Plan must not repeat Expected end date: ${toDisplayPath(filePath)}`);
+  }
+
+  const value = lines[expectedEndDateLines[0]].slice('Expected end date:'.length).trim().replace(/\.$/, '');
+  if (!isIsoDate(value)) {
+    errors.push(`Plan Expected end date: must be a valid ISO date in YYYY-MM-DD format: ${toDisplayPath(filePath)}`);
+  }
+}
+
 function lintTypeIndex(indexPath, xdrsRoot, artifacts, errors) {
   const content = fs.readFileSync(indexPath, 'utf8');
   const localLinks = parseLocalLinks(content, path.dirname(indexPath));

package/lib/testPrompt.js

@@ -231,6 +231,7 @@ async function runJudgePhase({ judgePrompt, commandTemplate, continueFlag, works
 		'',
 		'<INSTRUCTIONS>',
 		'You are evaluating the result of the task you completed in the RUN PHASE.',
+		'Don\'t ask any questions and assume automatically everything because you are running in a testing environment without the possibility of user interaction',
 		'Read files from the workspace directly when you need their contents.',
 		'ALWAYS answer with JSON using the schema specified below, and never include any other text.',
 		'Response schema: {"pass":false,"text":"plain text summary of the evaluation","findings":[{"target":"file","path":"relative/path.ext","line":1,"message":"explanation","assertionRef":"exact relevant phrase from the judge prompt"}]}.',

package/package.json

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