@fission-ai/openspec 1.13.1 → 1.14.0

package/dist/utils/index.d.ts

@@ -1,6 +1,6 @@
 export { validateChangeName, createChange } from './change-utils.js';
 export type { ValidationResult, CreateChangeOptions } from './change-utils.js';
-export { readChangeMetadata, writeChangeMetadata, resolveSchemaForChange, validateSchemaName, ChangeMetadataError, } from './change-metadata.js';
+export { readChangeMetadata, writeChangeMetadata, resolveSchemaForChange, validateSchemaName, ChangeMetadataError, listUnknownChangeMetadataKeys, readUnknownChangeMetadataKeys, formatUnknownChangeMetadataKeysMessage, CHANGE_METADATA_KNOWN_KEYS, } from './change-metadata.js';
 export { FileSystemUtils, removeMarkerBlock } from './file-system.js';
 export { transformCommandInvocations, transformToSkillReferences, getSkillReferenceTransformer, getTransformerForTool, } from './command-references.js';
 //# sourceMappingURL=index.d.ts.map

package/dist/utils/index.js

@@ -1,7 +1,7 @@
 // Shared utilities
 export { validateChangeName, createChange } from './change-utils.js';
 // Change metadata utilities
-export { readChangeMetadata, writeChangeMetadata, resolveSchemaForChange, validateSchemaName, ChangeMetadataError, } from './change-metadata.js';
+export { readChangeMetadata, writeChangeMetadata, resolveSchemaForChange, validateSchemaName, ChangeMetadataError, listUnknownChangeMetadataKeys, readUnknownChangeMetadataKeys, formatUnknownChangeMetadataKeysMessage, CHANGE_METADATA_KNOWN_KEYS, } from './change-metadata.js';
 // File system utilities
 export { FileSystemUtils, removeMarkerBlock } from './file-system.js';
 // Command reference utilities

package/dist/utils/line-endings.d.ts

@@ -0,0 +1,34 @@
+/**
+ * Line-ending helpers.
+ *
+ * Every parser in this codebase normalizes CRLF to LF on the way in, so all
+ * serialization logic can assume '\n'. That leaves the write side responsible
+ * for restoring whatever convention the file already used: without it, editing
+ * one requirement in a CRLF spec rewrites every line of the file and buries the
+ * real change in the diff.
+ */
+export type LineEnding = '\n' | '\r\n';
+/**
+ * The dominant line ending in `content`, or undefined when it holds no line
+ * break to judge from.
+ *
+ * Mixed files resolve to whichever ending is more common, with CRLF winning a
+ * tie: a file that is mostly CRLF is a CRLF file that picked up a stray LF, and
+ * settling the whole file on one ending is what keeps later diffs small.
+ */
+export declare function detectLineEnding(content: string): LineEnding | undefined;
+/**
+ * Re-apply `ending` to LF-normalized `content`.
+ *
+ * Normalizes to LF first, so the result is uniform even if the caller passed
+ * content that already contained CRLF.
+ */
+export declare function applyLineEnding(content: string, ending: LineEnding): string;
+/**
+ * Rewrite `content` to match the convention of `original`.
+ *
+ * When `original` has no line break to learn from, `content` is left as LF —
+ * the portable default this project writes new files with.
+ */
+export declare function matchLineEnding(content: string, original: string): string;
+//# sourceMappingURL=line-endings.d.ts.map

package/dist/utils/line-endings.js

