Changelog

All notable changes to Bucker.

Bucker is pre-launch. Version numbers were assigned when this changelog was published, so entries before 0.13.0 are reconstructed from work that had already shipped and are dated by the day it landed — which is why several share a date. Where something shipped only in part, the entry says which part rather than dropping it.

Unreleased

Added

• A customer can now add their own scrubbing rules. Bucker's built-in redaction — credentials, cards, private keys, and at the agent tier emails and IP addresses — never knew about the identifiers that are secret only inside one company. An organization's admins can now add rules of their own by key, by path or by pattern, at either tier, and try one against a pasted sample before saving it. They only ever add: there is no way to switch a built-in rule off, so "the agent sees a subset of what we stored" stays true whatever a tenant configures. A pattern that could hang the ingest path on the customer's own events is refused when it is written, and refused again when it is loaded, where it disables itself and leaves every other rule running.
• Personal access tokens, for scripts and CI. A named, scoped, revocable credential you mint for yourself against one organization, instead of putting a password or a 15-minute session token into a deploy script. The secret is shown once, at creation, and stored only as a digest; afterwards you see the name, the first few characters, when it was last used and from where. It carries the scopes you ask for and only the ones you actually hold in that organization — and it is checked against your current membership on every request, so being moved to a narrower role narrows every token you minted, and leaving the organization stops them working, with nothing to revoke and no delay. Approving a fix, changing billing and administering an organization can never be done by a token; those stay with the person. Revoke your own at any time, and an operator can revoke one from the console.
• A status page is now actually served on your own hostname. Verifying a custom domain has worked since 0.9.0 — two DNS records and a check that both resolve — but nothing then read the hostname a reader arrived on, so status.acme.com reached a renderer that only knew how to serve /acme/status. It does now: a verified, public domain resolves to its page, the reader's address bar keeps saying their hostname, and every route under the page comes with it — the embed widget, the RSS and Atom feeds, the badge, the brand assets and both JSON APIs. The old address keeps working and redirects to the new one, so links shared during an earlier incident do not rot. A hostname pointed at us that belongs to no published page is a 404; a hostname we could not look up because our own control plane is unreachable is a 503, never a 404, because "we could not check" is not "your page does not exist" — and a renderer that has already served a hostname keeps serving it straight through such an outage.
• A verified domain is not advertised until it is really being served. Verification proves you control the zone; it does not put the hostname on our platform or get a certificate issued, which is a step we perform. Until that is done, the link the dashboard offers you to share stays the one that works, and the old URL does not redirect anywhere.
• Notifications got their own settings tab, and quiet hours actually do something. The unified notification model has carried a quietHoursStart/quietHoursEnd/ timezone since it was introduced, but nothing wrote them and nothing read them; the two /me/digest routes built for a notification settings surface had no surface. Both are real now: a Notifications tab holds the daily-digest opt-in and a quiet-hours window — a start hour, an end hour, and the IANA timezone they are read in, required together because a window with no zone is wrong for almost everyone. The digest sweep consults it at send time and defers a recipient inside their own window to its next pass; it never opts them out, so a bad night's sleep costs one email, not the subscription.

0.15.0 — 2026-09-11

Added

