14 Commits
Author SHA1 Message Date
hanzo-dev 0d602fc9dc surface: regenerate the document for zip v1.26.0's operation names
zip v1.26.0 gave an operation ONE naming rule, and the bump landed without
re-projecting the document it renames. 758 operationIds across openapi.yaml and
55 plugin subsets still carried the old spellings — post_collaborator_rpc_documentId
and v1.admin.affiliates.post_id_approve where the rule now says
post_collaborator_rpc_by_documentid and post_v1_admin_affiliates_by_id_approve.

Nothing about the surface moved: same paths, same operations, same prose. An
operationId is the METHOD NAME in eight generated SDKs, the tool name in the MCP
list and the command in the spec-derived CLI, so leaving it stale means every
client offers a name the document no longer agrees with.

This is what surface-check exists to refuse, and it is why the gate has been red
on main: `make describe`, then commit what it wrote.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-08-05 13:40:25 -07:00
hanzo-dev ad15df5781 openapi: regenerate the subsets — the ai door renamed three resources and gave permissions back to IAM
Hanzo CI/CD / cicd (push) Successful in 18s
CI/CD / gate (push) Successful in 18s
CI/CD / containment (push) Successful in 1m13s
CI/CD / image (push) Successful in 18s
CI/CD / rollout (push) Failing after 11s
CI/CD / reach (push) Skipped
CI/CD / fanout (push) Skipped
CI/CD / receipt (push) Failing after 1s
plugin/ai/openapi.json was last written at 3b50091c, with go.mod pinned to
hanzoai/ai v1.832.10. d5d768f1 took v1.832.12 for an unrelated key fix and
754fb821 took .13; neither regenerated a subset. Since then the published
document has been describing a router the binary no longer has.

v1.832.12 rewrote the ai door's resource table. Three resources moved address and
one was deleted:

	/v1/ai/applications      -> /v1/ai/deployments        8 operations
	/v1/ai/sessions          -> /v1/ai/signin-sessions    7
	/v1/ai/users             -> /v1/ai/usages/user-names  1
	/v1/ai/users/table-infos -> /v1/ai/usages/by-user     1
	/v1/ai/permissions          deleted                   6

The six deleted are GET and POST /v1/ai/permissions and GET, PUT, PATCH and
DELETE /v1/ai/permissions/{owner}/{name}. Every handler behind them was an iam.*
call to the IAM server — controllers/permission.go held no rows of its own — so
the address was a second door onto /v1/iam/permissions, which apps/iam serves and
still serves. Upstream deleted the controller with the routes and says so in the
same edit.

So openapi.yaml has been advertising 23 addresses that answer 404 and hiding 18
that are served: the 17 renamed above plus POST /v1/iam/oauth/device/info, whose
prose was written in b5d8f927 and has been waiting for a regeneration to reach the
document. Every SDK, the CLI's command tree and docs.hanzo.ai are projections of
this file, so a client generated from it calls /v1/ai/applications and gets
nothing.

floor.json comes down by six, which is the act it is designed for: the deletion is
upstream, deliberate and already shipped, so the number moves in the commit that
carries it rather than being absorbed by a re-measure. paths and operations follow
(-1 and -5 — the six net against iam's one), and iam goes up by one.

Forty-two other subsets change prose and schema only: a summary now leads with
what the operation does rather than with the Go identifier that implements it, and
visor's cluster list publishes the degraded field its response type already
carried.

Nothing in the router changed here. Regenerating a second time reproduces all 119
generated files byte for byte.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-08-02 20:39:35 -07:00
hanzo-dev 3b50091c77 mcp: the catalogue is a query — delete the 116 committed tool files
The fleet's agent door answered from plugin/<app>/mcp.json: the tool array each
app's binary projected when it was BUILT, embedded by plugin/embed.go and handed
to zip as Plugin.Tools. 116 files, 49,865 lines, and a second source for a fact
every child already knows.

A second source can only be stale or accidentally correct. This one was stale in
the way no gate in this repository could see: o11y's 353 missing ops live in
github.com/hanzoai/o11y, so a go.mod bump in ANOTHER repo invalidated an artifact
in this one with nothing in the diff to say so. Regenerating it more often is not
the fix — a generator on a hook is still two sources with a race between them,
and the trigger is in a different repository. (593aa309 did regenerate it, which
is why the file reads 365 today. The next cross-repo bump silently un-fixes it.)

So the host asks. POST /v1/mcp is the HOST's own handler now (zip's is Disabled,
so exactly one handler holds the address). A tools/list forwards the CALLER's own
message to every composed subsystem's own /mcp over its private ZAP socket, in
parallel, and unions the replies — zip.App.Start resolves a cold child on the
same single-flighted path a prefix request takes, so the first list pays one
start per app and nothing after it does. A tools/call goes to the app that listed
the name, verbatim; the child's own registry decides whether the tool exists.

