[Jacksondr5]

Upstream edits, approved by Jackson (2026-10-13)

Four edits inside upstream's files, each its own commit.

#	Commit	Size	Without it	With it
1	04f1f39402	MessagesTimeline.tsx, 1 import, 1 prop renamed where it is read, 1 hook call	A person's own bubble, Copy and the minimap show the raw [Message from …] line; another person's message cannot be told from the reader's own	Own messages as today; whose each message is reaches J5's card
2	658e068794	MessagesTimeline.tsx, 1 import, 1 line	A settled approval or question does not say who answered	"· answered by Priya" after the prompt's line. Depends on edit 1, whose hook reads who answered
3	7b3503ae92, then ab430f6235	ChatView.tsx, 1 import, 2 lines	"Edit from here" on a message of a shared conversation puts its note and [Message from …] line in the composer, and sending it again shows them	The typed words come back
4	91011056f6	packages/client-runtime/package.json, 4 lines	The functions that split a stored message cannot be imported by web or mobile from the client runtime	One more J5 export, ./j5/shared-conversation

Decisions

• The author line and the note keep their format. The note no longer reports answered approvals: the server stopped writing that line (Jackson, 2026-10-13). "Answered by" on a prompt is unchanged.
• Three messages that each carry the note show three notices, one closed line each; they do not collapse (the build lead).
• A member's slash command is sent as typed (Jackson, 2026-10-13): no author line, no note and no record, so /compact, /goal … and a provider's commands and skills work for a member. On a guest's screen such a message is drawn as a card naming "A member" (72872ebd51): the server stamps everything a guest sends, so an unstamped command from the server is a member's, though which member is not known. A member's screen keeps upstream's bubble for it.
• A guest's slash message is always stamped, so it reaches the agent as words under their name.
• The thread title gets no upstream edit, and "Edit from here" is not offered on another person's message.
• Another person's message is a card: initials, the name, a "guest" or "member" tag, the time, Copy, and the words drawn as upstream draws a person's own.

Known limits

• A mention on another person's message shows as its label, not as upstream's chip, and Copy gives the label (as upstream's Copy does). Before 331953bb1c it showed as a raw [label](t3-context://…) link.
• A member's slash command on another member's screen is drawn as that member's own bubble: without a record, a member's client cannot tell its own command from another member's.
• Another person's attachments are not drawn on the card (Sharing: let a guest collaborator attach files and mention things #597). A member's message with an image shows its words only on a guest's screen (and on another member's). The member's own bubble shows the image.
• A one-frame gap: on a member's screen, the first prompt answered in a thread where nobody has sent a message since it was shared can show [Answer from …] for one frame.
• Claude's expanded tool row can read [Answer from Priya (guest)] Coffee: that is a tool's own output, which the client does not rewrite.
• A View guest sees a prompt's options and Submit disabled, as upstream shows them (Jackson, 2026-10-13).
• A guest's slash commands are sent as words.
• Search results and a fork of a shared thread show platform text: Shared conversations: upstream surfaces that show a stored message's text show the platform's lines #612. Mobile: Share links: sharing on mobile #609. Attachments from a guest: Sharing: let a guest collaborator attach files and mention things #597.

Live testing of the final change

After the rebase onto #615 (#600 at a1f88a47a7, 72872ebd51), on a rebuilt test home: a guest who joined by an open link lands on the thread and sees cards and the notice, with no platform text; the same guest joins a second thread's open link as themselves. Nothing visible changed, so no new images.

On #600 at f59b9d9a12, a rebuilt test home, Claude Haiku and GPT-6-Luna, headless Chromium:

• A guest's message with a thread mention: a chip on the guest's own bubble; on the member's screen a card whose words show the thread's title, and Copy gives those words. No t3-context:// link and no platform text on either screen.
• A member's /compact on a Claude thread: sent as typed; compaction ran ("Context compacted 42.1K → 3.67K tokens"). The member sees their own bubble. The guest saw it as their own bubble ("You") before 72872ebd51, and as a card naming "A member" after.
• A member's /goal … on a Codex thread (GPT-6-Luna): sent as typed; Codex took it as a goal ("Pursuing goal"), and the member then paused it. The guest sees a card naming "A member".
• A guest's /compact: the guest's own bubble shows /compact; the member sees the guest's card; no compaction ran.
• A member's message with a thread mention, on a guest's screen (on 26263850b2): the card shows the thread's title, not the link.
• A member's message with an image, on a guest's screen (on 26263850b2): the words only (the limit above).

	Before	After
