Trial 0027 — The owner's real project rebuilt with Hozu (ADR 0080 B)
Question: can Hozu carry a real project the owner already runs, a booking and shop site for a beauty studio with a
Go API, its public site and its back office, to the same behaviour and a deploy, and where does it stall?
Answer (agents building on Hozu 0.27–0.29 from npm, claude-opus-5-5, against a local copy of the Go API):
Yes: both frontends were rebuilt, checked and deployed in containers.
Public site: 25 pages. At 390 and 1440 px, most pages differ from the Nuxt original by under 1 % of pixels, and
none by more than 2.05 %. It makes the same API requests per flow. 38 contracts cover its decisions.
Back office: 43 routes for two roles, every feature of the original (bookings, orders, members, inventory,
reports with charts, uploads, page editor). It has 51 contracts, and its API requests were matched against the
original's source.
Deploy: both ran from hozu build --target node images with docker run. A member, and a staff member, signed
in through native forms, and admin-only pages refused staff.
The walls were in the framework, and each was fixed in a release: 19 frictions on the public site (ADR 0083),
23 in the back office (ADR 0084), and 2 in the deploy (ADR 0085). Three were serious:
a fixed mobile menu drawn under the page (0.29);
an admin link shown to staff with no diagnostic, from a ?: inside a test (0.30);
containers that stopped at start because of dependency lists (0.30.1).
Not measured: people. The builders were agents. The owner set the goal and the parity standard: the public site
identical, the back office functionally exact.
Setup
Public site
Back office
Original
Nuxt (frontend-web-nuxt)
Nuxt (frontend-cms-nuxt)
Rebuilt in
2025-mori-hozu/web
2025-mori-hozu/cms
Standard
Identical: screenshots at 390 / 1440 px, the same API requests per flow
Functionally exact: every feature, field, permission and API request; the presentation may differ
Backend
The original Go API, unchanged, in local containers (Postgres, Redis), seeded with fake data
The same
External services
Email and object storage replaced by local stand-ins; no real key used
The same
Tool calls
About 185
About 365
Deviations kept on purpose
Where
Deviation
Why
Public
Toasts after a page change come from a ?notice= enum in the address
Every link is a document load; there is no global store (recipe since 0.29)
Public
JSON-LD only for the site; no title template
The head is a closed set (ADR 0043 D); recorded for after 1.0
Public
Booking draft kept in the server session
State across pages lives on the server or in the address
Public
Member history pages show data
The original showed empty pages: a bug there, fixed here on request
Back office
Filters are GET forms with a button, and confirmations are native dialogs
They work without JavaScript
Back office
Uploads need JavaScript
A native post sends file names only (ADR 0084)
Back office
Activity logs and member events work
The original answered 500
What each release took from it
Release
From
Main changes
0.29 (ADR 0083)
Public site F1–F19
Shared views named only during a transition; kit configs keep plain project classes; *; HZ079 / HZ028 / HZ063 fixes; browse keys, overlays, CSP hint
0.30 (ADR 0084)
Back office C1–C23
Conditional tests lowered; an unconvertible schema is HZ014; browse loads local-port images and uploads files; recipes for uploads, bound checkboxes, Invalid
0.30.1 (ADR 0085)
Docker rehearsal
@hozu/bundle moved, not duplicated; --target node names dependency-list mistakes
Limits
The builders were agents with the full guide. The owner did not write the code.
Local containers only; no hosting platform, real email or storage was used.
The rebuilt apps and the original repositories stay private; this record holds no customer data, and every account
and record used was fake.
HOZU