@fission-ai/openspec 1.3.0 → 1.4.0

package/dist/core/templates/workflows/onboard.js

@@ -167,7 +167,7 @@ Now let's create a change to hold our work.
 \`\`\`
 ## Creating a Change
 
-A "change" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives in \`openspec/changes/<name>/\` and holds your artifacts—proposal, specs, design, tasks.
+A "change" in OpenSpec is a container for all the thinking and planning around a piece of work. It lives at the \`changeRoot\` reported by \`openspec status --change "<name>" --json\` and holds your artifacts—proposal, specs, design, tasks.
 
 Let me create one for our task.
 \`\`\`
@@ -179,11 +179,11 @@ openspec new change "<derived-name>"
 
 **SHOW:**
 \`\`\`
-Created: \`openspec/changes/<name>/\`
+Created: <changeRoot from status JSON>
 
 The folder structure:
 \`\`\`
-openspec/changes/<name>/
+<changeRoot>/
 ├── proposal.md    ← Why we're doing this (empty, we'll fill it)
 ├── design.md      ← How we'll build it (empty)
 ├── specs/         ← Detailed requirements (empty)
@@ -245,7 +245,7 @@ After approval, save the proposal:
 \`\`\`bash
 openspec instructions proposal --change "<name>" --json
 \`\`\`
-Then write the content to \`openspec/changes/<name>/proposal.md\`.
+Then write the content to the \`resolvedOutputPath\` from \`openspec instructions proposal --change "<name>" --json\`.
 
 \`\`\`
 Proposal saved. This is your "why" document—you can always come back and refine it as understanding evolves.
@@ -266,12 +266,10 @@ Specs define **what** we're building in precise, testable terms. They use a requ
 For a small task like this, we might only need one spec file.
 \`\`\`
 
-**DO:** Create the spec file:
+**DO:** Resolve where the spec file should be created:
 \`\`\`bash
-# Unix/macOS
-mkdir -p openspec/changes/<name>/specs/<capability-name>
-# Windows (PowerShell)
-# New-Item -ItemType Directory -Force -Path "openspec/changes/<name>/specs/<capability-name>"
+openspec instructions specs --change "<name>" --json
+# Use resolvedOutputPath from the JSON. If it is a glob, choose the concrete file path using the schema instruction and workspace planning context.
 \`\`\`
 
 Draft the spec content:
@@ -298,7 +296,7 @@ Here's the spec:
 This format—WHEN/THEN/AND—makes requirements testable. You can literally read them as test cases.
 \`\`\`
 
-Save to \`openspec/changes/<name>/specs/<capability>/spec.md\`.
+Save to the concrete file path chosen from \`resolvedOutputPath\`.
 
 ---
 
@@ -343,7 +341,7 @@ Here's the design:
 For a small task, this captures the key decisions without over-engineering.
 \`\`\`
 
-Save to \`openspec/changes/<name>/design.md\`.
+Save to the \`resolvedOutputPath\` from \`openspec instructions design --change "<name>" --json\`.
 
 ---
 
@@ -381,7 +379,7 @@ Each checkbox becomes a unit of work in the apply phase. Ready to implement?
 
 **PAUSE** - Wait for user to confirm they're ready to implement.
 
-Save to \`openspec/changes/<name>/tasks.md\`.
+Save to the \`resolvedOutputPath\` from \`openspec instructions tasks --change "<name>" --json\`.
 
 ---
 
@@ -425,7 +423,7 @@ The change is implemented! One more step—let's archive it.
 \`\`\`
 ## Archiving
 
-When a change is complete, we archive it. This moves it from \`openspec/changes/\` to \`openspec/changes/archive/YYYY-MM-DD-<name>/\`.
+When a change is complete, we archive it. The archive path is derived from \`planningHome.changesDir\` and the date.
 
 Archived changes become your project's decision history—you can always find them later to understand why something was built a certain way.
 \`\`\`
@@ -437,7 +435,7 @@ openspec archive "<name>"
 
 **SHOW:**
 \`\`\`
-Archived to: \`openspec/changes/archive/YYYY-MM-DD-<name>/\`
+Archived to: \`<planningHome.changesDir>/archive/YYYY-MM-DD-<name>/\`
 
 The change is now part of your project's history. The code is in your codebase, the decision record is preserved.
 \`\`\`
@@ -500,7 +498,7 @@ Try \`/opsx:propose\` on something you actually want to build. You've got the rh
 If the user says they need to stop, want to pause, or seem disengaged:
 
 \`\`\`
-No problem! Your change is saved at \`openspec/changes/<name>/\`.
+No problem! Your change is saved at the \`changeRoot\` reported by \`openspec status --change "<name>" --json\`.
 
 To pick up where we left off later:
 - \`/opsx:continue <name>\` - Resume artifact creation

package/dist/core/templates/workflows/propose.js

@@ -30,7 +30,7 @@ When ready to implement, run /opsx:apply
    \`\`\`bash
    openspec new change "<name>"
    \`\`\`
-   This creates a scaffolded change at \`openspec/changes/<name>/\` with \`.openspec.yaml\`.
+   This creates a scaffolded change in the planning home resolved by the CLI with \`.openspec.yaml\`.
 
 3. **Get the artifact build order**
    \`\`\`bash
@@ -39,6 +39,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - \`applyRequires\`: array of artifact IDs needed before implementation (e.g., \`["tasks"]\`)
    - \`artifacts\`: list of all artifacts with their status and dependencies
+   - \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`actionContext\`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -56,10 +57,10 @@ When ready to implement, run /opsx:apply
         - \`rules\`: Artifact-specific rules (constraints for you - do NOT include in output)
         - \`template\`: The structure to use for your output file
         - \`instruction\`: Schema-specific guidance for this artifact type
-        - \`outputPath\`: Where to write the artifact
+        - \`resolvedOutputPath\`: Resolved path or pattern to write the artifact
         - \`dependencies\`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using \`template\` as the structure
+      - Create the artifact file using \`template\` as the structure and write it to \`resolvedOutputPath\`
       - Apply \`context\` and \`rules\` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 
@@ -140,7 +141,7 @@ When ready to implement, run /opsx:apply
    \`\`\`bash
    openspec new change "<name>"
    \`\`\`
-   This creates a scaffolded change at \`openspec/changes/<name>/\` with \`.openspec.yaml\`.
+   This creates a scaffolded change in the planning home resolved by the CLI with \`.openspec.yaml\`.
 
 3. **Get the artifact build order**
    \`\`\`bash
@@ -149,6 +150,7 @@ When ready to implement, run /opsx:apply
    Parse the JSON to get:
    - \`applyRequires\`: array of artifact IDs needed before implementation (e.g., \`["tasks"]\`)
    - \`artifacts\`: list of all artifacts with their status and dependencies
+   - \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`actionContext\`: path and scope context. Use these instead of assuming repo-local paths.
 
 4. **Create artifacts in sequence until apply-ready**
 
@@ -166,10 +168,10 @@ When ready to implement, run /opsx:apply
         - \`rules\`: Artifact-specific rules (constraints for you - do NOT include in output)
         - \`template\`: The structure to use for your output file
         - \`instruction\`: Schema-specific guidance for this artifact type
-        - \`outputPath\`: Where to write the artifact
+        - \`resolvedOutputPath\`: Resolved path or pattern to write the artifact
         - \`dependencies\`: Completed artifacts to read for context
       - Read any completed dependency files for context
-      - Create the artifact file using \`template\` as the structure
+      - Create the artifact file using \`template\` as the structure and write it to \`resolvedOutputPath\`
       - Apply \`context\` and \`rules\` as constraints - but do NOT copy them into the file
       - Show brief progress: "Created <artifact-id>"
 

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

@@ -18,9 +18,18 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
    **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
 
-2. **Find delta specs**
+2. **Resolve change context**
 
-   Look for delta spec files in \`openspec/changes/<name>/specs/*/spec.md\`.
+   Run:
+   \`\`\`bash
+   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.
 
    Each delta spec file contains sections like:
    - \`## ADDED Requirements\` - New requirements to add
@@ -30,9 +39,9 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
    If no delta specs found, inform user and stop.
 
-3. **For each delta spec, apply changes to main specs**
+4. **For each delta spec, apply changes to main specs**
 
-   For each capability with a delta spec at \`openspec/changes/<name>/specs/<capability>/spec.md\`:
+   For each repo-local capability delta spec path returned by the CLI:
 
    a. **Read the delta spec** to understand the intended changes
 
@@ -63,7 +72,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
       - Add Purpose section (can be brief, mark as TBD)
       - Add Requirements section with the ADDED requirements
 
-4. **Show summary**
+5. **Show summary**
 
    After applying all changes, summarize:
    - Which capabilities were updated
@@ -156,9 +165,18 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
    **IMPORTANT**: Do NOT guess or auto-select a change. Always let the user choose.
 
-2. **Find delta specs**
+2. **Resolve change context**
+
+   Run:
+   \`\`\`bash
+   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**
 
-   Look for delta spec files in \`openspec/changes/<name>/specs/*/spec.md\`.
+   Use \`artifactPaths.specs.existingOutputPaths\` from the status JSON as the list of delta spec files.
 
    Each delta spec file contains sections like:
    - \`## ADDED Requirements\` - New requirements to add
@@ -168,9 +186,9 @@ This is an **agent-driven** operation - you will read delta specs and directly e
 
    If no delta specs found, inform user and stop.
 
-3. **For each delta spec, apply changes to main specs**
+4. **For each delta spec, apply changes to main specs**
 
-   For each capability with a delta spec at \`openspec/changes/<name>/specs/<capability>/spec.md\`:
+   For each repo-local capability delta spec path returned by the CLI:
 
    a. **Read the delta spec** to understand the intended changes
 
@@ -201,7 +219,7 @@ This is an **agent-driven** operation - you will read delta specs and directly e
       - Add Purpose section (can be brief, mark as TBD)
       - Add Requirements section with the ADDED requirements
 
-4. **Show summary**
+5. **Show summary**
 
    After applying all changes, summarize:
    - Which capabilities were updated

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

@@ -24,15 +24,18 @@ export function getVerifyChangeSkillTemplate() {
    \`\`\`
    Parse the JSON to understand:
    - \`schemaName\`: The workflow being used (e.g., "spec-driven")
+   - \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`actionContext\`: path and scope context
    - Which artifacts exist for this change
 
-3. **Get the change directory and load artifacts**
+   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
    openspec instructions apply --change "<name>" --json
    \`\`\`
 
-   This returns the change directory and context files. Read all available artifacts from \`contextFiles\`.
+   This returns the change directory and \`contextFiles\` (artifact ID -> array of concrete file paths). Read all available artifacts from \`contextFiles\`.
 
 4. **Initialize verification report structure**
 
@@ -46,7 +49,7 @@ export function getVerifyChangeSkillTemplate() {
 5. **Verify Completeness**
 
    **Task Completion**:
-   - If tasks.md exists in contextFiles, read it
+   - If \`contextFiles.tasks\` exists, read every file path in it
    - Parse checkboxes: \`- [ ]\` (incomplete) vs \`- [x]\` (complete)
    - Count complete vs total tasks
    - If incomplete tasks exist:
@@ -54,7 +57,7 @@ export function getVerifyChangeSkillTemplate() {
      - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
 
    **Spec Coverage**:
-   - If delta specs exist in \`openspec/changes/<name>/specs/\`:
+   - If delta specs exist in \`contextFiles.specs\`:
      - Extract all requirements (marked with "### Requirement:")
      - For each requirement:
        - Search codebase for keywords related to the requirement
@@ -85,7 +88,7 @@ export function getVerifyChangeSkillTemplate() {
 7. **Verify Coherence**
 
    **Design Adherence**:
-   - If design.md exists in contextFiles:
+   - If \`contextFiles.design\` exists:
      - Extract key decisions (look for sections like "Decision:", "Approach:", "Architecture:")
      - Verify implementation follows those decisions
      - If contradiction detected:
@@ -192,15 +195,18 @@ export function getOpsxVerifyCommandTemplate() {
    \`\`\`
    Parse the JSON to understand:
    - \`schemaName\`: The workflow being used (e.g., "spec-driven")
+   - \`planningHome\`, \`changeRoot\`, \`artifactPaths\`, and \`actionContext\`: path and scope context
    - Which artifacts exist for this change
 
-3. **Get the change directory and load artifacts**
+   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
    openspec instructions apply --change "<name>" --json
    \`\`\`
 
-   This returns the change directory and context files. Read all available artifacts from \`contextFiles\`.
+   This returns the change directory and \`contextFiles\` (artifact ID -> array of concrete file paths). Read all available artifacts from \`contextFiles\`.
 
 4. **Initialize verification report structure**
 
@@ -214,7 +220,7 @@ export function getOpsxVerifyCommandTemplate() {
 5. **Verify Completeness**
 
    **Task Completion**:
-   - If tasks.md exists in contextFiles, read it
+   - If \`contextFiles.tasks\` exists, read every file path in it
    - Parse checkboxes: \`- [ ]\` (incomplete) vs \`- [x]\` (complete)
    - Count complete vs total tasks
    - If incomplete tasks exist:
@@ -222,7 +228,7 @@ export function getOpsxVerifyCommandTemplate() {
      - Recommendation: "Complete task: <description>" or "Mark as done if already implemented"
 
    **Spec Coverage**:
-   - If delta specs exist in \`openspec/changes/<name>/specs/\`:
+   - If delta specs exist in \`contextFiles.specs\`:
      - Extract all requirements (marked with "### Requirement:")
      - For each requirement:
        - Search codebase for keywords related to the requirement
@@ -253,7 +259,7 @@ export function getOpsxVerifyCommandTemplate() {
 7. **Verify Coherence**
 
    **Design Adherence**:
-   - If design.md exists in contextFiles:
+   - If \`contextFiles.design\` exists:
      - Extract key decisions (look for sections like "Decision:", "Approach:", "Architecture:")
      - Verify implementation follows those decisions
      - If contradiction detected:

package/dist/core/update.d.ts

@@ -38,6 +38,11 @@ export declare class UpdateCommand {
      * Displays a note about extra workflows installed that aren't in the current profile.
      */
     private displayExtraWorkflowsNote;
+    /**
+     * Suggest opting back into core when a custom profile still matches the old
+     * pre-sync core set. Keep custom profiles user-owned; do not mutate them.
+     */
+    private displayOldCoreCustomProfileNote;
     /**
      * Removes skill directories for workflows when delivery changed to commands-only.
      * Returns the number of directories removed.

package/dist/core/update.js

@@ -23,6 +23,7 @@ import { WORKFLOW_TO_SKILL_DIR, getCommandConfiguredTools, getConfiguredToolsFor
 import { scanInstalledWorkflows as scanInstalledWorkflowsShared, migrateIfNeeded as migrateIfNeededShared, } from './migration.js';
 const require = createRequire(import.meta.url);
 const { version: OPENSPEC_VERSION } = require('../../package.json');
+const OLD_CORE_WORKFLOWS = ['propose', 'explore', 'apply', 'archive'];
 /**
  * Scans installed workflow artifacts (skills and managed commands) across all configured tools.
  * Returns the union of detected workflow IDs that match ALL_WORKFLOWS.
@@ -95,6 +96,7 @@ export class UpdateCommand {
             // Still check for new tool directories and extra workflows
             this.detectNewTools(resolvedProjectPath, configuredTools);
             this.displayExtraWorkflowsNote(resolvedProjectPath, configuredTools, desiredWorkflows);
+            this.displayOldCoreCustomProfileNote(profile, globalConfig.workflows);
             return;
         }
         // 8. Display update plan
@@ -201,6 +203,7 @@ export class UpdateCommand {
         this.detectNewTools(resolvedProjectPath, configuredAndNewTools);
         // 14. Display note about extra workflows not in profile
         this.displayExtraWorkflowsNote(resolvedProjectPath, configuredAndNewTools, desiredWorkflows);
+        this.displayOldCoreCustomProfileNote(profile, globalConfig.workflows);
         // 15. List affected tools
         if (updatedTools.length > 0) {
             const toolDisplayNames = updatedTools;
@@ -264,6 +267,23 @@ export class UpdateCommand {
             console.log(chalk.dim(`Note: ${extraWorkflows.length} extra workflows not in profile (use \`openspec config profile\` to manage)`));
         }
     }