• The operator console became an admin panel. It was five tabs of read-only tables; it is now seven sections at their own addresses — health, ingest, customers, users, Bucker's own failures, security and lifecycle — and it can change things. Links saved when it was five tabs still land where they meant to.
• Deployment health in one place: how much is being accepted and dropped right now and why, how deep the ingest queue is and what its dead letters say, whether every worker and every one of thirty scheduler passes is alive, how long the database takes to answer, which provider each seam selected, and the hostnames this deployment believes in. A number nobody measured reads as a stated absence rather than as a green tick, which is the difference between "nothing is wrong" and "nothing has told us anything".
• Dead ingest jobs can be requeued or purged from the console, bounded, filtered, and after seeing a count that comes from the same query the action then runs. Recovering from a dependency outage was previously hand-written SQL against production.
• A customer page that answers "which customer is having a bad time": plan, quota, keys, usage, people, a timeline of everything that has happened to the account, internal notes, and a list of risk signals written as sentences with their evidence — a DSN that was issued and never used, a project that went quiet, events being dropped, a card that stopped working.
• Operators can now change a customer's plan, quota, billing settings and membership, suspend an account or an organization's ingest, revoke a DSN key or a credential, and pause a runaway scheduler. Every one of those writes two audit rows: one here, and one in that customer's own audit log, in their vocabulary, saying a deployment operator did it.
• How much of their own data Bucker's operators may read is now the customer's setting. It defaults to metadata only — counts, configuration, plan, drop reasons — and that is exactly what the console could already see. A customer can raise it to their issues, or to event payloads and replays, from their own organization settings; the grant expires on its own, every read made under it appears in their audit log naming the operator, and it can be lowered at any time. There is no impersonation at any level.
• GET /metrics in the Prometheus exposition format, authenticated with a new METRICS_TOKEN and refusing to publish anything without one. The registry behind it had been complete and unreachable since it was written.
• Ingest can be suspended for an organization or a single project. A suspended project's envelopes are refused with the advisory header SDKs act on, the refusals are counted under their own reason rather than being confused with a backlog, and every DSN-authenticated surface honours it, not only the envelope route.
• Bucker's own six self-monitoring projects are visible on one screen, including the state that matters most: a surface that has never reported anything, which is what a missing or misinstalled DSN looks like from here.
• Releases now stamp themselves. BUCKER_RELEASE is baked into each Fly image as a build argument and passed to each Vercel deployment, so an image and the release it claims cannot disagree.

Fixed

• The rollback record had been frozen since 2026-09-07 and nobody could have noticed. A release records the images it is about to replace so --rollback can put them back, and it kept that record for as long as it named images that were no longer live — meant as "a previous release already moved these, this run is a retry". A release that works ends that way too, so the rule held from the first release onwards and the file stopped being rewritten. It was six releases and 55 commits behind; rolling back would have restored four-day-old images, against a schema seven migrations newer, and reported success. A retry is now told apart by commit rather than by image drift.

• /trust/status on the marketing site is redirected to status.bucker.io instead of starting to 404. The page was deleted for reading as an internal decision note rather than as marketing; the sitemap is derived from the filesystem and drops it on its own, but the URL is live and indexed, so the release shipping the deletion is the release that breaks it.

• The ingest queue's bulk statements did not honour their own limits. A request to requeue two dead jobs could requeue every matching job instead: the statement's inner SELECT … LIMIT n FOR UPDATE SKIP LOCKED can be re-executed by the query planner, and each re-execution pulled the next n rows. Both the requeue and the worker's own claim now use a form the planner must evaluate once. Nothing had caught it because the requeue had never had a caller.

• A scheduler that stopped silently used to be invisible. Every scheduler pass now records a row, so the evidence of a stopped scheduler is a timestamp that stopped moving — the one failure a log cannot show, because the symptom is the absence of a line.

• Releases and deploys can now be recorded. The Releases page always described tracking deploys and change correlation; nothing had ever written a Deploy row, and a release carried only its version, never the commit it shipped. POST endpoints now register a release and a deploy per environment, so list_releases and the Releases page report what actually shipped and where, instead of a version string with everything else blank.

0.14.0 — 2026-09-11

Added

• Provenance certificates are signed with Ed25519 instead of a shared secret, using the same key already published at /.well-known/proof-ledger-keys. A certificate can now be checked by anyone holding the public half, where before only the holder of the secret could check one — and anyone who could check one could equally have forged it. Nothing was rewritten: a certificate records the algorithm it was signed with, so every certificate issued earlier still verifies with the secret that signed it.
• The in-browser verifier now checks the signature as well as the claims, using the browser's own cryptography and a key fetched from the published endpoint rather than read out of the document. Authorship and self-consistency are reported as two separate verdicts, because a document that supports its own claims and a document we actually signed are different facts. A signature the browser could not check reads "not checked" and never "invalid".
• The in-browser verifier accepts a provenance certificate, not only a Proof Ledger bundle, and reports whether the certificate contradicts itself — a tier claimed above the evidence recorded, a patch outside its own blast radius, a commit attested without a checkout. Certificates signed with the older shared secret are still refused by name, because nothing a browser holds could check one.
• The AI-lane spend cap is enforced where it was claimed to be. A run that would exceed a HARD cap is now refused before it starts, rather than after the work has been done — which was the promise, against a gate nothing called. A soft cap still refuses nothing.
• Verified fixes are metered and invoiced on a schedule. A fix whose merge raced the meter is picked up on the next pass, and an invoice line that failed to reach the payment provider is retried until it lands, keyed on the line so a retry cannot charge twice.

