@fission-ai/openspec 1.4.1 → 1.6.0-beta.1

package/dist/core/templates/workflows/sync-specs.js

@@ -1,3 +1,4 @@
+import { STORE_SELECTION_GUIDANCE } from './store-selection.js';
 export function getSyncSpecsSkillTemplate() {
     return {
         name: 'openspec-sync-specs',
@@ -6,6 +7,8 @@ export function getSyncSpecsSkillTemplate() {
 
 This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
 
+${STORE_SELECTION_GUIDANCE}
+
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**
@@ -25,8 +28,6 @@ This is an **agent-driven** operation - you will read delta specs and directly e
    openspec status --change "<name>" --json
    \`\`\`
 
-   If status reports \`actionContext.mode: "workspace-planning"\`, explain that workspace spec sync is not supported in this slice and STOP. Do not fall back to repo-local paths or edit linked repos.
-
 3. **Find delta specs**
 
    Use \`artifactPaths.specs.existingOutputPaths\` from the status JSON as the list of delta spec files.
@@ -153,6 +154,8 @@ export function getOpsxSyncCommandTemplate() {
 
 This is an **agent-driven** operation - you will read delta specs and directly edit main specs to apply the changes. This allows intelligent merging (e.g., adding a scenario without copying the entire requirement).
 
+${STORE_SELECTION_GUIDANCE}
+
 **Input**: Optionally specify a change name after \`/opsx:sync\` (e.g., \`/opsx:sync add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**
@@ -172,8 +175,6 @@ This is an **agent-driven** operation - you will read delta specs and directly e
    openspec status --change "<name>" --json
    \`\`\`
 
-   If status reports \`actionContext.mode: "workspace-planning"\`, explain that workspace spec sync is not supported in this slice and STOP. Do not fall back to repo-local paths or edit linked repos.
-
 3. **Find delta specs**
 
    Use \`artifactPaths.specs.existingOutputPaths\` from the status JSON as the list of delta spec files.

package/dist/core/templates/workflows/update-change.d.ts

@@ -0,0 +1,10 @@
+/**
+ * Skill Template Workflow Modules
+ *
+ * This file is generated by splitting the legacy monolithic
+ * templates file into workflow-focused modules.
+ */
+import type { SkillTemplate, CommandTemplate } from '../types.js';
+export declare function getUpdateChangeSkillTemplate(): SkillTemplate;
+export declare function getOpsxUpdateCommandTemplate(): CommandTemplate;
+//# sourceMappingURL=update-change.d.ts.map

package/dist/core/templates/workflows/update-change.js

@@ -0,0 +1,167 @@
+import { STORE_SELECTION_GUIDANCE } from './store-selection.js';
+export function getUpdateChangeSkillTemplate() {
+    return {
+        name: 'openspec-update-change',
+        description: "Update an OpenSpec change by revising its existing planning artifacts and keeping them coherent with one another. Use when the user wants to revise a change's plan, fold new decisions into it, or reconcile its artifacts after an edit. Never edits code.",
+        instructions: `Revise a change's existing planning artifacts and keep them coherent. Never edit code.
+
+${STORE_SELECTION_GUIDANCE}
+
+**Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run \`openspec list --json\` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to update.
+
+   Present the top 3-4 most recently modified changes as options, showing:
+   - Change name
+   - Schema (from \`schema\` field if present, otherwise "spec-driven")
+   - Status (e.g., "0/5 tasks", "complete", "no tasks")
+   - How recently it was modified (from \`lastModified\` field)
+
+   Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to update.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Get the change's artifacts**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+   Parse the JSON to understand current state. The response includes:
+   - \`schemaName\`: The workflow schema being used (e.g., "spec-driven")
+   - \`artifacts\`: Array of artifacts with their status ("done", "ready", "blocked")
+   - \`isComplete\`: Boolean indicating if all artifacts are complete
+   - \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`actionContext\`: path and scope context. Use these instead of assuming repo-local paths.
+
+   The artifact ids and paths come from the active schema - do NOT assume them, and do NOT branch on hardcoded artifact names. Custom schemas must work unchanged.
+
+   The files to edit are \`artifactPaths.<id>.existingOutputPaths\` - the concrete files that exist on disk, already glob-expanded for glob artifacts (e.g. \`specs/**/*.md\`). Do NOT write to \`resolvedOutputPath\`: for a glob artifact it is still the glob pattern, not a real file.
+
+3. **Understand the request**
+   - If the user asked for a specific revision ("the design now uses X"), that is the starting edit.
+   - If they only said "update" / "make this coherent", treat it as a coherence review: read the existing artifacts and check them against each other for contradictions, gaps, and duplication.
+
+4. **Read and reconcile**
+   - Read the artifact(s) the request touches and the change's other existing artifacts.
+   - Apply the requested edit. Then check every other existing artifact against it - in ANY direction: an edit to a later artifact may require revising an earlier one, not only the other way around. Build order is a useful reading order, not a constraint on which artifacts may be revised.
+   - Note everything that is now inconsistent, missing, or contradictory.
+   - Revise only files that already exist (\`existingOutputPaths\`). Do NOT create artifacts that don't exist yet, and do NOT invent new files under a glob artifact - note them and point the user to \`/opsx:continue\` to create them.
+   - If the change is already coherent, say so and make no edits.
+
+5. **Confirm and apply, one artifact at a time**
+   - Show each proposed revision and why. Write only after the user confirms.
+   - If the user rejects a revision, do not write it - leave that artifact unchanged.
+   - When a substantial rewrite is needed, get that artifact's rules and template first:
+     \`\`\`bash
+     openspec instructions <artifact-id> --change "<name>" --json
+     \`\`\`
+
+6. **Point to the next step (guidance only - NEVER act on it)**
+   - Artifacts still missing -> suggest \`/opsx:continue\` to create them.
+   - Change already implemented (tasks checked off / already applied) -> the code may no longer match the revised plan; suggest \`/opsx:apply\` to carry the delta into code.
+   - Everything done and implemented -> suggest \`/opsx:archive\`.
+
+**Output**
+
+After each invocation, show:
+- Which artifacts were revised (and which proposed revisions were rejected)
+- Anything deferred to \`/opsx:continue\` (not-yet-created artifacts or files)
+- Where the change stands and the recommended next command
+
+**Guardrails**
+- Planning artifacts only - NEVER edit implementation code. If the revised plan implies code changes, stop and point to \`/opsx:apply\`.
+- Use the artifact ids and paths reported by \`openspec status\`; never branch on hardcoded artifact names.
+- Edit only the concrete files in \`existingOutputPaths\`; never write to a glob \`resolvedOutputPath\`.
+- Do not advance the build frontier: no new artifacts, no new files under glob artifacts - that is \`/opsx:continue\`'s job.
+- Confirm every edit with the user before writing.
+- If the request changes the change's *intent* rather than refining it, recommend starting fresh with \`/opsx:new\` (the "Update vs. Start Fresh" heuristic).`,
+        license: 'MIT',
+        compatibility: 'Requires openspec CLI.',
+        metadata: { author: 'openspec', version: '1.0' },
+    };
+}
+export function getOpsxUpdateCommandTemplate() {
+    return {
+        name: 'OPSX: Update',
+        description: "Update a change - revise existing planning artifacts and keep them coherent (Experimental)",
+        category: 'Workflow',
+        tags: ['workflow', 'artifacts', 'experimental'],
+        content: `Revise a change's existing planning artifacts and keep them coherent. Never edit code.
+
+${STORE_SELECTION_GUIDANCE}
+
+**Input**: Optionally specify a change name after \`/opsx:update\` (e.g., \`/opsx:update add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
+
+**Steps**
+
+1. **If no change name provided, prompt for selection**
+
+   Run \`openspec list --json\` to get available changes sorted by most recently modified. Then use the **AskUserQuestion tool** to let the user select which change to update.
+
+   Present the top 3-4 most recently modified changes as options, showing:
+   - Change name
+   - Schema (from \`schema\` field if present, otherwise "spec-driven")
+   - Status (e.g., "0/5 tasks", "complete", "no tasks")
+   - How recently it was modified (from \`lastModified\` field)
+
+   Mark the most recently modified change as "(Recommended)" since it's likely what the user wants to update.
+
+   **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
+
+2. **Get the change's artifacts**
+   \`\`\`bash
+   openspec status --change "<name>" --json
+   \`\`\`
+   Parse the JSON to understand current state. The response includes:
+   - \`schemaName\`: The workflow schema being used (e.g., "spec-driven")
+   - \`artifacts\`: Array of artifacts with their status ("done", "ready", "blocked")
+   - \`isComplete\`: Boolean indicating if all artifacts are complete
+   - \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`actionContext\`: path and scope context. Use these instead of assuming repo-local paths.
+
+   The artifact ids and paths come from the active schema - do NOT assume them, and do NOT branch on hardcoded artifact names. Custom schemas must work unchanged.
+
+   The files to edit are \`artifactPaths.<id>.existingOutputPaths\` - the concrete files that exist on disk, already glob-expanded for glob artifacts (e.g. \`specs/**/*.md\`). Do NOT write to \`resolvedOutputPath\`: for a glob artifact it is still the glob pattern, not a real file.
+
+3. **Understand the request**
+   - If the user asked for a specific revision ("the design now uses X"), that is the starting edit.
+   - If they only said "update" / "make this coherent", treat it as a coherence review: read the existing artifacts and check them against each other for contradictions, gaps, and duplication.
+
+4. **Read and reconcile**
+   - Read the artifact(s) the request touches and the change's other existing artifacts.
+   - Apply the requested edit. Then check every other existing artifact against it - in ANY direction: an edit to a later artifact may require revising an earlier one, not only the other way around. Build order is a useful reading order, not a constraint on which artifacts may be revised.
+   - Note everything that is now inconsistent, missing, or contradictory.
+   - Revise only files that already exist (\`existingOutputPaths\`). Do NOT create artifacts that don't exist yet, and do NOT invent new files under a glob artifact - note them and point the user to \`/opsx:continue\` to create them.
+   - If the change is already coherent, say so and make no edits.
+
+5. **Confirm and apply, one artifact at a time**
+   - Show each proposed revision and why. Write only after the user confirms.
+   - If the user rejects a revision, do not write it - leave that artifact unchanged.
+   - When a substantial rewrite is needed, get that artifact's rules and template first:
+     \`\`\`bash
+     openspec instructions <artifact-id> --change "<name>" --json
+     \`\`\`
+
+6. **Point to the next step (guidance only - NEVER act on it)**
+   - Artifacts still missing -> suggest \`/opsx:continue\` to create them.
+   - Change already implemented (tasks checked off / already applied) -> the code may no longer match the revised plan; suggest \`/opsx:apply\` to carry the delta into code.
+   - Everything done and implemented -> suggest \`/opsx:archive\`.
+
+**Output**
+
+After each invocation, show:
+- Which artifacts were revised (and which proposed revisions were rejected)
+- Anything deferred to \`/opsx:continue\` (not-yet-created artifacts or files)
+- Where the change stands and the recommended next command
+
+**Guardrails**
+- Planning artifacts only - NEVER edit implementation code. If the revised plan implies code changes, stop and point to \`/opsx:apply\`.
+- Use the artifact ids and paths reported by \`openspec status\`; never branch on hardcoded artifact names.
+- Edit only the concrete files in \`existingOutputPaths\`; never write to a glob \`resolvedOutputPath\`.
+- Do not advance the build frontier: no new artifacts, no new files under glob artifacts - that is \`/opsx:continue\`'s job.
+- Confirm every edit with the user before writing.
+- If the request changes the change's *intent* rather than refining it, recommend starting fresh with \`/opsx:new\` (the "Update vs. Start Fresh" heuristic).`
+    };
+}
+//# sourceMappingURL=update-change.js.map

package/dist/core/templates/workflows/verify-change.js

@@ -1,9 +1,12 @@
+import { STORE_SELECTION_GUIDANCE } from './store-selection.js';
 export function getVerifyChangeSkillTemplate() {
     return {
         name: 'openspec-verify-change',
         description: 'Verify implementation matches change artifacts. Use when the user wants to validate that implementation is complete, correct, and coherent before archiving.',
         instructions: `Verify that an implementation matches the change artifacts (specs, tasks, design).
 
+${STORE_SELECTION_GUIDANCE}
+
 **Input**: Optionally specify a change name. If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**
@@ -27,8 +30,6 @@ export function getVerifyChangeSkillTemplate() {
    - \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`actionContext\`: path and scope context
    - Which artifacts exist for this change
 
-   If status reports \`actionContext.mode: "workspace-planning"\`, explain that full workspace implementation verification is not supported in this slice and STOP. Do not infer repo-local implementation ownership or edit linked repos.
-
 3. **Get planning context and load artifacts**
 
    \`\`\`bash
@@ -175,6 +176,8 @@ export function getOpsxVerifyCommandTemplate() {
         tags: ['workflow', 'verify', 'experimental'],
         content: `Verify that an implementation matches the change artifacts (specs, tasks, design).
 
+${STORE_SELECTION_GUIDANCE}
+
 **Input**: Optionally specify a change name after \`/opsx:verify\` (e.g., \`/opsx:verify add-auth\`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.
 
 **Steps**
@@ -198,8 +201,6 @@ export function getOpsxVerifyCommandTemplate() {
    - \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`actionContext\`: path and scope context
    - Which artifacts exist for this change
 
-   If status reports \`actionContext.mode: "workspace-planning"\`, explain that full workspace implementation verification is not supported in this slice and STOP. Do not infer repo-local implementation ownership or edit linked repos.
-
 3. **Get planning context and load artifacts**
 
    \`\`\`bash

package/dist/core/update.js

@@ -130,8 +130,8 @@ export class UpdateCommand {
                     for (const { template, dirName } of skillTemplates) {
                         const skillDir = path.join(skillsDir, dirName);
                         const skillFile = path.join(skillDir, 'SKILL.md');
-                        // Use hyphen-based command references for OpenCode
-                        const transformer = (tool.value === 'opencode' || tool.value === 'pi') ? transformToHyphenCommands : undefined;
+                        // Use hyphen-based command references for tools where filename === command name (oh-my-pi, opencode, pi)
+                        const transformer = (tool.value === 'opencode' || tool.value === 'pi' || tool.value === 'oh-my-pi') ? transformToHyphenCommands : undefined;
                         const skillContent = generateSkillContent(template, OPENSPEC_VERSION, transformer);
                         await FileSystemUtils.writeFile(skillFile, skillContent);
                     }
@@ -523,8 +523,8 @@ export class UpdateCommand {
                     for (const { template, dirName } of skillTemplates) {
                         const skillDir = path.join(skillsDir, dirName);
                         const skillFile = path.join(skillDir, 'SKILL.md');
-                        // Use hyphen-based command references for OpenCode
-                        const transformer = (tool.value === 'opencode' || tool.value === 'pi') ? transformToHyphenCommands : undefined;
+                        // Use hyphen-based command references for tools where filename === command name (oh-my-pi, opencode, pi)
+                        const transformer = (tool.value === 'opencode' || tool.value === 'pi' || tool.value === 'oh-my-pi') ? transformToHyphenCommands : undefined;
                         const skillContent = generateSkillContent(template, OPENSPEC_VERSION, transformer);
                         await FileSystemUtils.writeFile(skillFile, skillContent);
                     }

package/dist/core/validation/validator.d.ts

@@ -18,6 +18,13 @@ export declare class Validator {
      * - No duplicates within sections; no cross-section conflicts per spec
      */
     validateChangeDeltaSpecs(changeDir: string): Promise<ValidationReport>;
+    /**
+     * Recursively collect every delta `spec.md` under a change's specs directory,
+     * so both the one-level (specs/<capability>/spec.md) and nested multi-area
+     * (specs/<area>/<capability>/spec.md) layouts are discovered (#1182b).
+     * Returns absolute paths, sorted for deterministic issue ordering.
+     */
+    private findDeltaSpecFiles;
     private convertZodErrors;
     private applySpecRules;
     private applyChangeRules;

package/dist/core/validation/validator.js

@@ -4,7 +4,8 @@ import { SpecSchema, ChangeSchema } from '../schemas/index.js';
 import { MarkdownParser } from '../parsers/markdown-parser.js';
 import { ChangeParser } from '../parsers/change-parser.js';
 import { MIN_PURPOSE_LENGTH, MAX_REQUIREMENT_TEXT_LENGTH, VALIDATION_MESSAGES } from './constants.js';
-import { parseDeltaSpec, normalizeRequirementName } from '../parsers/requirement-blocks.js';
+import { parseDeltaSpec, normalizeRequirementName, extractRequirementsSection } from '../parsers/requirement-blocks.js';
+import { extractRequirementBody as extractRequirementBodyShared, containsShallOrMust as containsShallOrMustShared, countScenarios as countScenariosShared, } from '../parsers/requirement-text.js';
 import { findMainSpecStructureIssues } from '../parsers/spec-structure.js';
 import { FileSystemUtils } from '../../utils/file-system.js';
 export class Validator {
@@ -98,12 +99,12 @@ export class Validator {
         const missingHeaderSpecs = [];
         const emptySectionSpecs = [];
         try {
-            const entries = await fs.readdir(specsDir, { withFileTypes: true });
-            for (const entry of entries) {
-                if (!entry.isDirectory())
-                    continue;
-                const specName = entry.name;
-                const specFile = path.join(specsDir, specName, 'spec.md');
+            // Discover delta specs at any depth so the nested multi-area layout
+            // (specs/<area>/<capability>/spec.md) is validated, not just the
+            // one-level specs/<capability>/spec.md layout (#1182b). The spec-driven
+            // specs glob is specs/**/*.md; delta files are always named spec.md.
+            const specFiles = await this.findDeltaSpecFiles(specsDir);
+            for (const specFile of specFiles) {
                 let content;
                 try {
                     content = await fs.readFile(specFile, 'utf-8');
@@ -112,7 +113,24 @@ export class Validator {
                     continue;
                 }
                 const plan = parseDeltaSpec(content);
-                const entryPath = `${specName}/spec.md`;
+                const entryPath = FileSystemUtils.toPosixPath(path.relative(specsDir, specFile));
+                // Surface (as INFO, never a failure) the non-canonical level-3 headers
+                // the delta reader skipped while parsing ADDED/MODIFIED sections —
+                // without this note a stray divider like "### Documentation
+                // Requirements" would pass validate <change> while failing
+                // archive/validate <spec>. The list comes from the parse itself, so it
+                // reflects exactly what the reader skipped.
+                for (const stray of plan.skippedHeaders) {
+                    const nameless = /^requirement:?$/i.test(stray.header);
+                    issues.push({
+                        level: 'INFO',
+                        path: entryPath,
+                        line: stray.line,
+                        message: nameless
+                            ? `Header "### ${stray.header}" in ${stray.section} is missing a requirement name and is ignored by validation. Add a name, e.g. "### Requirement: <name>".`
+                            : `Header "### ${stray.header}" in ${stray.section} is not a "### Requirement:" header and is ignored by validation. Use "### Requirement: ${stray.header}" if it should be validated as a requirement.`,
+                    });
+                }
                 const sectionNames = [];
                 if (plan.sectionPresence.added)
                     sectionNames.push('## ADDED Requirements');
@@ -147,10 +165,16 @@ export class Validator {
                     }
                     const requirementText = this.extractRequirementText(block.raw);
                     if (!requirementText) {
-                        issues.push({ level: 'ERROR', path: entryPath, message: `ADDED "${block.name}" is missing requirement text` });
+                        issues.push({
+                            level: 'ERROR',
+                            path: entryPath,
+                            message: this.containsShallOrMust(block.name)
+                                ? this.buildMissingShallOrMustMessage(`ADDED "${block.name}"`, block.name)
+                                : `ADDED "${block.name}" is missing requirement text`,
+                        });
                     }
                     else if (!this.containsShallOrMust(requirementText)) {
-                        issues.push({ level: 'ERROR', path: entryPath, message: this.buildMissingShallOrMustMessage('ADDED', block.name) });
+                        issues.push({ level: 'ERROR', path: entryPath, message: this.buildMissingShallOrMustMessage(`ADDED "${block.name}"`, block.name) });
                     }
                     const scenarioCount = this.countScenarios(block.raw);
                     if (scenarioCount < 1) {
@@ -169,10 +193,16 @@ export class Validator {
                     }
                     const requirementText = this.extractRequirementText(block.raw);
                     if (!requirementText) {
-                        issues.push({ level: 'ERROR', path: entryPath, message: `MODIFIED "${block.name}" is missing requirement text` });
+                        issues.push({
+                            level: 'ERROR',
+                            path: entryPath,
+                            message: this.containsShallOrMust(block.name)
+                                ? this.buildMissingShallOrMustMessage(`MODIFIED "${block.name}"`, block.name)
+                                : `MODIFIED "${block.name}" is missing requirement text`,
+                        });
                     }
                     else if (!this.containsShallOrMust(requirementText)) {
-                        issues.push({ level: 'ERROR', path: entryPath, message: this.buildMissingShallOrMustMessage('MODIFIED', block.name) });
+                        issues.push({ level: 'ERROR', path: entryPath, message: this.buildMissingShallOrMustMessage(`MODIFIED "${block.name}"`, block.name) });
                     }
                     const scenarioCount = this.countScenarios(block.raw);
                     if (scenarioCount < 1) {
@@ -256,6 +286,35 @@ export class Validator {
         }
         return this.createReport(issues);
     }
+    /**
+     * Recursively collect every delta `spec.md` under a change's specs directory,
+     * so both the one-level (specs/<capability>/spec.md) and nested multi-area
+     * (specs/<area>/<capability>/spec.md) layouts are discovered (#1182b).
+     * Returns absolute paths, sorted for deterministic issue ordering.
+     */
+    async findDeltaSpecFiles(specsDir) {
+        const results = [];
+        const walk = async (dir) => {
+            let entries;
+            try {
+                entries = await fs.readdir(dir, { withFileTypes: true });
+            }
+            catch {
+                return;
+            }
+            for (const entry of entries) {
+                const full = path.join(dir, entry.name);
+                if (entry.isDirectory()) {
+                    await walk(full);
+                }
+                else if (entry.isFile() && entry.name === 'spec.md') {
+                    results.push(full);
+                }
+            }
+        };
+        await walk(specsDir);
+        return results.sort();
+    }
     convertZodErrors(error) {
         return error.issues.map(err => {
             let message = err.message;
@@ -302,6 +361,23 @@ export class Validator {
                 });
             }
         });
+        // SHALL/MUST body-keyword enforcement for main specs (#1156). The main-spec
+        // parser collapses the requirement header into `text`, so we recover the
+        // header+body pairs here (the same source the delta path trusts) and reuse
+        // the delta detection: a body that omits the keyword errors, with the
+        // targeted "move it to the body line" hint when the keyword is in the header
+        // only and the generic message otherwise. Emitted exactly once per
+        // requirement (the Zod refine that used to emit a generic error is removed).
+        extractRequirementsSection(content).bodyBlocks.forEach((block, index) => {
+            const requirementText = this.extractRequirementText(block.raw);
+            if (!requirementText || !this.containsShallOrMust(requirementText)) {
+                issues.push({
+                    level: 'ERROR',
+                    path: `requirements[${index}]`,
+                    message: this.buildMissingShallOrMustMessage(`Requirement "${block.name}"`, block.name),
+                });
+            }
+        });
         return issues;
     }
     applyChangeRules(change, content) {
@@ -376,30 +452,16 @@ export class Validator {
         return report.valid;
     }
     extractRequirementText(blockRaw) {
-        const lines = blockRaw.split('\n');
-        // Skip header line (index 0)
-        let i = 1;
-        // Find the first substantial text line, skipping metadata and blank lines
-        for (; i < lines.length; i++) {
-            const line = lines[i];
-            // Stop at scenario headers
-            if (/^####\s+/.test(line))
-                break;
-            const trimmed = line.trim();
-            // Skip blank lines
-            if (trimmed.length === 0)
-                continue;
-            // Skip metadata lines (lines starting with ** like **ID**, **Priority**, etc.)
-            if (/^\*\*[^*]+\*\*:/.test(trimmed))
-                continue;
-            // Found first non-metadata, non-blank line - this is the requirement text
-            return trimmed;
-        }
-        // No requirement text found
-        return undefined;
+        // Delegate to the shared, fence-/metadata-/multi-line-aware body reader.
+        // Validation intentionally does not use the parser/display header-title
+        // fallback for canonical `### Requirement:` blocks: #1280 requires a
+        // SHALL/MUST that appears only in the header to receive the body-keyword
+        // hint. Line 0 is the `### Requirement: ...` header.
+        const [, ...bodyLines] = blockRaw.split('\n');
+        return extractRequirementBodyShared(bodyLines) || undefined;
     }
     containsShallOrMust(text) {
-        return /\b(SHALL|MUST)\b/.test(text);
+        return containsShallOrMustShared(text);
     }
     /**
      * Build an error message for a requirement block whose body lacks SHALL/MUST.
@@ -411,16 +473,17 @@ export class Validator {
      * on the requirement body line (the line right after the header), so we point
      * the author at that exact fix when the keyword is found in the header only.
      */
-    buildMissingShallOrMustMessage(action, blockName) {
-        const base = `${action} "${blockName}" must contain SHALL or MUST`;
+    buildMissingShallOrMustMessage(prefix, blockName) {
+        const base = `${prefix} must contain SHALL or MUST`;
         if (this.containsShallOrMust(blockName)) {
             return `${base} in the requirement body, not only in the header. Move the SHALL/MUST statement to the line immediately after the "### Requirement: ..." header.`;
         }
         return base;
     }
     countScenarios(blockRaw) {
-        const matches = blockRaw.match(/^####\s+/gm);
-        return matches ? matches.length : 0;
+        // Fence-aware count via the shared reader: a `#### Scenario:` inside a fenced
+        // example is not a real scenario. Drop the header line (index 0).
+        return countScenariosShared(blockRaw.split('\n').slice(1));
     }
     formatSectionList(sections) {
         if (sections.length === 0)

package/dist/core/view.js

@@ -70,7 +70,7 @@ export class ViewCommand {
         const entries = fs.readdirSync(changesDir, { withFileTypes: true });
         for (const entry of entries) {
             if (entry.isDirectory() && entry.name !== 'archive') {
-                const progress = await getTaskProgressForChange(changesDir, entry.name);
+                const progress = await getTaskProgressForChange(changesDir, entry.name, path.dirname(openspecDir));
                 if (progress.total === 0) {
                     // No tasks defined yet - still in planning/draft phase
                     draft.push({ name: entry.name });

package/dist/core/working-set.d.ts

@@ -0,0 +1,47 @@
+/**
+ * Working-set assembly (slice 4.1): the full set a root's declarations
+ * describe — the OpenSpec root and its referenced stores — as an
+ * agent-consumable brief. A local convenience
+ * computed from declared relationships, never a planning system; no
+ * clone/sync/launch machinery. Unresolvable members are reported, not
+ * guessed.
+ */
+import type { StoreDiagnostic } from './store/errors.js';
+import { type ReferenceIndexEntry } from './references.js';
+import { type ResolvedOpenSpecRoot } from './root-selection.js';
+export type WorkingSetRole = 'referenced_store';
+export interface WorkingSetMember {
+    role: WorkingSetRole;
+    id: string;
+    path?: string;
+    remote?: string;
+    fetch?: string;
+    status: StoreDiagnostic[];
+}
+export interface WorkingSet {
+    root: {
+        path: string;
+        source: ResolvedOpenSpecRoot['source'];
+        store_id?: string;
+        role: 'openspec_root';
+    };
+    members: WorkingSetMember[];
+    status: StoreDiagnostic[];
+}
+export interface AssembleWorkingSetInput {
+    root: ResolvedOpenSpecRoot;
+    referenceEntries: ReferenceIndexEntry[];
+    /** The composition's top-level status; the working set keeps only
+     * the registry-unreadable degradation (selected by code, never by
+     * position). */
+    topLevelStatus?: StoreDiagnostic[];
+}
+/** AVAILABLE = path present AND per-entry status empty. */
+export declare function isAvailableMember(member: WorkingSetMember): boolean;
+export declare function assembleWorkingSet(input: AssembleWorkingSetInput): WorkingSet;
+/**
+ * Pure builder for the `.code-workspace` editor view — one consumer of
+ * assembly, not the feature. Available members only.
+ */
+export declare function buildCodeWorkspaceJson(workingSet: WorkingSet, rootName: string): string;
+//# sourceMappingURL=working-set.d.ts.map

package/dist/core/working-set.js

@@ -0,0 +1,43 @@
+import { fetchRecipe } from './references.js';
+import { toRootOutput } from './root-selection.js';
+/** AVAILABLE = path present AND per-entry status empty. */
+export function isAvailableMember(member) {
+    return member.path !== undefined && member.status.length === 0;
+}
+export function assembleWorkingSet(input) {
+    const members = [];
+    for (const entry of input.referenceEntries) {
+        members.push({
+            role: 'referenced_store',
+            id: entry.store_id,
+            ...(entry.root !== undefined ? { path: entry.root } : {}),
+            ...(entry.root !== undefined && entry.status.length === 0
+                ? { fetch: fetchRecipe(entry.store_id) }
+                : {}),
+            status: entry.status,
+        });
+    }
+    const status = (input.topLevelStatus ?? []).filter((entry) => entry.code === 'relationship_registry_unreadable');
+    return {
+        root: { ...toRootOutput(input.root), role: 'openspec_root' },
+        members,
+        status,
+    };
+}
+/**
+ * Pure builder for the `.code-workspace` editor view — one consumer of
+ * assembly, not the feature. Available members only.
+ */
+export function buildCodeWorkspaceJson(workingSet, rootName) {
+    const folders = [
+        { name: rootName, path: workingSet.root.path },
+    ];
+    for (const member of workingSet.members) {
+        if (!isAvailableMember(member)) {
+            continue;
+        }
+        folders.push({ name: `ref:${member.id}`, path: member.path });
+    }
+    return JSON.stringify({ folders }, null, 2) + '\n';
+}
+//# sourceMappingURL=working-set.js.map