+    /**
+     * Suggest opting back into core when a custom profile still matches the old
+     * pre-sync core set. Keep custom profiles user-owned; do not mutate them.
+     */
+    displayOldCoreCustomProfileNote(profile, workflows) {
+        if (profile !== 'custom' || !workflows) {
+            return;
+        }
+        const workflowSet = new Set(workflows);
+        const matchesOldCore = workflowSet.size === OLD_CORE_WORKFLOWS.length &&
+            OLD_CORE_WORKFLOWS.every((workflow) => workflowSet.has(workflow));
+        if (!matchesOldCore) {
+            return;
+        }
+        console.log(chalk.dim('Note: The core profile now includes sync. Your custom profile is preserving the old core workflow set.'));
+        console.log(chalk.dim('Run `openspec config profile core` and then `openspec update` to add sync.'));
+    }
     /**
      * Removes skill directories for workflows when delivery changed to commands-only.
      * Returns the number of directories removed.

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

@@ -27,6 +27,17 @@ export declare class Validator {
     isValid(report: ValidationReport): boolean;
     private extractRequirementText;
     private containsShallOrMust;
+    /**
+     * Build an error message for a requirement block whose body lacks SHALL/MUST.
+     *
+     * When the SHALL/MUST keyword already appears in the requirement header (e.g.
+     * `### Requirement: The system SHALL ...`) the original generic error
+     * ("must contain SHALL or MUST") is confusing because the keyword is visibly
+     * present in the spec. Per the OpenSpec conventions the keyword has to live
+     * 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.
+     */
+    private buildMissingShallOrMustMessage;
     private countScenarios;
     private formatSectionList;
 }

