In-app bug reports

The ledger separates what the audit changed, what was kept on purpose, and what has not run in production yet.

1. Fixed in the templates

   • Vercel Cron could not reach any worker The proxy resolved the tenant from the host before anything else. Cron calls the deployment's own *.vercel.app host, which no tenant owns, so every cron route in the app, not only this module's, answered 404 from the proxy. Development did not show it: the local seed mapped a *.vercel.app wildcard to a test tenant. Shipped: CRON_PATHS, the bypass placed first in the proxy, and a test that the list equals vercel.json, see outbox.md.
   • The webhook host answered "Domain not configured" The App's webhook pointed at the operator host, which the proxy did not yet treat as a host without a tenant. Every delivery answered 404 before the route ran. Shipped: a critical fact, an OPERATOR_ORIGIN the env reader requires, and a curl probe in the go-live list that tells a proxy 404 from the route's 401, see webhook.md, operations.md.
   • The text written on GitHub was in the tenants' language Table labels, link text and comment signatures were hard-coded in the language of the console. The repository is read by engineers, in the repository's language. Shipped: TRACKER_STRINGS, English by default, separate from the members' copy, see adaptation.md.
   • Ignored deliveries left no trace An event from the wrong installation or repository, or for an issue no report owned, answered 200 with the reason in the body and was otherwise invisible. A misconfigured App looked exactly like a quiet one. Shipped: the reason logged, and written to bug_report_bridge for the health view, see webhook.md.
   • Sign-in from an attachment link lost the file An anonymous request to an attachment was redirected to sign-in without a return path. Operators open these links from GitHub, usually before they have a session. Shipped: loginUrl(returnTo) in the host seam, called with the attachment's path, see attachments.md.
   Show 3 moreShow fewer

   • The lists stopped at a fixed cap The member list read the newest 200 reports and the operator list the newest 300, with no sign that more existed. Shipped: keyset pagination on (last_activity_at, id) with a cursor in the URL, see actions.md.
   • The worker logic could not be tested Which deliveries counted, and when a failed job retried, were decided inside functions that also read and wrote the database. Shipped: planDelivery and decideRetry as pure functions with their own suites, see webhook.md, outbox.md, testing.md.
   • The issue job read the host's members table The worker looked up the reporter's role in a host table at send time. Shipped: reporter_role snapshotted on the report at insert, next to reporter_name, so the module reads no host table at all, see data-model.md.

2. Kept deliberately

   • The webhook is processed inline It looks slower than answering first and working in after(). GitHub does not redeliver a failed delivery by itself, so work after the answer turns every failure into a silent 200. Inline, a failure is a 500 in the App's log and a Redeliver button; the ledger makes that safe.
   • Visibility is opt-in, through /reply from the team It costs the team a prefix on every answer. Every alternative that mirrors by default leaks the team's own conversation the first time someone forgets a marker.
   • No status writer but the tracker Operators get no close button either. Two writers of one field is how an app and a tracker disagree about whether a bug is fixed.
   • Markers are found by listing, not by search Listing the label's issues with since looks heavier than one search query. GitHub's search does not index HTML comments, so a search for the marker returns nothing and the retry opens a duplicate.
   • No role check for reporting The person who hits a bug is rarely the person with an admin role. Every member may report and comment, and the RLS admits any member; a per-member revoke would hide a button the database still serves.

3. Added

   • A comment waiting for its issue gets its attempt back In the earlier implementation a comment job waiting for its issue spent attempts like a failing one, so during an outage it could be parked while its issue was not. decideRetry refunds the attempt while the issue job is pending. Designed here; it has never run in production. See outbox.md.
   • The bridge health view Last delivery, last ignored delivery and why, last worker run, pending jobs and failed reports, derived from timestamps the bridge writes. Designed here; the earlier implementation showed only per-report sync states. See operations.md.
   • The test config skips the installed skill vitest.config.ts shipped in 0.1.0 with include: ["**/*.test.ts"] and only node_modules excluded, so in an app with the skill installed in the project, under .agents/skills/ or .claude/skills/, vitest also collected the skill's own assets/tests/ copies, whose relative imports resolve nowhere, and npm test failed. Found by the 0.1.0 agent evals, where one agent patched the config to get its run green; reproduced against the template and fixed with .*/** in exclude. Designed here. See testing.md.
   • Marker lookups read every page findIssueByMarker and findCommentByMarker shipped through 0.1.1 reading only the first page of 100. A retry after more than a hundred newer labelled issues, or on an issue with more than a hundred comments since the job began, missed its own marker and opened a duplicate. Found by the 0.1.1 agent evals, where one agent paged the lookups; reproduced with a fake fetch that puts the marker on page 2, and fixed by paging until a short page, with a test in server/github/app.test.ts. Designed here. See github-app.md.
   • A failed upload never ends as "uploading" The upload picker shipped through 0.1.2 ran each upload in an async block with no catch. When the action was unreachable, or createBrowserClient threw because the NEXT_PUBLIC_ Supabase values were not in the bundle, the file stayed "uploading" and the form, which waits for every upload, could never send. Found by the 0.1.2 agent evals, where one agent added the catch; reproduced by calling createBrowserClient without its config, which throws. The block now ends in an error state on any throw. No suite covers it: the suites run without a React environment. See attachments.md.