Changed

• Settlement and sandbox execution are no longer published as partly-shipped claims. Both are written in full and neither is configured on this deployment, which is a fact about the deployment rather than a grade for the software, so each is now stated in sentences under its own heading: nothing here has ever charged a card, and no fix here has ever been verified in a sandbox. Both still carry an amber marker, so neither is easier to overlook than the card it replaced.
• The billing page now says what connecting a payment provider actually takes. The secret key alone decides only whether a provider exists, so setting just that key reports the deployment as connected while a plan change still fails on a missing price id — a worse state than not connecting it at all.
• The /changelog, /pricing, /billing and /verified-fixes pages were corrected where they described the product as it was rather than as it is. The sandbox note said the hosted provider was a stub and it is a complete adapter; the settlement note said no payment integration existed and one does. What is still not true on this deployment — no payment provider connected, no sandbox credentials, no public transparency log — is stated on the claim it belongs to.
• Code samples on the marketing site and in the documentation are syntax-highlighted. The highlighting is done where the page is built, so no highlighter is downloaded and the pages still ship no client-side JavaScript.
• Legal pages no longer carry a draft banner or a line naming the file they were rendered from. The documents are still generated from the repository, so the page and the file cannot disagree.
• The status link in the site footer points at status.bucker.io, and the placeholder page that used to stand in for it has been removed.

0.13.0 — 2026-09-10

Added

• Idempotency-Key is now accepted on the writes where a retry can create something twice — a second organization, a second ingest key, a second incident update sent to every subscriber. Repeating a request with the same key and the same payload replays the original response with Idempotent-Replay: true instead of running the handler; the same key with a different payload returns 422, and a key reused while the first request is still in flight returns 409. The header is opt-in, so existing clients are unaffected. The record is held per machine and is lost on restart, so the guarantee does not hold across a restart or during a rolling deploy.
• Every API response carries an X-API-Version header, including health and event ingest, so a client can ask which contract it is talking to on any request. Routes that are retiring additionally carry deprecation and sunset headers, on error responses as well as successful ones.
• Span and log partitions are now created automatically ahead of time, and late-arriving data from the previous day still finds a partition after a restart. Without this, telemetry written after the pre-created window would have been stored in a way retention could not remove.

Changed

• Spans and log records are stored in daily partitions, the way events already were, so retention can remove them by dropping a partition rather than deleting rows from a live, high-write table. Deletion policy is unchanged: each project's own retention window is still honoured row by row.
• Agent access tokens use the bpat_ prefix. No tokens were in issue, so nothing in flight was invalidated.
• The setup tool writes bucker.server.* and a .bucker/ directory in place of the previously named equivalents, and adopts a repository that was set up with the old names rather than appending a second block beside the first. It does not delete the old files, so a repository that re-runs setup will have both until the old ones are removed by hand.
• The JavaScript SDK packages carry a licence, a changelog and a build configuration in preparation for public release. Nothing is published yet.

Fixed

• The setup tool generated a verification script that failed on its first statement with a ReferenceError, on every Express, Fastify and plain Node install. It failed in the most misleading way available: error reporting was already initialised, so the crash could itself be captured and sent, and watching that event arrive looked like proof the install worked. The generated script is now executed by a test rather than only inspected.
• The pre-authentication rate limit on event ingest was keyed on the exact caller address, which is a limit for IPv4 and no limit at all for IPv6 — an ordinary allocation is a /64, so a single caller had 2^64 separate allowances. IPv6 callers are now counted per /64 on the ingest, OTLP and public status endpoints, which share one allowance between them by design.

Security

