ZERO hosted /api/ across apps/ (was 273 on origin/main).
The last three were endpoints nobody serves. Replaced with what is real,
each proven on api.hanzo.ai against a 404/19 bogus control:
console.hanzo.ai/api/public/metrics/cost -> /v1/billing/usage (401)
app.platform.hanzo.ai/api/environment.approveDeployment -> deleted; there is
no approval op. The block now shows GET /v1/environments (403) and
POST /v1/platform/projects/:project/apps/:app/deploy (403), which are real.
app.platform.hanzo.ai/api/volume.create -> deleted; storage has no HTTP surface.
Roles/memberships/orgs are IAM's, not the platform's, so those examples move to
the ops that exist: /v1/iam/update-role, /v1/iam/add-membership,
/v1/iam/get-organizations, /v1/iam/get-user (401 each, bogus 404/34).
Per-service hosts are apps and consoles, never API bases: iam./kms. normalised
onto api.hanzo.ai/v1/{iam,kms}. platform.hanzo.ai/v1/git-webhook stays -- it is
a receiver GitHub POSTs to, not a customer API base, and api.hanzo.ai does not
proxy it (404).
Co-authored-by: Hanzo Dev <[email protected]>
Proven against api.hanzo.ai with a discriminating bogus control (404/19):
/v1/iam/oauth/logout 200 · /v1/esign/documents 403 · /v1/flow/workflows 403
/v1/kms/health 200 · /v1/o11y/traces 403 · /v1/bot/integrations 403
Per-service hosts (iam./kms./esign./flow.) are apps and consoles, never API
bases, so every API example now points at the one host.
Corrects an earlier claim of mine: iam.hanzo.ai/api/sso-logout -> /v1/sso-logout
was NOT verified. That host returns 200/654 for EVERY path including
/v1/zzz-bogus -- a catch-all page, so the 200 proved nothing. IAM has no
sso-logout route at all; the real one is /v1/iam/oauth/logout (internal/oidc/oidc.go:28).
Deleted apps/platform/content/docs/api/{vms,containers,clusters}.mdx: platform's
root.ts registers no cluster, vm, container, volume or orgTeam router, and the
dotted procedure form 404s on the API host. They documented an API that does not
exist. Nav pruned to match.
Co-authored-by: Hanzo Dev <[email protected]>
Three things the workspace disagreed with itself about.
Versions. apps/docs ran ahead on next 16.2.6 / react 19.2.6 / TS 6, the other
21 apps trailed on next 16.1.6 / react 19.2.3 / TS 5.9.3, and the packages sat
somewhere between with five different @types/react pins. Everything is now on
the newest patch of the line it was already on — react 19.2.8, next 16.2.12,
@types/react 19.2.18, @types/react-dom 19.2.4 — and the TS-5 stragglers join
the TS 6.0.3 the root and every package already used. No majors were invented:
6.0.3 IS the top of the 6.x line, and TS 7 is blocked because [email protected]
declares `typescript: ^5.5.0 || ^6.0.0`.
The duplicate key. next.config.mts declared `transpilePackages` twice in one
object literal, so the later list won and @hanzogui/shell and @hanzo/brand had
never been transpiled — the comment explaining why they must be outlived the
setting it described. tsc had been reporting this the whole time as
next.config.mts(193,3) TS1117; the app's `types:check` never reaches tsc (its
script starts with a bare `@hanzo/docs-mdx`, which is not the bin's name and
fails immediately), so nobody saw it. One list now, both groups in it.
Dead weight. Twelve packages apps/docs declared and no file, config, script or
browserslist field referenced: @radix-ui/react-dialog, @floating-ui/react-dom,
@mixedbread/sdk, @orama/orama, openapi-sampler, react-remove-scroll,
algoliasearch, gray-matter, tinyexec, tinyglobby, @types/three (types for a
package that isn't installed) and shadcn (no components.json exists anywhere in
the repo, so the CLI was never initialized). The ones that are real
dependencies of packages/openapi, packages/core and packages/cli keep their own
copies — pnpm's node_modules is isolated, so nothing lost a resolution.
@orama/core stays: apps/docs/app/static.json/route.ts pulls OramaDocument
through @hanzo/docs-core/search/orama-cloud, which types against it.
Verified against a clean worktree at HEAD, since the working tree carries
gigabytes of untracked synced project docs that CI never checks out:
turbo build, apps + packages 43/52 before, 43/52 after, same 9 failures
docs export 1764 html pages, byte-identical page count
deploy.yml gate index/docs/services present, /docs has nav
tsc --noEmit in apps/docs 325 errors before, 324 after (the TS1117)
vitest 169 passed / 13 failed, both sides
The 9 build failures and 13 test failures are unchanged from HEAD and none are
version-related: 7 sibling apps cannot resolve @hanzo/mdx:collections/server
under `next build --webpack`, zen-docs has a committed docs/server.ts importing
a deleted zen5-coder-flash.mdx, and packages/preview cannot resolve its own
@/lib/source alias under waku/vite.
Co-authored-by: Hanzo Dev <[email protected]>
The <script src="analytics.hanzo.ai/script.js" data-website-id> tag is a shim:
it talks to a read LENS instead of the one ingestion front door, so a docs site
could only ever produce pageviews — no errors, no product events, and a separate
per-site id to keep in sync. Replaced across all 12 sites with @hanzo/event
POSTing api.hanzo.ai/v1/event, which Cloud fans server-side into the web
(analytics), product (insights) and error (sentry) lenses. `product` is the only
per-site knob; Cloud resolves the tenant, so no site carries an id any more.
One implementation, not twelve: packages/analytics (@hanzo/docs-analytics)
mounts the provider, adds a pageview per client-side route change, and honors
Global Privacy Control / Do-Not-Track by disabling the client outright. The main
hub's inline Insights snippet goes too — that lens is already fed by the one
stream.
Co-authored-by: Hanzo Dev <[email protected]>
Replace the nginx:alpine Dockerfile.static (platform rule violation) with a
hanzoai/static re-serve shim that wraps the existing flow-site:0.1.0 Next.js
export. Pin apps/flow/Dockerfile (from-source build) to static:0.4.1 and add
the explicit --root=/srv --spa --port=3000 entrypoint. flow.hanzo.ai was
serving ~20 bytes from the broken nginx pod; this serves the real 64 KB export.
The fumadocs-fork rebrand left ~13 apps + examples referencing packages under
names that don't exist in the workspace (in BOTH directions: some kept
fumadocs-*, some became @hanzo/docs-*). pnpm install failed outright. Mapped
every reference (deps + imports, 607 source + 61 package.json) to the package
that actually exists, by suffix:
@hanzo/docs-{core,mdx,ui,base-ui} → fumadocs-{core,mdx,ui} / @fumadocs/base-ui
@fumadocs/{story,cli,mdx-remote,tailwind} → @hanzo/docs-{story,cli,...}
fumadocs-{docgen,epub,twoslash,typescript} → @hanzo/docs-{...}
drop phantom eslint-config-custom
Guarded @hanzo/docs-mdx vs -mdx-remote. Also fixes a pre-existing cli bug
(createConfigSchema referenced undefined isSrc) that blocked the package build.
Verified: pnpm install resolves clean (46.8s, was broken); package dist
regenerates phantom-free from the corrected source (hanzo-docs 430→0). Full
app build-green is blocked only by a node v26 toolchain bug in fumadocs-mdx's
config loader (repo targets node >=24.14; CI node builds it).
- Remove TODO comments from base-ui, radix-ui, core, mdx packages
- Replace nginx:alpine with ghcr.io/hanzoai/static in all app Dockerfiles
(bot-docs, cloud, flow, visor)
zeekay
