Skip to content

v2 self host frontier - #11928

Closed
briansrls wants to merge 12 commits into
mainfrom
roadmap-wind-down-items
Closed

briansrls wants to merge 12 commits into
mainfrom
roadmap-wind-down-items

Conversation

@briansrls

Copy link
Copy Markdown
Contributor

Auto-opened by session-dashboard for session proud-bat-569.
Pushing to roadmap-wind-down-items advances this PR.

Worker attestation

Before flipping this PR to ready for review, confirm each item:

  • Title describes the change (not the session id or branch).
  • PR body summarises what and why (replace the TODO below).
  • Tests run: name the command (e.g. npm test, cargo test) and the result.
  • If this closes a work item, the body contains a Closes #N directive.
  • No commits on this branch are surprises (no fork/cherry-pick I did not make).
  • No secrets / credentials / large binaries staged.

Summary

TODO: replace this paragraph with one or two sentences naming the change and its motivation. Reviewers read this first.

Test plan

  • TODO: list the commands that ran (or "no tests changed; relied on CI") and the outcome.

Brian Searls and others added 12 commits September 20, 2026 15:13
Wind-down of the self-host frontier lane. Four deliverables that were live
in pull requests, prepared locally, or found as defects are recorded as
roadmap nodes so none of the state survives only in PR bodies and session
messages.

- self-host-service-family-on-literal-terminal
- whole-service-witness-costs-more-than-its-budget
- required-floor-passes-with-a-failed-phase
- runner-throughput-witness-imports-absent-members

ROADMAP.md is a projection of this authority and is not regenerated here:
no compiler binary is built in this worktree and building one under the
current load is the wrong trade. The generated-artifact heal step is the
intended actuator for the projection.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review 69209: two displaced_cost fields carried measurements with no named
producer. DESIGN section 6 requires a measurement to be cited by naming the
producer that re-derives it, never by copying numbers into prose, because a
transcribed number is unreachable from the thing that owns it.

Both now name the required floor's per-claim cost receipt — the
required-floor-claim-cost artifact, which carries eval_steps per witness
identity — as the producer, and date the reading. The compliant form already
in this file (roadmap_authority.dag:1303, "from the run named in DESIGN.md
Building & checks") is the pattern followed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ledger-Repair-Judged: docs/design-rung-drops.md
Heal-Candidate-Run: 35520547733
The remaining work for the service family is prepared but unlanded. Name the
branch and exact tip in the row's first_slice so whoever resumes finds the
work rather than rebuilding it, and say plainly that it predates the
2026-09-20 merges and needs rebasing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
…into roadmap-wind-down-items

# Conflicts:
#	ROADMAP.md
Review 69295. Two displaced_cost fields still carried exact measurements
alongside the producer. DESIGN section 6 says a measurement is cited by
naming the producer that re-derives it, never by copying its numbers into
prose, because a transcribed number is unreachable from the thing that owns
it and rots without anyone touching either end.

An earlier review read naming-beside-the-number as sufficient; this one reads
the rule strictly. The strict reading is the safer one and costs little, so
the exact figures are gone. What remains is the qualitative shape that makes
each item legible - a unidirectional shift across a large minority of the
population, and a witness several times over its budget - plus the
required-floor-claim-cost receipt as the producer that re-derives both.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review 69315, advisory finding. The row said the prepared service-family
slice "needs rebasing before it is pushed", which was true when written and
false by the time it landed in the diff: the branch was pushed to origin at
80a560d before its lane closed, precisely so
the work would survive the lane.

Say what is true now: the branch is on the shared remote so the citation
resolves for anyone with the repository, and what it needs is rebasing onto
current main before it can be proposed for landing.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Review 69328. The service-family row carried a dated staleness note in
first_slice, which this module's own annotation above fn updated forbids in
terms: the slice is consumed as "next executable slice" by current_state and
the dispatch brief, so a position written there forks its meaning and rots
with no time axis to say so. fn fields concatenates first_slice verbatim, so
a worker would have been handed "rebase a 2026-09-20-stale branch" as the
slice itself.

first_slice is now the executable slice only, keeping the branch and tip
citation. The staleness and the rebase requirement move to an updated(on:,
note:) entry where a dated position belongs and where the page renders it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Reviews 69295, 69315, 69328 and 69339 all found the same blocker: ROADMAP.md
is a committed projection of roadmap_authority.dag and diverged from it once
four rows were added. A committed projection diverging from its authority
stops the line, and it did.

I had reported this as unfixable here, on the grounds that regeneration needs
a gunbc binary: a local release build is the host churn the wind-down forbids,
and a remote build is linux/amd64 on an arm64 container whose runners refuse
`gunbc run` with HostBudgetUnreadable anyway. That was wrong about the
available instruments. The required floor ALREADY performs the regeneration
and uploads it: its log records `[file] write ROADMAP.md (68580 bytes)` and
run 35529884525 carries a heal-repair-candidate artifact.

This commit applies that artifact rather than hand-editing the projection.
Verified by content hash at all three points the manifest pins:

  expected_head_sha  5cbc649  = HEAD
  base_blob          e4d64cd  = committed file
  proposed_blob      e95d1c3  = applied file

The derived focus count moves 132 -> 138 and the ci-control row
required-floor-passes-with-a-failed-phase now renders as a bullet, which is
what the reviews said must happen.

Ledger-Repair-Judged: docs/design-rung-drops.md

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merging main moved roadmap_authority.dag, so the projection committed in the
previous merge (taken from main's side to resolve a generated-file conflict)
no longer matched the merged authority. The required floor regenerated it
again; this applies that artifact rather than hand-editing.

Verified by content hash at all three points run 35533100665's manifest pins:

  expected_head_sha  c68eede  = HEAD
  base_blob          395c145  = committed file
  proposed_blob      3b1048f  = applied file

Derived focus count is now 145; the ci-control row renders as a bullet.

Ledger-Repair-Judged: docs/design-rung-drops.md

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
# Conflicts:
#	ROADMAP.md
#	dag/gunbc/roadmap/roadmap_authority.dag
@gunbai-bot

gunbai-bot Bot commented Sep 21, 2026

Copy link
Copy Markdown
Contributor

Closing: this PR is empty, and the conflict is a squash-merge artifact rather than unlanded work.

#11853 squash-merged this branch's content into main at 02:43. Squash keeps the content and drops the history, so GitHub still diffs against the old merge-base and reports rows that are already on main as additions.

Verified against current main (a6f10a8f5d) — each of the four roadmap identities is present exactly once on both sides:

rn_6ZFZPYVBX39088FFTWTNF3SCXJ  main=1  branch=1
rn_4YXQ47680VA8B4GNGGVPV2DQZ8  main=1  branch=1
rn_ARHDM19A4Y5Z6EVGYFAWCJ434C  main=1  branch=1
rn_02PRZ2Q7Q5Q8TJRANYM293HKJD  main=1  branch=1

and git diff main..branch -- dag/gunbc/roadmap/roadmap_authority.dag adds 0 lines. Rebasing and resolving would re-apply rows that already exist, so the requested repair is the wrong operation here.

This also does not block other work: the follow-up #11933 is on its own branch off main and is CLEAN.

— sent from proud-bat-569

@gunbai-bot gunbai-bot Bot closed this Sep 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant