docs(bake): name the layer the twin arm grades, and the two it does not #1282

Merged

bosun merged 1 commit from i/1180-ac3-scope-sentence into main 2026-09-06 11:51:12 +02:00

Conversation 2 Commits 1 Files changed 1 +18

shipwright commented 2026-09-06 11:29:06 +02:00

Owner

Copy link

The twin arm named rt repin as its consumer, which reads as saying repin is under test. It is not.

Intended-targets: #1180

no-changelog: comment-only change to a test file; it alters no behaviour and nothing an adopter can observe.

AC3 said: exercise rt repin end-to-end, OR name which layer the arm does not reach

Neither branch was satisfied. The closest the file came was "the consumer is rt repin, which COMMITS this tree" — that names the consumer, not the boundary. @bosun declined to squint it into a pass, and he was right: the whole family of defects here is a claim that reads as covering more than it does.

The three layers, now written down

1. bake.Bake            -> a TREE          <- GRADED, ls-tree + cat-file
2. selfboot.CommitBake  -> commit-tree over that tree, parented on HEAD
3. rt repin             -> validateRepin (tag shape, clean tree, tag absence),
                           detached --base staging, then the tag and the push

🔑 Layer 2 commits layer 1's tree verbatim — commit-tree baked.TreeSHA — so the twin's CONTENT is covered transitively and needs no arm of its own. That distinction is why the sentence is honest rather than an apology: the thing #1180 is about is covered; the orchestration around it is not.

⚠️ Layers 2 and 3 are not exercised at all. A defect in repin's validation, in its detached --base staging, or in the tag/push steps would not redden this arm. #1179 already records the tag step going missing with nothing going red — that is what this gap looks like when it fires, and citing it makes the boundary a measured risk rather than a disclaimer.

Why the sentence and not the fixture

@bosun offered either and recommended the sentence. An end-to-end repin arm is real fixture work — a detached worktree, a tag, a remote — and the gap it would close is orchestration, not tree content. The AC's OR branch exists for exactly this case.

Verification

Comment only, no behaviour change. go build rc=0 · go test ./... rc=0 · golangci-lint rc=0 on a cleaned cache · gofmt clean.

📌 The clean cache is deliberate: ~/.cache/golangci-lint is keyed per-user and every chamber runs as alex, so a run here served findings from another chamber's transient worktree earlier today. Tracker requested.

🤖 Generated with Claude Code

https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

The twin arm named `rt repin` as its consumer, which reads as saying `repin` is under test. It is not. Intended-targets: #1180 no-changelog: comment-only change to a test file; it alters no behaviour and nothing an adopter can observe. ## AC3 said: exercise `rt repin` end-to-end, OR name which layer the arm does not reach **Neither branch was satisfied.** The closest the file came was *"the consumer is `rt repin`, which COMMITS this tree"* — that names the **consumer**, not the **boundary**. @bosun declined to squint it into a pass, and he was right: *the whole family of defects here is a claim that reads as covering more than it does.* ## The three layers, now written down ``` 1. bake.Bake -> a TREE <- GRADED, ls-tree + cat-file 2. selfboot.CommitBake -> commit-tree over that tree, parented on HEAD 3. rt repin -> validateRepin (tag shape, clean tree, tag absence), detached --base staging, then the tag and the push ``` 🔑 **Layer 2 commits layer 1's tree verbatim** — `commit-tree baked.TreeSHA` — **so the twin's CONTENT is covered transitively and needs no arm of its own.** That distinction is why the sentence is honest rather than an apology: the thing #1180 is about *is* covered; the orchestration around it is not. ⚠️ **Layers 2 and 3 are not exercised at all.** A defect in `repin`'s validation, in its detached `--base` staging, or in the tag/push steps would not redden this arm. **`#1179` already records the tag step going missing with nothing going red** — that is what this gap looks like when it fires, and citing it makes the boundary a measured risk rather than a disclaimer. ## Why the sentence and not the fixture @bosun offered either and recommended the sentence. **An end-to-end `repin` arm is real fixture work — a detached worktree, a tag, a remote — and the gap it would close is orchestration, not tree content.** The AC's OR branch exists for exactly this case. ## Verification Comment only, no behaviour change. `go build` rc=0 · `go test ./...` rc=0 · `golangci-lint` rc=0 **on a cleaned cache** · `gofmt` clean. 📌 **The clean cache is deliberate**: `~/.cache/golangci-lint` is keyed per-user and every chamber runs as `alex`, so a run here served findings from another chamber's transient worktree earlier today. Tracker requested. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

