How to regenerate artifacts after modifying upstream dependencies?

[liangfengmic]

Description

I'm trying to understand the "Fluid" workflow philosophy in OpenSpec 1.0. The documentation states:

"Natural—update any artifact anytime" (https://github.com/Fission-AI/OpenSpec/blob/main/docs/migration-guide.md#whats-changing)

"During implementation, if you discover the design needs adjustment, just update the artifact and continue." (https://github.com/Fission-AI/OpenSpec/blob/main/docs/getting-started.md)

However, I'm encountering a workflow gap:

Scenario:

1. Run /opsx:ff to create all artifacts (proposal → specs → design → tasks)
2. During implementation, discover that design.md needs significant changes
3. Manually edit design.md
4. Now tasks.md is stale and based on the old design

Problem:

• /opsx:continue only creates the next ready artifact, not regenerate existing ones
• No command to regenerate tasks.md based on updated design.md
• Only workaround: manually delete tasks.md and run /opsx:continue again

Question:
I found a proposal for this exact issue at openspec/changes/add-artifact-regeneration-support/proposal.md in the repo, but it appears unimplemented (only proposal.md exists, no design/specs/tasks).

1. Is artifact regeneration support planned for a future release?
2. Is there a recommended workaround besides manual deletion?
3. Without this feature, how is the 1.0 workflow fundamentally different from the legacy version regarding artifact updates?

Any clarification would be greatly appreciated!

[lobsteinda]

I'm also interested to know how to update task based on updated specs

[aud1ence]

I think we should interact with AI in this case to provide more content and intent, example:

You: I'm implementing add-dark-mode but discovered the design approach
won't work with our current component structure. Need to revise design.md

AI: Let me update design.md based on what you've learned...
[Updates design.md with new approach]

Updated design.md to reflect:
- Component structure constraints
- Alternative implementation strategy

Should I update tasks.md to match?

You: Yes

AI: ✓ Updated tasks.md
Ready to continue with /opsx:apply

[simwong2008]

It seems that OpenSpec only tells us that we can update exsiting specs and re-apply, but it doesn't tell us how to do that correctly.

[opensansara]

same problem

[guangxian81]

I discovered a way to solve the problem. artifacts are generated step by step.
So you can change proposal.md ,and all other markdown files will be change by openspec ,with /opsx:propose.
But if you want to change task.md , you must change all spec.md ,and run /opsx:apply

[clay-good]

Both halves of this are now solved.

1. There is a command for it: /opsx:update. It revises a change's existing planning artifacts and keeps them coherent with one another, planning only, never touching code. Edit design.md, run /opsx:update, and it reports which parts of tasks.md now disagree and offers the fixes. No more deleting files to force regeneration.

Shipped in v1.6.0 via #1340. Docs: docs/commands.md.

2. Stale reads are fixed too. #1368 changed the workflow instructions to re-read dependency artifacts from disk rather than from conversation memory, so a hand-edited design.md is actually picked up rather than remembered wrong. That is on main and ships next release.

On the proposal you found: add-artifact-regeneration-support was removed by #1278, the same PR that introduced /opsx:update. It was replaced, not forgotten.

There is also a whole page for the "wait, can I go back and change that?" question now: docs/editing-changes.md. Its short answer is yes.

Thanks @lobsteinda, @simwong2008, @opensansara, and @guangxian81 for keeping this thread alive until there was something to point at.