A board card's detail is cut at exactly 300 chars mid-word with no ellipsis — 13 of 15 irreversible acts vanish, and the full text is already on the same card

[serge-ivo]

A board card's detail is cut at exactly 300 chars mid-word with no ellipsis — 13 of 15 irreversible acts vanish, and the full text is already on the same card

What the owner sees

instance_board for instance bd43f4de-ef35-4051-bdec-43f8571414a1, card deleg-ae7fa3f2-53a1-43ba-b3ad-921dd8dba7b1, Failed column:

outcome: failed — run error: Too many API requests by single Worker invocation. To configure this limit, refer to https://developers.cloudflare.com/workers/wrangler/configuration/#limits | Acts: pushed directly to the trunk origin main; pushed directly to the trunk origin main; pushed directly to th

Measured: exactly 300 characters, ending …pushed directly to th. No ellipsis, no marker. It reads as a finished sentence that names two pushes.

The same card, in instance_task_events, carries the full text under a different key:

reasoning (691 chars): Overseer delegated on your behalf → apps/chess-academy: … — outcome: failed — run error: … | Acts: pushed directly to the trunk origin main; ×4; **and 11 more.**

4 named + 11 more = 15 acts. Corroborated independently by agent_trace(level:"warn"), which has 15 act.consequential events on that run's session, all irreversible: true — 14 push.trunk to origin main and one recursive file.delete.

The board shows 2 of 15 irreversible acts, and gives the reader no reason to think anything is missing. The delegated objective was "commit directly to main, push. Do NOT create feature branches."

Mechanism — the cut and the marker are in two different functions

Verified. workers/api/src/lib/delegation.ts:41:

...(opts.note ? { description: opts.note.slice(0, 300) } : {}),

against reasoning two lines up (:30), capped at 8000. The comment at :36-41 explains why both exist:

ALSO as description, because that is the field every generic reader takes a card's one-line detail from (board.ts, and instance-work.ts for a supervisor) — reasoning is in neither chain, so the outcome text reached the console and nothing else.

So description is the field every generic reader (the console board, MCP instance_board, a supervising agent) uses, and it is the one carrying the 300-char cut. reasoning — complete, with its honest and 11 more. — is on the same row and is read by nothing on that chain.

lib/coding-board.ts:65 has the identical slice(0, 300), and lib/repo-policies.ts:257 (MAX_DESCRIPTION = 300) is the third — but repo-policies.ts:367 is the one that gets it right:

const sentence = parts.sentence.slice(0, Math.max(0, MAX_DESCRIPTION - attribution.length));

it budgets for the attribution it must keep. Nothing does the equivalent for the acts list.

Verified precedent for the marker. lib/tool-result-cap.ts:95-99 already made exactly this decision for the tool log, and states the principle:

A success is cut EXACTLY as before, with no ellipsis … A failure marks its cut, because the sentence it is cutting is an instruction and a silently truncated instruction is how this started.

A truncated list of irreversible pushes is the same class of sentence and gets no marker.

Why the ordering of the text makes it worse