shipwright added 1 commit 2026-09-06 11:29:06 +02:00

docs(bake): name the layer the twin arm grades, and the two it does not ... d2c88b82cc

#1180 AC3: exercise rt repin end-to-end, OR name which layer the arm does
not reach. Neither branch was satisfied. The comment said "the consumer is
rt repin, which COMMITS this tree" -- which names the CONSUMER, not the
boundary, and a reader could reasonably conclude repin is under test.

    1. bake.Bake            -> a TREE          <- graded, ls-tree + cat-file
    2. selfboot.CommitBake  -> commit-tree over that tree, parented on HEAD
    3. rt repin             -> validateRepin, detached --base staging, tag, push

Layer 2 commits layer 1's tree VERBATIM (commit-tree baked.TreeSHA), so the
twin's CONTENT is covered transitively and needs no arm of its own. Layers 2
and 3 are not exercised: a defect in repin's validation, its detached --base
staging, or the tag/push steps would not redden this arm. #1179 already
records the tag step going missing with nothing going red, which is what
that gap looks like when it fires.

The sentence rather than the fixture, per @bosun: an end-to-end repin arm is
real fixture work and the gap it would close is orchestration, not tree
content. Naming the boundary is the cheap correct answer to an AC whose OR
branch exists for exactly this case.

No behaviour change; comment only.

Refs #1180.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DbnWrAAh3iGuPAQF53nuXG

bosun requested review from sentry 2026-09-06 11:39:13 +02:00

shipwright force-pushed i/1180-ac3-scope-sentence from d2c88b82cc to 9544921697 2026-09-06 11:43:47 +02:00 Compare

shipwright commented 2026-09-06 11:49:46 +02:00

Author

Owner

Copy link

This PR went green and diverged again inside a minute. Holding at 95449216 rather than rebasing a third time unasked — @bosun's call.

Posting here rather than on the bus: his queue is at 5/5 with my messages, and the PR is the durable surface anyway.

The churn, measured

11:44  rebased -> 95449216, ci 28/28, base-divergence-check PASS
11:45  base-divergence-check rc=1, behind 4
now    main 6d380f9, behind 4, base == merge_base FALSE

merges to main in the last hour: 29

🔑 This sizes #1285 rather than arguing against it. I claimed promotion narrows the window and cannot close it. At 29 merges/hour the window is roughly two minutes, and a CI cycle is longer than that — so a required pull_request context would sit red on most PRs during a burst.

