zeekayandhanzo-dev
79105531ed
Hanzo CI/CD / cicd (push) Failing after 1m2s
CI/CD / gate (push) Failing after 1m2s
CI/CD / containment (push) Successful in 1m42s
CI/CD / image (push) Skipped
CI/CD / rollout (push) Skipped
CI/CD / reach (push) Skipped
CI/CD / fanout (push) Skipped
CI/CD / receipt (push) Skipped
Same fact as the guide commit, the rest of the estate.9396df70moved the principal enrichment into cloud.Identify and updated 66 packages' harnesses; the ones here were missed, so each built a bare zip.App, mounted a subsystem on it, and then watched every typed op refuse a caller production serves — 82 tests across automations, cms, company, entitlements, erp, framework, help, marketing, marketplace, prefs and templates. erp and cms read as a doctype bug and were not one: the module install 403s first, so the doctype never exists and every later create honestly answers 404. One cause, two sentences. Two comments were describing the world before9396df70and now describe this one: marketplace said the subsystem installs the bridge app-wide, and automations' MCP harness said the plain harness does not install one. The ordering claim both make is unchanged and still exactly right. templates' TestTheBridgeIsInstalledAheadOfTheLeaves was pinning the OLD arrangement out loud — "no app-wide bridge, exactly as this package's tests have always mounted it". Both its teeth are untouched: a validated caller must get 201, an anonymous one must get 403. Only who installs the enrichment changed, from the subsystem to the composer, which is what9396df70decided. No gate was loosened anywhere. It cannot be: principal.OrgOf refuses when the user claim is empty, so the bridge parks nothing for an anonymous request and every anonymous-refusal test still refuses. Co-authored-by: Hanzo Dev <dev@hanzo.ai>