Steps within a run are listed newest first in the delivery log #15

Queued: the loop will work on this version of the issue.

loop:queued cid=bafyreibdbpvmosl4kxj7p4x3fqacd7x4tsiig2brfp7yaq7wfhlnr77jci

Working on this, attempt 1.

loop:claim run=contribute-20261026-150237-3my32fha56n22 branch=loop/3my32fha56n22 attempt=1 issue=15

fix(logs): list the steps inside a run in execution order

The delivery log grouped a run's rows in the order they were loaded, which is newest first. A run's steps therefore read bottom to top, so Create Record showed above Bluesky Post even though Post ran first. groupLogsByRun now sorts each run's rows by ascending id, which is execution order. Runs stay newest first, and each run header is still dated by its newest row.

What changed #

• app/islands/log-run-grouping.ts: each run group's rows is sorted by ascending id. The group now has a newest field for the run header to use.
• DeliveryLog, LogsBrowser and AdminLogsBrowser take the header's time, automation name and event time from group.newest. Before, they used group.rows[0], which is now the oldest row.
• When "load more" fetches the rest of a run that the page cursor split, the older rows still join that run's group, and they now appear above the rows already shown.

Verification #

• pnpm run check passes.
• pnpm run test passes: 166 files, 2592 tests.
• New unit test: runs stay newest first, the rows inside each run come out oldest first, and newest is the run's highest id.
• Updated tests:
  • The pagination test now expects [8, 9, 10] and newest 10.
  • The DeliveryLog render test now feeds rows newest first and checks that the step that ran first is rendered first.
• I did not check this in a browser.

Acceptance criteria #

• Runs are still listed newest first.
• The steps inside a run are listed in execution order.

Decisions you can reverse #

• I took ascending delivery_logs.id as execution order, because each step's row is inserted when that step runs. A suspended step keeps its id when it resolves. A retry that writes a new row sorts by when it ran.
• Headers are dated by a new newest field on the group. The alternative was to read rows.at(-1) in each island.

Review: https://tangled.org/exosphere.site/airglow/compare/main...loop/3my32fha56n22

loop:pushed run=contribute-20261026-150237-3my32fha56n22 sha=c8e90eb499f685bc61d30355e9c124e29692f13d

Verdict: merge. The branch does what issue #15 asks. groupLogsByRun still puts runs in newest-first order (each run sits where its newest row sits), and it now sorts the rows inside each run by ascending id, which is execution order. pnpm run check and pnpm run test both pass.

What I checked:

• Execution order. The delivery_logs.id column is an identity column. Every per-step write in lib/jetstream/run-steps.ts (writeRow and the dry-run insert) inserts one row when that step runs, so ascending id is the order the steps ran. Rows with no run id (system and historical rows) are left alone and stay flat.
• Every place that uses a run group. DeliveryLog, LogsBrowser and AdminLogsBrowser all built the run header from group.rows[0]. After the sort that would be the oldest row. All three now read group.newest, which tracks the row with the highest id. Flat groups still render rows[0], and that is correct because they hold one row. groupInProgress checks every row, so the sort does not change it. No other code reads the groups.
• Pagination. When a page break splits a run, the rows that "load more" brings in still join that run's group, and the sort puts them first.
• Tests. A new unit test checks that runs come out newest first, the steps inside each run come out oldest first, and newest is right. The pagination test now expects [8, 9, 10]. The DeliveryLog render test feeds rows newest first and checks that they render in execution order.
• Results: pnpm run check is clean, and pnpm run test passes all 166 files and 2592 tests.
• Scope: the diff touches only the grouping helper, the three islands and their tests. There is no migration and no follow-up.

loop:verdict run=review-20261026-151136-3my32fha56n22 sha=c8e90eb499f685bc61d30355e9c124e29692f13d verdict=merge

Merged main into the branch: 3d5f8f1b2da37752fe0c2ae97666c1f3226ff300.

loop:carry from=c8e90eb499f685bc61d30355e9c124e29692f13d sha=3d5f8f1b2da37752fe0c2ae97666c1f3226ff300

Merged onto main as 133fdbbd4671c0c4c579b8249e7f14b8a27a894a.

loop:merged sha=133fdbbd4671c0c4c579b8249e7f14b8a27a894a head=3d5f8f1b2da37752fe0c2ae97666c1f3226ff300