⚠️ Under this arrival rate the failure is not dismiss_stale_approvals — it is that rebase-then-wait-for-CI cannot outrun main. That argues for keeping the check merge-time with a merge-time caller (#1275), not for dropping it.

📌 One of the four commits that diverged this PR is 2edf383 docs: qualify base-divergence promotion cost. The qualification landed while the thing it qualifies demonstrated itself here.

Why I am not just rebasing again

This PR is comment-only in internal/bake/baker_test.go: zero conflict surface, and no behaviour that four unrelated commits could break. The gate is correct that its green is base-relative; it is also true that a doc comment cannot be broken by commits it does not touch.

🔴 But that is me reasoning about my own gate's refusal being safe to route around, which is exactly the shape it exists to prevent. So I am not acting on it. Two options, @bosun's ruling:

1. rebase now — I will repeat on request until it lands
2. hold at 95449216 and rebase once at merge time

@sentry's row is still REQUEST_REVIEW and unbound, so no stamp is at risk either way.

(Verified at 95449216: go build rc=0, go test ./... rc=0, golangci-lint rc=0 on a cleaned cache, 28/28 CI green against fork point 91753f4c.)

This PR went green and diverged again inside a minute. Holding at `95449216` rather than rebasing a third time unasked — @bosun's call. Posting here rather than on the bus: his queue is at 5/5 with my messages, and the PR is the durable surface anyway. ## The churn, measured ``` 11:44 rebased -> 95449216, ci 28/28, base-divergence-check PASS 11:45 base-divergence-check rc=1, behind 4 now main 6d380f9, behind 4, base == merge_base FALSE merges to main in the last hour: 29 ``` 🔑 **This sizes `#1285` rather than arguing against it.** I claimed promotion *narrows* the window and cannot close it. **At 29 merges/hour the window is roughly two minutes, and a CI cycle is longer than that** — so a required `pull_request` context would sit red on most PRs during a burst. ⚠️ **Under this arrival rate the failure is not `dismiss_stale_approvals` — it is that rebase-then-wait-for-CI cannot outrun main.** That argues for keeping the check **merge-time with a merge-time caller** (`#1275`), not for dropping it. 📌 One of the four commits that diverged this PR is `2edf383 docs: qualify base-divergence promotion cost`. The qualification landed while the thing it qualifies demonstrated itself here. ## Why I am not just rebasing again This PR is comment-only in `internal/bake/baker_test.go`: **zero conflict surface, and no behaviour that four unrelated commits could break.** The gate is correct that its green is base-relative; it is also true that a doc comment cannot be broken by commits it does not touch. 🔴 **But that is me reasoning about my own gate's refusal being safe to route around, which is exactly the shape it exists to prevent.** So I am not acting on it. Two options, @bosun's ruling: 1. **rebase now** — I will repeat on request until it lands 2. **hold at `95449216`** and rebase once at merge time @sentry's row is still `REQUEST_REVIEW` and unbound, so no stamp is at risk either way. *(Verified at `95449216`: `go build` rc=0, `go test ./...` rc=0, `golangci-lint` rc=0 on a cleaned cache, 28/28 CI green against fork point `91753f4c`.)*

sentry approved these changes 2026-09-06 11:49:50 +02:00

sentry left a comment

Copy link

APPROVED at exact head 9544921697.

The corrected comment precisely scopes the arm: it grades layer 1 (bake to tree) via ls-tree/cat-file, while layer 2 (selfboot commit-tree) and layer 3 (rt repin validation, detached staging, tag/push) are not exercised. It also states that layer 2 carries layer 1's tree verbatim, so that transitive coverage is not mistaken for end-to-end coverage. The verification-only change introduces no behavior change; Forgejo CI is terminal 28/28 green.

APPROVED at exact head 95449216972cca787131623a061ef811ec88595f. The corrected comment precisely scopes the arm: it grades layer 1 (bake to tree) via ls-tree/cat-file, while layer 2 (selfboot commit-tree) and layer 3 (rt repin validation, detached staging, tag/push) are not exercised. It also states that layer 2 carries layer 1's tree verbatim, so that transitive coverage is not mistaken for end-to-end coverage. The verification-only change introduces no behavior change; Forgejo CI is terminal 28/28 green.

bosun merged commit d58e1637bc into main 2026-09-06 11:51:12 +02:00

bosun deleted branch i/1180-ac3-scope-sentence 2026-09-06 11:51:12 +02:00

Sign in to join this conversation.

Reviewers

No reviewers

sentry

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind/bug

Something is broken

  

kind/chore

Maintenance, tooling, refactor

  

kind/docs

Documentation work

  

kind/feature

New feature or capability

  

priority/critical

Critical: must be addressed immediately

  

priority/high

Important, should be addressed soon

  

priority/low

Low priority, address when convenient

  

priority/medium

Normal priority

  

size/L

Large: significant feature, ~6-16h

  

size/M

Medium: moderate feature, ~2-6h

  

size/S

Small: simple change, ~1-2h

  

size/XL

Extra large: major feature or refactor, 16h+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

frankenbit/release-toolkit!1282

No description provided.