ci: canonical pair — hanzo.yml + forge caller

github.com has no runner for hanzo-build-linux-amd64, so a caller under
.github/workflows is a gate that can never be scheduled. This is the ~7-line
caller on the plane that can (git.hanzo.ai git-runner fleet), pinned @v1.

Co-authored-by: Hanzo Dev <[email protected]>

.hanzo/workflows/cicd.yml

@@ -0,0 +1,15 @@
+# Canonical caller — every knob lives in /hanzo.yml, none here.
+# Runs on the git-runner fleet at git.hanzo.ai, the only pool serving these
+# labels. github.com resolves only .github/workflows and has no runner for
+# them, so a caller placed there is a gate that cannot be scheduled.
+name: CI/CD
+on:
+  push:
+    branches: [main, master]
+    tags: ['v*']
+  pull_request:
+  workflow_dispatch:
+jobs:
+  cicd:
+    uses: hanzoai/ci/.hanzo/workflows/build.yml@v1
+    secrets: inherit

hanzo.yml

@@ -0,0 +1,21 @@
+# hanzoai/mcp — the Hanzo MCP server/toolkit (TypeScript). Publishes to npm; the
+# image lane is not declared here, so this is a gate and nothing else.
+#
+# TYPECHECK, THEN BUNDLE, and the order is the whole point. `pnpm build` is
+# esbuild, and esbuild does not typecheck — it happily bundles a tree full of
+# type errors. So the bundle alone is a gate that cannot go red for the defect
+# this codebase is most likely to have. `tsc --noEmit` against the repo's own
+# tsconfig asks the question esbuild skips; the bundle then proves the entry
+# points still resolve and that the externals list has not gone stale.
+#
+# Not `pnpm test`: five of the eighteen jest suites reach a network or a live
+# tool surface (search-engine, unified/fetch, tracker, code-intel,
+# configuration). Those belong in an integration lane with the services they
+# need, not in the gate every push must pass.
+test:
+  - name: typecheck-and-build
+    run: |
+      set -e
+      pnpm install --frozen-lockfile
+      pnpm exec tsc --noEmit
+      pnpm build