@@ -0,0 +1,46 @@
+/**
+ * Line-ending helpers.
+ *
+ * Every parser in this codebase normalizes CRLF to LF on the way in, so all
+ * serialization logic can assume '\n'. That leaves the write side responsible
+ * for restoring whatever convention the file already used: without it, editing
+ * one requirement in a CRLF spec rewrites every line of the file and buries the
+ * real change in the diff.
+ */
+/**
+ * The dominant line ending in `content`, or undefined when it holds no line
+ * break to judge from.
+ *
+ * Mixed files resolve to whichever ending is more common, with CRLF winning a
+ * tie: a file that is mostly CRLF is a CRLF file that picked up a stray LF, and
+ * settling the whole file on one ending is what keeps later diffs small.
+ */
+export function detectLineEnding(content) {
+    const crlf = content.match(/\r\n/g)?.length ?? 0;
+    // Count LFs not preceded by CR, so CRLF is never also counted as LF.
+    const lf = content.match(/(?<!\r)\n/g)?.length ?? 0;
+    if (crlf === 0 && lf === 0)
+        return undefined;
+    return crlf >= lf ? '\r\n' : '\n';
+}
+/**
+ * Re-apply `ending` to LF-normalized `content`.
+ *
+ * Normalizes to LF first, so the result is uniform even if the caller passed
+ * content that already contained CRLF.
+ */
+export function applyLineEnding(content, ending) {
+    const normalized = content.replace(/\r\n/g, '\n');
+    return ending === '\n' ? normalized : normalized.replace(/\n/g, '\r\n');
+}
+/**
+ * Rewrite `content` to match the convention of `original`.
+ *
+ * When `original` has no line break to learn from, `content` is left as LF —
+ * the portable default this project writes new files with.
+ */
+export function matchLineEnding(content, original) {
+    const ending = detectLineEnding(original);
+    return ending === undefined ? content : applyLineEnding(content, ending);
+}
+//# sourceMappingURL=line-endings.js.map

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@fission-ai/openspec",
-  "version": "1.13.1",
+  "version": "1.14.0",
   "description": "AI-native system for spec-driven development",
   "keywords": [
     "openspec",
@@ -52,7 +52,7 @@
     "vitest": "^4.1.11"
   },
   "dependencies": {
-    "@inquirer/core": "^11.2.1",
+    "@inquirer/core": "^12.0.0",
     "@inquirer/prompts": "^8.5.2",
     "chalk": "^5.6.2",
     "commander": "^14.0.0",

package/schemas/spec-driven/schema.yaml

@@ -13,7 +13,7 @@ artifacts:
       - **Why**: 1-2 sentences on the problem or opportunity. What problem does this solve? Why now?
       - **What Changes**: Bullet list of changes. Be specific about new capabilities, modifications, or removals. Mark breaking changes with **BREAKING**.
       - **Capabilities**: Identify which specs will be created or modified:
-        - **New Capabilities**: List capabilities being introduced. Each becomes a new `specs/<capability-path>/spec.md`. Use kebab-case for path segments you introduce (e.g., `user-auth` or `identity/user-auth`) and follow the project's existing spec organization.
+        - **New Capabilities**: List capabilities being introduced. Each becomes a new `specs/<capability-path>/spec.md`. Name each capability for a durable system behavior (for example, `user-auth`), not the work in this change (for example, `add-login-endpoint`). Choose a cohesive boundary that can own related requirements as the system evolves; avoid broad catch-all capabilities. Use kebab-case for path segments you introduce (e.g., `user-auth` or `identity/user-auth`) and follow the project's existing spec organization.
         - **Modified Capabilities**: List existing capabilities whose REQUIREMENTS are changing. Only include if spec-level behavior changes (not just implementation details). Each needs a delta spec file. Use the exact existing path under `openspec/specs/`. Leave empty if no requirement changes.
       - **Impact**: Affected code, APIs, dependencies, or systems.
 
@@ -94,6 +94,7 @@ artifacts:
       - Each scenario: `#### Scenario: <name>` with WHEN/THEN format
       - **CRITICAL**: Scenarios MUST use exactly 4 hashtags (`####`). Using 3 hashtags or bullets will fail silently.
       - Every requirement MUST have at least one scenario.
+      - Keep each requirement's description (the text between `### Requirement:` and its first scenario) to 500 characters or fewer. `openspec validate` flags longer descriptions once they reach the main spec. This is an informational hint, not an error. When writing a new requirement, state one behavior per requirement: move examples and edge cases into scenarios, and split a requirement that covers several behaviors into separate `### Requirement:` blocks, each with its own scenarios. Under MODIFIED, keep the existing requirement block whole; never split, trim or rewrite existing text just to meet the length.
 
       New capabilities only: the delta spec's first section is `## Purpose` -
       one or two sentences (50+ characters, or `openspec validate --strict`
@@ -210,6 +211,13 @@ artifacts:
         that task's checkbox description. Use a separate verification task only
         when it checks broader integration or system behavior that spans
         multiple implementation tasks.
+      - Each task group MUST land the tests and documentation its own work
+        calls for. Do NOT collect testing or documentation into a final group -
+        when a late group first exercises work from an early one, the failures
+        cascade back through every group in between and force rework. A group
+        whose work calls for neither, such as scaffolding or dependency setup,
+        carries neither. A final group is for integration checks only, not for
+        the tests and docs an earlier group owed.
 
       Example:
       ```
@@ -224,6 +232,7 @@ artifacts:
 
       - [ ] 2.1 Implement data export function and verify the export test passes
       - [ ] 2.2 Add CSV formatting utilities and verify unit tests cover quoting and delimiters
+      - [ ] 2.3 Document the export API in docs/export.md and verify the documented command runs as written
       ```
 
       Reference specs for what needs to be built, design for how to build it.

package/schemas/spec-driven/templates/proposal.md

@@ -11,9 +11,12 @@
 ## Capabilities
 
 ### New Capabilities
-<!-- Capabilities being introduced. Use kebab-case for path segments you introduce
-     (e.g., user-auth or identity/user-auth) that follow the project's existing
-     spec organization. Each creates specs/<capability-path>/spec.md. -->
+<!-- Capabilities being introduced. Name each capability for a cohesive system
+     behavior that can own related requirements as the system evolves. Do not name
+     implementation tasks or proposal sections. Avoid broad catch-all names. Use
+     kebab-case for path segments you introduce (e.g., user-auth or identity/user-auth)
+     that follow the project's existing spec organization. Each creates
+     specs/<capability-path>/spec.md. -->
 - `<capability-path>`: <brief description of what this capability covers>
 
 ### Modified Capabilities