GoJavaScriptTypeScriptPythonCC++SwiftC#JavaPerlPHPSQLRustZigRubyKotlinDartScalaRShellLuaObjective-CLispHaskellAssemblyVisual BasicPascalFortranCOBOLAdaJuliaGroovyClojureElixirErlangF#PowerShellRacketOCamlNimCrystalVSolidityTerraformMakeDockerfileYAMLVueSvelteDelphi Git-native proof your bug fix holds.

No. Trackers are where teams discuss, assign, prioritize, and remember work. bug lives beside git because the repair has to be verified where the code, test, commit, and future maintenance burden actually live. Keep the tracker; use bug when trust needs verification.

bug proves that closure was earned. PROVABLY CLOSED means the issue was described, the red test demonstrated the defect, the green fix changed that outcome, the commits back the transition, and the repair explanation is concrete enough for the next maintainer. It is a standard backed by repository evidence, not a status someone typed.

Red is the moment the team proves the bug is real. Green is the moment the team proves the repair changed the outcome. The value is not ceremony; it is preserving the transition from broken to fixed so a reviewer, agent, auditor, or future maintainer can verify the story later.

It keeps the thread in the repository. A record can show who filed the issue, when red proof was captured, who captured it, which commit held that proof, which test output hash describes the failure, who later greened the fix, and which commit closed it. The second-order effect is less coordination tax: the Monday maintainer starts from facts instead of chat archaeology. The third-order effect is cultural: handoffs become transparent without turning into blame, because the record shows the work path, not just the final success story.

Start in the repo you already have. bug initializes beside your code, respects existing files, and can begin audit-only before you enforce anything. That matters because teams are tired of tools that demand a migration before proving value. bug earns trust by showing where closure is already weak.

Without the failing-before state, a passing test can be theatre. Red proof answers the first maintenance question: did we ever prove the issue we claimed to fix? It protects the team from polished fixes, agent guesses, and tests that were written after the fact but never caught the original defect.

Outages are when standards are easiest to abandon and hardest to recover. People are tired, customers are angry, managers want updates, and a quick patch can quietly become tomorrow's bigger incident. bug gives the team a narrow path through the pressure: describe the defect, capture red proof, land the repair, prove green, and leave the record behind so the postmortem starts from facts instead of panic memory.

No. Real companies do not maintain one tidy language forever. bug is built for mixed repositories and the hero count is generated from the supported language list, so the page cannot drift from the product. Go currently gets the deepest parser-backed treatment, but the value is one maintenance habit across the stacks your company actually has.

No. bug works hand in glove with git because git is already where engineering time is recorded. Branches, commits, pull requests, and reviews stay central. bug adds the missing defect proof layer so maintenance history is not split between code truth and ticket folklore.

CI proves a command passed. It does not usually prove the issue was described well, that the right regression failed first, that the same defect was fixed, or that the next maintainer has enough context. CI is execution. bug is closure evidence.

It verifies records, tests, current Git history, certified writer proofs, signatures, and revocations. Then it names what is proven, half fixed, stale, malformed, open, parked, or unproven. Plain audit is read-only, and the right to keep reading and auditing what you already produced survives your subscription on the machines it already covered.

Half-fixed means there is smoke but not enough proof. Maybe the team has a green run but no red failure, a named test that does not match the bug, stale file anchors, or a repair explanation that would not help the next maintainer. bug makes that uncomfortable middle state visible.

Malformed means the proof record cannot be trusted yet. That is different from an unfixed bug. It means the evidence itself is broken: missing fields, bad paths, invalid IDs, broken references, or structure that would force a human or agent to guess.

Because maintenance happens in the repository. Tickets drift, teams reorganize, vendors change, and context disappears. A repo-local proof record moves with the branch, pull request, commit, review, and agent work that actually changed the system.

Because teams are mixed now. Humans need readable Markdown they can review in a pull request, hand to a maintainer, or show during an incident review. Agents need structured JSON so they can inspect state without scraping prose. Both point at the same proof instead of creating two separate stories.

It gives agents the same hard boundary as people. Each licensed device writes immutable signed claims instead of fighting over a shared file. Audit verifies every writer independently and refuses prose-only closure.

Agents cannot satisfy bug by editing a sentence, inventing confidence, or calling a passing command a fix. They have to describe the issue, attach the right files and tests, prove red, prove green, and leave a repair explanation that a maintainer can understand.

They bind each mutation to a device key certified by the license server. Red, green, and reattest claims also bind the bug, operation, commit, and proof hash. A teammate on your licensed machines can clone the repo and verify the chain without your private key and without an active subscription.

Download the signed binary and activate the license once per device. Proof creation switches on immediately, including on day one of the thirty-day free trial, then the license disappears into the background. Everything needed to run the first proof cycle ships with the binary, so there is no onboarding call to schedule. Reading, showing, verifying, and auditing existing records never needs a key, because your maintenance evidence is your repository data.

The routine license check-in carries five things and no more: entitlement status, the registered device identifier, the binary version and build hash, per-command counts since the last check-in, and crash, activation, and abuse-prevention signals about the binary itself. It never carries source, arguments, file paths, bug titles, repository or branch names, test output, or proof records. Attested and Archive custody is a separate authenticated path: bug uploads the signed proof selected for custody and its integrity metadata into encrypted tenant-private storage, never the repository or captured command output. Air-gapped deployments check in never and upload nothing.

