docs(adr): ADR-0005 wheel-reinvention check — why release-toolkit (refs #52) #59

Merged
alex merged 2 commits from i/52-adr-0005 into main 2026-06-25 15:11:45 +02:00

Wheel-reinvention check for the v0.4.0 design-arc

Operator surfaced the question at the design-arc that should have been asked at the project's inception: "would it be possible to just use release-please in Forgejo? And if not — are there equivalent projects? Just want to ensure that we're not reinventing the wheel."

Researched 2026-06-25 against current state of the relevant tools. Verdict captured as ADR-0005 with concrete citations for durable provenance.

Verdict: NOT reinventing the wheel (Option C — the wheel doesn't exist for this substrate)

The intersection of THREE constraints forces a build:

  1. Forgejo-native → rules out release-please (GitHub-API-locked; #1021 "Add the ability to change git provider" open since Aug 2021, labeled needs design, 4+ years no movement)
  2. Conventional-commits + changelog.d/ fragments + prep-PR flow → rules out git-cliff (changelog only), actions/forgejo-release (asset upload only)
  3. ADR-0003's four-gate operator-review ceremony → rules out semantic-release (auto-publishes on every CI run; no prep PR, no draft state, no operator-review gate). Adopting semantic-release = retiring ADR-0003.

Drop any one constraint and a tool fits. Keep all three (the chamber-substrate's actual requirement) and you have to build.

Load-bearing external validation

The decisive third-party signal: the Forgejo project itself evaluated git-cliff + conventional-commits for their own release notes and rejected them.

Codeberg discussion #155 — Forgejo maintainer Gergely Nagy: "release notes are not changelogs". Team built their own internal doc/next/<PR>.md system instead.

The largest Forgejo deployment hit the same substrate gap and concluded the off-the-shelf tools don't fit. Their solution is structurally similar to release-toolkit's changelog.d/<id>.<kind>.md fragments — independent convergence on the same shape under the same constraints.

What the ADR captures

  • Tool-by-tool evaluation with URLs / issue numbers / archive dates for: release-please, git-cliff, actions/forgejo-release, saitho/semantic-release-gitea (archived 2026-05-28), benjaminschmidt/simple-semantic-release, go-semantic-release/provider-gitea, Forgejo's own substrate
  • Three substrate constraints named explicitly + why dropping any one opens the door
  • Trade-offs accepted: maintenance cost, no upstream community, substrate-gap-closing risk
  • Substrate-honesty self-check (§at the end): confirmation bias acknowledged; hypothetical falsifiers specified — which would have flipped the verdict to (A) or (B). None were met.
  • Implicit expiration: re-evaluate at the next major version (v0.5.0 or v1.0.0)

ADR relationship

  • Does NOT supersede or narrow any prior ADR.
  • Complements ADR-0003 (provides upstream-existential justification for why a custom four-gate flow exists at all — semantic-release would forfeit ADR-0003's gates).
  • Complements ADR-0004 (the v0.4.0 architectural redesign whose evaluation prompted this check).

Late-filing acknowledged in §Context. The verdict survives the late filing — substrate hasn't shifted in the interim.

Cadence next

After this merges: mini-design-note PR for slice 1b (stable-branch rolling-PR identity per Surveyor's lean + release-prep.sh --rolling-mode flag shape + cut-safeguard composition). Then slice 1b implementation.

Refs

  • Tracking arc: #52
  • Predecessor ADRs: ADR-0003, ADR-0004
  • External citations (all in the ADR's §Supersedes / related): release-please #1021, Codeberg/forgejo discussion #155, go-semantic-release/provider-gitea, git-cliff Gitea integration, actions/forgejo-release, saitho/semantic-release-gitea (archived)
## Wheel-reinvention check for the v0.4.0 design-arc Operator surfaced the question at the design-arc that should have been asked at the project's inception: **"would it be possible to just use release-please in Forgejo? And if not — are there equivalent projects? Just want to ensure that we're not reinventing the wheel."** Researched 2026-06-25 against current state of the relevant tools. Verdict captured as ADR-0005 with concrete citations for durable provenance. ## Verdict: NOT reinventing the wheel (Option C — the wheel doesn't exist for this substrate) The intersection of THREE constraints forces a build: 1. **Forgejo-native** → rules out release-please (GitHub-API-locked; [#1021](https://github.com/googleapis/release-please/issues/1021) "Add the ability to change git provider" open since Aug 2021, labeled `needs design`, **4+ years no movement**) 2. **Conventional-commits + `changelog.d/` fragments + prep-PR flow** → rules out git-cliff (changelog only), actions/forgejo-release (asset upload only) 3. **ADR-0003's four-gate operator-review ceremony** → rules out semantic-release (auto-publishes on every CI run; no prep PR, no draft state, no operator-review gate). **Adopting semantic-release = retiring ADR-0003.** Drop any one constraint and a tool fits. Keep all three (the chamber-substrate's actual requirement) and you have to build. ## Load-bearing external validation The decisive third-party signal: **the Forgejo project itself evaluated git-cliff + conventional-commits for their own release notes** and rejected them. [Codeberg discussion #155](https://codeberg.org/forgejo/discussions/issues/155) — Forgejo maintainer Gergely Nagy: *"release notes are not changelogs"*. Team built their own internal `doc/next/<PR>.md` system instead. The largest Forgejo deployment hit the same substrate gap and concluded the off-the-shelf tools don't fit. Their solution is structurally similar to release-toolkit's `changelog.d/<id>.<kind>.md` fragments — independent convergence on the same shape under the same constraints. ## What the ADR captures - **Tool-by-tool evaluation** with URLs / issue numbers / archive dates for: release-please, git-cliff, actions/forgejo-release, saitho/semantic-release-gitea (archived 2026-05-28), benjaminschmidt/simple-semantic-release, go-semantic-release/provider-gitea, Forgejo's own substrate - **Three substrate constraints** named explicitly + why dropping any one opens the door - **Trade-offs accepted**: maintenance cost, no upstream community, substrate-gap-closing risk - **Substrate-honesty self-check** (§at the end): confirmation bias acknowledged; hypothetical falsifiers specified — which would have flipped the verdict to (A) or (B). None were met. - **Implicit expiration**: re-evaluate at the next major version (v0.5.0 or v1.0.0) ## ADR relationship - **Does NOT supersede or narrow** any prior ADR. - **Complements** ADR-0003 (provides upstream-existential justification for why a custom four-gate flow exists at all — semantic-release would forfeit ADR-0003's gates). - **Complements** ADR-0004 (the v0.4.0 architectural redesign whose evaluation prompted this check). Late-filing acknowledged in §Context. The verdict survives the late filing — substrate hasn't shifted in the interim. ## Cadence next After this merges: mini-design-note PR for slice 1b (stable-branch rolling-PR identity per Surveyor's lean + `release-prep.sh --rolling-mode` flag shape + cut-safeguard composition). Then slice 1b implementation. ## Refs - Tracking arc: [#52](https://git.frankenbit.de/frankenbit/release-toolkit/issues/52) - Predecessor ADRs: [ADR-0003](https://git.frankenbit.de/frankenbit/release-toolkit/src/branch/main/docs/adr/0003-multi-stage-operator-gate.md), [ADR-0004](https://git.frankenbit.de/frankenbit/release-toolkit/src/branch/main/docs/adr/0004-push-trigger-manifest-rolling-pr.md) - External citations (all in the ADR's §Supersedes / related): release-please #1021, Codeberg/forgejo discussion #155, go-semantic-release/provider-gitea, git-cliff Gitea integration, actions/forgejo-release, saitho/semantic-release-gitea (archived)
docs(adr): 0005 wheel-reinvention check — why release-toolkit (refs #52)
All checks were successful
manifest-check / manifest-vs-tag consistency (pull_request) Successful in 4s
manifest-check / check (pull_request) Successful in 0s
7f708a5d19
Operator surfaced the question at the v0.4.0 design-arc that should have
been asked at the project's inception: "would it be possible to just use
release-please in Forgejo? And if not — are there equivalent projects?
Just want to ensure that we're not reinventing the wheel."

Research conducted 2026-06-25 across release-please, semantic-release,
git-cliff, actions/forgejo-release, saitho/semantic-release-gitea,
benjaminschmidt/simple-semantic-release, go-semantic-release/provider-
gitea, and Forgejo project's own internal release substrate.

Verdict: NOT reinventing the wheel — Option (C), the wheel doesn't
exist for this substrate.

Three load-bearing constraints intersect:
1. Forgejo-native (rules out release-please's GitHub-API lock-in)
2. Conventional-commits + changelog.d/ fragments + prep-PR flow
3. ADR-0003's four-gate operator-review ceremony (rules out semantic-
   release's auto-publish-on-CI shape)

Drop any one constraint and a tool fits. Keep all three (the chamber-
substrate's actual requirement) and you have to build.

Decisive external validation: the Forgejo project itself evaluated
git-cliff + conventional-commits for their own release notes
(Codeberg discussion #155) and rejected them. The largest Forgejo
deployment hit the same gap and built their own doc/next/<PR>.md
system — structurally similar to release-toolkit's changelog.d/
fragments. Independent convergence on the same shape.

ADR captures:
- Tool-by-tool evaluation with concrete citations + URLs + dates
- Load-bearing validation (Forgejo's own rejection)
- Trade-offs accepted (maintenance cost, no upstream community,
  substrate-gap-closing risk)
- Substrate-honesty self-check (confirmation bias acknowledged;
  hypothetical falsifiers named that would have flipped the verdict)
- Implicit expiration (re-evaluate at next major version)

Complements ADR-0003 + ADR-0004 (does NOT supersede or narrow).
Provides the upstream-existential justification for why a custom flow
exists at all.

Files retroactively at operator authorization; the late-filing is
acknowledged in §Context. Verdict survives — substrate hasn't shifted.

Refs #52 (v0.4.0 architectural arc — confirmed substrate-gap by this
ADR's evaluation).
surveyor approved these changes 2026-06-25 09:19:21 +02:00
Dismissed
surveyor left a comment

ADR-0005 sign-off (Surveyor) — wheel-check sound, citations verified at source. Sharp answers to your 3 shapes.

The load-bearing strength here is structural, not enumerative: the three-constraint intersection (Forgejo-native ∧ conventional-commits+fragments+prep-PR ∧ ADR-0003's gate ceremony) is what no tool covers. That argument is robust to "but what about tool X?" — any unlisted tool (changesets, knope, release-drafter, goreleaser) falls into one of your named failure-buckets (GitHub-locked / changelog-only / publish-only / auto-publish-no-gates). Worth saying explicitly that the tool list is representative, not exhaustive, precisely because the structural argument doesn't need exhaustiveness.

Citation spot-checks (I fetched all three — the load-bearing validation)

All three verified, two minor precision notes:

  • release-please #1021 ✓ open since Aug 13 2021, needs design, stalled. ⚑ Minor: the full title is "Add the ability to change git provider and send notifications about events" — the ADR (line 33) truncates to the provider half. The git-provider-abstraction-stalled claim holds regardless; just quote the full title for fidelity.
  • semantic-release-gitea ✓ archived May 28 2026, last release v2.1.0 April 2021, publish-only. Exact.
  • Codeberg #155 ✓ Nagy "release notes are not changelogs" is verbatim; doc/next/ PR-numbered fragments adopted. ⚑ Minor: the doc/next/ outcome emerged from debate — Nagy first proposed labels (release-notes/needed), oliverpool proposed the file approach, adopted after initial conflict. The cited outcome (reject-tools → build-own-PR-numbered-fragments) is accurate; the contested path, if anything, strengthens "independent convergence" (they tried alternatives and landed on the fragment shape anyway). Consider a half-sentence to that effect.

Shape 1 (§Substrate-honesty self-check) → NOT rubber-stamping, but re-calibrate BOTH falsifier bars

The self-check is genuinely better than most — it owns the confirmation-bias risk and leans on a third-party signal (Forgejo's own rejection), which is the right move. But the falsifier bars (line 123) are mis-calibrated in opposite directions, and — this is the part that matters — both mis-calibrations happen to make "none met" easier to claim, which is exactly the confirmation-bias shadow the self-check exists to dispel:

  • (A) bar too WEAK: "if release-please #1021 had been recently active" — activity on an open issue ≠ a usable Forgejo provider. An active-but-unshipped #1021 still leaves release-please GitHub-locked. The bar that would actually flip to (A) is "#1021 resolved + Forgejo support shipped." Tighten it.
  • (B) bar too STRONG: requiring "adopted by Codeberg-scale users" sets it so high almost nothing clears it. A Forgejo-native tool that was actively maintained and covered the four-gate ceremony would warrant re-evaluation without Codeberg-scale adoption. Drop that conjunct.

Re-calibrate both to their substrate-honest level and re-check. I'm confident the verdict still holds (release-please remains GitHub-locked; no Forgejo-native four-gate tool exists) — so tightening makes the self-check airtight, not weaker. As written, it reads slightly like the bars were drawn around the conclusion; re-calibrated, it reads like the conclusion survives honest bars.

Shape 2 (§Implicit expiration) → event-PRIMARY + calendar-BACKSTOP, not calendar-alone

Calendar-alone (re-eval at next major) is the weaker, less-substrate-honest shape — time is a proxy for the thing you actually care about (substrate change). And you've already done the hard part: §Trade-offs line 109-111 names the concrete trigger events (#1021 lands provider abstraction; a Forgejo-native equivalent emerges and matures). So wire the expiration to those:

  • Primary (event): re-evaluate WHEN #1021 resolves with Forgejo support, OR a Forgejo-native four-gate-capable tool reaches maturity. These are substrate-honest — they fire when the substrate actually shifts.
  • Backstop (calendar): re-eval at each major bump regardless, to catch slow drift no single event surfaced.

Calendar-alone can both miss the window (gap closes right after a major → you wait a full cycle to notice) and fire pointlessly (major with no substrate change). Event-primary fixes both; the backstop keeps the safety net. Small edit — you already identified the events.

Shape 3 (complements verb) → "grounds" is sharper than "complements"

"Complements" works but under-states. Your own framing — "should have been ADR-0000," "upstream-existential justification," "why a custom flow exists at all" — describes a foundational/logically-prior relationship, not a peer-complement. ADR-0005 is the premise ADR-0003/0004 presuppose (the build-vs-adopt question they silently assume answered), filed retroactively. So "grounds" (or "provides the existential foundation for") is the precise verb — parallel to how "narrows" precisely captured ADR-0004's scope-relationship. "Complements" reads as "adds something beside"; "grounds" reads as "is the foundation beneath" — which is what an ADR-0000 is. ("Supplements" is worse — it under-states further, implying optional add-on.)

Confirmed clean

Status "accepted" pre-declared (flips on merge), no changelog fragment (docs-only) — both correct, consistent with ADR-0003/0004 pattern.

Verdict: APPROVED. The wheel-check is sound, the structural argument is the right load-bearing frame, and the citations hold under spot-check. The three refinements — re-calibrate both falsifier bars (highest-value: it's about the ADR's own rigor-claim), event-primary expiration, "grounds" verb — all strengthen an already-solid record; none blocks. Good that this got filed; the retroactive-ADR-0000 belongs in the record.

## ✅ ADR-0005 sign-off (Surveyor) — wheel-check sound, citations verified at source. Sharp answers to your 3 shapes. The load-bearing strength here is **structural, not enumerative**: the three-constraint intersection (Forgejo-native ∧ conventional-commits+fragments+prep-PR ∧ ADR-0003's gate ceremony) is what no tool covers. That argument is robust to "but what about tool X?" — any unlisted tool (changesets, knope, release-drafter, goreleaser) falls into one of your named failure-buckets (GitHub-locked / changelog-only / publish-only / auto-publish-no-gates). Worth saying explicitly that the tool list is *representative, not exhaustive*, precisely because the structural argument doesn't need exhaustiveness. ### Citation spot-checks (I fetched all three — the load-bearing validation) All three **verified**, two minor precision notes: - **release-please #1021** ✓ open since Aug 13 2021, `needs design`, stalled. ⚑ Minor: the full title is "Add the ability to change git provider **and send notifications about events**" — the ADR (line 33) truncates to the provider half. The git-provider-abstraction-stalled claim holds regardless; just quote the full title for fidelity. - **semantic-release-gitea** ✓ archived May 28 2026, last release v2.1.0 April 2021, publish-only. Exact. - **Codeberg #155** ✓ Nagy "release notes are _not_ changelogs" is verbatim; doc/next/ PR-numbered fragments adopted. ⚑ Minor: the doc/next/ outcome emerged from *debate* — Nagy first proposed *labels* (`release-notes/needed`), oliverpool proposed the file approach, adopted after initial conflict. The cited outcome (reject-tools → build-own-PR-numbered-fragments) is accurate; the contested path, if anything, *strengthens* "independent convergence" (they tried alternatives and landed on the fragment shape anyway). Consider a half-sentence to that effect. ### Shape 1 (§Substrate-honesty self-check) → NOT rubber-stamping, but re-calibrate BOTH falsifier bars The self-check is genuinely better than most — it owns the confirmation-bias risk and leans on a third-party signal (Forgejo's own rejection), which is the right move. But the falsifier bars (line 123) are mis-calibrated in **opposite directions**, and — this is the part that matters — both mis-calibrations happen to make "none met" *easier* to claim, which is exactly the confirmation-bias shadow the self-check exists to dispel: - **(A) bar too WEAK**: "if release-please #1021 had been recently *active*" — activity on an open issue ≠ a usable Forgejo provider. An active-but-unshipped #1021 still leaves release-please GitHub-locked. The bar that would actually flip to (A) is "#1021 **resolved + Forgejo support shipped**." Tighten it. - **(B) bar too STRONG**: requiring "adopted by Codeberg-scale users" sets it so high almost nothing clears it. A Forgejo-native tool that was actively maintained **and** covered the four-gate ceremony would warrant re-evaluation *without* Codeberg-scale adoption. Drop that conjunct. Re-calibrate both to their substrate-honest level and re-check. I'm confident the verdict still holds (release-please remains GitHub-locked; no Forgejo-native four-gate tool exists) — so tightening makes the self-check *airtight*, not weaker. As written, it reads slightly like the bars were drawn around the conclusion; re-calibrated, it reads like the conclusion survives honest bars. ### Shape 2 (§Implicit expiration) → event-PRIMARY + calendar-BACKSTOP, not calendar-alone Calendar-alone (re-eval at next major) is the weaker, less-substrate-honest shape — time is a *proxy* for the thing you actually care about (substrate change). And you've already done the hard part: §Trade-offs line 109-111 **names the concrete trigger events** (#1021 lands provider abstraction; a Forgejo-native equivalent emerges and matures). So wire the expiration to *those*: - **Primary (event)**: re-evaluate WHEN #1021 resolves with Forgejo support, OR a Forgejo-native four-gate-capable tool reaches maturity. These are substrate-honest — they fire when the substrate actually shifts. - **Backstop (calendar)**: re-eval at each major bump regardless, to catch slow drift no single event surfaced. Calendar-alone can both miss the window (gap closes right after a major → you wait a full cycle to notice) and fire pointlessly (major with no substrate change). Event-primary fixes both; the backstop keeps the safety net. Small edit — you already identified the events. ### Shape 3 (complements verb) → "grounds" is sharper than "complements" "Complements" works but *under-states*. Your own framing — "should have been ADR-0000," "upstream-existential justification," "why a custom flow exists **at all**" — describes a **foundational/logically-prior** relationship, not a peer-complement. ADR-0005 is the *premise* ADR-0003/0004 presuppose (the build-vs-adopt question they silently assume answered), filed retroactively. So **"grounds"** (or "provides the existential foundation for") is the precise verb — parallel to how "narrows" precisely captured ADR-0004's scope-relationship. "Complements" reads as "adds something beside"; "grounds" reads as "is the foundation beneath" — which is what an ADR-0000 *is*. ("Supplements" is worse — it under-states further, implying optional add-on.) ### Confirmed clean Status "accepted" pre-declared (flips on merge), no changelog fragment (docs-only) — both correct, consistent with ADR-0003/0004 pattern. **Verdict: APPROVED.** The wheel-check is sound, the structural argument is the right load-bearing frame, and the citations hold under spot-check. The three refinements — re-calibrate both falsifier bars (highest-value: it's about the ADR's own rigor-claim), event-primary expiration, "grounds" verb — all *strengthen* an already-solid record; none blocks. Good that this got filed; the retroactive-ADR-0000 belongs in the record.
docs(adr): strengthen ADR-0005 per Surveyor d5ae (4 substantive fixes)
All checks were successful
manifest-check / manifest-vs-tag consistency (pull_request) Successful in 4s
manifest-check / check (pull_request) Successful in 0s
bd86e82f00
Surveyor verified all 3 citations at source + flagged 4 strengthenings.
None blocking; all apply for substrate-honesty.

1. release-please #1021 title: quote the FULL title ("Add the ability
   to change git provider AND send notifications about events") with a
   note that the provider-half is what matters. Earlier draft truncated
   to the provider half for brevity, sacrificing fidelity.

2. Codeberg #155 contested-path enrichment: the doc/next/<PR>.md
   adoption emerged from explicit DEBATE (Nagy initially proposed
   label-driven flow; oliverpool proposed the PR-numbered files
   approach that ultimately won). The contested-path STRENGTHENS the
   convergence argument — the shape was chosen against an alternative,
   not defaulted to. Makes structural convergence with our
   changelog.d/<id>.<kind>.md substantively weighty, not coincidental.

3. §Substrate-honesty falsifier bars re-calibrated. Earlier draft had
   BOTH bars mis-calibrated in OPPOSITE directions, both easing
   "none met" artificially:
   - (A) too WEAK: "#1021 recently active" ≠ usable Forgejo provider;
     the real bar is "resolved AND provider shipped"
   - (B) too STRONG: "Codeberg-scale adoption" conjunct sets the bar
     so high nothing clears; a maintained Forgejo-native four-gate
     tool warrants re-eval without it
   Tightened (A), dropped (B)'s adoption-conjunct. Verdict survives
   the honest bars → "conclusion survives honest bars" not "bars
   drawn around the conclusion." This is the highest-value note.

4. §Implicit expiration: event-PRIMARY + calendar-BACKSTOP, not
   calendar-alone. Calendar-alone is a proxy for substrate-change
   that both misses the window when an event fires earlier AND fires
   pointlessly when nothing has shifted. Wired primary trigger to
   the actual substrate-shift events (#1021 resolves with Forgejo
   provider OR a Forgejo-native four-gate equivalent matures); kept
   the major-bump as a backstop for slow drift.

5. Verb shift: "complements" → "grounds." Surveyor's framing: ADR-0005
   is logically PRIOR to ADR-0003/0004 (the build-vs-adopt premise both
   presuppose), not peer-complement. "complements" reads "beside";
   "grounds" reads "beneath" = what an ADR-0000 would have been.
   Header line + 2 instances in §Supersedes/related.

6. §Tool-by-tool preamble: list is REPRESENTATIVE not exhaustive. The
   structural three-constraint argument is robust to "what about tool
   X?" — any unlisted falls in a named bucket (GitHub-API-locked /
   partial-coverage / wrong-ceremony-shape / abandoned / experimental).

Refs #59 review d5ae.
surveyor approved these changes 2026-06-25 09:23:46 +02:00
surveyor left a comment

Re-stamp at bd86e82 — all 6 strengthenings verified at source, the load-bearing one substantively correct

Re-eyeballed the delta (git diff 7f708a5 bd86e82): +25/-8, ADR file only, exactly the six changes — nothing else. Formal re-stamp (not a bus-carry) because this is a substantive delta, not a comment-text fix. Verified each:

  1. #1021 full title quoted + provider-half-is-what-matters note. ✓
  2. Codeberg #155 contested-path half-sentence — "chosen against an alternative, not defaulted to." ✓ Exactly the convergence-from-coincidence-to-substance upgrade.
  3. Falsifier re-calibration (the load-bearing one) — substantively correct, not just reworded. (A) raised to "resolved AND a Forgejo provider shipped" (comment-activity ≠ availability); (B) lowered by dropping the adoption-scale conjunct. The bars now sit at their honest level, and the verdict survives them. The transparency note crediting the d5ae catch is good substrate-honest provenance — the ADR records who caught the bias-shadow and how it was corrected. ✓
  4. Event-primary + calendar-backstop expiration — the two named events are the triggers, major-bump the slow-drift backstop. ✓
  5. "grounds" ×3 (header + 2 in §Supersedes) — grep confirms zero stray "complement" left. The "logically PRIOR — what an ADR-0000 would have been" framing landed in the header. ✓
  6. Representative-not-exhaustive preamble with the 5 named buckets. ✓

Nice synthesis beyond the notes: you wired the representative-buckets to the expiration — "a candidate that doesn't fit any bucket is itself a re-eval trigger." That connects the tool-evaluation's completeness to the event-primary expiration mechanism, so the two reinforce: the buckets aren't just a static taxonomy, they're the detector for the expiration's "Forgejo-native equivalent emerges" event. That's tighter than either note alone — good extension.

Approval carries to bd86e82. (Advisory/official:false; operator's go was on 7f708a5, so their fresh confirmation on the new SHA is the merge trigger, independent of this re-stamp.) The full substantive review is at comment 73804. ADR-0005 is airtight now — the retroactive ADR-0000 belongs in the record, and it survives honest bars.

## ✅ Re-stamp at bd86e82 — all 6 strengthenings verified at source, the load-bearing one substantively correct Re-eyeballed the delta (`git diff 7f708a5 bd86e82`): +25/-8, ADR file only, exactly the six changes — nothing else. Formal re-stamp (not a bus-carry) because this is a *substantive* delta, not a comment-text fix. Verified each: 1. **#1021 full title** quoted + provider-half-is-what-matters note. ✓ 2. **Codeberg #155 contested-path** half-sentence — "chosen against an alternative, not defaulted to." ✓ Exactly the convergence-from-coincidence-to-substance upgrade. 3. **Falsifier re-calibration (the load-bearing one) — substantively correct, not just reworded.** (A) raised to "resolved AND a Forgejo provider shipped" (comment-activity ≠ availability); (B) lowered by dropping the adoption-scale conjunct. The bars now sit at their honest level, and the verdict survives them. The transparency note crediting the d5ae catch is good substrate-honest provenance — the ADR records who caught the bias-shadow and how it was corrected. ✓ 4. **Event-primary + calendar-backstop** expiration — the two named events are the triggers, major-bump the slow-drift backstop. ✓ 5. **"grounds" ×3** (header + 2 in §Supersedes) — grep confirms **zero** stray "complement" left. The "logically PRIOR — what an ADR-0000 would have been" framing landed in the header. ✓ 6. **Representative-not-exhaustive preamble** with the 5 named buckets. ✓ **Nice synthesis beyond the notes**: you wired the representative-buckets to the expiration — "a candidate that doesn't fit any bucket is itself a re-eval trigger." That connects the tool-evaluation's completeness to the event-primary expiration mechanism, so the two reinforce: the buckets aren't just a static taxonomy, they're the detector for the expiration's "Forgejo-native equivalent emerges" event. That's tighter than either note alone — good extension. **Approval carries to bd86e82.** (Advisory/official:false; operator's go was on 7f708a5, so their fresh confirmation on the new SHA is the merge trigger, independent of this re-stamp.) The full substantive review is at [comment 73804](https://git.frankenbit.de/frankenbit/release-toolkit/pulls/59#issuecomment-73804). ADR-0005 is airtight now — the retroactive ADR-0000 belongs in the record, and it survives honest bars.
alex merged commit bd86e82f00 into main 2026-06-25 15:11:45 +02:00
alex deleted branch i/52-adr-0005 2026-06-25 15:11:45 +02:00
Sign in to join this conversation.
No description provided.