mirror of
https://github.com/Fission-AI/OpenSpec.git
synced 2026-09-14 20:16:53 +08:00
Tabish Bidiwale
5a4837c37d
* feat: add CLI e2e testing improvement plan ## Summary - Add phased approach to stabilize CLI spawn testing - Expand cross-shell/OS matrix coverage when stable - Optional packaging validation for CI environments * feat: add markdown parser CRLF fix proposal and update e2e plan - Add comprehensive proposal for fixing CRLF parsing issues on Windows - Update CLI path references from dist/cli.js to dist/cli/index.js - Streamline e2e testing tasks based on refined approach * fix: correct spec delta to add parsing requirement instead of modifying remediation - Change from MODIFIED to ADDED Requirements for cross-platform line ending parsing - Create focused requirement for parser behavior rather than validation messages - Maintain logical coherence between requirement and scenario
1.7 KiB
1.7 KiB
Update Markdown Parser CRLF Handling
Problem
Windows users report that openspec validate raises “Change must have a Why section” even when the section exists (see GitHub issue #77). The CLI currently splits markdown on \n and compares headers without stripping \r, so files saved with CRLF line endings keep a trailing carriage return in the header token. As a result the parser fails to detect ## Why/## What Changes, triggering false validation errors and breaking the workflow on Windows-default editors.
Solution
- Normalize markdown content inside the parser so CRLF and lone-CR inputs are treated as
\nbefore section detection, trimming any carriage returns from titles and content comparisons. - Reuse the normalized reader everywhere
MarkdownParseris constructed to keep behavior consistent for validation, view, spec, and list flows. - Add regression coverage that reproduces the failure (unit test around
parseChangeand a CLI spawn/e2e test that writes a CRLF change then runsopenspec validate). - Update the
cli-validatespec to codify the expectation that required sections are recognized regardless of line-ending style.
Benefits
- Restores correct validation behavior for Windows editors without requiring manual line-ending conversion.
- Locks in the fix with targeted tests so future parser refactors keep cross-platform support.
- Clarifies the spec so downstream work (e.g., cross-shell e2e plan) understands the non-negotiable behavior.
Risks
- Low: parser normalization touches shared code paths that parse specs and changes; need to ensure no regressions in other command consumers (mitigated by existing parser tests plus the new CRLF fixtures).