Documentation
¶
Overview ¶
Package apps is the composition root: the single, explicit list of which Hanzo cloud subsystems are linked into the binary AND the order they mount in.
Wire() returns []cloud.MountSpec in mount order (slice position == order). There is no init()-registry and no order-int: adding, removing, or reordering a subsystem is a one-line edit to Wire(), read top-to-bottom. cmd/cloud and cmd/hanzo both call Wire() and thread the slice into cloud.Serve — the set is defined ONCE, here.
(This package must NOT live in package cloud: the subsystems import cloud for Deps + Typed, so a root-package bundle would form an import cycle. As a sibling subpackage it composes them without one.)
HIP-0106: the unified cloud binary is the APPLICATION layer plus the embedded KMS secrets plane and the embedded IAM identity plane ("one Go binary embeds IAM + KMS + o11y"). The edge/infra tier (mcp, gateway, ingress-edge) runs as its own deployments for blast-radius isolation; several application folds (iam, base, commerce, captable, dataroom, sign, ingress) are STAGED — linked here but mounted only when the operator names them in CLOUD_ENABLE.
Ordering provenance: order-int ascending; ties in the exact order the pre-refactor init()-registry mounted them, captured empirically from origin/main @c504d2b (68 self-registering specs) and frozen by TestWireOrderMatchesFrozen (wire_test.go). ai (@150) and the hanzoai/o11y module wildcard (@70) are NOT in that dump: on their wave-2 tags (ai v1.805.2, o11y v1.5.12) they no longer self-register, so origin/main currently DROPS them (a latent regression this composition root fixes). They are wired back at their order-int slots — o11y-ext kept adjacent to the in-repo o11y read-plane (@69); ai as the last /v1/* catch-all before plugins (@900). Do not re-sort; edit positions deliberately.
commerce.go mounts the hanzoai/commerce MODULE into the unified cloud binary (HIP-0106) via the NATIVE co-residence contract: commerce registers its routes directly on the HOST's zip app (EmbedConfig.App) — one router, one specificity space, zero handler adaptation. This adapter narrows cloud.Deps, boots the embed, and wires the in-process seams. Direction is one-way: cloud → commerce.
PCI SCOPE. Commerce is a LIGHT ROUTER, NOT in PCI-DSS scope: tokens + intent IDs only, NEVER a PAN. PAN-touching paths call the out-of-process Payments / Vault (ZAP-RPC); when those clients are absent the payment handlers fail closed while tenant config + admin stay served — mountCommerce warns loudly at startup.
FAIL-SOFT. A broken Embed does NOT crash the binary: commerce degrades to a 503 on its own prefixes while every co-resident subsystem stays up.
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
func ServeSingle ¶
ServeSingle is the ONE way to run a single app standalone: validate `name` against Wire(), then serve exactly it (cloud.Serve with a one-name enable list — MountAll mounts only it). It is the path `hanzo <name>` already uses; promoting it here lets each cmd/<app>/main.go stub reuse it instead of re-implementing the dispatch, so adding an app in Wire() is still the one edit and its standalone binary comes for free (generated). Returns an error for an unknown name rather than booting a no-op.
func Wire ¶
Wire returns every linked subsystem as a cloud.MountSpec, in mount order. The slice position IS the order: cloud.MountAll iterates it as-given, registering each subsystem's teardown as a zip shutdown hook so teardown runs in reverse (LIFO). Enablement is a separate axis: cloud.Serve mounts only the specs cfg.Enabled(name) admits, so a STAGED subsystem is linked but inert until named.
Types ¶
This section is empty.
Source Files