Eleven console PRs — a map, a suggested merge order, and permission to close half of them

[ameet-rajababa]

Eleven open PRs from me are sitting in the queue, which is a lot to land on a maintainer without context. This is the map: what they are, why they exist, which order to take them in, and which ones to close if you'd rather not.

Everything here came out of using Archon for a day's work and fixing what got in the way. No PR is a rewrite; every one is scoped to one concern, has tests, and follows the template.

---

The short version

#	What it does	Size	Risk	Server?
#3360	Stops the console collapsing line breaks in your own messages	+8	none	no
#3361	Casts id to text in findWorkflowRunsByIdPrefix	+10	none	yes
#3362	Puts $HOME/.local/bin on a spawned node's PATH	+113	low	yes
#3336	Follows the chat tail by height, not message count	+433	low	no
#3354	Drag and paste files onto the composer	+178	low	no
#3355	Shows which files a sent message carried	+97	none	no
#3356	Lets a file ride the first message of a chat	+244	medium	yes
#3358	Opens a project on the view you last used	+98	low	no
#3365	New chat, switcher, rename	+260	low	no
#3366	Color-label a chat	+490	medium	yes + migration
#3369	The chat rail — replaces #3365's dropdown	+829	medium	no

---

Suggested order

1. Take the four small fixes first — fix(web/console): keep the line breaks in a user's message #3360, fix(db): cast id to text in findWorkflowRunsByIdPrefix #3361, fix(workflows): put $HOME/.local/bin on a spawned node's PATH #3362, fix(console): follow the chat tail by height, not message count #3336. They're independent, low-risk, and mostly one-liners with a test.
2. Then the upload trio — feat(web/console): attach files by dropping or pasting them into the chat composer #3354 → feat(web/console): show on a sent message which files were attached #3355 → feat(server,web/console): attach files to the first message of a new chat #3356. Each stands alone; feat(server,web/console): attach files to the first message of a new chat #3356 is the only one touching the server.
3. Then chat management — feat(web/console): start, switch between and rename a project's chats #3365 → feat(server,web/console): colour-label a chat so a project's list can be scanned #3366 → feat(web/console): show a project's chats as a rail instead of a dropdown #3369, in that order. They're stacked.
4. feat(web/console): open a project on the view it was last used in #3358 whenever — independent of everything.

If you only want one: #3360. Eight lines, and it makes every pasted stack trace in the console readable.

---

Where they came from

Three of these are your own roadmap, not my ideas. console-open-questions.md §1 says:

Current state. The console chat is exactly one persistent conversation per project… There is no way to start a fresh chat, no switcher, no reset.

…and lists "Expose New chat" as recommendation #1 and the switcher as #2. That's #3365, and #3369 is the version of #2 with room to grow.

#1913 covers the upload work, including the note that drag-drop and paste were scoped out of #1916.

---

The chat rail (#3369)

It borrows ProjectRail's language deliberately — monogram tile, filter box, count pill, colored left edge — so the two rails read as one system. The selected card's edge takes the chat's own color rather than the brand accent, so a colored chat shows one signal rather than two.

Screenshots are synthetic — invented project and chat names, nothing from a real workspace.

---

What I'd build next, if you want it

A short summary on each chat, kept current by the agent rather than typed by a human — because a hand-written status field goes stale in a day and then quietly misleads you.

Three fields, optional, in plain language: what we're trying to do, where we are, what's left. The card shows two lines; the pinned card shows all of it. The amber "may be stale" line matters more than it looks — a summary you can't date is one you'll wrongly trust.

This isn't built. It needs a column and a tool the agent calls, and I'd rather know you want it first.

---

Two things worth saying plainly

The console is explicitly disposable. Its own isolation rule exists "so that it can be extracted or discarded cleanly." If you've got plans for it that make #3369 the wrong shape, say so and I'll close it — I'd rather that than have it sit in the queue.

Close anything you don't want. Eleven PRs is a real cost to review and I'd rather you dropped half than felt obliged to work through them. The bug fixes are the ones with the clearest value; the chat-management work is a proposal and should be treated as one.

Happy to split, rebase, or rewrite any of them.

[ameet-rajababa]

Update: two more PRs since this was written, so the map is now thirteen.

#	What it does	Size	Server?
#3369	The chat rail — replaces #3365's dropdown	+829	no
#3371	Archive a chat, and get it back again	+330	yes
#3373	A per-chat summary that shows its age	+560	yes + migration
#3374	The tool that keeps the summary current	+250	yes

#3369 and #3371 were listed already or follow directly from the rail; #3373 and #3374 are the summary work that the original post described as "what I'd build next, if you want it".

---

One finding worth passing on

I tried running these on my own instance by patching the container's server source. It would not boot, and the cause is a trap worth knowing about:

@archon/providers/types on dev exports defineNativeToolInputSchema (added in #3309). A released build does not have it. Both report version 0.10.1, so nothing surfaces the skew until a module throws at load.

That is only a self-inflicted deployment problem on my side — it says nothing about the PRs, which are all against dev and type-check there. But if anyone else is tempted to cherry-pick native-tool work onto a release, that is the wall.

---

The offer still stands, more so now

Thirteen PRs is more than anyone should feel obliged to review. The bug fixes — #3360, #3361, #3362, #3336 — are the ones with the clearest value and the smallest diffs. The chat-management chain (#3365 → #3366 → #3369 → #3371 → #3373 → #3374) is a proposal, and closing it costs me nothing.

Everything works on my own instance regardless, so none of this is blocking me.