Distribution Gate — first external capture → retained baseline → repeat-use compare

[yaertu]

🎯 North-star question

Will an unrelated maintainer keep a FixBundle artifact and use fixbundle compare on a later incident because it reduces debugging time or uncertainty?

This is the product gate after v0.6.0. Do not start v0.7 merely to increase the version number.

✅ Proven before outreach

• v0.6.0 implementation merged
• final implementation PR CI 10/10 PASS (33591771123)
• implementation post-merge main CI 10/10 PASS (33591951443)
• release PR CI 10/10 PASS (33592233607)
• v0.6.0 GitHub Release published (380983293)
• release target verified: 8b75bdd021974ad53e4b9fe2d128e24c0c07cda0
• post-release main CI 10/10 PASS (33592335467)
• validation/falsification gate merged to main (2068f937b4e2bb5a0f4982b60cd433d063506544)
• validation-gate main CI 10/10 PASS (33594019142), including Live GitHub failure evidence

🔎 Repository discovery metadata

Target state is documented in docs/product/REPO_HOME.md.

• About description confirmed live: Package failures into redacted evidence bundles and compare what changed across local, CI, and OpenTelemetry incidents.
• github-actions live
• regression-testing live
• incident-response live
• GitHub API re-read on 2026-09-02
• remove obsolete singular topic github-action
• add missing target topic git

Connected repository tooling does not expose About/Topics mutation. The two unchecked topic edits are manual GitHub UI work; do not claim them complete until the live API confirms them.

🧪 External adoption gate

• first unrelated maintainer installs FixBundle
• first real external failure is captured
• maintainer intentionally retains the evidence ZIP as a baseline
• same maintainer returns for a second real incident/failure
• fixbundle compare <baseline> <incident> is used on those retained artifacts
• capture whether compare reduced time, uncertainty, tool-switching, or evidence reconstruction
• record friction/missing evidence without inventing a feature before the evidence exists

🚫 Anti-goals

• no fake users, stars, downloads, testimonials, benchmarks or time-saved claims
• do not count repository-owner usage or FixBundle's own CI as external validation
• no bulk unsolicited promotion or drive-by spam on unrelated issues
• do not upload proprietary/sensitive bundles publicly
• no automatic evidence upload
• no v0.7 feature work until this gate produces evidence or a documented reason to change direction

Outreach rule

Prefer evidence-first outreach: find a public debugging problem where FixBundle can produce a genuinely useful read-only artifact/report, verify that result, then offer it contextually. A repo link by itself is not a contribution.

Success

The strongest signal is not a star. It is the same unrelated maintainer using FixBundle twice and finding the second incident easier to compare against the first.

[yaertu]

User #1 candidate checkpoint — tanbamboo/rusql#159

Status: strong evidence-first candidate; no external contact made.

Why it qualifies

• Human maintainer / repo owner opened the issue (tanbamboo).
• Public, small/medium repository; issue is open with 0 comments at inspection time.
• P0 CI failure asks exactly the evidence question FixBundle targets: last-green vs later failed runs, with several merges listed as possible causes.

Read-only evidence found

The issue currently says the mysql-diff / multi_schema failure also occurred on runs 33486254297 and 33492641764, and describes the last green as being before M59/M61/M63/M64 merges. GitHub job evidence narrows/corrects that timeline:

M59/M61  2d446a0  run 33486254297  mysql-diff PASS (overall run failed on rust/cargo fmt)
last green 2574725 run 33487091024 mysql-diff PASS
M64       ad79f15  run 33492641764  mysql-diff PASS (overall run failed on rust/cargo fmt)
M63       a3d0372  run 33493550987  mysql-diff FAIL
later docs 8f9ba52  run 33493712604  mysql-diff FAIL

The compare API also shows M59/M61 commit 2d446a0 is an ancestor of the documented last-green SHA 2574725, so M59/M61 cannot be the first introduction of this mysql-diff regression.

Evidence gap

scripts/mysql-diff.mjs launches rusql-server with stdio: 'ignore' and does not report the child exit code/signal when a suite mismatch occurs. Therefore the current CI artifact cannot distinguish a server panic/exit from a connection/lifecycle failure. The issue's root-cause hypotheses remain hypotheses until child-process evidence is retained.

Why this is useful product validation

This case demonstrates the wedge without an LLM root-cause claim: two overall-red runs were incorrectly grouped as the same failure, while job/step evidence shows their failure identities differ. The first actual mysql-diff red is narrowed to the M63 merge window.

Next gate

Before any outreach, prepare a concise maintainer-facing evidence note with exact run/job links and no promotional language. Do not post it externally without explicit approval. If the maintainer finds it useful, ask them to retain a FixBundle capture as a baseline for the next incident; repeat-use remains the real success metric.