Obel CLI

Obel wraps a command, watches it run, and captures the failure when it exits unsuccessfully. The result is a local folder called a failure capsule.

A capsule is designed to preserve the evidence around a broken command: what ran, what printed, how it exited, which project it came from, and what environment it happened inside.

The first principle is simple: debugging context should not disappear when the terminal scrolls away.

The CLI should stay small enough to remember. These commands define the current product shape:

A failure capsule is the core Obel object. It is local-first, inspectable, and structured so humans and tools can both read it.

Known capsule structure:

Obel captures enough context to explain and replay a failure without turning the user’s machine into a surveillance surface.

Obel is local-first by default. Capsules are stored on the developer’s machine, and environment data should be secret-redacted before it becomes part of a report.

The tool should prefer explicit user action over background collection. No account, hosted service, or surprise upload should be required for the CLI workflow.

Obel should not remain just a CLI. The long-term direction is a local-first failure intelligence system: Sentry-style debugging, but self-hosted, capsule-based, and without surprise billing.

The strongest next step is an Obel Dashboard where failures can be viewed, searched, replayed, assigned, explained, and fixed.