Another person's message with a mention, on the reader's screen

	Before	After
A member's /compact on the guest's screen
A member's /goal on a Codex thread, on the guest's screen	new
A guest's /compact on the member's screen	new

Earlier runs are below, as they were written at the time.

Problem

In a shared conversation the server stores each person's message with a first line for the agent, and sends the agent its own notes about who can write. The client showed both raw, every message as "You", and never who answered a prompt (#533; Shared conversations AC9, AC17 to AC19).

What changed

• Whose a message is comes from the server's record (j5.sharing.listThreadAuthors), never from the text. It is asked for only when a thread holds a message that begins exactly as the server writes an author line (J5's older envelopes that also begin [Message from do not count; an ordinary thread holding one sent no request, counted live), and again when the server's copy of a person's message arrives (its text gains the author line) or a prompt settles. One read after a message arrives settles whose it is: a read asked for while another is out is sent again and the earlier answer is never shown, which a test holds. Who answered is shown only on a settled prompt: the server records the answerer before the prompt settles, and an open prompt is never read for one.

• Another person's message is a card with their name. The reader's own is drawn as before, without the author line.

• The platform's note is a one-line notice, "The agent was told who can write to this thread", that opens to the text.

• A settled prompt says who answered it.

• The cards use the seam upstream's timeline already gives J5 for agent-to-agent deliveries, so they need no upstream edit.