The 300 chars are spent, in order, on: the outcome, a raw Cloudflare error, a Wrangler docs URL (81 chars of it), and then the acts. So the least useful content — a link to a configuration page for a Worker the owner does not own (#523) — displaces the record of 13 pushes to main. The acts are the part a human reads a Failed card for.

What to do — cheapest first

1. Add the ellipsis. One character, and it converts a false complete sentence into a visibly-cut one. The lowest-value fix, and worth shipping alone if nothing else is.

2. Build description as a budgeted summary rather than a prefix of reasoning. The count is already known at the call site — and 11 more. is computed there. Put the count FIRST: outcome: failed — 15 irreversible acts (14 pushes to origin main, 1 recursive delete) — run error: …. 300 chars is plenty for the facts; it is not plenty for a prefix of a 691-char sentence.

3. Let the generic readers reach the full text. instance_board returns a truncated detail and no field saying more exists. Either return reasoning alongside, or return detailTruncated: true — a reader that cannot tell it was cut cannot go and look.

Alternatives considered and rejected

• Raise the cap to 8000 and drop description. description exists because the generic chain reads it; widening it pushes 691-char blobs into every board card and every supervisor payload. [bug] The Coder Lead can only ever see 3 of 6 agents — subordinate_status returns 60,239 chars into a 24,000 cap, so half the roster is silently dropped #503 is the same repo's counter-example — 60,239 chars into a 24,000 cap silently dropped half a roster. The cap is right; the selection is wrong.
• Show only the acts, drop the error. The error is why the card is in Failed. Both belong; the ordering and the budget are the fix.
• Fix it in instance_board's renderer. The truncation happens at write time (delegation.ts:41), so the full text never reaches the reader — nothing downstream can restore it.

Acceptance criteria

• A delegation card whose run performed N acts states N; a reader can tell 15 from 2.
• Any truncated description is visibly marked as truncated.
• The full text remains reachable from the board response (reasoning or an explicit flag).
• Test: build a card from a run with 15 acts and a 200-char error; assert the rendered detail names 15 and is ≤ the cap.

Regression risk

description is read by board.ts and instance-work.ts (per the comment at delegation.ts:36), and a supervising agent parses it. Changing the shape from "prefix of reasoning" to "budgeted summary" changes what a Lead reads back from a subordinate — check subordinate-payload.ts, which already trims this text a second time (:111) and could double-trim a newly-front-loaded count. Assert the count survives both passes.

Related: #523 (same run and same card — that issue is about classifying the failure, this one is about the acts being invisible), #503 (a payload silently dropping half its content), #517 (tool-result-cap's marked-cut precedent).

[serge-ivo]

Landed in 0172534 (CI green, API Worker deployed).

What shipped

lib/card-detail.ts (pure) now owns how a card's one-line detail is composed:

• actHeadline states the count and the irreversible count before anything competes for the space, collapsing identical summaries with a multiplier. The reported run renders as 15 acts, all irreversible: 14× pushed directly to the trunk origin main; deleted files recursively — 97 chars for what the old prefix spent 120 chars saying about three of them.
• cardDetail budgets: the headline is bounded so the note keeps a 120-char floor, and anything cut carries … inside the budget (tool-result-cap.ts appends outside its budget, which would overrun here because several cuts compose into one field). Same reserve-for-what-you-keep pattern as repo-policies.ts:367.

delegation.ts takes the acts as data; workflows/coding-session.ts:248 passes the array it already had in scope. coding-board.ts:67 carried the identical slice(0, 300) and gets the marker too — no reader can tell which writer produced the card it is holding, so a mid-word ending has to mean the same thing on both.

What the guards measure

delegation.test.ts builds the fixture through the real chain (summarizeActs → runOutcomeNote → delegationTaskRecord) from the 15 acts in the trace, and asserts the denominators: the note is 375 chars against a 300-char field, Acts: starts at 182, and ; and 11 more. begins past 300.

Reverted to note.slice(0, 300) in place: 4 of 9 failed, and the string the old code produced was character-for-character the one this issue measured on the live card, ending pushed directly to th. That corroborates the fixture independently of the issue text.

Front-loading the count is what makes it survive the second trim: fitStatusPayload is driven end-to-end at the asserted terse rung with the old string and the new one at the same budget — the old one names no acts at 240/140/90/80, the new one still says 15.

Two corrections to the issue

1. 691 is the length of reasoning, not of the note. reasoning prefixes the note with Overseer delegated on your behalf → …. The note itself is 375 chars. Identical defect, misattributed number.
2. Acceptance criterion 3 was already met at the API level — buildInstanceBoard populates BoardItemView.reasoning alongside the capped description, confirmed live on this instance just now (description 300 chars, reasoning 691). A guard now pins that rather than trusting the comment claiming it.

The gap this leaves — worth its own issue

MCP's groupBoard (workers/mcp/src/instance-tools/shared.ts:130) maps detail: it.description and drops reasoning. Verified in the source. So a model reading instance_board still cannot reach the full text — it can now at least tell it was cut, from the …. Carrying an 8,000-char reasoning onto every MCP card is a payload decision (cf. #503), not a one-liner, so it was deliberately left out of scope.

Cards written before this deploy keep their stored text — the truncation happened at write time, so nothing downstream can restore it. The reported card still reads as it did.