package/dist/core/validation/validator.js

@@ -5,6 +5,7 @@ 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 { findMainSpecStructureIssues } from '../parsers/spec-structure.js';
 import { FileSystemUtils } from '../../utils/file-system.js';
 export class Validator {
     strictMode;
@@ -149,7 +150,7 @@ export class Validator {
                         issues.push({ level: 'ERROR', path: entryPath, message: `ADDED "${block.name}" is missing requirement text` });
                     }
                     else if (!this.containsShallOrMust(requirementText)) {
-                        issues.push({ level: 'ERROR', path: entryPath, message: `ADDED "${block.name}" must contain SHALL or MUST` });
+                        issues.push({ level: 'ERROR', path: entryPath, message: this.buildMissingShallOrMustMessage('ADDED', block.name) });
                     }
                     const scenarioCount = this.countScenarios(block.raw);
                     if (scenarioCount < 1) {
@@ -171,7 +172,7 @@ export class Validator {
                         issues.push({ level: 'ERROR', path: entryPath, message: `MODIFIED "${block.name}" is missing requirement text` });
                     }
                     else if (!this.containsShallOrMust(requirementText)) {
-                        issues.push({ level: 'ERROR', path: entryPath, message: `MODIFIED "${block.name}" must contain SHALL or MUST` });
+                        issues.push({ level: 'ERROR', path: entryPath, message: this.buildMissingShallOrMustMessage('MODIFIED', block.name) });
                     }
                     const scenarioCount = this.countScenarios(block.raw);
                     if (scenarioCount < 1) {
@@ -270,6 +271,14 @@ export class Validator {
     }
     applySpecRules(spec, content) {
         const issues = [];
+        for (const structuralIssue of findMainSpecStructureIssues(content)) {
+            issues.push({
+                level: 'ERROR',
+                path: 'file',
+                line: structuralIssue.line,
+                message: structuralIssue.message,
+            });
+        }
         if (spec.overview.length < MIN_PURPOSE_LENGTH) {
             issues.push({
                 level: 'WARNING',
@@ -392,6 +401,23 @@ export class Validator {
     containsShallOrMust(text) {
         return /\b(SHALL|MUST)\b/.test(text);
     }
+    /**
+     * Build an error message for a requirement block whose body lacks SHALL/MUST.
+     *
+     * When the SHALL/MUST keyword already appears in the requirement header (e.g.
+     * `### Requirement: The system SHALL ...`) the original generic error
+     * ("must contain SHALL or MUST") is confusing because the keyword is visibly
+     * present in the spec. Per the OpenSpec conventions the keyword has to live
+     * 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`;
+        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;

package/dist/core/workspace/foundation.d.ts

@@ -0,0 +1,67 @@
+import { type ContextStoreBinding, type ContextStoreSelector } from '../context-store/index.js';
+export declare const WORKSPACE_METADATA_DIR_NAME = ".openspec-workspace";
+export declare const WORKSPACE_VIEW_STATE_FILE_NAME = "workspace.yaml";
+export declare const WORKSPACE_CHANGES_DIR_NAME = "changes";
+export declare const WORKSPACE_CODE_WORKSPACE_EXTENSION = ".code-workspace";
+export declare const WORKSPACE_SUPPORTED_OPENER_VALUES: readonly ["codex-cli", "claude", "github-copilot", "editor"];
+export declare const WORKSPACE_AGENT_OPENER_IDS: readonly ["codex-cli", "claude", "github-copilot"];
+export declare const WORKSPACE_EDITOR_OPENER_IDS: readonly ["vscode"];
+export type WorkspaceSupportedOpenerValue = typeof WORKSPACE_SUPPORTED_OPENER_VALUES[number];
+export type WorkspaceAgentOpenerId = typeof WORKSPACE_AGENT_OPENER_IDS[number];
+export type WorkspaceEditorOpenerId = typeof WORKSPACE_EDITOR_OPENER_IDS[number];
+export type WorkspacePreferredOpener = {
+    kind: 'agent';
+    id: WorkspaceAgentOpenerId;
+} | {
+    kind: 'editor';
+    id: WorkspaceEditorOpenerId;
+};
+export interface WorkspaceContextState {
+    kind: 'initiative';
+    store: ContextStoreBinding;
+    initiative: {
+        id: string;
+    };
+}
+export interface WorkspaceViewState {
+    version: 1;
+    name: string;
+    context: WorkspaceContextState | null;
+    links: Record<string, string | null>;
+    preferred_opener?: WorkspacePreferredOpener;
+    tools?: string[];
+    workspace_skills?: WorkspaceSkillState;
+}
+export interface WorkspaceSkillState {
+    selected_agents: string[];
+    last_applied_profile?: 'core' | 'custom';
+    last_applied_delivery?: 'both' | 'skills' | 'commands';
+    last_applied_workflow_ids?: string[];
+    last_applied_at?: string;
+}
+export declare function getWorkspaceMetadataDir(workspaceRoot: string): string;
+export declare function getWorkspaceViewStatePath(workspaceRoot: string): string;
+export declare function getWorkspaceChangesDir(workspaceRoot: string): string;
+export declare function getWorkspaceCodeWorkspaceFileName(workspaceName: string): string;
+export declare function getWorkspaceCodeWorkspacePath(workspaceRoot: string, workspaceName: string): string;
+/**
+ * @deprecated Managed workspaces no longer create portable ignore rules.
+ * This compatibility shim remains for callers that still ask which ignore
+ * patterns OpenSpec owns for workspace-local generated files.
+ */
+export declare function getWorkspacePortableIgnorePatterns(_workspaceName?: string): string[];
+export declare function validateWorkspaceName(name: string): string;
+export declare function validateWorkspaceLinkName(name: string): string;
+export declare function isValidWorkspaceName(name: string): boolean;
+export declare function isValidWorkspaceLinkName(name: string): boolean;
+export declare function isWorkspaceAgentOpenerId(value: string): value is WorkspaceAgentOpenerId;
+export declare function isWorkspaceSupportedOpenerValue(value: string): value is WorkspaceSupportedOpenerValue;
+export declare function parseWorkspacePreferredOpenerValue(value: string): WorkspacePreferredOpener;
+export declare function validateWorkspacePreferredOpener(opener: WorkspacePreferredOpener): WorkspacePreferredOpener;
+export declare function createWorkspaceInitiativeContext(store: ContextStoreBinding, initiativeId: string): WorkspaceContextState;
+export declare function getWorkspaceContextStoreId(context: WorkspaceContextState): string;
+export declare function getWorkspaceContextStoreSelector(context: WorkspaceContextState): ContextStoreSelector;
+export declare function getWorkspaceContextInitiativeId(context: WorkspaceContextState): string;
+export declare function parseWorkspaceViewState(content: string): WorkspaceViewState;
+export declare function serializeWorkspaceViewState(state: WorkspaceViewState): string;
+//# sourceMappingURL=foundation.d.ts.map