Trial 0025 — A CMS, a shop admin and a storefront on one database, over five releases (ADR 0068–0073)

Question: can an agent build a real, data-backed application with Hozu alone: a CMS plus shop back office, and the storefront that sells from it, against a real database that both share? And does the framework hold up when it changes under the apps, release after release, while the same agents keep working on them?

Answer (qualitative, two agents, one day):

• Both apps were built to the end without intervention, on 0.21.1, from create-hozu and the shipped guide only. They share one MySQL database: orders placed on the storefront went through their lifecycle in the admin, and stock moved in both directions.
• Eight upgrades (each app to 0.22, 0.23, 0.24 and 0.25) needed no hand edit to migrate. Each time hozu migrate rewrote 0 files and reported the IR equal; every change after that was the agent adopting a new form (on 0.23 the admin also re-ran hozu gen for its Go contract, as hozu check asked).
• The asks shrank from round to round. After round 1 the agents reported framework friction in back-office work of 20–30 % of their time (admin) and about 1.5 h of 5 h (storefront, its own estimate). By round 4 they mostly asked for tool details and ergonomics, plus structural limits that were declined on principle. In round 5 the one new feature they tried, keyboard shortcuts, showed four limits with one cause, and 0.26 redesigned it.
• Both agents would choose Hozu again for this kind of app. Both named the same limits: one machine per feature, parts that cannot cross features, how little a view can compute, and no global notice.
• Not measured: tokens, cost or correctness against a hidden acceptance. This is a record of what two agents did and said, and of what the framework changed in reply.

Setup

• Agents: two background Claude agents (claude-opus-5-5), started on 2026-10-08 at 01:29 (UTC), each from an empty folder:
  • admin: "a CMS plus an e-commerce admin back office" (~/Developer/hozu-trial-admin/admin);
  • store: "the public front end of a content site plus an online shop" (~/Developer/hozu-trial-store/store).
• Rules (both prompts):
  • Start with npx -y create-hozu@latest <name> --agent claude.
  • Learn Hozu only from the generated guide, npx hozu docs, CLI help and the installed packages. Do not read the Hozu repository or the other agent's folder.
  • No long-running servers: verify with hozu check, get, browse, call and build.
  • Every detail is the agent's: features, data model, routes, visual style and copy. Images come from picsum.photos, and all data is fake.
  • Build it all the way to done: "Do not stop at a skeleton or ask for confirmation".
• The shared database: three minutes in, a requirement update replaced in-memory data with a real database:
  • MySQL 8.4 in Docker, database hozu_trial, credentials in hozu-trial-shared/db.env.
  • The admin owns the schema and writes hozu-trial-shared/SCHEMA.md: every table, how the storefront places orders and decrements stock, and how to run the migrations. That file is the only thing the storefront reads from the admin.
  • The storefront keeps its own tables under a store_ prefix, and writes its requests to the admin into store-requests.md.
• Rounds:

