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
20 lines
1.7 KiB
Markdown
20 lines
1.7 KiB
Markdown
# 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 `\n` before section detection, trimming any carriage returns from titles and content comparisons.
|
|
- Reuse the normalized reader everywhere `MarkdownParser` is constructed to keep behavior consistent for validation, view, spec, and list flows.
|
|
- Add regression coverage that reproduces the failure (unit test around `parseChange` and a CLI spawn/e2e test that writes a CRLF change then runs `openspec validate`).
|
|
- Update the `cli-validate` spec 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).
|
|
|