fleet/fleetd
3
0
Fork 0
Code Issues 106 Pull Requests 3 Actions Packages Projects Releases 1 Wiki Activity

The observer-send header names only a terminal id — add the space and tab label so a receiver can tell who sent it #799

New Issue
Open
opened 2026-10-06 19:10:57 +02:00 by ltms · 0 comments
ltms commented 2026-10-06 19:10:57 +02:00
Owner
Copy Link
Copy Source

Requested by the operator on 2026-10-06, after a day of reading these headers by hand.

Now

FleetMcp.attributeIfObserver (FleetMcp.java:994) prefixes an observer's SEND with its terminal id and nothing else:

public static String attributeIfObserver(Principal caller, String content) {
    return caller != null && caller.isObserver()
            ? "[fleet_send from observer " + caller.terminal() + "]\n" + content : content;
}

A receiver sees:

[fleet_send from observer term_65d106559ba0a2]
vms channel check

term_65d106559ba0a2 identifies the sender exactly and tells a reader nothing. Every message today had to be resolved against fleet_list by hand to learn it was the vms tab in the vms space. Three panes were involved and the ids differ only in their last few characters, which is also how a reader mixes two of them up.

Wanted

The space and tab label in the header, alongside the id:

[fleet_send from observer vms (space vms, tab w9:t1) term_65d106559ba0a2]

Exact wording is the implementer's call. The constraints below are not.

The labels already exist on the server

identity.panes() supplies tabLabels and workspaceLabels as lazy suppliers, already wired into the fleet_list path at FleetMcp.java:617, and PaneSource (FleetMcp.java:330) is the record that carries them. So no new herdr call is needed. Note the existing tabLabelsOrEmpty / workspaceLabelsOrEmpty helpers (FleetMcp.java:2570): a missing label map is a normal state, not an error.

Three constraints that must hold

  1. The terminal id stays in the header, always. It is the only unforgeable identifier and the only thing a receiver can reply to. A label must never replace it.
  2. A label is display-only and is not unique. Three tabs on this host were labelled lead at once today, in three different spaces. So the header must not read as an address — a receiver that replies to a label instead of the id will reach the wrong pane, or none. If the wording can suggest an address, change the wording.
  3. Degrade cleanly when a label is unknown. The suppliers can return an empty map. The header must then fall back to the id alone, and must never render null, (space null, tab null), or empty brackets.

Known callers and tests

  • attributeIfObserver is shared with the REST entry path in FleetApp, so both surfaces attribute identically. That must stay true — do not fix one and leave the other.
  • Two tests assert the exact current string and will need updating: FleetMcpObserverSendToLeadDeliveryTest.java:143 and FleetMcpObserverSendDeliveryTest.java:122.
  • The mod needs no change: plugin/hooks/register.js:207 prepends Message from the fleet, via fleetd: to whatever the daemon produced, so fixing the daemon fixes the pasted and the collected path together.

Out of scope

Only the observer header. A lead's brief to its own member, and lead-to-lead mail, are not attributed this way today, and whether they should be is a separate question. Do not widen it here.

Requested by the operator on 2026-10-06, after a day of reading these headers by hand. ## Now `FleetMcp.attributeIfObserver` (`FleetMcp.java:994`) prefixes an observer's `SEND` with its terminal id and nothing else: ```java public static String attributeIfObserver(Principal caller, String content) { return caller != null && caller.isObserver() ? "[fleet_send from observer " + caller.terminal() + "]\n" + content : content; } ``` A receiver sees: ``` [fleet_send from observer term_65d106559ba0a2] vms channel check ``` `term_65d106559ba0a2` identifies the sender exactly and tells a reader nothing. Every message today had to be resolved against `fleet_list` by hand to learn it was the `vms` tab in the `vms` space. Three panes were involved and the ids differ only in their last few characters, which is also how a reader mixes two of them up. ## Wanted The space and tab label in the header, alongside the id: ``` [fleet_send from observer vms (space vms, tab w9:t1) term_65d106559ba0a2] ``` Exact wording is the implementer's call. The constraints below are not. ## The labels already exist on the server `identity.panes()` supplies `tabLabels` and `workspaceLabels` as lazy suppliers, already wired into the `fleet_list` path at `FleetMcp.java:617`, and `PaneSource` (`FleetMcp.java:330`) is the record that carries them. So no new herdr call is needed. Note the existing `tabLabelsOrEmpty` / `workspaceLabelsOrEmpty` helpers (`FleetMcp.java:2570`): a missing label map is a normal state, not an error. ## Three constraints that must hold 1. **The terminal id stays in the header, always.** It is the only unforgeable identifier and the only thing a receiver can reply to. A label must never replace it. 2. **A label is display-only and is not unique.** Three tabs on this host were labelled `lead` at once today, in three different spaces. So the header must not read as an address — a receiver that replies to a label instead of the id will reach the wrong pane, or none. If the wording can suggest an address, change the wording. 3. **Degrade cleanly when a label is unknown.** The suppliers can return an empty map. The header must then fall back to the id alone, and must never render `null`, `(space null, tab null)`, or empty brackets. ## Known callers and tests - `attributeIfObserver` is shared with the REST entry path in `FleetApp`, so both surfaces attribute identically. That must stay true — do not fix one and leave the other. - Two tests assert the exact current string and will need updating: `FleetMcpObserverSendToLeadDeliveryTest.java:143` and `FleetMcpObserverSendDeliveryTest.java:122`. - The mod needs no change: `plugin/hooks/register.js:207` prepends `Message from the fleet, via fleetd:` to whatever the daemon produced, so fixing the daemon fixes the pasted and the collected path together. ## Out of scope Only the observer header. A lead's brief to its own member, and lead-to-lead mail, are not attributed this way today, and whether they should be is a separate question. Do not widen it here.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
blocked
Cannot start until something else lands. The body says what.
 needs-live-proof
Merged and green, but never shown working on the running daemon. Not the same as done.
 ready-to-delegate
Scope, files and acceptance criteria are written. A worker can be briefed from the body alone.
 silent-default
A feature that compiles, passes tests, and ships turned off. Nine recurrences and counting.
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
agent kevin ltms
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: fleet/fleetd#799
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?