• Who judged: the lead session (the owner's coordinator) relayed every release note and judged every ask against Hozu's principles. The owner approved each ADR. Each later round also told the agents what had changed.
• Data: both apps are git repositories (after round 4: admin 25 commits, store 14). The agents' transcripts stay untracked.

What was built

• How the admin worked: in round 1 the admin split the work across four sub-agents, each in its own copy of the app (articles and pages; taxonomy and media; products and inventory; customers, discounts and settings). It then merged them and verified again. Its note: merging was easy "because the lock is derived from the code", so there was no lock conflict to resolve.
• The Go service (round 2):
  • What moved: 10 effects. The order lifecycle (with restock in one transaction, SELECT … FOR UPDATE), the inventory with its ledger, and the dashboard statistics.
  • Size: 1 334 lines of Go plus 260 lines of tests, replacing 734 lines of TypeScript. The CSV export stays in TypeScript, because only JSON effects go remote. The contract hozu gen wrote was 656 lines.
  • What stayed in Hozu: access, Invalid and the output check.
  • Kept for comparison: the TypeScript version is the git tag ts-backend.

What was verified, per round

All results below are the agents' own reports. The lead did not re-run their acceptance; it re-ran only hozu check on both apps after round 4 (the table above). After round 5 the agents reported contracts 26/35 decisions (admin) and contracts 7/8 decisions (store), both with 0 errors and 0 warnings; the gap is a counting bug (C1 below), not missing contracts.

• A bug of the storefront's own, found in round 4: product and article cards "could not be clicked in a real browser" since round 1.
  • Cause: the full-card overlay (after:absolute after:inset-0) was on the heading, not on the link.
  • Why it hid so long: hozu get cannot see it. hozu browse clicked, reported nothing, and the step passed.
  • What changed: 0.25 made such a click fail the step (E1 below). In round 5 the store put the overlay back on the heading on purpose: the step failed in both modes, "what took me four experiments last time is now said in one line".
• The owner's manual test (round 5; the owner's, not the agents'): the owner used both apps in real browsers and found two problems that no agent run could see.
  • Safari could not sign in under hozu serve: the session cookie was Secure over plain http on 127.0.0.1, which Safari refuses. Fixed in 0.26.
  • Arc blanks the window on every document load, query-only changes included. A plain multi-page site without Hozu does the same, and Chrome and Safari do not. Documented, not worked around: a client router would reverse ADR 0043 I for one browser (ADR 0073 D).

What each round asked, and what was decided

Who: A = admin, S = storefront. The rows below are the asks that changed the framework or were declined explicitly; the ADRs list every item.

Round 1 (0.21.1 → 0.22, ADR 0069)

Round 2 (0.22 → 0.23, ADR 0070) and the Go service

Round 3 (0.23 → 0.24, ADR 0071)

Round 4 (0.24 → 0.25, ADR 0072 E)

In round 4, asked about the two round-3 refusals, the storefront said:

• allow narrowing fields: "low, I can accept the refusal".
• The untagged-cache diagnostic: "largely not needed any more", because hozu call site.revalidate --write now lists what it invalidates and refreshes.

Round 5 (0.25 → 0.26, ADR 0073 B, C)

The store also noted that the guide undersold current(shop, { category }): it works on query data inside ui.each, not only over a constant list.

How the upgrades went

• The storefront in round 2: the upgrade was "the best framework upgrade process I have used". Its one complaint, a one-line change summary, became bullets in 0.24.
• The admin in round 2: it asked migrate to point at code that a new form could replace (for example body:has( or session?.). That was not taken up.
• The admin in round 5: the release note pointed at a CHANGELOG that the installed packages did not contain; it learnt the changes from the migrate bullets and the guide's topics instead (C9 ships it).

The agents' verdicts (translated)

What changed in Hozu

The trial drove five releases. Each ADR records every ask with the decision and the reason.

• 0.22 (ADR 0068, ADR 0069):
  • one-shot commands exit, and app({ dispose });
  • server errors surface in onError, get and browse;
  • flash reports name their elements;
  • seed from a query, ui.dialog({ open }), fail('Forbidden'), signedIn narrowing, head with search;
  • plurals, rel, null in lists;
  • hozu docs database;
  • Go resolvers through remote().
• 0.23 (ADR 0070):
  • the canonical-URL and route-param bugs;
  • signed machine state for no-JS multi-step forms;
  • { ...search } in links, and narrowing for every access;
  • the Go path's call ids, per-effect fingerprints and named enums;
  • Internal error in production.
• 0.24 (ADR 0071):
  • sections are declared with current(route) instead of guessed;
  • descendant --select, endpoint tags in hozu call, migrate bullets;
  • the two refusals above.
• 0.25 (ADR 0072 E):
  • browse fails a click that lands on another element;
  • current(route, params);
  • class in --select output.
• 0.26 (ADR 0073 B, C, D; its main subject, one-command deploys, did not come from this trial):
  • keys moves from ui.send to the element it presses: a field is focused, a button or link is clicked, with no machine needed and aria-keyshortcuts written by the server;
  • the coverage summary and hozu why count a shared on once;
  • --select prints class last and cut; a covering element is named; --js both no longer repeats the arrival;
  • the CHANGELOG ships in @hozu/cli, and hozu migrate prints each step's entry;
  • from the owner's manual test: hozu serve signs in on Safari over http, and the guide says why Arc flashes.
• The lesson recorded in ADR 0071: accepting an ask as stated can be wrong.
  • 0.22's automatic aria-current answered the admin's ask. It misfired on the next-page link, and the narrower rule of 0.23 misfired on filtered lists.
  • What a section is belongs to the app. The owner's instruction for 0.24 was to judge asks by the framework, not to take them as given.
• Round 5's lesson (ADR 0073 B): four asks about one new feature (Mod+s, / to focus, a machine for every shortcut, final states) had one cause: a shortcut is "press this control", not "send this event". One redesign answered all four instead of four additions.

Limits

• Qualitative. No hidden acceptance, no held-out changes, no token or cost measurement, and no comparison framework. The numbers above are counts the agents reported (URLs, orders, stock, lines changed) and the line counts of the repositories today.
• The agents graded their own work. Their "verified" means their own hozu check / get / browse runs and database queries. The storefront's broken cards passed three rounds of its own verification.
• Time figures are the agents' estimates. The transcripts show about 50 minutes of wall clock from start to the first build's report for each agent, with the admin running four sub-agents in parallel. The storefront's "about 5 hours" and the per-item minutes are therefore not measurements.
• One model, one run, two apps. Both agents were claude-opus-5-5. They worked in parallel on one machine, against one shared database.
• The lead judged the asks, and the same session wrote this record. Each round's prompt also told the agents what had changed, which steers a retest towards the fixes.
• The framework moved under the apps. Retests show that a fix works for the agent that asked for it; they do not show that the fix generalises.
• Writes on a shared database: --js both wrote twice to the shared database, and test orders and edits stayed in it. Both agents report cleaning up most of them.
• Round 5's decisions are not retested. 0.26 changed the shortcut form after the agents' last run, so no agent has used keys on an element yet.
• Agent verification covers one browser family. hozu browse drives a Chromium-based browser against the in-process handler; the Safari sign-in failure and Arc's blank frames surfaced only in the owner's manual test in round 5.
• The managed instructions of the organisation shaped the form of every report (tables, three next steps), as in earlier trials.