/opsx:continue does not reflect spec.md changes after design.md and tasks.md deletion

[HowardYan888]

Description:

When I modify an existing spec.md file within a change, then delete the corresponding design.md and tasks.md files, and subsequently run /opsx:continue, the newly generated design.md and tasks.md do not reflect the changes made to the spec.md. It appears that /opsx:continue might be using an outdated context or cache of the spec.md when regenerating these artifacts.

Steps to Reproduce:

Start a new change (e.g., using /opsx:propose or /opsx:new).
Allow spec.md, design.md, and tasks.md to be generated.
Open the spec.md file (e.g., openspec/changes//specs//spec.md) and make a significant modification (e.g., add a new requirement, change a key detail). Save the spec.md.
Delete the design.md file (e.g., openspec/changes//design.md).
Delete the tasks.md file (e.g., openspec/changes//tasks.md).
Run the command /opsx:continue within the change directory.
Observe the newly generated design.md and tasks.md.
Expected Behavior:

The newly generated design.md and tasks.md should incorporate and reflect the latest changes made to the spec.md file. The /opsx:continue command should re-evaluate the current state of the spec.md when regenerating dependent artifacts.

Actual Behavior:

The newly generated design.md and tasks.md appear to be based on the original content of the spec.md (before the modification in step 3), completely ignoring the recent changes. This forces manual re-creation or extensive manual editing to align design.md and tasks.md with the updated spec.md.

[clay-good]

Hi @HowardYan888, thanks for the detailed repro — this is a real gap and your diagnosis was right: the CLI reads nothing itself, but the workflow instructions only told the agent to "read dependency files for context," so an agent that already had spec.md in its session context treated it as read and regenerated design.md/tasks.md from the stale, pre-edit copy.

I've opened #1368 to fix this: the continue/propose/fast-forward instructions and the openspec instructions dependency block now tell the agent to re-read dependency artifacts from disk before creating the next one, even if it saw them earlier in the conversation. With that, your exact workflow (edit spec.md, delete design.md + tasks.md, run /opsx:continue) regenerates from the current spec content.

Until it ships, a reliable workaround is to say explicitly: "I've edited spec.md since you last read it — re-read it from disk before regenerating."

[clay-good]

Fixed on main. Your repro was correct and so was the instinct that something was stale, though the cache was in the conversation rather than in the CLI.

The CLI reads nothing on its own. The workflow instructions simply said "read dependency files for context," so an agent that already had spec.md in its session context considered it read and regenerated design.md and tasks.md from the pre-edit copy.

The instructions now say the quiet part out loud:

Always read dependency artifacts before creating a new one - re-read from disk, not from conversation memory (files may have changed since you last saw them)

continue-change.ts:109, with the same line in propose.ts, ff-change.ts, and the openspec instructions dependency block.

Fix: #1368. Your exact sequence (edit spec.md, delete design.md and tasks.md, run /opsx:continue) now regenerates from what is on disk. Merged to main, ships in the next release.