The C2 view: what is actually deployed, where it runs, and how the pieces talk.

​
The eight deployables

apps/action is a ninth build artifact but not a deployed one — it ships as a committed bundle (pnpm --filter @policycodex/action build + commit dist/index.cjs) that consumer repos’ CI runs directly, no Cloudflare/Supabase step involved. Two different “what redeploys” rules apply, and mixing them up is a common support mistake:
  • Rows 1, 2, 5, 6, 7 (the git-connected Pages projects + the Workers Builds worker) have no path filter — literally any push to main rebuilds all five, whether or not you touched that app.
  • Rows 3 and 4 (the two Mintlify sites) are the opposite: their GitHub Actions workflows trigger only on pushes touching that site’s own apps/docs/** / apps/support/** paths — a push that doesn’t touch a Mintlify site’s files never redeploys it.
packages/core is not deployed on its own — it is bundled into every artifact, so a core change is invisible in production until every consumer (web, worker, functions, action) is redeployed.

​
Two data paths worth memorising

The check path (why a PR gets a red or green PolicyCodex check): Evaluations never run inside the webhook request — an LLM call exceeds the runtime’s waitUntil budget — so a check appearing 1–2 minutes after the PR is normal. The identity path (why roles/entitlements exist in the database at all): Clerk owns users, org membership, custom roles and billing. The clerk-webhook function is the only writer that syncs them into codex.user_profiles, codex.members and codex.org_subscriptions. Org creation is deliberately not webhook-driven: codex.bootstrap_org (called during sign-up, requires a live session) is the only path that creates orgs, and webhooks for unknown orgs are ignored.