• Event ingest now bounds the size of every field it accepts. The schema checked the shape of incoming data but placed no limit on its size, so an oversized payload was validated rather than refused.
• Stored credentials are encrypted at rest: device push tokens, notification channel configuration, uptime monitor request headers and staged-rollout provider configuration, each with its own key purpose and a recorded key id so rotation is a re-encrypt rather than a loss. Existing rows are migrated by a separate backfill that is safe to re-run; until it has run everywhere, reads fall back to the unencrypted column and those columns have not yet been removed.
• The authenticated API now has per-organization and per-credential ceilings. Previously there was no per-tenant limit anywhere on the control plane, so one customer's runaway script could consume the capacity of the whole service. Counts are kept per machine, so the effective ceiling scales with the number of machines running.
• Repeated requests carrying an invented ingest key are now refused from a short-lived negative cache. Each one previously bought an indexed lookup and a pooled database connection — the cheapest request to send, and the most expensive to serve.
• Any API route that is neither authenticated nor explicitly listed as public now fails the build, so a missing authentication hook is caught before the route can be deployed. This checks that authentication was a decision rather than an omission; it does not check that an authenticated route authorizes the right thing.
• Startup checks in production gained three rules: selecting S3 storage requires S3 credentials (a credential-less selection previously started cleanly and failed at the first write, after an event had already been accepted); an explicitly local sandbox provider is refused; and services that sign attestations must have a signing key, required only of the services that actually sign.

0.12.0 — 2026-09-09

Added

• An operator console at /admin for whoever runs a Bucker installation — on a self-hosted one, you. It answers what previously required reading server logs: how many organizations, users and projects exist, what the ingest queue is doing and how long its oldest job has been waiting, which provider each configurable seam actually selected, and what the production readiness check would report right now.
• Every part of Bucker can report its own failures through Bucker: the API, the workers, the MCP server, the dashboard, the marketing site and the status page each accept a DSN and send errors through the same SDK a customer would use. Each surface is its own project, so grouping stays separate.
• The two console screens that show people's email addresses write an audit record before they show them.

Changed

• Self-reporting is off until a DSN is configured. With none set, no SDK is loaded, no network request is made, and the service behaves exactly as it did before — which is the right default for a self-hosted install, since there is no Bucker of ours for it to report to.
• The API does not report failures of its own error-reporting path, because answering one failure with two compounds it. It does report an ingest failure on any other project: a 500 on the endpoint that receives your errors is the thing most worth hearing about. It does not report a 404 or a permission refusal, because those are the product working.
• Background workers report through their logger rather than through hand-written handlers at each call site, so a job added later is covered by the logging it already does.

Security

• Console access is deliberately narrow, and no instance-administrator account was added. Authority comes from owning an organization that the installation names as its operator — a real person in a real organization, whose actions are audited like anyone else's. Every console route is read-only, and there is no "act as this user". An operator who needs to change a customer's data joins that organization and does it in the open.
• Every part of self-reporting is inert when unconfigured, catches its own errors and cannot fail a request. A malformed DSN disables reporting and says so once rather than refusing to start.

0.11.0 — 2026-09-08

Added

• The marketing site now offers "Dashboard" instead of "Sign in" when you already have a session. The site and the dashboard are separate origins, so the site could not previously tell; signing in now sets a small cookie on the site's domain that it reads to choose which link to draw.

Changed

• The cookie can be out of date — a session ended on another device leaves it saying you are signed in. That is accepted rather than overlooked: the only thing it changes is which link appears, and the dashboard decides for itself, sending an expired session to the login page, which is where "Sign in" led anyway.

Security

• The cookie's entire content is the character 1. Not a token, not a name, not an organization: a cookie on that domain is readable by any script on the page and sent with every request, so it holds only something already obvious to whoever is holding the device. It cannot be used to reach the API, the dashboard does not accept it as a credential, signing out removes it, and it expires after thirty days. The privacy notice covers it in full.
• The marketing site now sends a Content-Security-Policy along with HSTS, a referrer policy and a permissions policy, refusing to load a script, style, font or connection from anywhere but its own origin. The site still ships no client-side JavaScript beyond the three inline lines that read the cookie, and a test fails if a second script ever appears.

0.10.0 — 2026-09-07

Added

• status.bucker.io now leads with Bucker's own status. The root page checks the public endpoints — event ingest, the API, the dashboard and the MCP endpoint — and shows what came back: the HTTP status, how long it took, the URL behind each claim, and the time the check ran. The note for customers' own status page readers is still there, above it.

Changed