Because there are three rungs of custody, not three proof workflows or a feature paywall. The figures are public: no Contact Sales gate, negotiation, or discount cycle. Solo keeps proof in your repository and receives a signed check-back date after the billing window should clear. Attested adds a countersignature and one year of encrypted tenant-private cloud custody, so someone outside your company can confirm the record we held. Archive retains the same signed proof for five years and adds a long signed offline lease for one to five years, so regulated and air-gapped machines can keep creating local records when the network is not allowed in. The binary manages its signing identity; customers do not provision a KMS, HSM, or separate uploader.

A trial, yes. Refunds, no. Solo comes with a one-time thirty-day free trial with every proof command switched on: start, red, green, and audit, on every machine your team uses, with nothing held back. We take a payment method up front so the subscription converts without interrupting your work, and nothing is charged during those thirty days. Cancel before day thirty and you are not billed at all. The trial is one per customer and covers Solo only, because the prepaid Archive lease is a prepaid offline term rather than a monthly subscription. After the trial converts, all sales are final: there are no refunds, credits, or prorated cancellations, and cancelling stops the next charge rather than returning the current period. We would rather say that plainly here than have you find it out after a charge. Everything needed to judge bug is public before you spend anything anyway: the full workflow, the commands, the benchmarks, the licensing terms, and the price. Your evidence is never held over you either way, because reading and audit keep working without a license and every record stays in your repository.

Solo is $69 US dollars a month for your whole team, however many people and machines that is, and the first thirty days are free. The trial starts the day you activate, runs on a card we do not charge, and converts to the monthly rate on day thirty-one unless you cancel first. After activation, bug keeps a local signed lease and receives the next check-back date after the billing window should clear, during the trial exactly as afterward. The prepaid Archive lease has no trial because it prepays one to five years so regulated or air gapped teams can keep proof creation running without reconnecting.

Creating new proof eventually stops. Reading does not. show, list, verify, and audit keep working on an expired or absent license because historical maintenance evidence must not become hostage data. Your proof outlives your subscription, and it would outlive us too.

One organization license. Solo, Attested, and Archive are flat prices for the whole team, with no per-person or per-machine multiplier. Each machine still registers and holds its own signed lease so a shared credential remains detectable without turning device count into the billing meter.

A revoked or expired lease stops new proof creation. bug does not delete records, rewrite history, or block inspection. Existing evidence remains readable and auditable on every machine.

bug proves the closure path: defect, red, green, explanation, commits, and certified writer. Witness preserves the wider quality run for outside review. Together they answer: was the bug repaired, and did the supporting checks really run?

Yes, as engineering evidence. Certification and recertification work asks whether real processes exist and operate over time. bug helps show how the organization maintains software: defects were described, assigned, red-tested, green-fixed, explained, dated, committed, and governed by the same standard whether the actor was a person or an agent. Handoff records also show continuity: the organization can explain how work moved between people instead of relying on one person's memory.

Recertification asks whether controls operated over time. If a critical service has one job for years, the evidence that matters is how the team kept that job reliable. bug is built for code plus time: who or what touched the record, when operations happened, what fix was claimed, which test failed first, which test passed after, which commits prove the transition, and what audit state the repository reports.

It should stay visible instead of being buried. Maintenance is not pretending everything is done; it is knowing what is open, parked, unproven, or unsafe to close. bug lets the repository tell that truth without turning uncertainty into fake completion.

No. It gives reviewers better facts. Humans still decide whether the fix is good, but bug makes the basic maintenance evidence structured, repeatable, and auditable before review becomes a judgment call.

The numbers come from the bug benchmark suite, measured on a developer machine rather than a server: go test ./internal/run -run '^$' -bench . -benchmem -count 3 on an Apple M1 Max. Start/report on a 10,000-bug inventory ran at 17.3 ms. Red and green first resolve and load the record at 1.7-1.8 ms and 2.5-2.6 ms, then the move bookkeeping measured 15.0-15.9 ms for the ledger and 26.1-26.3 ms for the index on a 5,000-bug inventory. Audit-shaped validation measured 17.1-17.5 ms for 200 open bugs and 120-122 ms for 300 closed bugs. The 10,000 concurrent writers proof wrote 97.656 GiB through Primitive Filestore at 448.78 MB/s and every destination SHA-256 matched the source; its exact commands, raw results, and CPU and memory profiles are retained under test_results.

Creating, reading, verifying, and auditing local proof does not depend on a proof server: the authoritative record lives in the repository. Solo uses a local signed lease until its server-issued check-back date. Attested and Archive use Off Grid only for the independently held encrypted copy, and Archive can create local proof offline for its prepaid lease term. If our custody service is unavailable, your repository evidence remains readable and verifiable.

A binary or repo edit alone cannot create certified proof. Each device generates its writer key locally; the server certifies only the public key, and audit verifies the certificate, device signature, Git ancestry, proof hash, and revocation state. The private writer key never leaves the device.