Go JavaScript TypeScript Python C C++ Swift C# Java Perl PHP SQL Rust Zig Ruby Kotlin Dart Scala R Shell Lua Objective-C Lisp Haskell Assembly Visual Basic Pascal Fortran COBOL Ada Julia Groovy Clojure Elixir Erlang F# PowerShell Racket OCaml Nim Crystal V Solidity Terraform Make Dockerfile YAML Vue Svelte Delphi 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 license-free.

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 can clone the repo and verify the chain without your private key or a paid license.

Download the signed binary and activate the license once per device. Proof creation switches on immediately, 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.

Command counters, and nothing else. We do not need your code, arguments, paths, bug titles, repository names, or proof records to license a tool. The point of bug is that your evidence stays with you. Air gapped deployments check in never and send nothing.

Because there are two lease shapes, not two products. The figures are public: no Contact Sales gate, no negotiation, and no discount cycle. Standard stores a local signed lease; when bug checks in, it sends subscription status and anonymized command counts, and the server returns the next check-back date after the billing window should clear. Enterprise costs twice as much because it buys a long signed offline lease for one to five years, so regulated and air gapped machines can keep creating records when the network is not allowed in. It is not a feature paywall.

All sales are final. There are no trial periods, refunds, credits, or prorated cancellations. We would rather say that plainly here than have you find it out after a charge. The reason is that everything needed to judge bug is public before you spend anything: the full workflow, the commands, the benchmarks, the licensing terms, and the price. If you are on a monthly subscription you can cancel at any time and the next charge will not be taken, though the current period is not refunded. 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.

Standard is fifty dollars a seat, billed monthly. After activation, bug keeps a local signed lease and receives the next check-back date after the billing window should clear. Enterprise 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. A seat is a person, not a computer. Put bug on up to five of your machines under one seat and each holds its own offline lease. Maintenance work happens on laptops, desktops, build hosts, and incident machines; the pricing should not punish that reality.

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.

Your evidence never needs one. The proof lives in the repository, so there is no external database to trust when someone asks what happened. Standard proof creation uses a local signed lease until its server-issued check-back date; Enterprise proof creation can run offline for the full prepaid term.

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.