• The checks are made from outside. The page runs on different infrastructure from the services it reports on, holds no database client, and calls nothing that has to be alive for it to report that something is not.
• Background processing has no endpoint anything outside can reach, so it reads "No data" — not a green tick, and not a row quietly left out. That is the same rule customer uptime bars follow.
• The page is deliberately less than a status page: no uptime history, no incident write-ups, no subscriber notifications, no maintenance calendar, no SLA. Its footer says so rather than letting the layout imply otherwise.

0.9.0 — 2026-09-06

Added

• Public status pages, so you can tell your customers what your monitoring already told you: components, incidents, subscribers and a published page.
• A component binds to signals you already run — an uptime monitor, a cron monitor, your issue stream, release health — and derives its status from them, keeping the evidence that produced it, so the page can answer "why do you say that?" without leaving the product.
• Every uptime figure carries its window and the number of checks behind it, and when the window was not fully observed, how much of it was: "99.94% over 90 days, 129,431 of 129,509 checks".
• A day with no data is drawn as no data rather than as a healthy day.
• A manual override that contradicts your monitoring is published as one: the page shows your status, your reason, and what the checks report. Overrides expire.
• Incident updates are append-only. You can fix a typo at 03:00, and the fact that you edited it survives.
• Statuspage-compatible endpoints — /api/v2/summary.json and its seven siblings, including the exact status vocabulary — so bots, dashboards and Slack integrations written against Statuspage work unmodified. Alongside them: a native API carrying what that schema cannot express, RSS and Atom feeds, an embeddable widget, a README badge, and three read-only MCP tools so an agent can check a vendor's status before assuming a failure is its own.
• Email, webhook and Slack subscribers with double opt-in, per-component subscriptions, one-click unsubscribe, and a delivery ledger recording what was actually sent.
• Status pages are part of Community Edition. Attaching your own hostname is Cloud-only, because certificate issuance happens on infrastructure we operate and a self-hoster already serves their own domain. What shipped here was the verification half only — the two DNS records and the check that both resolve. Serving a page on that hostname came later; see Unreleased.

Changed

• The public page is a separate application that reads a pre-generated snapshot from object storage and never calls our API or database, so a total Bucker outage leaves it serving. When it cannot reach fresh data it serves what it has and says so on the page.

Known limitations

• This deployment cannot yet send mail, so email subscriber notifications are logged rather than delivered. Webhook and RSS subscribers work today.
• No multi-region probing: it needs probe workers deployed in more than one place.
• No on-call product — no schedules, no rotations, no paging. Status events route to PagerDuty, Opsgenie or Slack through existing integrations.

0.8.0 — 2026-09-05

Added

• The dashboard and the marketing site now share one design layer — colour and surface tokens, a type scale, a radius scale, motion, and the components built on them — so the two stop disagreeing about what the accent colour is.
• Typography: Public Sans for the interface, Commit Mono for identifiers and the brand. Both are open-licensed and self-hosted, so no page requests a font from a third party.
• A mark, and the favicon, Apple icon, social card and in-page logo are all generated from its geometry rather than drawn four times.
• Link previews: site-wide Open Graph and Twitter card metadata, a canonical URL on every route, and a 1200 × 630 image built for the home page, pricing, the trust page and every documentation page.
• sitemap.xml, derived from the site itself rather than maintained by hand, with a test that walks the site independently and fails if the two disagree, plus a robots.txt naming it.
• A 404 page inside the site's own chrome.
• Privacy, terms and DPA pages. They state only what can be checked — what is stored, the retention defaults, that no payment provider is connected, that no sub-processor is contracted, and that no certification exists.
• llms.txt listing every published page with a one-line description, and a security.txt. Its security contact is the trust page, because there is no security mailbox yet and a contact address that bounces is worse than none.

Known limitations

• The apex is not cut over: bucker.io and www.bucker.io still redirect to the dashboard, and the marketing site has no deployment of its own.
• There is no security mailbox and no named operating entity. The legal pages and security.txt say so rather than inventing either.

0.7.0 — 2026-09-02

Added

• A readiness endpoint on the API and the MCP server that actually queries the database and answers 503 when it cannot reach it. The existing health endpoint remains a liveness check, and deployment health checks now point at readiness — the two answer different questions, restart versus route, and collapsing them turns a database blip into a rolling restart.

