fix(resolution): converge validate, view, and archive onto canonical resolution (#1182, #1202, #1156)

[clay-good]

Status

LGTM — ready to review. Planning artifacts (proposal / design / spec deltas / tasks) and the implementation + tests are now all in this PR. The change validates --strict; the full suite is green (1791 passed; only the pre-existing, environment-specific zsh-installer failures remain); all 36 repo specs pass --specs --strict with no new false positives.

What was wrong

Three read/validate commands each silently forked their own resolution or validation logic instead of reusing the canonical implementation a sibling command already gets right. The fork stays invisible until the two paths disagree — then the tool reports a confident falsehood about the spec source of truth. All three were reproduced against the built pre-fix CLI (base 546224e).

• openspec validate cannot resolve changes in a workspace planning home #1182 — validate gates on proposal.md while status/instructions gate on directory existence. A scaffolded/still-authoring change that status --change foo resolves (exit 0) makes validate foo return Unknown item (exit 1). Worse, validate --all over a lone proposal-less change prints No items found to validate and exits 0 — a silent CI pass. The proposal.md membership gate (getActiveChangeIds) diverged from the directory-existence rule (validateChangeExists) at three call sites (targeted, bulk, interactive selector). Nested multi-area deltas (specs/<area>/<capability>/spec.md) were also not discovered, so a resolved multi-area change reported No delta sections found.
• Feedback: openspec view does not detect nested tasks.md files #1202 — view/list/archive hardcode changes/<name>/tasks.md while status resolves the schema's tracked-tasks glob. With tasks split across backend/tasks.md (2/2) + frontend/tasks.md (1/3) and no top-level file, view mislabeled the change Draft and list showed No tasks. The same helper bug let archive move a 3/5 unfinished change into changes/archive/ — the incomplete-task gate was wholly bypassed (data-safety bug), proven empirically.
• 1.4.0 clearer SHALL/MUST hint does not apply to main specs #1156 — the 1.4.0 SHALL/MUST body-keyword hint fired for change deltas but not main specs. The main-spec parser discards the requirement header before the Zod refine runs, so a header-only keyword in a main spec got a generic message where the equivalent delta got the targeted, actionable hint.

How it was fixed

Each divergent path is pointed at the canonical implementation, and the agreement is asserted by test (design Decision 7). No new command, flag, schema field, or output format; the already-correct paths are unchanged.

Bug	Canonical (correct)	Divergent (now converged)
#1182	status/instructions resolve by directory existence	validate now resolves via shared getAvailableChanges at all 3 sites; new findDeltaSpecFiles walker recurses the nested multi-area layout
#1202	status resolves the tracked-tasks artifact's generates glob (resolveArtifactOutputs)	getTaskProgressForChange now resolves through that glob, aggregating checkboxes scoped to the change dir, with a never-throw fallback to a single top-level tasks.md; all 4 callers rewired and the duplicate copy in change.ts folded onto the helper
#1156	delta validator emits the targeted hint	applySpecRules recovers the header via extractRequirementsSection and emits the hint (header-only) or generic message (no keyword) exactly once; the now-redundant Zod refine is removed (deltas never used it)

The main-spec actionable sentence is byte-identical to the change-delta path.

Proof it works

• Empirical repro (pre-fix CLI): each bug reproduced against the built CLI — full trace in design.md → "Empirical evidence" (including the archive moving a 3/5 change into changes/archive/, and validate --all exiting 0 on a lone proposal-less change).
• New parity/regression tests (all now passing): validate↔status resolution parity incl. exit code (test/commands/validate.test.ts), nested multi-area delta discovery and header-only main-spec hint parity (test/core/validation.test.ts), view resolves the same files as status (test/core/view.test.ts), the archive incomplete-task gate (test/core/archive.test.ts), and nested-glob task aggregation (test/utils/task-progress.test.ts, new).
• Suite: 1791 passed (only pre-existing zsh-installer env failures remain); change validates --strict; 36 repo specs pass --specs --strict.

Corrections captured during verification

• openspec validate cannot resolve changes in a workspace planning home #1182 is a membership-gate bug, not a "workspace home" bug. Planning homes are repo-only; the workspace feature is now stores, and validate already accepts --store. show.ts and the deprecated noun-form change validate are scoped out.
• Feedback: openspec view does not detect nested tasks.md files #1202 apply.tracks is a filename, not a glob — it selects the tracked artifact; the glob is that artifact's generates. Parity is resolution-mechanism (same files), not count: status checks file existence and never counts checkboxes (it called a 3/5 change isComplete:true), so view/archive count checkboxes themselves.
• 1.4.0 clearer SHALL/MUST hint does not apply to main specs #1156 the Zod refine is removed, not relaxed — once applySpecRules owns both the header-only and no-keyword cases, the refine would double-emit. RENAMED carries no body and is out of scope.

Scope boundaries

• Not the validate: MODIFIED/REMOVED/RENAMED-from headers that don't exist in base spec aren't caught until archive (proposal: opt-in cross-change MODIFIED) #1112 authoring false-positive (that's sync --check in the sync/unarchive proposal).
• Not artifact completeness (Incomplete artifacts marked as "done" after workflow interruption #1084/No Specs generated after /opsx:propose #1260) — Feedback: openspec view does not detect nested tasks.md files #1202 is strictly about where task files are resolved.

Review surface

• Planning: proposal.md, design.md (root-cause table, empirical evidence, 8 decisions, parity test strategy), specs/cli-validate|cli-view|cli-archive/spec.md, tasks.md.
• Implementation: src/commands/validate.ts, src/core/validation/validator.ts, src/utils/task-progress.ts, src/commands/change.ts, src/core/{view,list,archive}.ts, src/core/schemas/base.schema.ts.
• Tests: test/commands/validate.test.ts, test/core/{validation,view,archive}.test.ts, test/utils/task-progress.test.ts.

🤖 Generated with Claude Code

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds a change bundle with specs, implementation, and tests for validate resolution parity, tracked-task progress resolution, archive gating, and main-spec SHALL/MUST hinting.

Changes

Resolution Parity Bug-Fix Bundle

Layer / File(s)	Summary
Bundle metadata and spec docs openspec/changes/fix-validate-view-resolution-parity/.openspec.yaml, openspec/changes/fix-validate-view-resolution-parity/proposal.md, openspec/changes/fix-validate-view-resolution-parity/design.md, openspec/changes/fix-validate-view-resolution-parity/tasks.md, openspec/changes/fix-validate-view-resolution-parity/specs/...	Adds the change metadata and supporting documents that define the parity requirements, scope, and command-specific behavior.
Validate resolution and hinting src/commands/validate.ts, src/core/schemas/base.schema.ts, src/core/validation/validator.ts, test/commands/validate.test.ts, test/core/validation.test.ts	Switches change selection to filesystem-based resolution, discovers nested delta specs recursively, and moves SHALL/MUST body enforcement into validator logic with matching tests.
Tracked task progress resolution src/utils/task-progress.ts, src/commands/change.ts, src/core/archive.ts, src/core/list.ts, src/core/view.ts, test/utils/task-progress.test.ts, test/core/view.test.ts, test/core/archive.test.ts	Reworks task progress to resolve schema-tracked artifacts and aggregate nested task files, then threads the new progress source through view, list, archive, and tests.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~60 minutes

Possibly related issues

• Feedback: openspec view does not detect nested tasks.md files #1202 — Matches the nested tracked-task resolution behavior added for view.

Possibly related PRs

• Fission-AI/OpenSpec#759 — Touches the same getAvailableChanges-based change discovery path used by validate.
• Fission-AI/OpenSpec#966 — Modifies the same main-spec validation flow in src/core/validation/validator.ts.
• Fission-AI/OpenSpec#1135 — Overlaps on the SHALL/MUST header-only hint behavior and message wording.

Suggested reviewers

• TabishB
• alfred-openspec

Poem

🐇 I hop through globs and nested trees,
And carry tasks on autumn breeze.
A hint, a check, a change, a view—
Parity now shines right through.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 37.50% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately summarizes the core parity fix across validate, view, and archive and references the addressed issues.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (1)

openspec/changes/fix-validate-view-resolution-parity/tasks.md (1)

6-6: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Clarify the validate resolution path.
status.ts uses toPlanningHome(root) + getChangeDir(...), while resolveCurrentPlanningHomeSync(...) is used in instructions.ts; update 1.2 to name the exact pattern validate should follow so the implementation target is unambiguous.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@openspec/changes/fix-validate-view-resolution-parity/tasks.md` at line 6,
Clarify the validate resolution flow by specifying the exact planning-home
lookup pattern it should use: in `src/commands/validate.ts`, resolve the named
item via `resolveCurrentPlanningHomeSync` and `getChangeDir` from
`src/core/planning-home.ts` before any repo-discovery fallback, matching the
shared resolution approach used by `workflow/status.ts` and aligning the wording
with `instructions.ts` so the implementation target is unambiguous.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@openspec/changes/fix-validate-view-resolution-parity/tasks.md`:
- Line 6: Clarify the validate resolution flow by specifying the exact
planning-home lookup pattern it should use: in `src/commands/validate.ts`,
resolve the named item via `resolveCurrentPlanningHomeSync` and `getChangeDir`
from `src/core/planning-home.ts` before any repo-discovery fallback, matching
the shared resolution approach used by `workflow/status.ts` and aligning the
wording with `instructions.ts` so the implementation target is unambiguous.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 409ffc07-1111-49e4-933d-df06e388608b

📥 Commits

Reviewing files that changed from the base of the PR and between 546224e and 0f2a0ee.

📒 Files selected for processing (6)

• openspec/changes/fix-validate-view-resolution-parity/.openspec.yaml
• openspec/changes/fix-validate-view-resolution-parity/design.md
• openspec/changes/fix-validate-view-resolution-parity/proposal.md
• openspec/changes/fix-validate-view-resolution-parity/specs/cli-validate/spec.md
• openspec/changes/fix-validate-view-resolution-parity/specs/cli-view/spec.md
• openspec/changes/fix-validate-view-resolution-parity/tasks.md

[coderabbitai]

🧹 Nitpick comments (1)

openspec/changes/fix-validate-view-resolution-parity/specs/cli-archive/spec.md (1)

21-26: 📐 Maintainability & Code Quality | 🔵 Trivial

Consider adding a scenario for aggregated task counts across multiple glob matches.

The PR summary mentions "aggregate matches," but the spec only implicitly covers this via the glob-tasks scenario. A dedicated scenario would clarify behavior when both a top-level tasks.md and nested **/tasks.md files exist, ensuring the gate counts all tasks rather than stopping at the first match.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In
`@openspec/changes/fix-validate-view-resolution-parity/specs/cli-archive/spec.md`
around lines 21 - 26, Add a dedicated scenario in the cli-archive spec to cover
aggregated task counts when both a top-level changes/<name>/tasks.md and nested
**/tasks.md files exist. Update the archive behavior description around the
incomplete-task gate so it clearly states that the gate uses all matched task
files rather than stopping at the first match, and reference the existing
glob-tasks scenario plus the single top-level tasks file scenario for
consistency.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In
`@openspec/changes/fix-validate-view-resolution-parity/specs/cli-archive/spec.md`:
- Around line 21-26: Add a dedicated scenario in the cli-archive spec to cover
aggregated task counts when both a top-level changes/<name>/tasks.md and nested
**/tasks.md files exist. Update the archive behavior description around the
incomplete-task gate so it clearly states that the gate uses all matched task
files rather than stopping at the first match, and reference the existing
glob-tasks scenario plus the single top-level tasks file scenario for
consistency.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 5850442c-96e9-4809-ac01-ea6e3e647fbe

📥 Commits

Reviewing files that changed from the base of the PR and between 0f2a0ee and 3553f03.

📒 Files selected for processing (6)

• openspec/changes/fix-validate-view-resolution-parity/design.md
• openspec/changes/fix-validate-view-resolution-parity/proposal.md
• openspec/changes/fix-validate-view-resolution-parity/specs/cli-archive/spec.md
• openspec/changes/fix-validate-view-resolution-parity/specs/cli-validate/spec.md
• openspec/changes/fix-validate-view-resolution-parity/specs/cli-view/spec.md
• openspec/changes/fix-validate-view-resolution-parity/tasks.md

✅ Files skipped from review due to trivial changes (2)

• openspec/changes/fix-validate-view-resolution-parity/tasks.md
• openspec/changes/fix-validate-view-resolution-parity/specs/cli-view/spec.md

🚧 Files skipped from review as they are similar to previous changes (1)

• openspec/changes/fix-validate-view-resolution-parity/proposal.md

[coderabbitai]

🧹 Nitpick comments (2)

openspec/changes/fix-validate-view-resolution-parity/design.md (1)

15-20: 📐 Maintainability & Code Quality | 🔵 Trivial | 💤 Low value

Clarify #1182b relationship to #1182 in the root causes table.

The table lists #1182 and #1182b as separate rows, but the PR objectives and commit messages describe three issues total (#1182, #1202, #1156). The #1182b suffix appears to denote a secondary symptom (nested delta discovery) of the same #1182 validation resolution failure. Consider adding a parenthetical or footnote clarifying that #1182b is a sub-symptom of #1182 (nested-layout delta discovery failure), not a fourth independent issue, to prevent readers from expecting a fourth work item in tasks.md.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@openspec/changes/fix-validate-view-resolution-parity/design.md` around lines
15 - 20, Clarify the root-causes table entry for `#1182b` so it is explicitly
presented as a sub-symptom of `#1182` rather than a separate independent issue.
Update the wording around the `#1182` and `#1182b` rows in design.md to note that
the nested-layout delta discovery failure belongs under the broader validate
resolution parity problem, using the existing anchors like
src/core/validation/validator.ts and src/commands/validate.ts to keep the
relationship obvious.

openspec/changes/fix-validate-view-resolution-parity/tasks.md (1)

18-27: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Clarify the apply.tracks vs generates distinction in task 3.2.

The task item correctly captures Decision 4's mechanism, but the inline parenthetical "(NOTE: apply.tracks is a filename that selects the artifact, NOT a glob — the glob is the artifact's generates)" is critical and easy to miss in a long bullet. Consider pulling this into a separate sub-bullet or callout, as misunderstanding this distinction was explicitly called out in design lines 50-53 as a "correction to an earlier draft" that is "load-bearing."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@openspec/changes/fix-validate-view-resolution-parity/tasks.md` around lines
18 - 27, Task 3.2 currently buries a load-bearing distinction between
apply.tracks and generates, which can be missed and lead to the wrong matching
logic. Rewrite the task text in
openspec/changes/fix-validate-view-resolution-parity/tasks.md so the helper in
src/utils/task-progress.ts clearly resolves the tracked artifact by schema
apply.tracks (or tasks fallback) and then counts checkboxes from
artifact.generates, with the distinction pulled into its own sub-bullet or
callout for visibility.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@openspec/changes/fix-validate-view-resolution-parity/design.md`:
- Around line 15-20: Clarify the root-causes table entry for `#1182b` so it is
explicitly presented as a sub-symptom of `#1182` rather than a separate
independent issue. Update the wording around the `#1182` and `#1182b` rows in
design.md to note that the nested-layout delta discovery failure belongs under
the broader validate resolution parity problem, using the existing anchors like
src/core/validation/validator.ts and src/commands/validate.ts to keep the
relationship obvious.

In `@openspec/changes/fix-validate-view-resolution-parity/tasks.md`:
- Around line 18-27: Task 3.2 currently buries a load-bearing distinction
between apply.tracks and generates, which can be missed and lead to the wrong
matching logic. Rewrite the task text in
openspec/changes/fix-validate-view-resolution-parity/tasks.md so the helper in
src/utils/task-progress.ts clearly resolves the tracked artifact by schema
apply.tracks (or tasks fallback) and then counts checkboxes from
artifact.generates, with the distinction pulled into its own sub-bullet or
callout for visibility.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 4d618687-638e-4dfa-bd8c-65c7c7239ce1

📥 Commits

Reviewing files that changed from the base of the PR and between 3553f03 and de572ea.

📒 Files selected for processing (6)

• openspec/changes/fix-validate-view-resolution-parity/design.md
• openspec/changes/fix-validate-view-resolution-parity/proposal.md
• openspec/changes/fix-validate-view-resolution-parity/specs/cli-archive/spec.md
• openspec/changes/fix-validate-view-resolution-parity/specs/cli-validate/spec.md
• openspec/changes/fix-validate-view-resolution-parity/specs/cli-view/spec.md
• openspec/changes/fix-validate-view-resolution-parity/tasks.md

✅ Files skipped from review due to trivial changes (2)

• openspec/changes/fix-validate-view-resolution-parity/proposal.md
• openspec/changes/fix-validate-view-resolution-parity/specs/cli-view/spec.md

🚧 Files skipped from review as they are similar to previous changes (2)

• openspec/changes/fix-validate-view-resolution-parity/specs/cli-archive/spec.md
• openspec/changes/fix-validate-view-resolution-parity/specs/cli-validate/spec.md

[alfred-openspec]

Reviewed the proposal against the current validate/view/archive paths and codebase notes. This is scoped correctly: it fixes the real parity splits in change discovery, schema-backed task resolution, archive task gating, and main-spec hint emission without turning into the broader sync/check work. Approved, with the key implementation bar being parity tests for direct/bulk/interactive validate, store roots, nested task globs, archive blocking, and single-emission hints.

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (2)

test/core/validation.test.ts (1)

682-695: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Consider asserting the issue path field uses forward slashes for the nested layout.

This test exercises new path-construction logic (findDeltaSpecFiles + path.relative/toPosixPath in validator.ts) for nested specs/<area>/<capability> discovery, but only checks report.valid/absence of message substrings — it never asserts the actual issue.path value. Adding an assertion that the reported path uses / (e.g. via a deliberately broken-requirement fixture so an issue with a path is produced) would guard against a future regression leaking OS-specific separators.

As per path instructions: "When touching path behavior, add coverage that would fail on Windows path separators."

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/core/validation.test.ts` around lines 682 - 695, The nested delta
discovery test currently verifies validity and message text only, but it does
not cover the reported issue path formatting. Update the
`Validator.validateChangeDeltaSpecs` / `findDeltaSpecFiles` coverage in this
test to produce an issue that includes a `path`, then assert that the
`issue.path` uses forward slashes for the nested `specs/<area>/<capability>`
layout. This will exercise the `path.relative` and `toPosixPath` behavior in
`validator.ts` and protect against OS-specific separator regressions.

Source: Path instructions

test/core/archive.test.ts (1)

108-150: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Good regression coverage for the nested-glob tasks.md gate; consider also asserting the archive completed.

The test confirms the warning message reflects nested-glob task counts, but doesn't assert that archiveCommand.execute(...) with --yes actually archived the change (i.e., that the gate didn't block it). Adding that assertion would close the loop on verifying --yes bypass behavior alongside correct counting.

✅ Suggested addition

       expect(console.log).toHaveBeenCalledWith(
         expect.stringContaining('2 incomplete task(s) found')
       );
+
+      const archiveDir = path.join(tempDir, 'openspec', 'changes', 'archive');
+      const archives = await fs.readdir(archiveDir);
+      expect(archives.some(a => a.includes(changeName))).toBe(true);
     });

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/core/archive.test.ts` around lines 108 - 150, The regression test in
archiveCommand.execute only checks the nested-glob task warning and does not
verify that the archive actually completed when called with { yes: true }.
Extend the existing test to assert the change was archived after execution,
using the archiveCommand.execute call and the resulting change location/state so
the test covers both correct task counting and that --yes does not block
archiving.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@test/commands/validate.test.ts`:
- Around line 170-185: The test fixture in validate.test.ts is creating its
scratch directory inside the repository tree, which can leave behind
test-validate-iso-tmp after interruptions. Update the isolated setup in the
validate --all test to build isoRoot under os.tmpdir() instead of process.cwd(),
and keep using the existing isoRoot, isoChanges, and runCLI flow so cleanup
remains confined to a temp location.

---

Nitpick comments:
In `@test/core/archive.test.ts`:
- Around line 108-150: The regression test in archiveCommand.execute only checks
the nested-glob task warning and does not verify that the archive actually
completed when called with { yes: true }. Extend the existing test to assert the
change was archived after execution, using the archiveCommand.execute call and
the resulting change location/state so the test covers both correct task
counting and that --yes does not block archiving.

In `@test/core/validation.test.ts`:
- Around line 682-695: The nested delta discovery test currently verifies
validity and message text only, but it does not cover the reported issue path
formatting. Update the `Validator.validateChangeDeltaSpecs` /
`findDeltaSpecFiles` coverage in this test to produce an issue that includes a
`path`, then assert that the `issue.path` uses forward slashes for the nested
`specs/<area>/<capability>` layout. This will exercise the `path.relative` and
`toPosixPath` behavior in `validator.ts` and protect against OS-specific
separator regressions.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: fe761afc-1e21-4564-9494-f6cc83d479c5

📥 Commits

Reviewing files that changed from the base of the PR and between de572ea and 6a5579c.

📒 Files selected for processing (15)

• .changeset/fix-validate-view-resolution-parity.md
• openspec/changes/fix-validate-view-resolution-parity/tasks.md
• src/commands/change.ts
• src/commands/validate.ts
• src/core/archive.ts
• src/core/list.ts
• src/core/schemas/base.schema.ts
• src/core/validation/validator.ts
• src/core/view.ts
• src/utils/task-progress.ts
• test/commands/validate.test.ts
• test/core/archive.test.ts
• test/core/validation.test.ts
• test/core/view.test.ts
• test/utils/task-progress.test.ts

✅ Files skipped from review due to trivial changes (2)

• .changeset/fix-validate-view-resolution-parity.md
• openspec/changes/fix-validate-view-resolution-parity/tasks.md

[coderabbitai]

🩺 Stability & Availability | 🟡 Minor | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
sed -n '1,40p' test/commands/validate.test.ts | rg -n "projectRoot"
rg -n "export const projectRoot|projectRoot =" test/helpers/run-cli.ts test/commands/validate.test.ts

Repository: Fission-AI/OpenSpec

Length of output: 422

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

echo "== validate.test.ts context =="
sed -n '1,220p' test/commands/validate.test.ts | cat -n

echo
echo "== temp-dir patterns in tests =="
rg -n "os\.tmpdir\(\)|test-validate-iso-tmp|test-validate-command-tmp|path\.join\(projectRoot" test -g '*.test.ts'

echo
echo "== run-cli helper context =="
sed -n '1,120p' test/helpers/run-cli.ts | cat -n

Repository: Fission-AI/OpenSpec

Length of output: 27352

---

Move this scratch directory under os.tmpdir()

isoRoot currently lives under process.cwd(), so an interrupted test run can leave test-validate-iso-tmp behind in the repo tree. Use a temp directory outside the checkout for this fixture.

🧰 Tools

🪛 ast-grep (0.44.0)

[warning] 175-175: Filesystem path is not a string literal; a request-/variable-derived path can enable path traversal. Validate and normalize the path before use.
Context: fs.writeFile(path.join(isoChanges, 'only', '.openspec.yaml'), 'schema: spec-driven\n', 'utf-8')
Note: [CWE-22] Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').

(detect-non-literal-fs-filename-typescript)

---

[warning] 176-176: Filesystem path is not a string literal; a request-/variable-derived path can enable path traversal. Validate and normalize the path before use.
Context: fs.writeFile(path.join(deltaDir, 'spec.md'), validDelta, 'utf-8')
Note: [CWE-22] Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal').

(detect-non-literal-fs-filename-typescript)

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/commands/validate.test.ts` around lines 170 - 185, The test fixture in
validate.test.ts is creating its scratch directory inside the repository tree,
which can leave behind test-validate-iso-tmp after interruptions. Update the
isolated setup in the validate --all test to build isoRoot under os.tmpdir()
instead of process.cwd(), and keep using the existing isoRoot, isoChanges, and
runCLI flow so cleanup remains confined to a temp location.

[alfred-openspec]

Re-reviewed Clay's latest push at 6a5579c against the validate/view/archive parity paths and ran the focused local regression set: validate, task-progress, archive, and validation all pass. The remaining CodeRabbit notes are useful test/documentation polish, but not blockers for this fix.

[TabishB]

A quick unrelated note after going through a couple of these PR reviews: I think we actually need a step, possibly before the proposal reviews, where we align on whether something is an issue and deserves a proposal to be made. The proposals are quite heavy in themselves.

I think a lot of this stuff can be caught early. I'm finding that I'm trying to figure out the "why" behind some of this, and it is not as transparent as it could be.

There is a lot of Markdown to go through, read, and understand. I think this can hopefully be figured out at an even earlier step. I am just leaving this as a note for us to discuss later.