Answers to common questions about tooloutbox: is it hosted, what happens on a crash, can a write apply twice, what "unknown" means, how to re-attest past runs offline, and whether the tests touch anything real.
No. This is pre-release engineering. The local core and the crash/restart acceptance gate are implemented and tested, and you run them yourself from a clone. A hosted history dashboard is planned only after authentication, isolation, and retention/deletion tests land. No paid plan is active.
What happens if the process crashes in the middle of a tool write?
The intended write is persisted to a write-ahead log before the caller is acknowledged, so the intent survives the crash. On restart the engine recovers any write that persisted but did not commit, probes the adapter to learn whether the effect already happened, and reconciles it before any retry rather than blindly re-applying.
Can the same write be applied twice across a crash and retry?
No. Writes are applied at most once. The canonical fingerprint is written before the external effect and checked before any retry, so a replay cannot double-apply. This at-most-once guarantee is proven by a regression test against more than one adapter.
What does an "unknown" verdict mean, and why not just guess?
A verdict is unknown when the adapter cannot be probed, so whether the effect happened is genuinely uncertain. tooloutbox reports that honestly as a third verdict distinct from pass and fail, and the CLI exits with code 3 to match. It never guesses pass or fail to look more certain than it is.
How do I verify past runs without re-running them against the adapter?
Run node src/cli.mjs verify on a persisted receipt store. It re-attests the prior runs offline from the durable log alone — no adapter and no re-apply. Each record must still hash to its recorded fingerprint, which makes the store tamper-evident: a modified or missing receipt re-attests to fail.
Which adapters are supported today?
Two sandboxed adapters: an in-memory adapter and a mocked HTTP/webhook sink with its own delivery and payload caps, a URL allowlist, and HMAC-signed payloads. Both have documented limits and an idempotent apply/probe path, and the crash/restart acceptance gate passes against each, which is how the contract is shown to generalize beyond one adapter.
Does running the acceptance suite touch a real database or external service?
No. The suite runs entirely against local fixtures. The crash is a deterministic injected signal, not a real fault, so the acceptance gate is reproducible in CI with no real datastore, no network egress, and no real fault injection.
What does it cost to try it?
Nothing. The local fixture and CLI trial is free and needs no account. Any paid hosted-history or team-CI offer is a future hypothesis, and billing stays disabled until the implementation and test gates for it pass.