Polaris OS · where we are, and what comes next

Three holes in the app that is live today: any signed-in user can read and write other orgs' Inbox-task comments, can make themselves owner of an org whose id they know, and any member can promote themselves. The fix is 20261016000007_security_fixes.sql, tested on the branch, applied in one BEGIN/COMMIT and probed with a second org's token before and after.

Unblocks: nothing else depends on it, which is the point. It is safe to do first and on its own.

Pre-flight, then repairs, then the migrations one file at a time, with the runtime, edge functions and web deployed in the windows the runbook names. Paquito's opinion: two windows. First the 17 Oct set (slices 0 to 11), awareness off. A week later the 20 Oct set (12 to 14), with every external action set to ask first.

Needs first: decision 1, a green integration run and a week on staging. Unblocks: real use, the pilot numbers and the RunPod eval.

The alternative is AgentMail. Our own domain is cheaper and we control deliverability. The plan's working name is polarismail.co; we have not checked it is free or bought it. Mail records are never proxied.

Unblocks: the first real external effect (slice 12), then WhatsApp for Adi at PTP.

Desks run on a local sandbox in tests. Real workers need real machines, one per worker, on Fly. A separate app and a token scoped to it, with a spend cap. Fly billing has blocked us before on ControlTower, so the account limit needs checking too.

Unblocks: desks on staging, then zones that run code.

The pilot runs work on Claude as an explicitly chosen rung. scripts/eval-rung.ts replays 30 delivered TPS tasks through the RunPod Execute rung and grades them. Execute moves to RunPod only if it lands within 5 points of Sonnet. The script never flips anything on its own.

Needs first: about 30 real deliveries from the pilot, so roughly two pilot weeks.

Step 2 gives workers a small slice of the graph as context, behind a per-org switch that stays off unless the eval shows it helps (3 days). Step 3 adds affinity to routing and a taint walk, so a delivery that read outside mail can be traced and flagged (3 days). Step 3 matters before outside mail is on in live.

Needs first: step 2 needs the eval from decision 5. Step 3 needs nothing.

Every push since 18 Oct ends in startup_failure after 0 seconds. That pattern usually means a billing or spending limit on the account, not the workflow; we have not verified it. Until it runs, the only test gate is the run on the local VM.

Unblocks: an automatic check on every push before anything merges to main.

The product site build is ready but not deployed, and the apex domain step at Namecheap is the one thing it waits on. It does not affect the app.

Unblocks: the refreshed product pages on the real domain.