Changed

• Bucker is deployed and taking traffic: the API and the workers run continuously, the MCP server scales to zero between uses because agent traffic is bursty, and the dashboard runs on its own host. The whole load path was exercised against the real deployment — an event in, a 200 back, a worker claiming the job, a grouped issue, and an analysis out the other end.
• The database moved to a PostgreSQL 18.6 server reached over mutual TLS, with vector support available.
• The test suite can now be pointed at a remote database over mutual TLS as well as a local one. It is much slower over the network, so it is a compatibility check rather than the everyday loop.

Fixed

• Four background sweeps counted the wrong thing and reported success while doing nothing: each bounded its pass by the number of candidates inspected rather than the work completed, over an ordering whose head never cleared. Orphan blob reclamation stopped reclaiming, cold archive expiry stopped expiring, proof-ledger checkpointing covered only the same first organizations forever so later tenants were never checkpointed, and the alert pass resumed on a timestamp without the tiebreaker its own ordering used — so a burst of issues sharing one timestamp was skipped permanently and no alert ever fired for them.
• Three schedulers had lost the guard that stops a pass running on top of itself while keeping the comment promising it. For alerts this was customer-visible: overlapping retry passes re-sent the same alert and incremented the attempt count from a stale read, so the maximum-attempts limit never tripped and nothing was ever marked dead.
• Six deployment defects, none of which announced itself: an unrecognised build key meant every service built the same image, so the API came up running the dashboard; a liveness check pointed at a URL that answers with a redirect, and the platform counted that as a failure and suspended the app; the compiled output could not resolve its internal imports; the startup check demanded a signing key of services that do not sign, crash-looping the workers; the ingest hostname was unset, so every DSN the API handed out pointed at localhost; and the build context was 9.9 GB for want of an ignore file.
• The documented feature status understated four things, which is the direction that gets working features rebuilt: the dashboard has login, a real issue stream and an approve button; the remediation worker is started by the worker entrypoint; the MCP server exposes 20 tools, not 17. One correction went the other way — the OpenAI model provider can be selected but does not work.

Security

• Production refuses to start with the console email provider unless that is stated deliberately. It prints the message and reports success, so a password reset would land in the logs while the user waited and nothing went red.

0.6.0 — 2026-09-01

Added

• S3-compatible object storage, working against AWS, Tigris, R2 or MinIO, with listing that follows continuation tokens so orphan-blob reclamation can reach past the first thousand objects. Storage selection is explicit — filesystem, memory or S3 — and an unrecognised name is refused rather than guessed.
• A production readiness check. Every service now proves its configuration before it binds a port or claims a job, and reports every problem at once rather than one per deploy cycle.

Changed

• Production refuses to start on local-disk storage unless the deployment states that it really is one machine with a persistent volume. The API writes an event blob and the workers read it back by key; on two machines with two disks, every event above the inline size limit resolves to nothing, with no configuration error to point at.
• Two documented storage bucket settings that no code ever read were removed, along with their entries in the development stack.
• Six configurable provider seams — email, push, sandbox, model, embeddings and storage — previously hand-rolled the same selection, caching and test-injection machinery. There is now one mechanism, with each seam declaring only its own policy for what happens when the selected provider cannot be built.

Security

• Rate limits on login, MFA verification and password reset were declared but never applied. A plugin ordering problem meant every one of those paths was served by the global 1000-per-minute ceiling instead of 10 per minute. Nothing failed and nothing logged; the only visible symptom was the limit reported in the response headers. The limits now apply, and a test asserts the header on all six paths so a future reordering fails loudly.
• Forwarded client addresses are no longer trusted unconditionally. The per-IP limits on the credential endpoints are keyed on the caller's address, so trusting the whole forwarded chain let a caller choose their own rate-limit bucket — removing the defence against credential stuffing and MFA brute force — and wrote an attacker-chosen address into every audit record. The proxy topology is now stated explicitly, and production refuses both an unset value and "trust everything".
• Signing keys are required in production. Without them each process generated its own ephemeral keypair, so a second instance rejected the first instance's tokens and the public key served depended on which instance the load balancer reached.
• The encryption key for stored MFA secrets must be present, at least 32 characters, and not the placeholder from the example configuration.
• The API and app URLs must be set and must not be localhost: they are the token issuer and the CORS allowlist.
• The API now sends a deny-everything Content-Security-Policy, since a JSON API serves no scripts, and the dashboard sends a same-origin policy plus content-type, frame, referrer and permissions policies and HSTS. Neither sent any security headers before.

