Alphabet++ αlphabet++

00 The task

A failing build, restored — step by step.

An automated dependency update opened a pull request that broke the build: a testing library had been bumped to a version another library refused to work with. Below is every step the agent took to fix it, in order, with the real time and duration of each sara command, read from sara’s own usage log.

The striking part is the order. The very first thing the agent does — before it has even read the failing build — is a single command, sara begin, that opens the task, looks up the fix and sets the pass/fail check. Everything after that hangs on a task that already exists.

→ The lookup, up close

How the recall already knew the fix.

The one surprising beat of the run is that the fix was known before the build was read. That was not luck: it is what sara recall does, folded inside begin. Given the new task’s own words, it searched every saved note and returned a short, ranked shortlist — in fifteen milliseconds.

This is the actual shortlist it returned, strongest first. The left column is each note’s label; the tags show how it matched and how strong it is.

1. m529

   by meaning The same failure, from the previous pull request.cosine 0.45strength 2.1

   The closest match by meaning: the identical dependency conflict, fixed the same way one pull request earlier. Ranked first because it is both recent and often reinforced.

2. m228

   by words The root note of the whole failure family.canonicalstrength 2.0

   The one note every recurrence points back to: it names the cause in general and the exact fix — pin the testing library back below the breaking major. This is the note that made the answer known.

3. m517

   by words The same failure again, an earlier pull request.strength 2.0

   Another recurrence of the same fault, kept on the list as corroboration: the pattern has happened before, more than once.

4. m215

   by meaning A different, but related, build failure.cosine 0.46strength 2.0

   Close in meaning — another red pipeline over package versions — but a different cause. A near-miss the ranking keeps, and keeps below the exact hits, so it informs without misleading.

5. m6

   by words General background about the service.strength 1.5

   Weakly related context, ranked last. Present for completeness, not weight — the lower strength keeps it at the bottom.

That is the whole trick. Recall is not a cache of one answer; it is a ranked memory that returns a small family of prior notes, strongest first — so the exact fix and the canonical note that explains it arrive together, before the first file is read.

→ Another run

A new capability, founded — step by step.

The first run mended something broken. This one builds something that was never there: a request to add a new domain event and an endpoint to close a case. There is no fix to look up — and yet the opening move is identical. Before a single new file exists, the agent runs one command, sara begin, and the whole charge hangs on the task it creates. Every time and duration below is read from the same run’s log.

What changes is what the memory returns. Here recall does not hand back a fix — it hands back the pattern to imitate: how this codebase already adds an event-sourced change. And “done” is written as three pass/fail checks before any code is typed, so the build has a target from its first line.

1. 12:01:26

   I It starts with one command

   There is nothing to fix and nothing yet to read. The first act is still to open the task — new ground gets an anchor before it gets a line of code.

2. 12:01:26

   sara beginopens the taskrecalled the pattern

   72 msexit 0

   One command opens task #48 and, folded inside it, looks up the saved notes. It does not return a fix — there is none — but it surfaces how this codebase already makes a change like this: as an event. The template to follow exists before the agent has written anything.

3. 12:01:38

   II Lay the ladder

   Before any building, the agent writes down the ordered phases of the rite — recall, research, declare the checks, plan, build, witness — so the work has rungs to climb.

4. 12:01:38

   sara check×10 steps

   ~120 ms eachexit 0

   Ten ordered steps are laid down in one burst — the shape of the whole run, written before the first one is worked. The task now knows not just what “done” is, but the path to it.

5. 12:02:03

   III Recall the pattern, then read the code

   Deepen the lookup, bind what it finds onto the task, then open the real files it points at to confirm the shape.

6. 12:02:03

   sara recall×2 queries

   8 ms & 17 msexit 0

   Two targeted lookups — how a domain event mutates the aggregate, and how a command, handler and endpoint are wired — each answered in milliseconds from the saved notes.

7. 12:02:18

   sara annotatekind: finding×3

   43–47 msexit 0

   Bind the recalled prior art onto the task: the event-sourced mutation pattern, where backoffice endpoints live and how they are authorised, and that the tests assert real domain state, not just an HTTP code. The pattern now travels with the task.

8. read Open the closest existing template.

   Read the existing “update a case” event, command, handler and controller — the nearest thing already in the codebase — to copy their exact shape rather than invent one.

9. 12:03:46

   sara annotatekind: decisionkind: risk

   18–22 msexit 0

   Commit to one road: a new event plus a command, handler and endpoint that mirror the update path — everything flows through the event, no bespoke status write. The one risk — the acceptance tests need a database container — is written down, not left to surprise.

10. 12:04:11

    IV Declare “done” before building

    Three pass/fail checks, each with a command that proves it, written while the code is still empty. This is the target the build will be measured against.

11. 12:04:11

    sara checkkind: acceptance×3

    13–16 msexit 0

    The event exists and sets each terminal status; the endpoint closes a case and the whole solution builds clean; the handler emits and dispatches the event. Each is written with a runnable check, so none can be waved through.

12. 12:04:19

    V Build, smallest whole first

    One slice per check, the smallest complete piece first — the event — then the command that raises it, then the endpoint that calls it. Each slice is proved before the next begins.

13. 12:05:20

    sara step_doneslice 1 — the event

    24 msexit 0

    Add the new case-closed event and its unit test: constructing it with a non-terminal status is rejected, and each terminal status sets the aggregate correctly. Nine tests pass, none fail.

14. 12:05:58

    sara step_doneslice 2 — the command

    25 msexit 0

    Add the command and its handler, mirroring the update path: load the case, raise the event, dispatch it. Three handler tests pass, none fail.

15. 12:07:50

    sara step_doneslice 3 — the endpoint

    24 msexit 0

    Add the endpoint that closes a case by its id, its request body and an acceptance test, with the same authorisation and error handling as its template. The whole solution builds in release with zero warnings and zero errors.

16. 12:10:43

    VI Witness — prove every check

    One command runs all three checks’ own proofs at once. Only then are they marked met, each with its evidence.

17. 12:10:43

    sara validateall 3 checks

    5.5 sexit 0

    Run the verify command behind every acceptance check in one go — the event tests, the handler tests and the clean release build. They pass together, so “done” is proven, not asserted.

18. 12:10:59

    sara step_donekind: acceptance×3

    56–59 msexit 0

    Tick each of the three checks now that its proof has run, carrying the passing tests and the clean build as evidence. The new capability stands, and every claim about it is backed by a command that passed.

* Every time, duration and exit code here comes from the record of one real run on 2026‑09‑14. The dashed steps are the file reads and writes the log could not see, reconstructed from the record of the session.