How we verify fixes, and how you (or your agent) can check us

Stuck to Shipped publishes 13 fixes. This page explains what each claim means and how to check it without trusting us. The same text is at https://stucktoshipped.com/verify.md for agents.

Status labels

status	What it means	What it does not mean
`manually-verified`	We reproduced the exact error on our own test machine, applied the fix, and saw it pass, on the `last_verified` date with the listed `versions`.	That it was re-tested since that date, or on your OS.
`partially-verified`	We reproduced the error and verified part of the fix. The untested parts are listed free on every page under "What we could not test".	That the whole fix is proven.
`as-reported`	Built only from official docs and public reports (linked under Sources). Not reproduced by us. `last_verified` is `null` and `repro_url` is `null`.	Any test by us.

Every fix also has ci_status: "pending-ci". Nightly CI re-runs are planned but not running yet, and no CI results exist for any fix. We will never show a CI pass that didn't happen.

What's public and what's paid

Everything you need to judge a fix is free: the exact error, symptoms, root cause, status, dates, versions, limitations, sources, and the SHA-256 hash of every paid file. The full step-by-step fix, its commands and test record, and the runnable repro bundle are paid (see pricing). Paid items are not on sale yet.

Check our claims (step by step)

Get the record. GET https://stucktoshipped.com/fixes.json and find the fix by id, or by matching error_string / also_appears_as against your error. Each fix also has json_url and markdown_url twins.
Check freshness. Compare last_verified and versions with your environment. If your versions are newer, treat the fix as unverified for you. retest_due shows when we plan to re-test.
Check the sources. Every fix lists sources. For as-reported fixes, the sources are the whole basis, so read them, especially official docs and changelogs.
Check the limits. Read "What we could not test" on the page. A partial verification is only as good as the parts we did run.
Check the hashes. Each fix record has full_fix.sha256 (the SHA-256 of the full-fix Markdown file). Each verified fix has repro_files_url (/repros/<ID>/index.json), which lists every repro file with its byte size and SHA-256. These are public before you buy and are fixed in our git history, so we can't quietly swap the content later. After you buy, run sha256sum (or shasum -a 256 on macOS) on what you got and compare. If a hash doesn't match, tell us; that counts as a refund reason.
Re-run it (bundle owners). Use an isolated environment (a container or VM, a throwaway HOME, no real credentials). Run the "before" steps, confirm you get the same error_string, apply the fix, and confirm the success check. Our repros use dummy keys only; never use real secrets to test.
Check page integrity. content_sha256 in each fix record is the SHA-256 of the page's public Markdown source at build time.

What's coming (not live yet)

Nightly GitHub Actions re-runs on pinned versions plus "latest", from a private fixes repository. Each run will write a public results.json per fix (fix id, pass or fail, versions, run date, and the SHA-256 of the fix it tested). The results are public; the fixes stay paid.
Signed results. results.json will be attested with GitHub artifact attestations (Sigstore, keyless), so you can check a result came from our workflow without seeing the fix.
When a nightly run fails on new versions, the page will show a "failing now" banner automatically, and ci_status will change.

Until then, ci_status stays pending-ci on every fix.

Report a problem

If a fix is wrong, outdated, or unsafe, tell us: growtheshow@mail.grokbot.com. We correct pages and note the change.