• A Crew roster for a guest (J5's own j5/crew files, no upstream edit): a guest's client reads the rosters waiting on its thread (j5.crews.listThreadRosters), shows each seat's model and access with no way to change them, and approves or declines as proposed when it holds Collaborate. The gate's card says who decided ("· by Priya (guest)") when the server names them.

Another person's message is J5's card. It carries Copy, which gives the typed words without the author line.

Not built, a product question for Jackson: "Edit from here" on someone else's message. It would hand one person's words to another's composer and rewind the thread from a message someone else sent.

Checked and clean: a browser or desktop notification and the in-app toast show a fixed title ("Thread completed", "Approval needed" and so on) and the thread's title, never message text; the page title is the app's name.

Known limit, as ruled: every member's connection is the one owner, so a second member sees the owner's messages as their own.

UI changes

Before is #601's tip and after is this PR's, on the same server data and the same conversation. The guest's first message carries the note for the agent, as the server now stores it:

	Before	After
A member's view: the first shared message, which carries the note for the agent (current notice)
The guest's view of the same conversation (current notice)

From earlier runs, unchanged:

A Crew roster as a guest sees it: seats shown, nothing to edit
A settled approval says who answered

Live testing

On the reworked server, by the builder (521e1ee6eb over #600 at 48bc09fac8; rebuilt test home; a member and a guest added with the test script's guest command; Claude Haiku; headless Chromium):

• The guest's first message carries the note. Both screens show "The agent was told who can write to this thread" as a notice just before it, opening to the note's words with no tags; the member sees the guest's card, the guest their own bubble. The agent answered the message directly, with no turn of its own for the note.
• Sampled every frame on both screens over three messages: no frame showed [Message from or j5_shared_conversation.
• Copy on the card that carried the note gave only the typed words.
• With a run held: the member's queue line read "Priya: Guest queued words", the editor held "Guest queued words", the edit sent exactly the edited words, and the stored text was the author line with "edited by Test owner (member)" then those words. The guest's editor then held the edited words.
• "Edit from here" on the member's own message returned the typed words.

After the server's fix for the missing answerer (c7d99cacc7 over #600 at 9b380f8aea, rebuilt home, same setup):

• A prompt answered as the first shared action. The member's thread had an approval pending and no message from anyone since sharing. The guest was added and approved it. The member's log read "· answered by Priya", the guest's "· answered by you". The member's client sent no listThreadAuthors before the thread was shared and one after.
• A question answered by the guest (Claude's AskUserQuestion): the row read "Tea or coffee? / Coffee / · answered by Priya" for the member and "· answered by you" for the guest, with no [Answer from …] on it.
• "Edit from here": a guest's own message has Copy only; a member's own has both.
• The notice reads "The agent was given a note with this message" and opens to the note's words.

Left as it is, by the build lead's ruling: where upstream's own tool row shows a tool call's result, an answer can still read [Answer from Priya (guest)] Coffee. That is the answer with who gave it, which is true; the client does not rewrite a tool's output or edit upstream's row.

Not exercised on this version: a question on Codex; a Crew roster; lowering and raising a level; a change note with a purpose line; an inbox reply's card; the queued start, frame-sampled.

Earlier runs, on the note as a message of its own. What they showed about cards, the queue, levels and Crew still holds; what they showed about the note's own row no longer applies.

On #600 at b7678575d1 (4db5235f0b, rebuilt test home, a member and a guest, Claude Haiku, headless Chromium):

• Who answered, now that the record names a person only once the prompt has settled. An approval and a question, each answered by the guest: "· answered by Priya" on the member's screen and "· answered by you" on the guest's, about five seconds after the click on both (the measure includes the turn settling and the work row being opened, sampled every quarter second). The record is read again each time a prompt settles, so no read made before the settle is the last one.
• Found and fixed (4db5235f0b): for one frame after a question was answered, both screens read [Answer from Priya (guest)] Dogs, because the answer arrives a moment before the record does. The line is now taken off by its shape once the thread is known to be shared. Frame-sampled again on both screens (936 and 961 frames): none shows it. Not covered: a member's screen for the very first prompt answered in a thread where nobody has yet sent a message since it was shared, which can still show it for that frame.
• A note that repeats. A guest queued three messages while the agent was busy and before any message carrying the first note had run. The queue shows three plain lines with no note. Once run, each message has its own closed notice above it, as below. Left as built: the lead ruled that they do not collapse.
• Names in a card, the queue line, "answered by" and People all come from the record's name, never from the author line, so the server's change to the line (angle brackets stripped) is not seen by a person.

Three messages queued by a guest before the first note had run: the queue
The same three once run: each has its own notice

On #600 at bf9cab3f64 (a6bfff17bf): rebased onto the new j5/main, FORK case renumbered to 77, no content change; typechecked and unit-tested, not run live again.

On #600 at 31450e5ad3 (then 75fc1e0f9b): rebased only, typechecked and unit-tested, not run live again; the server change is wording in the note. Search results and a fork showing platform text are known limits (#612); the thread title gets no upstream edit.

On #600 at ccd862884d (then b200532225, rebuilt test home, a guest collaborating on the project, Claude Haiku, headless Chromium):

• A new thread started by the owner in a shared project. Its first message now carries the note and author line. The owner sees one closed notice and their own bubble; the guest sees the notice and a card "Test owner · member". Frame-sampled on the owner's screen from the draft through the launch (281 frames) and on both screens after (1,572 and 1,091): no platform text on any. The thread was titled "Create a Launch Text File", from the typed words, not the note.
• A guest whose answer comes second. With what the server sends the guest held back, the owner approved and the guest then declined. The guest sees a red line above the thread, "This prompt is not waiting for an answer.", the prompt closes, and the row reads "· answered by Test owner". Without the hold, the prompt left the guest's screen within 60 ms of the owner's click, before the guest could press anything.
• A rewind to before the note: the resent message gets a fresh note and one notice (seen with the "Edit from here" fix above).

A new thread in a shared project, the owner's first message
The same thread on the guest's screen
A guest whose answer came second

After the independent test of 3c2c3d02cf (the fix is now 2c3fcdb22d, rebuilt test home, Claude Haiku, headless Chromium):

• Found by the tester, fixed (2c3fcdb22d): "Edit from here" on a message carrying a note put the note, the author line and the words in the composer, and sending it drew all of it. Reproduced first, then fixed: the typed words are read before the rewind, which takes the message out of the author record. Seen on a note-carrying message and on a plain authored one: the composer holds only the typed words, and the resent message shows no platform text. No unit test: the change is the order of two lines in ChatView.
• "Queued" on a guest's own answered messages: upstream's marker for a message that was sent as a queued turn, stored on the message. It is not a statement that the message is still queued. Left alone.
• A View guest sees a question's options and Submit, disabled: upstream's own look for a connection that cannot operate the thread; approvals look the same. Hiding them takes edits in two upstream files, so it is left for a ruling.
• A second "Edit from here" after a resend fails ("Rollback target run ordinal 2 is unavailable…"): the same happens on an unshared thread on j5/main (79e53e8580), so it is not this stack's.
• Platform text still shows, not fixed: sidebar search results for a shared thread show the stored text ("You: [Message from Priya (guest)] Reply with…", and the note for a note-carrying message); a fork of a shared thread shows the note and author lines raw in the copied messages, since the fork's messages are new ones the record does not hold.

Peer tester, #601 and #602 together (report: test-reports/j5code/share-ui-5-shared-conversation.md, commit 8f32050c64, Haiku and Luna turns). Verdict: fail, on three findings; all thirteen areas were exercised.

• Passed: the Share dialog with Collaborate; the guest's composer; a two-person conversation with cards and the note as a notice; the queue with a held run, including a member steering a guest's queued message; approvals answered in both directions, with who answered shown after and nothing while open, and kept across a restart; a question answered by the guest; a Crew roster approved by the guest; the promotion dialog for a self-named person; lowering and raising the level live; an unshared thread and a View guest seeing nothing new; a restart.
• Found, fixed since (now in c698a84b3b, which also keeps the line from flashing for a few frames while the record is read), re-run pending: a later message sometimes showed its raw [Message from …] line, and Copy then carried it. The record of who wrote what was read too early for a person's own message.
• Found, fixed since in feat(web): a guest who holds Collaborate sends, queues and answers from the web client #601 (b58c6f28a3), re-run pending: a View guest could click Dismiss on a dismissible question; the server refused it.
• Found, the server as built: a question the member answered while the only collaborator was lowered to View shows no answerer, then or later. Who answered is recorded only while a guest can write.
• Observed, not a failure: a "Queued" label stays on some messages. Checked afterwards against the stored value: it is upstream's own label for a message that really queued, which in a shared thread is the first message after who can write changed (it queues behind the note's turn) and any message sent while a run is going. In a steady exchange with the agent idle between messages, none of six messages carried it. No thread stayed unread in a guest's sidebar.

The tester's final round (same report, dec7d20416 then a5424e6224): all pass. Frame-sampled on both screens through hold, queue, edit and release: no raw author line, no nameless card, no message on the wrong side. A member's edit of a guest's queued message is stored as the author line, with its "edited by", then exactly the typed words. "Edit from here" returns typed words. An unshared thread with an inbox-reply-shaped message sends no request; a typed look-alike sends one and stays as typed. A change note with a purpose line reads cleanly, and in-thread search shows no author line. Copy on the other person's card gives exactly their words, both ways, and there is no "Edit from here" on someone else's message. A rename while "Let … collaborate?" is open is caught on Save (see #601), with one caveat recorded there. Only these requested checks were re-run on the final commits; the full thirteen-item run is on 8f32050c64.

The tester's earlier re-run (same report, commit c698a84b3b): the raw author line and Copy pass with zero frames showing the line on either screen, including on reopening; Dismiss as a View guest passes; a question answered by the member shows the member's name; a Crew seat beneath the Captain is read-only with no cards or notes; a held guest's queued message leaves both queues when they are lowered; a guest shared as Jackson (member) reads "Jackson" tagged guest. One fail there: a person's own queued message showed as a card with no name for 60 to 300 ms when its turn started. Fixed since (in a5424e6224); the builder's frame sampling on the fix found none; the tester's re-check is pending.

After the Opus review (nothing blocking), on a5424e6224, seen live by the builder: an ordinary thread holding an inbox-reply-shaped message sends no listThreadAuthors, and a typed look-alike line is asked about once and then shown as typed; a member who edits a guest's queued message is handed the guest's words, sends exactly the edited words, and the stored text is the author line then those words; "Edit from here" on a message of a shared conversation returns the typed words; in-thread search shows messages without the line; a guest lowered to View while editing their own queued message loses the item and the edit state with no error.

The tester's targeted re-run (same report, commit d59a4dcaf9):

• Pass: Dismiss as a View guest does nothing by click, Enter or Space and sends no request, including after a live lowering from Collaborate; it still works for the member and for the guest raised again. After a hold, a guest's queue edit, a member's queued message, a release and a switch to Supervised, four rapid alternating messages settle with no author line. Copy on each person's own message holds only the typed words. A question answered by the member shows the member's name to a guest who still holds Collaborate.
• Withdrawn: the missing answerer with only a View guest present, which is the server's rule.
• Still failing on that commit: the raw author line flashing for a few frames as a message arrives (150 to 462 ms). c698a84b3b, one commit later, keeps the line off the screen while the record is read; the builder's own per-frame sampling there found none. The tester's sampling on that commit is pending.
• The full thirteen-item run is on 8f32050c64; later commits got these targeted re-runs only.

The builder's own runs:

By the builder, on the commits now at the tip, same setup as #601: the same conversation opened as the member and as the guest; the member sees the guest's card and the guest sees the member's; the note is a notice for both; after the guest approved a command, the member's expanded work log reads "· answered by Priya". A Crew, live: after the member allowed it, the guest asked for a Crew of two; the roster appeared above the guest's composer with Decline and "Approve 2 seats" and no Edit, Remove or Add; the guest approved; the gate left and the notice read "readme-note-crew · by Priya (guest)". The member's card for the same roster had the edit controls. One stray request seen: after approving, the card asked for one more runtime preview and was told the proposal is no longer open; nothing showed. The agent told the guest the roster was "waiting for approval in the app's inbox", which is the agent's own wording and not true for a guest. Not exercised live: a question prompt's answerer, a thread shared and later unshared, a long history.

Upstream impact

FORK.md case 77 (76 until main took case 74 and the server's case moved up) and the file-table row; a History line under D33.

Checklist

• One concern
• Tests cover the changed behavior
• UI changes: before/after pairs above; no motion in this change
• Live testing: the section above says what ran live and what did not
• Upstream-owned files: recorded in FORK.md in this PR
• Upstream product: Jackson approved the edits on 2026-10-13; the register's History line says so
• Surfaces: web and desktop; mobile out of scope
• Docs: none yet

Claude Opus 5.5, Claude Code harness in J5 Code.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
j5-code	Ready	Preview	Oct 14, 2026 6:49pm UTC

[Jacksondr5]

@bryantderosier an update since my replies, after Jackson's read of the stack (2026-10-13):

• Crews: a thread grant writes to the one agent it names and reads the agents beneath it; a guest still cannot answer a seat's prompts. "A grant applies to all children" was considered and withdrawn for now because of its Crew and inbox effects (Sharing v2: a Crew's seat requests go to the inbox, which a guest collaborator never sees #534).
• AC9: the line that told the agent about approvals on the next message is removed (a queued message is the wrong way to deliver it). People still see who answered; a question's answer carries its author; a roster's Captain gets decided_by.
• Content: a guest's message may now carry composer context (mentions and the other kinds). Attachments stay refused and move to Sharing: let a guest collaborator attach files and mention things #597 with the id check written there. A guest's plan reference must name a thread they collaborate on (a security pass found upstream marks the source plan completed); titleSeed is not taken from a guest.
• Slash commands: the author line at the front meant no slash command worked in a shared conversation. A member's message that begins with / now goes to the agent as typed; a guest's is always labelled, so it reaches the agent as words.
• Format: the author line and note stay as they are; the author as an upstream context record, and the line at the end of the message, were looked at and recorded on Shared conversations: upstream surfaces that show a stored message's text show the platform's lines #612.
• Mobile: out of scope (Share links: sharing on mobile #609).

A third security pass on the content change and a final live pass at 6d36fafd11 (test-reports/j5code/collaborate-final-6d36fafd11.md) both came back clean.

🤖 Generated with Claude Code

[Jacksondr5]

Closed unmerged, by Jackson's decision (2026-10-17). The product was redefined from first principles in #631 (People and access, and a reworked Shared conversations), which reverses most of this stack's guest restrictions. The parts that still apply (the author line and note, the launch wrap, the answer records, the cards and notices) will be carried into a single rebuild PR against the new definitions, after the next upstream advance. The branch is kept for reference.

🤖 Generated with Claude Code