A SUBSYSTEM THAT DOES NOT ANSWER IS NAMED, in result._meta["hanzo.ai/unavailable"],
because a silently-short list and a stale file are the same defect: the caller
cannot tell an app that serves nothing from one that did not answer. Measured on
the built binaries — host + real o11y child, kms pointed at a dead address:

    tools=364, unavailable=[{kms, connection refused}]

364 and not 365 because o11y projects get_v1_o11y_logs twice; the door serves the
first and logs the collision. THAT DUPLICATE IS WHY cmd/cloud's tests were red on
main — zip refused the Load ("tool is already served by plugin o11y"), a boot
failure. One name still has one owner; it is no longer fatal to the fleet.

Also gone with the mechanism they configured: manifest.App.Open and zip's
one-open-plugin rule. The host forwards the caller's own request to EVERY
subsystem now, so each answers for this caller out of its own rows, and being
asked per caller is no longer a privilege one app holds.

The release gate moved with the door. Car 3 compared the live tool count against
`jq -s length` over the committed files — both sides were the same bytes, so it
proved only that the image carried its own tree, and it passed while o11y's
catalogue held 12 of 365. It asks the better question now: did every subsystem
answer. A broken deployment used to match the files exactly.

plugin/<app>/openapi.json SURVIVES, for the one reason the catalogue could not:
the weave carries each subsystem's prose, and that prose is lifted from the app's
SOURCE at describe time (openapi.Synopsis). A running child has no comment to
read and would answer with its deployment's brand blurb, which the weave would
publish as the description of every product tag. Deleting that half waits on the
synopsis becoming a declared value.

Tests are against RUNNING subsystems (fleet/mcp_test.go): real zip children on
real ZAP sockets, exact sets, bodies never status codes. Mutation-checked three
ways — unmount a child, silence the outage report, ask only the first app — all
three go red.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-08-02 14:22:10 -07:00
hanzo-dev f403c603f1 cloud: the composition root's verb is Listen, because that is what it does
CI/CD / gate (push) Canceled after 0s
CI/CD / containment (push) Canceled after 0s
CI/CD / image (push) Canceled after 0s
CI/CD / rollout (push) Canceled after 0s
CI/CD / reach (push) Canceled after 0s
CI/CD / fanout (push) Canceled after 0s
CI/CD / receipt (push) Canceled after 0s
Serve and Listen were two names for one act. zip's App already calls it Listen —
`app.Listen(zapAddr, httpAddr)` — and this function's whole job is to build that
app and hand it its addresses, so calling it Serve made the entry point disagree
with the thing it enters. One verb, all the way down: a plugin's main says
cloud.Listen, cloud says app.Listen, and nothing has to be translated in a
reader's head on the way through.

