coding_timeline records no per-step token, cost, files-changed or test-result summary — the ordering half of this is fixed

[proagentstore]

coding_timeline is the only MCP-side window into what a coding session is actually doing, and it shows one half of the conversation.

Observed on session csess_42bdfe20-ca10-4172-90af-14114b70b28c (issue #672 implementation run). Every event returned was type command or brain — the instructions going into the coding engine. Sample:

• seq 9077, type brain — "AI run started — objective: ..."
• seq 9078, type command — "Let's start by exploring the repository structure..."
• seq 9084, type command — "Let's proceed with implementing the solution... First, let me see the existing /v1/auth/me route..."
• seq 9086, type command — "Yes, create a new branch off main, commit all the changes, push the branch, open a PR..."

What is never present:

• the engine's replies
• the shell commands it actually ran, and their output
• file diffs, or even a list of files touched
• test and typecheck results
• token or cost accounting per step

Impact: a user watching a run can see what the agent was asked at each step but cannot verify what it did. When a run reports success, the only evidence is its own closing summary. When a run stalls, there is no way to see where. Reviewing the resulting PR after the fact is the only real audit path, which defeats the purpose of a live timeline.

Note this is also a correctness-review gap. In the run above, the plan visible at seq 9084 included using github_login as the email field on the assumption that Google users have their email stored there. That assumption was visible only because it happened to appear in an inbound prompt. Had the engine reasoned its way there in a reply, nothing would have surfaced it.

Requested change:

1. Emit engine replies as timeline events, with a distinct type so clients can filter.
2. Emit tool and shell invocations with their commands and captured output, truncated with a length marker rather than dropped.
3. Emit a per-step summary of files changed and test results.
4. Keep the existing seq cursor and byte-budget paging semantics so clients can tail without change.

Reported by the account owner while watching a run in progress over the MCP connector.

[serge-ivo]

Confirmed, and it is the same defect as #653 — oldest-first ordering, not missing data

Reproduced 2026-08-16 on bd43f4de-ef35-4051-bdec-43f8571414a1:

coding_timeline(instance_id, limit: 3)
  → brain, brain, command          hasMore: true      ← no engine output
coding_timeline(instance_id, limit: 4)
  → brain, brain, command, terminal(toolCalls[…])     ← output appears

The output is not missing — it is behind paging, because events are returned oldest→newest. Every prompt in a run precedes every piece of output, so a caller reading the first page sees only what was sent to the engine and reasonably concludes the engine's own output is absent. At limit: 3 that is exactly what this issue reports.

The consequence scales the wrong way: the more work a run did, the further its latest output sits from page 1. For debugging — the tool's stated purpose, and why the server's own instructions say to reach for it — the newest events are the ones wanted first and the ones hardest to reach.

Same shape as #653

#653 — "A ticket thread is read oldest-200-first, so past 200 events the thread stops updating" — is this defect in another surface. Both take an oldest-first window over an append-only log and hand the caller the wrong end of it. Worth fixing with one decision rather than two, because the answer ("which end does a reader want, and what does the cursor mean") is the same in both.

Note the cursor convention this repo settled on differs by direction and that is deliberate: instance_messages pages newest-first with before (#566), while coding_timeline pages oldest-first with since_seq (#581) because it was designed for polling a live run — where oldest-first is correct, since you want what happened since you last asked. The defect is that the same tool is also the audit surface for a finished run, where the requirement inverts. #527 was closed by giving both jobs to this one tool.

What a fix has to decide

1. Whether a finished session should default to newest-first while a live poll stays oldest-first, or whether both directions should be available explicitly (a before-style cursor alongside since_seq).
2. Whether the default limit should guarantee at least one terminal row — a cheap mitigation, but it treats the symptom.
3. Whether A ticket thread is read oldest-200-first, so past 200 events the thread stops updating and every /ask is answered from a frozen window #653 is fixed with the same mechanism.

Verified vs inferred

• Verified: both calls above and their exact event types; hasMore: true on the 3-event page; that terminal rows carry toolCalls with inputs and outputs once reached; A ticket thread is read oldest-200-first, so past 200 events the thread stops updating and every /ask is answered from a frozen window #653's title and mechanism.
• Inferred: that a caller hitting this concluded the output was absent rather than paged. That is this issue's own report and it is consistent with the reproduction, but the reporter's exact call was not observed.

[serge-ivo]

Fixed in 81163c96, deployed (CI + API/MCP/Host workers all green).

The decision, and why it is not a new one

The default page is now the NEWEST one, before walks back, and since_seq polls forward exactly as before.

This turned out to be the convention the repo had already settled — loadTerminalSnapshots, in the same file over the same table, already carries both arms (after ascending for the live tail, before descending for scrollback) and its docstring says why: "deliberately the same before/limit/hasMore shape the chat thread needs (#428), so one convention covers both". loadRepoTimeline records the same reasoning for the default: "the cap has to keep the LATEST rows, and ORDER BY seq ASC LIMIT n would keep the oldest". loadTimelineFeed was the one reader in the file contradicting both.

So this applies the existing decision rather than making a new one — which also resolves the "two deliberate conventions" tension in the issue: the position is both directions on one reader, selected by the cursor, not one direction per tool.

Both alternatives in "What a fix has to decide", rejected

1. Default by session state (finished ⇒ newest, live ⇒ oldest) — rejected, and it has a race. The Pilot ends a session on every finished run (coding-feed.ts:24-27), so a live poller walking forward would be re-pointed at the newest page mid-poll, silently re-delivering or skipping. That is the exact no-overlap-no-skip guarantee the cursor exists to provide. It is also unobservable: the caller can neither request a direction nor tell from the reply which rule applied.

2. Guarantee a terminal row in the default page — rejected. It leaves the scaling problem standing, and it cannot be honoured under FEED_BYTE_BUDGET without either breaking the budget or dropping the narrative rows that explain why the terminal looks like that.

3. Is #653 fixed by the same mechanism? Yes — same decision, other surface, committed separately as 39b59535.

Red first

The test asserted page 1 on your reproduction's shape and failed on the reported symptom before any fix:

expected [ 'brain', 'brain', 'command' ] to include 'terminal'

New file workers/api/src/lib/coding-timeline-feed-order.test.ts (11 tests): page-1 content, newest-event reachability, render order preserved, hasMore/oldestSeq describing the OLD end, the backward walk being disjoint and complete, and — the compatibility arm — sinceSeq still walking forward byte for byte. since + before together is refused rather than resolved by precedence.

One implementation detail worth recording: the byte budget is now applied from the end the page travels away from. A forward page drops its newest rows, a backward page drops its oldest. Trimming the wrong end would have handed a caller asking for the newest page a budget-shaped slice of the middle.

Not delivered from this issue, deliberately

Items 1-3 of "Requested change" asked for new emissions — engine replies, shell invocations with captured output, per-step file/test summaries. Those are not done here and I did not silently narrow the scope: the reproduction in your comment established that the engine's output is already recorded (terminal rows with toolCalls carrying inputs, outputs and ok), and was simply unreachable from page 1. Item 4 (keep the seq cursor and byte-budget paging) is preserved.

If a genuine emission gap remains after this — token/cost accounting per step is the clearest candidate, since that really is absent from this record — it is worth its own issue with the missing field named, rather than being carried by a ticket whose premise the reproduction changed.

Verified vs not

• Verified: the failing-then-passing page-1 assertion; full suite 9529 passed / 548 files; e2e 413 passed (chromium + webkit); all 9 script gates; 0.1.8 live in the public MCP registry as isLatest, and served by proagentstore.online/.well-known/mcp-server.json; the API route deployed and answering.
• Not verified live: the tool's actual output through an authenticated MCP session — mcp.proagentstore.online/mcp requires OAuth and coding_timeline is outside the tool allowlist available to me. Worth one call against a real session to confirm page 1 now leads with terminal rows.

[serge-ivo]

Leaving this open rather than closing it. The ordering defect your comment identified is fixed and deployed; what is not delivered is the original body's request for new emissions, and one part of that is a real gap rather than a premise the reproduction overturned: per-step token and cost accounting genuinely is absent from coding_timeline, whereas engine output, tool calls and their results turned out to be present and merely unreachable from page 1.

Your call on whether that becomes its own issue (I would file it as "coding_timeline records no per-step token or cost", scoped to the write side) or whether this one carries it. Happy to do either — I did not want to close a ticket over a sub-item I had knowingly not built.

[serge-ivo]

Behavioural check made — page 1 now leads with engine output

81163c96's author could not run this (the affected tools are outside that agent's allowlist) and correctly did not claim it. Run now against bd43f4de-ef35-4051-bdec-43f8571414a1, the same instance and the same call as the original reproduction:

coding_timeline(instance_id, limit: 3)

before	after
brain, brain, command	command, terminal, outcome
no engine output on page 1	the engine's own output, including its error, plus the run's outcome
—	oldestSeq: 8968 returned for paging backwards

The terminal row carries the real pane content (You've hit your weekly limit…) and the outcome row the run's verdict — the two things a caller asking "what did this run do" actually wants, now on the first page with no cursor.

Verified on the deployed tool, not on a fixture.

Why this issue stays open

Engine output and per-tool-call detail were never missing — they were unreachable behind oldest-first paging, and that is fixed. But this issue's original body also asked for new emissions, and one is a genuine gap the reproduction did not overturn: per-step token and cost accounting is absent from coding_timeline.

That is a real ask and it was knowingly not built. It should either be tracked here or split into its own issue — but it should not be closed on the strength of the ordering fix, which is a different thing.

Verified vs inferred

• Verified: both call results above, on the deployed tool; the oldestSeq cursor; that the terminal row carries real pane content.
• Inferred: nothing. The token/cost gap is stated by the implementing agent as knowingly unbuilt, not deduced.

[serge-ivo]

Audit verdict: delivered by 81163c96 (2026-08-16) — recommend closing.

Read against main and re-measured live today.

• loadTimelineFeed (workers/api/src/lib/coding-timeline.ts:306) now selects ORDER BY seq DESC
  and reverses when the caller names no cursor, so an absent cursor answers with the newest
  page. :335 is the branch; :329-333 is the forward arm, untouched.
• undefined and 0 are kept distinct at :326-328 — since=0 stays an explicit
  "poll me from the beginning" on the forward arm — so a poller is byte-identical.
• Tests: lib/coding-timeline-feed-order.test.ts:64 "page 1 contains the engine's OUTPUT, not only
  what was sent to it", :71 "the newest event in the session is on page 1", :78 rows still
  oldest→newest within a page, :155 before walks back without overlap or gap, :176 both
  cursors together is refused rather than silently resolved.
• Measured live on bd43f4de-ef35-4051-bdec-43f8571414a1, csess_613d1455…, no cursor: the page
  carries terminal × 8, command × 17, brain × 6, outcome × 3 — the engine's output is on
  page 1, and each terminal event carries toolCalls.

Caveat worth carrying forward, and it is the reason this ticket's title still describes something
real. The engine's output is now on page 1, but only 5% of its text is. Each terminal event is
a 400-character tail of an 8,000-character snapshot (FEED_TERMINAL_CHARS,
coding-timeline.ts:186); the full 64,000 characters this session stored are served by
GET …/timeline?terminal=1 and read by no MCP tool. That is #699, filed today — a size bound, not
the paging bug this issue found and fixed.

[serge-ivo]

Audit verdict: partially delivered. Leaving open, and retitling — the title now overstates what is wrong.

What is delivered, verified on main

81163c96 fixed the paging defect, and I re-measured it live today.

• lib/coding-timeline.ts:306 — loadTimelineFeed selects ORDER BY seq DESC and reverses when the caller names no cursor, so an absent cursor answers with the newest page (:335). The forward arm (:329-333) is untouched, and undefined vs 0 stay distinct (:326-328) so since=0 is still an explicit "poll me from the beginning".
• Tests: lib/coding-timeline-feed-order.test.ts:64 "page 1 contains the engine's OUTPUT, not only what was sent to it", :71 newest event on page 1, :78 rows still oldest→newest within a page, :155 before walks back without overlap or gap, :176 both cursors together refused rather than silently resolved.
• Measured live on bd43f4de…, session csess_613d1455…, no cursor: terminal ×8, command ×17, brain ×6, outcome ×3, and each terminal event carries toolCalls.

So items 1, 2 and 4 of "Requested change" are met, and by a route the original report did not anticipate: the engine's replies, its shell invocations and their captured output were never missing — they were unreachable behind oldest-first paging. lib/engine-tool-calls.ts derives the per-call arguments and results from the ⚙/↳ framing the pane already carried (883 of 914 production terminal rows, mean 12.05 calls per row), with inputCut/outputCut reporting the runner's own display caps rather than hiding them.

The 400-character-tail caveat carried on the last audit comment is also gone: #699 (441e1374) registered coding_terminal, which serves a finished run's stored pane text in full.

What is NOT delivered

Item 3 — "a per-step summary of files changed and test results" — and per-step token/cost accounting.

grep -n "tokens\|cost" workers/api/src/lib/coding-timeline.ts finds only the byte budget (:378-383) and the DELETE batch size (:574). There is no per-step token count, no per-step cost, and no per-step file/test summary anywhere in this record. 81163c96's author said so explicitly at the time ("knowingly not built") and that is still true.

Retitle

Old: "coding_timeline returns only the prompts sent to the engine, never the engine's output" — false since 81163c96, and a live reader would now be misled by it. Changed to name what actually remains.

Recommendation, yours to take

Either keep this ticket for item 3, or split it — I would split, because "files changed + test results per step" and "tokens + cost per step" are different write-side sources (the engine's own report vs the ai_usage ledger) and only the second has an existing store to read from. If you split, this one closes.