Concurrency tests against real Postgres fit inside the hour this Sekiban app took to build

Two borrow requests for the same book arrive together. Both handlers retrieve state, both get an available book, both pass validation, and both produce a BookBorrowed event. The handler validates against a state that was true at the moment it was read ^[16]. The published flow puts the resolution one stage later: after event creation comes conflict detection and persistence by Sekiban, and only then the projector and the query the UI reads ^[17]. Of the eight stages in that diagram, two decide whether a write is allowed, with one stage between them ^[22].

A Decider needs no code to connect to PostgreSQL ^[16], so Validate and Evolve can be exercised as pure functions. The conflict check at append time cannot be exercised without the store it appends to. The concurrency test therefore has to run against a real database, and in this project it did ^[12].

The Decider excerpt shows how the invariant is expressed. Validate is declared on BorrowedBookState and its body is a single throw of InvalidOperationException, "Book {state.BookId} is already borrowed"; Evolve is declared on AvailableBookState, takes a BookBorrowed event, and returns a BorrowedBookState carrying the LoanId and UserId ^[14]. No boolean field is involved: the state type carries availability, so a second borrow attempt is rejected by which method resolves ^[15].

The features the agent added map onto samples that shipped in the template. Borrowing and returning a book is enrolling and withdrawing with a capacity of one: Enrollment already covered enrolling in and withdrawing from classes, ClassRoom already had capacity, and Student already had enrollment limits ^[6]. The instruction leaned on that: read the three existing implementations end to end, treat them as the standard for the project, and "Do not introduce custom helpers, new abstractions, or shorthand syntax" ^[9][10]. It also told the model that if the existing approach could not meet the requirements, it should explain why, propose a change, and ask for confirmation before proceeding ^[11].

For the sub-hour figure to mean anything in another repo, that repo needs a feature slice of the same shape, running from UI through APIs and business rules to event persistence ^[7]. It also needs the consistency rules and verification scenarios written down before generation, as this project has them in docs/spec.md ^[8].

The author's case for the approach is legibility. The agent implemented the new business rules using the same Decider structure as the existing code, and keeping that structure consistent as features are added makes it easier for developers to know where to look for business rules ^[18]. "This is where I found the approach particularly useful for AI-assisted coding," the author wrote ^[19]. The available text ends mid-sentence at "Checking the current state alone doe" ^[21], so the concurrency scenarios and what they showed are not in it.