0.5.0 — 2026-08-29

Added

• A public verifier, no sign-in required: paste a proof bundle and every claim is re-derived from the evidence in the bundle, in your browser. The pasted JSON never leaves it. The verdict reads "Self-consistent", not "Verified", because the page does not check the signature — and that scope line sits above the input rather than in a footnote.
• bucker-verify gives the same verdict at a terminal. The browser build is a thin adapter over the same shared logic, and a differential test replays every fixture against the CLI across ten over-claiming mutations, comparing findings rather than a yes/no.
• A public transparency register: deployment-wide miss rates — rejected patches, in-window regressions, prompt-injection trial results — with inclusion and consistency proofs, and no route to edit, delete or retract a published snapshot. When no log is being operated, it says so instead of dressing an empty log as a running one.
• Per-organization verification numbers: verified-fix rate, repro-first-fail rate, in-window regression rate and reversal debt, each beside its sample size, each null rather than zero when there is nothing to divide, and each labelled lifetime because no rolling window is computed.
• A witness onboarding kit — documentation and a containerized reference co-signer — with witness and receipt management in settings.
• A free tier: 50,000 events a month, one included verified fix, no card. Included credits do not expire.
• A public site with pricing that reads the same plans endpoint the product enforces, documentation and this changelog rendered from the repository's own files, and no client-side JavaScript on any page.
• A trust page that allows a claim only if a reader can go and check it, answering thirteen vendor-questionnaire questions including the ones whose honest answer is no, and a SOC 2 readiness map that lists a control only where a named file implements it and a named test exercises it. No certification and no audit is claimed.
• Every audit record carries one plain-English sentence above the raw action, and a declined action is described by why it was declined, never by the verb attempted.

Fixed

• Personal data reached a third-party model. Fix-authoring prompts were built from stored issue text, which retains emails and IP addresses on purpose, and the additional scrub applied on the analysis paths was missing here. Fixed, with a regression test confirmed to fail without it.
• Agent sessions merged into a single row. The exemption that preserves high-entropy identifiers matched whole attribute keys, so a namespaced conversation id was redacted and every affected session shared one placeholder. Fixed by matching the final segment of the key.
• Three home-page disclaimers had been made false by the verifier shipping. Corrected together with their limits, rather than flipped into a claim.

Security

• A per-fix provenance certificate was refused rather than built: it would be signed with a shared secret, so anyone able to verify one could forge one.

Known limitations

• No payment provider is connected. The billing API reports payments as unconfigured, and nothing has ever charged a card. An upgrade against a provider's test mode was never executed, so the money path is proven against a recording transport rather than a provider.
• The site had no deployment of its own, so bucker.io did not yet serve it.

0.4.0 — 2026-08-29

Added

• Failures in your AI application arrive in the same issue stream as your exceptions — grouped, deduplicated and given a lifecycle. A tool-schema violation that returned HTTP 200 becomes an issue with an occurrence count, an assignee and a status, not a trace you have to go looking for.
• A dedicated AI area per project: sessions as a step tree, prompt versions, evaluation runs, judge scores and cost.
• Any span cross-links to the prompt version that produced it, so a regression points at the change that caused it.
• Cost is reported per session and per step, including spans that are not model calls.
• Session replay plays inside issue detail. You can scrub the recorded stream and seek directly to the moment a root-cause claim refers to, and a transcript toggle shows exactly the text the AI was given, after masking — what the agent read is what you read. What replay captures, masks and scrubs is documented rather than asserted.
• Structured logs: virtualized, filterable from the URL, with log bodies rendered as quarantined data rather than trusted markup.
• Issues link straight through to their trace waterfall. The paste-a-trace-ID workflow is gone.
• Cron and uptime monitors have a full interface — list, editor, run history, check-in snippets and latency history. Uptime rates are always shown with their denominator.
• User feedback has a triage view, with every visitor-supplied string rendered as data.
• Approval and evidence cards render as interactive UI inside Claude Code and other MCP clients that negotiate for it, instead of a wall of JSON, and a packaged quickstart takes you from nothing to approving a sandbox-verified fix without leaving your editor.
• An integrations catalog with server-side OAuth and write-only secret fields: a credential you paste can never be read back out of the interface.
• A billing tab showing your plan, current usage, the AI lane, and a receipt for every event that was sampled away. It shows no checkout, because payments are not wired yet, and says so rather than presenting a button that fails.

