Skip to content

Let the tool drawer put rows straight into the collection plan - #67

Merged
depalmar merged 1 commit into
mainfrom
feat/tool-drawer-to-plan
Aug 15, 2026
Merged

depalmar merged 1 commit into
mainfrom
feat/tool-drawer-to-plan

Conversation

@depalmar

Copy link
Copy Markdown
Owner

F18. The realistic entry point is "this host runs Claude Desktop". That led to a drawer → Show all 32 artifacts → the catalog → 32 individual ticks. Nothing on that path picked anything, though the drawer already ranks those rows by volatility two sections above the button.

Two buttons in the drawer footer: Add volatile (n) and Add all n. Both reuse the existing picks / savePicks, so a row added here is indistinguishable from one ticked by hand — no second path into the plan.

Why "volatile", not "p1"

The handoff proposed Add p1 paths. triage_priority lives on the tool, not on the row, so there is no p1 subset of these rows to offer — a button labelled p1 would name a field the data doesn't carry at that level.

Volatility is on every row, it answers "what do I lose if I reboot first", and the drawer's own Order of collection section already ranks by it. The button now matches the section above it.

Add-only on purpose

A button that un-picked on a second press would silently lose work, and per-row removal already exists in the plan. Pressing again reports Already in plan and adds nothing.

Verified in a browser

On AIRT-0011:

Check Result
Button labels Add volatile (8), Add all 32
Two clicks from closed drawer 8 picks — exactly the 8 live + rotating rows
Persisted 8 in localStorage
Plan view 8 rows, matches picks
Then Add all tops up to 32, no duplicates, reports Added 24
Third press stays 32, reports Already in plan

On AIRT-0013, which has no volatile rows, the volatile button is correctly absent.

Accept-when from the handoff: "a responder can go from Tools → a populated plan in two clicks." Met.

Gates

All pass.

🤖 Generated with Claude Code

F18. The realistic entry point is "this host runs Claude Desktop", and that led
to a drawer, then Show all 32 artifacts, then the catalog, then 32 individual
ticks. Nothing on that path picked anything, though the drawer already ranks the
rows by volatility two sections above the button.

Two buttons in the drawer footer: Add volatile (n) and Add all n. Both reuse
picks and savePicks, so a row added here is indistinguishable from one ticked by
hand, and neither introduces a second way into the plan.

Called it volatile rather than p1, which is what the handoff proposed.
triage_priority lives on the tool, not on the row, so there is no p1 subset of
these rows to offer - a button labelled p1 would be naming a field the data does
not carry at that level. Volatility is the field that answers "what do I lose if
I reboot first", it is already on every row, and the drawer's own Order of
collection section ranks by it, so the button matches the section above it.

Add-only on purpose. A button that un-picked on a second press would silently
lose work, and per-row removal already exists in the plan. Pressing again reports
Already in plan and adds nothing.

Verified in a browser rather than reasoned about. On AIRT-0011: buttons render
Add volatile (8) and Add all 32; two clicks from a closed drawer leave 8 picks,
matching the 8 live and rotating rows exactly, persisted to localStorage and
showing as 8 rows in the plan view. Add all then tops up to 32 without
duplicating and reports Added 24. A third press reports Already in plan and
leaves the count at 32. On AIRT-0013, which has no volatile rows, the volatile
button is correctly absent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@depalmar
depalmar merged commit db00586 into main Aug 15, 2026
4 checks passed
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.

1 participant