You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Let the human change an item's state directly in the sidecar pane (e.g. move a 🧠 Needs action item to ✅ Done). Sidecar writes the change back to the file.
Why — the real payoff
This turns SIDECAR.md into a two-way channel. Today the agent writes and the human reads. If the human can flip state in the pane, sidecar writes the file, and the agent picks up the diff on its next turn — no need to tell it 'I approved that' in chat. The human clicks ✅, Claude sees the file changed and acts. The write is the feature: a human→agent backchannel.
The 'how does the agent notice' is already half-built: the per-turn UserPromptSubmit reconcile hook reads SIDECAR.md every turn, so a human edit lands in the agent's context automatically. This feature rides that rail.
Design tension — don't undo v0.3.0
Clickable buttons need mouse capture, which is exactly what v0.3.0 removed to restore native text selection + clickable links. Re-enabling capture globally would undo that. (OSC 8 link clicks can't help — they open URLs in a browser, they don't call back into the app.)
Recommended framing:
Keyboard-first: cursor to an item (j/k), press a key to change state (d = done, space = cycle section). No mouse capture; keeps selection/links; matches the existing keybind model.
Mouse optional, gated: an 'action mode' toggle key that grabs the mouse for clickable [ ✅ Done ] buttons, so normal mode still has selection.
Scope this pulls in — viewer becomes an editor
Sidecar currently only reads the file; this makes it write. Needs atomic writes (rename-swap) and must lean on its existing reload-on-change so it doesn't fight external edits.
Write concurrency with the agent editing the same file simultaneously (the clobber worry from SQLite backing store instead of a markdown file? #5) becomes real. Consider: only edit the exact line moved, atomic replace, reload on conflict.
Only additive/whitelisted mutations (move item between sections, toggle a checkbox) — never free-form editing.
Parked from the sidecar dogfood queue. Related: #4 (per-section actions), #5 (write concurrency), #7 (template migration).
Let the human change an item's state directly in the sidecar pane (e.g. move a 🧠 Needs action item to ✅ Done). Sidecar writes the change back to the file.
Why — the real payoff
This turns SIDECAR.md into a two-way channel. Today the agent writes and the human reads. If the human can flip state in the pane, sidecar writes the file, and the agent picks up the diff on its next turn — no need to tell it 'I approved that' in chat. The human clicks ✅, Claude sees the file changed and acts. The write is the feature: a human→agent backchannel.
The 'how does the agent notice' is already half-built: the per-turn UserPromptSubmit reconcile hook reads SIDECAR.md every turn, so a human edit lands in the agent's context automatically. This feature rides that rail.
Design tension — don't undo v0.3.0
Clickable buttons need mouse capture, which is exactly what v0.3.0 removed to restore native text selection + clickable links. Re-enabling capture globally would undo that. (OSC 8 link clicks can't help — they open URLs in a browser, they don't call back into the app.)
Recommended framing:
j/k), press a key to change state (d= done,space= cycle section). No mouse capture; keeps selection/links; matches the existing keybind model.[ ✅ Done ]buttons, so normal mode still has selection.Scope this pulls in — viewer becomes an editor
Parked from the sidecar dogfood queue. Related: #4 (per-section actions), #5 (write concurrency), #7 (template migration).