117 composition roots move with it. ServePlane is untouched — it names a
different act (bind one app's own socket for the internal plane), and collapsing
it into this would be the opposite of the point.

Also fixes apps/iam's TestMain, which had gone red on every store test:
credz.Boot's last resort is cek.EnsureDevKey, and that DECLINES on a codec-linked
build by design — a build that can really encrypt must be handed a real key, not
invent one. So the throwaway goes in through the same door a deployment uses, and
only when nothing else supplied one. Six failures back to the one pre-existing
ratchet (iam serves 97 untyped ops against a budget of 88).

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-08-02 09:53:56 -07:00
hanzo-dev e6ae1244a7 describe: every operation the fleet publishes now says what it does
1465 published operations, 797 described. The other 668 offered an operationId and
nothing else — a generated SDK method with no docstring, a spec-derived CLI command
with no help text, an MCP tool an agent cannot choose between. Now 1491 of 1491.

The gap was structural, not neglect. Almost every one of them was an UNTYPED route:
a proxy to a vendored module, an SSE stream, a WebSocket upgrade, a byte upload, an
All() wildcard, or a surface owned by another repo entirely. None has a handler doc
comment in this tree for zipdoc to lift, which is exactly why 47 apps carried no
zipdoc directive — adding one would have produced an empty file. The seam they
needed existed and had one caller; it now has 523.

Three surfaces had no seam at all and would have been left behind:

  - metrics and licensing are vendored modules that deliberately do not import
    cloud, so their prose lands at cloud's OWN wire fact in build.go;
  - authz is a leaf forbidden from importing cloud, and its handlers are untyped
    closures in another module — both seams shut — so its prose lands in
    plugin/authz/main.go, the file whose own doc says it is where "cloud's plugin
    contract bends to the leaf."

Every sentence was read off the handler, and reading 668 handlers is most of what
this cost. It found ten defects, filed as #376 — two of them money: gpu-charge is
not idempotent, and the finance ledger's peer path emits a vocabulary its reader
does not classify, so credits render empty and deposits sign negative, with the test
green on both paths because it only exercises the S2S mock. None is fixed here.
Describing is not repairing, and a description that flattered the code would have
been worth less than the silence it replaced — so where a route is broken, the prose
says what it actually does.

Three tests used "has prose" as a proxy for "is a typed op". That equivalence held
while prose could only arrive by lifting a typed op's comment, and Describe breaks
it by design — so each of those tests forbade precisely what the seam exists to do.
They now read zip's own registry and assert something stronger: every operation is
either a typed op with lifted prose or a recorded raw address with declared prose,
and either way it carries prose. apps/exec's is a gate over all 56 of its ops, which
matters most on a pure-proxy surface, where the description IS the product surface.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-07-31 10:00:47 -07:00
hanzo-dev 4cfc10d095 docs: the first sentence of a product's doc is the customer's sentence, not ours
The package doc's opening line is no longer read only by us. openapi/synopsis.go
lifts it verbatim into the app's OpenAPI info.description, the weave lands it on
the product tag, and from there it is the MCP tool prose an agent reads and the
line `hanzo <product> --help` prints. It is the first thing a paying customer
sees about a product they are deciding whether to use.

Forty of them opened by describing the implementation instead: "mounts the Hanzo
Cloud /v1/code/* surface", "folds hanzoai/esign (the Documenso fork) into the
unified hanzoai/cloud binary as an in-process subsystem (HIP-0106, task #100,
epic #96)". A customer reading the tag list learned our file layout, our epic
numbers and our mount order — and not one thing about what they get. Several ran
past 200 characters, so the CLI help column truncated mid-clause.

So sentence one now answers the only question a buyer is asking:

  code    → search and symbols across your repos, for you and your agents.
  esign   → a document out for signature, signed and filed with an audit trail.
  world   → a live news feed filtered to what your project cares about.

NOTHING IS DELETED. Every clause the old opener carried — the mount path, the
fork it wraps, the HIP, the tenancy argument — moves down to sentence two, where
it is read by the person it was written for. Only the ORDER changed: what the
product is, then how it is built. Both were always in the same comment; only one
of them projects.

The rule the forty now hold, and the reason each is a rule: ≤90 characters (the
CLI help column); no "mounts"/"surface"/"subsystem"/"plane"/"binary" (words for
where the code lives, not what it does); no /v1 path, file name or HIP number (an
identifier no customer can look up); no shouting (the tag list is prose, not a
changelog). Sentence two keeps all of it.

Two files were already gofmt-dirty on main and are now clean, since they are
files this touches: apps/content/doctypes.go (comment alignment) and
apps/websearch/websearch.go (list-continuation indent).

Regenerated FROM SOURCE, not hand-edited: make describe → 1039 paths, 906 MCP
tools. The artifact diff is descriptions only — no path, operation, schema or
tool name moves.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-07-30 23:00:51 -07:00
hanzo-dev c0d7b3f969 openapi: a product tag says what the product is, in its owning package's words
The document has always known a product's NAME mechanically — the first path
segment after /v1/ — and never what the product IS. A caller reading the tag
list, an agent reading the MCP door, a CLI printing `hanzo <product> --help`
got 144 bare nouns.

There is exactly one place that sentence is already written and already
reviewed: the package doc of the package that implements the app. So this reads
it rather than asking anyone to write it twice.

  openapi/synopsis.go   Synopsis(plugin/<app>) -> the owning package's synopsis.
  describe.go           stamps it into that app's own subset as info.description.
  openapi/weave.go      lifts the tag prose off the subsets it already reads.

ONE computation, at the one moment an app describes itself. The weave does not
look the mapping up a second time in a second process — it reads the value the
app that knows it already wrote down, which is why Weave stays a pure function
of its parts.

The owner comes from the app's own composition root: plugin/<app>/main.go
imports exactly the package it mounts. Nothing else could be the source — four
apps are not named after their package (audit->auditlog, evals->eval,
plugins->plugin, zero-trust->zt) and one package backs two apps (account,
account-bridge), so a name-derived guess is right 107 times and silently wrong
5. An app whose subsystem is another MODULE imports no package here and gets
nothing, which is the honest answer.

And the comment taken is the one that OPENS "Package …", not go/doc's
first-file-in-filename-order fallback. Packages that open their
alphabetically-first file with a note about that FILE and state the real package
doc in <name>.go would otherwise publish "actions.go — the two GitOps write
actions" as the deploy product's description. A misfiled sentence reads exactly
like a real one; an absent one does not.

109 of 112 apps have a package doc; 85 of the 144 product tags gain a
description. The three without are metrics, authz and licensing, whose subsystem
is another module — there is no package here to read. The tag NAME is never
conditional on a description: the list stays a function of the document's
operations, so nothing enumerating products loses a product because nobody wrote
a sentence. The fleet identity remains the fallback for a subset whose package
has no doc, and the weave treats a part carrying it as having said nothing.

THE LIFTED PROSE LOSES THE HANDLER'S OWN NAME, which is the other half of the
same problem. A Go doc comment must open with the identifier it documents, and
that identifier is Go's, not the document's: "GetSQL returns one database"
reached the OpenAPI description, its summary, the MCP tool description an agent
reads, and the CLI help line — naming a function no caller can see. zip drops an
exact leading match of the handler's own name from v1.18.13 (main is on v1.18.14,
whose lift is byte-identical), and nothing had regenerated against it: 35
packages carried prose the pinned zip can no longer produce. They regenerate
here. Three test assertions quoted the leaked identifier and now quote the
projection.

Every generated artifact is regenerated FROM SOURCE (make -f mk/fleet.mk
surface-check, green: 1017 paths). Nothing this commit does moves the wire: of
openapi.yaml's 16,439 non-prose leaf facts, 0 changed. The 4 lost and 94 gained
are all one thing — surface main already decided and never republished:
/v1/insights/e removed and /v1/event given its declared body (6fc2d88c), the six
project-scoped git smart-HTTP paths (811ff080), and the sessions' `terminal`
property (afdda829). The three bare-root git paths reach no app, so they join
router_test.go's unreachable ledger, recorded on the first regeneration that
published them.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-07-30 21:33:38 -07:00
hanzo-dev e247e255cf mcp: ONE door — three hand-rolled registries collapse into the typed-op projection
Typing a route bought OpenAPI prose, an SDK method and a CLI command, and NOTHING
on the public MCP surface. zip has projected every typed op into an MCP tool since
v1.18.6 and cloud never called it: manifest routed /v1/mcp to apps/tools, which
hand-rolled its own tools/list + tools/call over a route-table scrape, and
apps/automations hand-rolled a THIRD catalogue. Three registries for one concept,
and the one the public reached exposed none of the 549 typed ops.

THE DOOR IS THE HOST'S. cmd/cloud sets zip.MCPConfig{Path:"/v1/mcp"} and hands
each plugin its own catalogue at Load. The host is the only process that CAN own
it: MCPTools() is in-process, so a plugin cannot enumerate a lazy sibling, and a
plugin-hosted door costs its own wake on the first list. Measured: POST /v1/mcp
beats ai's "/v1" remainder by specificity, not registration order.

THE LIST IS A BUILD ARTIFACT, so tools/list costs ZERO wakes. It has to be: 112
plugins mount LAZILY, and an MCP client calls tools/list constantly — a door that
fanned out over ZAP to ask would destroy the one invariant that makes 112 services
affordable. The answer is already fixed at build time, by the same typed-op
registry that emits openapi.json, so `<app> describe <dir>` now writes BOTH
projections from ONE mount at ONE instant: openapi.json and mcp.json. They cannot
be generated apart, so a tool cannot exist without its op or carry a stale schema.
The leaf plugin/embed.go go:embeds them (cmd/cloud goes 344 → 345 packages, still
zero from apps/). Measured live with the WHOLE fleet mounted: 549 tools listed,
child count 4 → 4 (the four eager apps, untouched).

tools/call is the ONLY trigger and starts exactly one child — p.target(), the same
single-flighted lazy path a prefix request takes — then forwards the SAME message
to that plugin's own /mcp over ZAP on its 0700 unix socket. Never HTTP. The child's
registry answers, so the host can only NAME a tool, never invoke one the child did
not declare. Measured live: get_v1_pricing woke 1 child and returned the pricing
catalog; get_v1_company answered its own handler's "X-Org-Id required" through the
plugin's full cloud.Serve identity chain.

DELETED, not left dark:
  apps/tools/builtin.go (223 lines) — the "full-cloud-control" route→tool scrape.
    Structurally dead since the monolith died: in the tools CHILD, GetRoutes() sees
    only tools' own ~13 routes, and its schemas were opaque {query,body} objects a
    model cannot fill. The new door is what it meant to be, with real schemas.
  apps/tools/http.go's mcp/mcpToolList/mcpToolCall/rpcResult/rpcError + the route.
  apps/automations/mcp.go's mcp/mcpTools/mcpResultObj/mcpErrorObj + its route.
  GET /v1/mcp — a Source view that is GET /v1/tools?source=mcp by its own comment.
  Principal.credential + credentialHeaders — replay state only builtin.go read.

KEPT, because it is a different capability: apps/tools' EXTERNAL MCP server
registry (records, KMS-sealed secrets, SSRF-validated dialer, tools/list fan-out),
now owning /v1/mcp/servers alone. Its tools, org skills, agents, functions and
connector actions are ROWS, not code, so no build-time catalogue can hold them —
they are reached through the typed POST /v1/tools/call, which is itself a tool on
the door. Nothing lost: connectorToolProvider already published every connector
action into that one registry.

THE GATE. mk/fleet.mk surface-check (which .hanzo/workflows/cicd.yml → hanzo.yml
app-contract actually invokes) regenerates every app FROM SOURCE and fails on
`git status --porcelain -- openapi.yaml plugin/` — mcp.json is under plugin/, so it
was covered the moment it landed there. PROVEN TO FIRE: adding one typed op to
apps/guide without regenerating turned it red on BOTH plugin/guide/mcp.json and
plugin/guide/openapi.json; reverted, green. Four more, all cheap: no App row may
claim /v1/mcp (fiber MERGES byte-identical patterns, so a Load there would shadow
the door silently); no served path may END in /mcp; no Go source outside cmd/cloud
may name an /mcp path unless it is a named foreign engine (apps/tasks' own
surface, which is not a projection of our ops); every catalogue tool must be an
operationId of its own app, unique fleet-wide, with a NON-EMPTY description —
the last one because a nameless tool is a silent failure a model pays context for.

549 tools across 36 apps, 349KB on the wire. zip v1.18.11 → v1.18.12.

Capability check, precisely: the 17 executable connector actions the deleted
automations door listed are NOT tool names on the fleet door, because they are
per-tenant rows — connectorToolProvider publishes every one of them into the ONE
registry from the same `registry` map that door read, so they are reached through
tools_call with the same activation, price, meter and audit. Nothing is lost; one
hop is added. Same for org skills, agents, functions and external MCP servers.

One door this gate structurally cannot claim: /v1/tasks/mcp is hanzoai/tasks' own
engine surface behind cloud's identity gate, mounted on a raw net/http mux so it
is in no subset at all. It is a foreign engine's tools, not a projection of ours,
so it is NAMED in foreignDoors with the reason rather than deleted.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-07-30 10:11:38 -07:00
hanzo-dev de9b59624f zip v1.18.9: the document stops saying four untrue things, and authz stops publishing a removed API
The bump alone changes 23 published artifacts, because zip v1.18.9 fixes what the
projection SAYS rather than what any route does. No wire moves.

  phantom request bodies 41 -> 9. A POST binding its whole input from the path
  published a required body whose only property was the path param, so every
  generated SDK gained an argument the caller must build to repeat a value it
  already passes in the URL. The 9 left are the raw-body family (git-upload-pack,
  bank-statement import, a deck upload) — they eat bytes, not JSON, and owe a
  binary content type via openapi.Binary rather than an empty object.

  time.Time stopped publishing as a $ref to a schema with no properties and now
  says format: date-time. Its fields are unexported, so reflection over them
  described nothing: every timestamp in every generated SDK was untyped.

  summaries lost their embedded line breaks — one sentence on one line, which is
  what the spec, the CLI's one-line help and an SDK's first docstring line all
  want.

  imported types' FIELD docs reach the document at all. zipdoc matched the parsed
  and type-checked views of a struct by byte offset, which only agrees for a
  package loaded from source; an imported type's position comes from export data
  with a synthetic offset. So every op whose In and Out live in the call plane
  published a description and zero field descriptions.

AND ONE STALE PUBLISHED SURFACE, which the regeneration exposed rather than
caused. plugin/authz/openapi.json documented GET, POST and DELETE
/v1/authz/policies. hanzoai/authz v1.10.15 does not serve them, and says why in
serve/mount.go: the grant set belongs to IAM, "a second writable copy behind this
surface would be a second source of truth for who may do what". So cloud was
advertising a writable authorization-policy API that had been deliberately
removed, and three methods in every generated client answered 404. Verified as
pre-existing by regenerating the subset at origin/main on the OLD zip: the same
three paths vanish.

That drift means the gate was red on main and stayed red. It is invoked
(hanzo.yml:134), which leaves the two ways it could have been red and unnoticed —
worth a look, not a guess.

Also: openapi-apps now honours OPENAPI_NEEDS_BROKER, which only openapi-check
did. The gate's own failure text says "fix: make openapi", and that fix routed
through openapi-apps, which mounts kafka, which fails closed with no broker — so
the single command told to repair a red gate could not run. One exemption list,
read everywhere it applies.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-07-30 07:08:28 -07:00
hanzo-dev b635355827 guide: publish the step objects the wire actually carries — stepView spells out JourneyStep
zip's structSchema publishes an embedded EXPORTED struct as one NESTED
property named after its type, while encoding/json PROMOTES its fields —
so every step object in GET /v1/guide and the skip/reset ops documented
{JourneyStep: {...}} for a wire that has always been flat {id, title,
deps, ..., state}, in openapi.yaml, in every generated SDK and in the MCP
tools' schemas. Fourth live instance of the embedded-struct class (recipe
rule 7: patchTargetIn, botView, clusterDetailView), and the published-
subset check that now rides in LLM.md finds two more in plugin/admin
(MetricsData -> SaaSMetrics, ServiceView -> ServiceRow).

The wire is untouched: the fields are inlined in promotion order with the
same json tags, TestStepViewCarriesJourneyStep pins the spelled-out copy
against JourneyStep so a field added later cannot silently drop out of
the view, and the step fields now carry their prose in the document
instead of riding on a property that never existed.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-07-29 11:59:37 -07:00
hanzo-dev edb39f2281 guide: the blueprint plane published a path this API never served
An EMPTY leaf on a group composes to the group's prefix plus "/", so
`zip.Get(b, "", …)` on `b := g.Group("/blueprint")` declared the plane's root
at /v1/guide/blueprint/. op.Path IS the identity every projection reads, so
that trailing slash reached all of them: the document keyed the resource on
/v1/guide/blueprint/, the operationId (and therefore the MCP tool an agent
picks and the method a generated SDK exposes) was get_v1_guide_blueprint_,
and every generated client called the slashed URL. Fifteen sibling guide
paths carry no slash; the tests, the FE and the untyped PUT beside it have
always used the slashless form.

Nothing was red, because the router is non-strict: both spellings answer,
before and after. That is also what makes the correction wire-preserving —
TestBlueprintPathIsSlashless pins BOTH spellings at 200 and asserts the op
registry publishes no trailing slash, and it fails on the old registration.

The root is declared on g with a /blueprint leaf now, the same shape overview
already used to avoid naming /v1/guide/ ("declaring it on g would name
/v1/guide/, which this API never served") — the file had reasoned past this
exact trap one group up and walked into it one group down, which is the tell
that it is mechanical. The untyped PUT moves with it, or the document splits
one resource across two keys. Only the sub-paths hang off the group now,
where the leaf is non-empty and the composition is exact.

Repo-wide there is no second instance; LLM.md carries it as failure mode 8
with the grep, since every remaining typing tranche can hit it.

No route converted here: guide's remaining 6 untyped routes each name a wire
fact the declaration still cannot carry (verified, not assumed) — a YAML-or-
JSON document body that a JSON In would 400 (PUT /curriculum, PUT
/blueprint), a merge-patch whose explicit null DELETES a key that a pointer
field cannot tell from absent (PATCH /blueprint/{collection}/{id}), and the
structured 409 {error, step, blockedBy} that zip's {status, code, error}
envelope cannot express (POST /steps/{id}/start|done, plus SSE on /do).

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-07-28 23:28:16 -07:00
hanzo-dev 7e50740e83 guide: type 13 of 19 routes — one declaration, every projection
/v1/guide had a route table and nothing else: no schema, no prose, no MCP tool,
no CLI command, no SDK method. Thirteen of its nineteen routes are typed ops now
and carry all five. The other six each name a wire fact the declaration cannot
yet make, and say so at the registration rather than being quietly skipped.

Typed: GET /v1/guide, /analytics, /profile, /strategies, /suggest, /curriculum,
/actions, /blueprint, /blueprint/versions; POST /chat, /steps/:id/skip,
/steps/:id/reset; DELETE /curriculum.

Left untyped, with the reason:
  - PUT /curriculum and PUT /blueprint take a YAML-**or**-JSON document
    (sigs.k8s.io/yaml). A typed In is decoded as JSON before the handler sees it,
    so typing them would answer 400 to every YAML body they accept today.
  - PATCH /blueprint/:collection/:id takes an opaque JSON merge-patch whose keys
    are the patched item's own — not a declarable In.
  - POST /steps/:id/start|done answer a blocked step with a STRUCTURED 409
    ({error, step, blockedBy}) written in-band. A typed op's only non-2xx is the
    error it returns, whose envelope is a different shape. They convert with zip
    multi-status (#78).
  - POST /steps/:id/do also STREAMS SSE, and an op answers exactly one JSON value.

The gated/ungated split is the discriminator worth copying: skip and reset pass
gate=false, so the 409 branch is unreachable for them and their whole answer set
is expressible. One shared body (applyStep) serves both halves; the gate is a
parameter and the blocked case is a VALUE the untyped pair renders.

Wire preserved exactly, and checked rather than assumed:
  - every response is the same JSON (maps became structs with the same keys);
  - GET /strategies still binds category/stage/workload from the query, and now
    DECLARES them;
  - DELETE /curriculum takes no body, before and after;
  - the SuperAdmin 403 on the blueprint plane is now one shared errNotSuperAdmin,
    so the untyped wrapper and the typed ops cannot drift into two refusals;
  - the URL stays the addressing authority on skip/reset — a body naming another
    step cannot redirect the write (TestTypedStepOpsFailClosed pins it).

Two things typing surfaced that nothing else would have:

1. openapi.Weave REFUSED the whole fleet document: guide's Step and marketing's
   Step are one schema name with two shapes, and a generated SDK would bind
   whichever it read last. guide's type is JourneyStep now — marketing's is
   already published and guide's was not, so guide yields. No wire change: the
   JSON keys live on the fields. The comment on the type says why, so nobody
   "simplifies" it back into the collision. LLM.md's failure mode 5 gains this
   second instance and a shape-aware scan, since a name-only grep passes when two
   apps legitimately agree.

2. zip cannot declare a bodyless POST (hasBody is unconditional), so skip and
   reset publish a requestBody they never read. The wire is unharmed — bindURL
   binds the path LAST, so the URL still names the target — but the document
   asserts something false. apps/admin already ships two of these. Logged as
   failure mode 7; same shape of gap as multi-status.

Three operationIds move (get_v1_guide_blueprint_, post_v1_guide_steps_id_skip,
..._reset). That is failure mode 6 and the house rule is explicit: TAKE the
rename, never pin it back with WithOperationID, which would make one app's ids a
special case. It is not the wire — no status, body or field name moves. The
registration says so where the next reader will look.

apps/guide gets its //go:generate zipdoc directive (it had none, so its prose
could never have reached the spec) and cloud.Bridge on its own subtree, so the
validated org reaches an op that receives only a context — never an In field,
which is caller-supplied.

TestRequestEscapeHatchIsPinned fired on this change, which is the gate working:
superAdminOK and ledgerOf are new cloud.Request sites, justified in the allowlist
rather than waved through — admin-ness lives in X-User-IsAdmin and the payer is
the SELECTED billing org, neither of which principal.OrgFrom carries, and both
fail closed off the HTTP path.

Green: apps/guide, openapi (the weave), the root package, manifest, cmd/cloud,
apps/marketing; go build ./...; zipdoc -check; openapi.yaml + plugin/guide
regenerated from source and clean under the drift gate.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-07-28 22:52:22 -07:00
antje 85dd3a6513 name: a thing the host loads is a Plugin
MountSpec was a compound naming a struct after the mechanism that consumes it.
The thing it describes is one of the plugins the host loads: name, price, mount.
The directory is plugin/, the framework is the zip plugin framework, and every
doc comment already called them plugins in prose. So: Plugin.

Not App, which was the obvious first choice and is wrong twice over -- package
cloud already declares an App in payloads.go, and the struct itself carries an
App field for a subsystem that gates the whole binary. Either collision alone
would have made the name ambiguous at every use site.

Mechanical: 132 files, plus the parameter and loop variables that carried the
old noun (specs, spec, sp) to the noun they actually hold.
2026-07-28 16:48:54 -07:00
hanzo-dev 2c4b045b0b cmd/cloud + plugin/<app>: the light host is the one binary — scope credentials, forward flags, own "/"
Hanzo CI/CD / cicd (push) Successful in 22s
CI/CD / gate (push) Successful in 22s
CI/CD / containment (push) Successful in 1m37s
Restructure to the canonical layout: cmd/host → cmd/cloud (the host IS the one
real binary; name it cloud), and every other cmd/<app> → plugin/<app>. `ls cmd/`
is `cloud/` alone; `ls plugin/` is the 116 per-app + tool dirs. gen-app-cmds
scaffolds into plugin/<app> and scans plugin/ for the bijection; the
Dockerfile / Makefile / mk / hanzo.yml / weave / controlplane-containment gate all
read the new paths. go build ./cmd/cloud links ~399 pkgs and zero subsystems.

credz KMS-key leak (#51 follow-up): zip builds each child's env as
append(os.Environ(), Plugin.Env...), so a host that keeps CLOUD_KMS_MASTER_KEY_REF
hands the root key to EVERY child — the Root posture credz exists to prevent, and
now the default entrypoint. cmd/cloud (stdlib credz/launch only — importing credz
would drag cek→sqlite and re-fatten the host) mints the launch secret, scrubs the
root key from its OWN environment, stamps each child a scoped CREDZ_TOKEN, and
re-injects the root key onto the kms broker child's Env ALONE. Every generic child
comes up with a token and no key and must ask the broker. Pinned by
cmd/cloud/main_test.go and proven by a live dns spawn.

helm flag forwarding: cmd/cloud accepts --brand/--domain/--data-dir/--iam-issuer
(the args the chart passes the entrypoint) and republishes each non-empty one as
its CLOUD_* env, which the per-app children read; an empty flag never clobbers a
value already pinned in the environment.

console at "/": nothing served the host root once mountConsole moved into the
per-app cloud.Serve. Extract the console into a light webui leaf (stdlib + embed +
a new strings-only brand leaf, both aliased back into package cloud so no call site
changes) so cmd/cloud — the front door — owns "/" and serves the white-labelled
SPA. The host stays ~399 packages and imports zero subsystems.

Co-authored-by: Hanzo Dev <dev@hanzo.ai>
2026-07-28 12:37:17 -07:00