Skip to content

Add bruw/workflow-conductor to seeds - #362

Open
bruw wants to merge 1 commit into
karanb192:mainfrom
bruw:seed-bruw-workflow-conductor
Open

bruw wants to merge 1 commit into
karanb192:mainfrom
bruw:seed-bruw-workflow-conductor

Conversation

@bruw

@bruw bruw commented Oct 20, 2026 •

Copy link
Copy Markdown

Adds bruw/workflow-conductor to data/seeds.txt (alphabetical, ignoring case).

Conductor demo

Conductor is a terminal UI for planning, running and understanding complex agent workflows inside Claude Code: a designer pane and a one-line band above the prompt, the /conductor command, and two tools of its own that Claude calls to read and edit a project and before writing a Workflow script. Its hooks read agent spawns, model turns and turn ends to draw a Workflow run on the plan. It makes no network requests and runs no programs; it writes only its project files under .claude/. The band hook passes downstream content through (next(e)).

MIT. Requires Claude Code 2.1.296+. claude plugin validate passes on v0.4.2.

Disclosure: I'm the author.

@bruw
bruw force-pushed the seed-bruw-workflow-conductor branch from eb36426 to 3bd532c Compare October 20, 2026 15:56

@karanb192 karanb192 left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1. Blocking: check the current project file before saving an open project's edits.

At hooks/project.tsx:1476-1488, an open project uses the cached projectAtom and skips reading its file. The revision guard tracks only this loaded session. If another session updates a block's logic, the next apply in the first session writes its cached project over that update through saveProject at lines 327-332.

Reconcile external changes or refuse a stale edit before saving. Apply the same protection to direct board edits, which also save cached state.

Verified good: Source 523e643cbb4287a0c9bb97eb18823e7b323065d9 passes all 175 original engine tests and plugin validation. The added regression writes a project, changes its file externally, then adds an unrelated block through the tool: expected the newer logic, received the original. File I/O is mocked. The existing two-surface prompt-band preservation test passes.

@bruw

bruw commented Oct 20, 2026 •

Copy link
Copy Markdown
Author

Thanks for the careful review and for catching this. It was a real data-loss bug.

It's fixed in v0.4.3 (bruw/workflow-conductor#8). Every save now checks the file against what the session last read or wrote, and if another session changed it write is skipped. This covers both tool edits and direct board edits:

  • Board edits: the board loads the newer file.
  • Claude's edits: they're refused until Claude reads the project again.

Added a regression test

@karanb192 karanb192 left a comment

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

1. Blocking: protect the complete read-to-write project update from overlapping saves.

At hooks/project.tsx:366-383, saveProject still writes unconditionally after its preflight read. The independent regression saves a newer project between that read and write; the saved logic changes from concurrent external save back to original. Protect the entire update or fail on conflict without replacing the newer file. Another comparison before an unconditional write leaves the same gap.

Verified good: The older external-edit case and strict validation pass. The new invalid-file protection does not cover this overlap. One author-suite timeout remains in isolation, separate from this reproducible data-loss failure. Filesystem calls were mocked.

Reviewed upstream source: fa1ea338c05d6078d5e0514394240f0653f93f5e.

@bruw

bruw commented Oct 22, 2026

Copy link
Copy Markdown
Author

At hooks/project.tsx:366-383, saveProject still writes unconditionally after its preflight read. The independent regression saves a newer project between that read and write; the saved logic changes from concurrent external save back to original. Protect the entire update or fail on conflict without replacing the newer file. Another comparison before an unconditional write leaves the same gap.

Yeah that's valid, I documented the gap in the PR.

RCA: Mod Engine does not provide atomic read-write operations. So before we write we first read the file and compare it has not moved. That leaves a short gap between read and before the write where the file could be written to by another process without plugin knowing.

Since the engine does not provide atomic read-write, there will always be this gap.
In practice after the fix that's milliseconds so a silent overwrite is very unlikely.

The only other solution I could think of was adding a lock, but that's overly complex and it still only guards the multiple plugin sessions on one file - not a likely scenario and not a universal fix.

Will keep it as is for now with this case documented, until a solution is found or it proves to be a real issue.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants