The harness plan ran D1→D5 toward `dev` as the engine, and every increment from
D3 on assumes "seeded from git.hanzo.ai / cloud VFS". Nothing creates that repo.
Measured: a project lives in browser IndexedDB plus whatever /v1/publish pushed
to S3, and the only git path is /v1/git/sync — which targets the USER'S OWN
GitHub/GitLab and needs a linked provider first. So the default project has no
repo anywhere and closing the tab ends it. That is the defect being reported as
"none of the work is persisting" and "it keeps starting over".
D0 makes a project a real repo on git.hanzo.ai from its first turn, committed
per turn, with the browser VFS demoted to a working copy. It is first because CI
has nothing to test, CD nothing to deploy, /v1/code nothing to index and a
sandbox pod nothing to seed from until it exists. /v1/git/sync stays untouched —
exporting to a user's own provider is a different intent from the project's home,
and merging the two would make both worse.
D0.1 puts CI and CD on that repo: ci.hanzo.ai runs the checks the builder already
computes (lib/pages/links, lib/pages/responsive) so a green CI and a clean build
cannot disagree, and cd.hanzo.ai deploys through platform /v1/site because a
generated app is static — publish becomes "promote this commit" instead of
"upload whatever the browser holds".
D0.2 writes down the stack defaults as INVARIANTS rather than preferences, since
each has one correct answer: IAM for auth (a generated login form is a security
defect), Base for data, @hanzo/gui for UI, S3 for files, @hanzo/event for
telemetry-and-errors, /v1/code for search. A template or a fork overrides the UI
default — the user's chosen starting point wins.
Also corrected section 1, which described the two builder modes without saying
that only the single-shot one is reachable: /v1/agent ships dark behind
AGENT_SERVER_ENABLED. Reading it, you would think the agent was in use.
Co-authored-by: Hanzo Dev <dev@hanzo.ai>
zooqueenandhanzo-dev
c671f7c4a6