Hi — another fork of block/buzz here, reading your fork-gates work with respect (your 2026-08-25 additive-only contract + required CI gate was already the strongest reference implementation we'd found; cb633a0's retirement of the PR #26/#27 carried patch via 000-docs/009 is a clean lifecycle demo).
We have a measurement that stress-tests one of check-additive-only.sh's design assumptions and thought it belonged here rather than nowhere.
The assumption: CARRIED_PATCHES[] entries are removed once upstream merges — i.e. the list trends toward empty.
Our data: we measure our modification surface vs block/buzz main at every integration gate. Three snapshots:
- 2026-08-24: 42 added / 89 modified upstream-owned paths (~13 of which would classify as carried)
- 2026-08-25: 57 A / 116 M (56 carried-class)
- 2026-08-28: 86 A / 128 M (64 carried-class, vs upstream/main 9733863)
So a fork that syncs upstream regularly still saw its carried class grow ~5x in a week. Bulk of the growth is NOT big features: at the last snapshot, 19 modified paths are ≤3-line changes and 32 are 4-10 lines — mostly one-line registration/wiring touches in upstream-owned files (lib.rs registration, api/mod.rs routing, single-line widget hooks). We upstream what we can (open PRs on block/buzz incl. block#6214/block#6259/block#6548, all merge-clean but review-blocked), so the growth happens even while upstreaming actively — the review queue, not the merge queue, sets the floor.
Open question: has the expiry assumption been exercised against a fork with ~60 standing carried entries? We're currently weighing three options for our own contract: (i) a generated zero-rationale divergence report (pure measurement, near-zero maintenance), (ii) a full rationale ledger per path (cost scales with the 128-path divergence — the 'second bookkeeping job'), (iii) no contract, keep status quo. Your gate is the best existence proof for a fourth option (generated report as the ledger + CI gate on the delta), but the 5x-week growth makes us suspect hand-maintained rationale can't survive contact with an actively-syncing fork. Curious whether PR #19's allowlist maintenance has hit anything similar.
(Numbers are from our integration gates: product/main vs block/buzz main at the SHAs cited above; happy to share the per-path numstat if useful.)
Hi — another fork of block/buzz here, reading your fork-gates work with respect (your 2026-08-25 additive-only contract + required CI gate was already the strongest reference implementation we'd found; cb633a0's retirement of the PR #26/#27 carried patch via 000-docs/009 is a clean lifecycle demo).
We have a measurement that stress-tests one of check-additive-only.sh's design assumptions and thought it belonged here rather than nowhere.
The assumption: CARRIED_PATCHES[] entries are removed once upstream merges — i.e. the list trends toward empty.
Our data: we measure our modification surface vs block/buzz main at every integration gate. Three snapshots:
So a fork that syncs upstream regularly still saw its carried class grow ~5x in a week. Bulk of the growth is NOT big features: at the last snapshot, 19 modified paths are ≤3-line changes and 32 are 4-10 lines — mostly one-line registration/wiring touches in upstream-owned files (lib.rs registration, api/mod.rs routing, single-line widget hooks). We upstream what we can (open PRs on block/buzz incl. block#6214/block#6259/block#6548, all merge-clean but review-blocked), so the growth happens even while upstreaming actively — the review queue, not the merge queue, sets the floor.
Open question: has the expiry assumption been exercised against a fork with ~60 standing carried entries? We're currently weighing three options for our own contract: (i) a generated zero-rationale divergence report (pure measurement, near-zero maintenance), (ii) a full rationale ledger per path (cost scales with the 128-path divergence — the 'second bookkeeping job'), (iii) no contract, keep status quo. Your gate is the best existence proof for a fourth option (generated report as the ledger + CI gate on the delta), but the 5x-week growth makes us suspect hand-maintained rationale can't survive contact with an actively-syncing fork. Curious whether PR #19's allowlist maintenance has hit anything similar.
(Numbers are from our integration gates: product/main vs block/buzz main at the SHAs cited above; happy to share the per-path numstat if useful.)