Crash anywhere, resume exactly
Everything is an event in an append-only log and a Markdown artifact, committed to git inside the project. karigor resume replays it to the exact state; karigor explain turns it into a story.
How it works
A real software process, run by a kernel that does not take an agent’s word for anything.
The kernel is small and deterministic. Agents do the thinking and the typing; the kernel decides what happens next, and only on evidence.
- 01Choose the processA selector picks a process template and a target profile for the idea. An estimator offers three cost tiers, and you pick one, once.
- 02Run the phasesPhase roles produce artifacts: the product owner writes the spec, the architect the design, the planner the backlog, the releaser the release.
- 03Build in a real workspaceThe developer works in a real git repository, one backlog item per commit. Its edits stay inside the workspace; network, privilege and publishing commands are denied.
- 04Pass the gatesEvery transition needs gates: real tests, lint, build and security scan, or a reviewer or skeptic verdict that must cite evidence. Failures walk a ladder.
- 05Release carefullyEvery journey runs again on a brand-new database. Then a preview starts, is checked over HTTP, a rollback is verified, and only then is it promoted. A promotion that fails goes back to what was live.
- 06OperateApp errors, downtime, vulnerable libraries and your feedback become work items. The maintenance template triages, fixes, verifies and releases again.
Thirteen gates. Each one needs proof.
A judged verdict fails only on blocking objections. Minor suggestions are recorded, not enforced, and a verdict with no citations is a fail.
| Gate | Kind | What it proves |
|---|---|---|
| schema-valid | mechanical | Every artifact an agent produced matches its schema. |
| budget-ok | mechanical | The work so far fits the tier you chose. |
| spec-complete | judged | A reviewer finds the spec complete enough to design and build from. |
| architecture-sound | judged | The design names the roles and modules and fits the spec. |
| tests-pass | mechanical | The project’s real tests run green. |
| lint-clean | mechanical | The code passes the linter. |
| build-succeeds | mechanical | The production build completes. |
| security-scan-clean | mechanical | No leaked secrets and no vulnerable dependencies. |
| diff-matches-spec | judged | The change does what its backlog item and the spec say. |
| skeptic-review | judged | A skeptic, who can only object, finds no blocking problem. |
| journeys-pass | mechanical | Each kind of user’s main jobs work in a browser, at phone and desktop size. |
| preview-healthy | mechanical | The preview serves the new build, not a login page or the old one. |
| rollback-verified | mechanical | Going back to the previous release actually works. |
When something fails
Failures walk a ladder, never a loop.
A retried role is shown exactly why it failed and what it produced last time. Dropped or parked work is reverted, so it never ships.
rung 1RetryWith the objection quoted and the last attempt shown.
rung 2Send back or shrinkReturn to an earlier phase, or cut the item down to what can pass.
rung 3ParkSet the item aside and revert it. The rest of the build carries on.
rung 4StopHalt the project and say why, in plain words. Nothing broken goes live.
Process templates
The right process for the idea.
Each template is a YAML file: which phases exist, which roles run in each, which gates guard each transition, and what to do on failure. You can write your own.
Writing a process templateShort sprints with phase gates. The default for most products.
Most ideas: built a few backlog items at a time, each sprint gated.
- specify
- design
- plan
- build (sprints)
- release
Waterfall. One pass through specify, design, plan, build, verify, release.
Small, well-understood ideas, like the family shopping list.
- specify
- design
- plan
- build
- verify
- release
Resolve one risky unknown with a throwaway spike, then build iteratively.
Ideas that hinge on one thing nobody is sure will work.
- specify
- spike
- design
- plan
- build (sprints)
- release
Builds the next stage of a released product on top of what is live.
Run by karigor grow, once stage 1 is live.
- design
- plan
- build
- release
Entered from a production signal. Triage, fix, verify, release.
App errors, downtime, a vulnerable library or your feedback.
- triage
- build
- release
Secrets stay where the app runs
Karigor makes secrets like a signing key itself and asks in plain words for what only you can provide. Values go only to the host’s sensitive settings or a private file; Karigor’s own records keep names, never values.
Every decision is correctable
Nobody is asked a technical question, but every assumption is recorded. Change any of them in your own words; once the app is live, the change becomes a work item and a fix round.
Self-host it safely
Run the chat UI from Docker to reach it from your phone. It refuses to listen beyond localhost without a token.