At the workbench.

Start with a bounded request

Say what should change, what must stay intact, and how you’ll know the result is right. Explicit acceptance criteria give the author and its independent reviewer the same thing to check.

Fix the parser’s empty-input case.

Done when:
- Empty input returns a named error.
- Existing valid input still parses.
- The regression test passes.

Don’t change the public API.

You don’t need to prescribe every tool call. You do need a clear boundary around the outcome.

Follow the work

1. Inspect

   Read the repository and relevant instructions before choosing a change. Code intelligence can help locate definitions and references.

2. Act

   Tools run through Ribhu’s approval path. A plan, a tool being available, and permission to change the workspace are different things.

3. Verify

   Run checks that bear on the request. A successful build supports a build claim; it doesn’t establish that a particular installed system behaved correctly.

4. Review

   For code-editing turns, the documented witness reviews the request, stated criteria, completion claim, diff and verification tail in a fresh session. It is a bounded second opinion, not a substitute for tests.

Read the record

“Finished” is something to examine, not a magic word. Receipts and the task ledger preserve what happened; verification checks the record and whether changed files still match it.

ribhu verify --last

After an interruption, inspect what actually landed before continuing. The recovery design distinguishes recorded completion, an interrupted call and an unknown effect. It does not turn uncertainty into permission to replay work.

Go one layer deeper