feat: install platform agent as org root (Phase 1) #2371
Reference in New Issue
Block a user
Delete Branch "feat/platform-agent-install"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Phase 1 of the org-level platform agent (RFC #2360). Stacked on #2361 (Phase 0) — base is
feat/platform-agent-kind; will retarget tomainonce #2361 merges.Adds the idempotent operation that makes the concierge the org root:
POST /admin/org/platform-agent(AdminAuth) →installPlatformAgent(). In one transaction it (1) upserts the platform-agent row (kind=platform,parent_id NULL) via ON CONFLICT, (2) re-parents the org's existing root(s) under it, (3) moves the org-anchor refs that key off the root workspace id —org_api_tokens.org_id+org_plugin_allowlist.org_id— old root → platform agent.Routing unchanged — platform-as-root reuses existing ancestor/descendant rules;
sameOrgstill isolates tenants.The CP calls this at org-provision (new orgs) and the existing-org backfill (CTO-authorized to run post-merge, snapshot+rollback).
Tests
orgRootID/sameOrgresolve to the platform agent + idempotency. Verified locally (postgres:15, all migrations apply, green).Audit note
The re-parent moves the org anchor; audit confirmed exactly 2 anchor tables (
org_api_tokens,org_plugin_allowlist).rescue_bundles.org_idis the CP org UUID (MOLECULE_ORG_ID), a different namespace — not affected.🤖 Generated with Claude Code
Add the idempotent, transactional operation that makes the org-level concierge the org root (RFC docs/design/rfc-platform-agent.md): POST /admin/org/platform-agent (AdminAuth) + installPlatformAgent(). In ONE transaction it: 1. upserts the platform-agent row (kind='platform', parent_id NULL, tier 0) via ON CONFLICT (id) DO UPDATE; 2. re-parents the org's existing root(s) under it; 3. moves the org-anchor references that key off the root workspace id — org_api_tokens.org_id and org_plugin_allowlist.org_id — from each old root to the platform agent, so a tenant's admin tokens + plugin allowlist never point at a stale anchor. Routing is UNCHANGED: once the platform agent is the root, the existing ancestor/descendant rules in registry/access.go give it universal in-org reach and org_scope.go keeps tenant isolation intact. The CP calls this at org-provision (new orgs, clean) and during the existing-org backfill rollout. Idempotent: a second call is a no-op. Tests: handler bad-input unit test; real-Postgres integration test proving the re-parent + both anchor migrations + orgRootID/sameOrg resolution + idempotency (sqlmock cannot evaluate the post-tx row state). Allowlisted in the workspaces-INSERT bulk-create regression guard with its ON CONFLICT safety note. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>3665faa5cato1c42488be7Independent review confirmed: install op idempotently makes the platform agent the org root, re-parents the existing root, and migrates the 2 org-anchor tables (org_api_tokens + org_plugin_allowlist) in one tx; real-PG integration test proves re-parent + anchor migration + orgRootID/sameOrg resolution + idempotency; allowlisted in the bulk-INSERT guard. Required checks green. Approving.
Security review: transactional re-parent + anchor migration is atomic; no routing change (platform==root reuses existing rules); sameOrg isolation preserved. Approving.