Feedback: openspec view does not detect nested tasks.md files

[awaithope]

OpenSpec version: 1.3.1\n\nWe use a project-local schema where the tasks artifact is configured as generates: "**/tasks.md" because each change can have separate backend/tasks.md and frontend/tasks.md files.\n\nObserved behavior:\n- openspec status --change correctly detects the tasks artifact as done and shows 4/4 artifacts complete.\n- openspec view does not show task progress for the same change. It classifies the change as Draft because it appears to look only for openspec/changes//tasks.md.\n\nExample structure:\nopenspec/changes/refine-people-groups-browse/backend/tasks.md\nopenspec/changes/refine-people-groups-browse/frontend/tasks.md\n\nExpected behavior:\nopenspec view should use the resolved schema artifact output glob, or at least count all **/tasks.md files, so dashboard task progress matches openspec status.\n\nLikely cause:\ndist/utils/task-progress.js getTaskProgressForChange() currently reads path.join(changesDir, changeName, 'tasks.md') directly, instead of resolving the schema glob or recursively collecting tasks.md files.\n\nSuggested fix:\nMake getTaskProgressForChange() aggregate checkbox counts from every resolved tasks artifact output, e.g. **/tasks.md for schemas that support layered frontend/backend design/tasks. This would make view consistent with status and project-local schemas.

---

Submitted via OpenSpec CLI

• Version: 1.3.1
• Platform: linux
• Timestamp: 2026-06-11T13:27:44.314Z

[mc856]

Two open PRs target this — #1235 and #1254. Both fix it the same way: recursively summing tasks.md under the change dir. (Confirmed against main: getTaskProgressForChange only reads <change>/tasks.md, so a nested-only change returns {0,0} and view buckets it as Draft — matches the report.)

One thing neither resolves, in case it helps triage: both hardcode the filename tasks.md and recurse, rather than resolving the schema's configured generates glob. So a project-local schema whose tasks artifact is named differently still wouldn't be counted — this matches the "at least count all **/tasks.md" fallback in the report, but the schema-aware path stays open.

[clay-good]

Closing as fixed by #1280, shipped in v1.6.0. getTaskProgressForChange (src/utils/task-progress.ts) now resolves the tracked tasks artifact through the schema: apply.tracks selects the artifact and its generates glob is aggregated, exactly as you suggested. The same resolution feeds view, list, and archive's incomplete-task gate, so all of them agree with status now.

Verified with your exact layout on current main: a schema with generates: "**/tasks.md" plus backend/tasks.md (1/2) and frontend/tasks.md (1/1) shows 2/3 tasks in list and 67% Active in view. No more Draft demotion for layered changes.