#39's body listed resume and next up together as the first screen a television
shows. Next up was taken out of that issue's scope on 2026-08-30, on the ground
that the surface record decides which paths the core may reach and the feature
issue builds to it, rather than a feature issue adding a path on its way past.
This is the route argued on its own merits.
The evidence
0010's table is what the core may reach, and it has a row for resume and none for
next up:
git rev-parse origin/main
2ba16aead4f46ce9e50a0e4e3735160212de1a0a
git show origin/main:docs/decisions/0010-the-server-surface-and-what-an-absence-does.md | grep -n 'UserItems/Resume\|Shows/NextUp'
101:| `resume-list` | `GET /UserItems/Resume` | What 0058 resumes into. | assertion |
The second name returns nothing, which is the whole of why this issue exists
rather than a line in #39's diff.
0039 already fixes what next up is not, so the shape of the answer is decided and
only the route is open:
git show origin/main:docs/decisions/0039-the-page-the-item-and-what-next-up-is-not.md | grep -n 'next up' | head -5
What this produces
A record superseding 0010 that adds the route next up is read from, with the row
carrying the same four columns as every other: the capability it belongs to, the
path, what it is for, and whether an absence is an assertion or a question.
The argument for the row, which is what a superseding record is for and what an
edit to the table would not carry: what a first screen loses without it, what the
route costs against both supported lines, and what an absence of that route on a
line means for a client that has already drawn a shelf for it.
Whether the answer is the item type 0039 fixes, or a different one, and if
different, why the core's promise that a client written against one read can
display the result of another survives it.
What this deliberately leaves out
The implementation. #39 delivers resume against the row 0010 already carries, and
this issue is a record rather than a call.
Whether next up belongs on a first screen at all, which is a product question the
kickoff already answered by naming it. What is open here is the route and its
cost, not the feature.
Done when
The record is in docs/decisions/, it supersedes 0010 rather than editing it,
and the row it adds carries the same columns and the same absence semantics as
the rest of that table.
#39's body listed resume and next up together as the first screen a television
shows. Next up was taken out of that issue's scope on 2026-08-30, on the ground
that the surface record decides which paths the core may reach and the feature
issue builds to it, rather than a feature issue adding a path on its way past.
This is the route argued on its own merits.
The evidence
0010's table is what the core may reach, and it has a row for resume and none for
next up:
The second name returns nothing, which is the whole of why this issue exists
rather than a line in #39's diff.
0039 already fixes what next up is not, so the shape of the answer is decided and
only the route is open:
What this produces
A record superseding 0010 that adds the route next up is read from, with the row
carrying the same four columns as every other: the capability it belongs to, the
path, what it is for, and whether an absence is an assertion or a question.
The argument for the row, which is what a superseding record is for and what an
edit to the table would not carry: what a first screen loses without it, what the
route costs against both supported lines, and what an absence of that route on a
line means for a client that has already drawn a shelf for it.
Whether the answer is the item type 0039 fixes, or a different one, and if
different, why the core's promise that a client written against one read can
display the result of another survives it.
What this deliberately leaves out
The implementation. #39 delivers resume against the row 0010 already carries, and
this issue is a record rather than a call.
Whether next up belongs on a first screen at all, which is a product question the
kickoff already answered by naming it. What is open here is the route and its
cost, not the feature.
Done when
The record is in
docs/decisions/, it supersedes 0010 rather than editing it,and the row it adds carries the same columns and the same absence semantics as
the rest of that table.