Known limitations

• The Modal sandbox provider, mobile push notifications and the packaged end-to-end demo kit did not ship and remain open.

0.3.0 — 2026-08-29

Added

• Root-cause analysis is presented as ranked hypothesis cards, each with an explicit confidence value and links to the exact signals it rests on. Every claim cites its evidence.
• A blast-radius panel showing affected services, releases and users, with severity.
• An honesty panel that surfaces the model's own self-critique rather than hiding it.
• "Copy for agent" hands the whole investigation to your coding agent as a token-budgeted bundle.
• Triage runs ahead of you: a background sweep means the issue list already reads "RCA ready · 0.82" when you open it, with nothing to click to start the analysis.
• Trust ladders per issue category — analysis only, then draft PR, then automatic attempt — with promotion offered and never taken automatically, and demotion applied automatically. Alongside them, a ranked autofix queue, budget controls, and a log of every decision.
• Slack: install via OAuth, receive alerts as Block Kit messages, and approve a fix from Slack — the approval lands on the same certificate chain as one made in the web app.
• Alert rules, channels and history, with test-fire and undoable deletes.
• Release list and detail with crash-free charts. When health data is unavailable, the interface says so as a first-class state rather than rendering an empty chart.
• Settings became a real area: members and invites, teams, projects and DSNs, and SSO.
• Saved views, a virtualized issue table with persisted columns, and a pinned shared view that survives a refresh and is shareable as a URL.
• Grouping review: a merge queue that shows its rationale, and exact unmerge.
• Suspect commits on issue detail, plus repository and code-mapping settings.
• Undo as a convention — destructive triage actions commit on a delay and are reversible with u.
• Daily digest emails with a signed one-click unsubscribe and durable opt-outs.
• GenAI instrumentation for JavaScript: a platform-neutral capture core plus adapters for OpenAI, Anthropic, the Vercel AI SDK and LangChain.

Changed

• Every "coming soon" placeholder in the product is gone.

0.2.0 — 2026-08-29

Added

• Shareable URLs. Filters, tabs, cursors and time ranges live in the query string, so a pasted link reproduces the exact state you were looking at.
• Organizations and projects in the path, with a keyboard-operable switcher. Old links keep working.
• A keyboard-first shell: a command palette, g-sequences for navigation, and cursor triage over the issue stream with j/k/x/r/a/Enter. Triage is fully operable without a mouse, and ? shows the cheatsheet.
• Live updates. Investigation timelines and fix-run progress stream over SSE and resume after a disconnect. When the stream cannot be held, the interface degrades to polling and tells you it has. New issues are held behind a pill rather than reflowing the page under you while you read.
• The investigation timeline: an append-only record of what the AI did, replayable rather than summarized.
• A blast-radius endpoint, composed from data already being stored.
• A rebuilt data layer, an expanded component kit including a virtualized data table and a mobile drawer, and real error and loading states on every route.
• The dashboard reports its own errors through the browser SDK.

Changed

• The product is called Bucker everywhere.

0.1.0 — 2026-08-26

Groundwork users never see directly, recorded because claims made elsewhere depend on it being true.

Added

• End-to-end browser coverage, including an accessibility sweep and a screenshot harness. Its first live run immediately caught a server-rendering bug on the main path.

Changed

• Continuous integration enforces the build and coverage. A shell fallback that was swallowing failures is gone.
• Test isolation moved to a database per package, so the suite runs in parallel honestly.
• 71 oversized source files were split into reviewable units by an order-preserving tool and renamed for their contents.
• The translation catalog was split into one file per namespace.

Security

• Database transport fails closed: a plaintext connection to a remote host is refused rather than silently accepted.