mirror of
https://github.com/dohooo/helmor.git
synced 2026-09-22 16:40:02 +08:00
Caspian Zhao
6a80be25b1
The F-B lockout (live-verified in class1 run #2): provision rotated HELMOR_COMPANION_TOKEN via 'secret put' BEFORE deploy/verify, and the desktop only receives the token on the terminal 'deployed' line — so any mid-run failure stranded the Worker on a NEW token the desktop never saw (desktop/Worker/container three-way mismatch, existing teams only). Fix (architect-approved failure matrix in class4-design.md par.2): reuse-or- generate. On a RE-provision the frontend passes the desktop's stored admin token (getTeamAdminToken) -> deploy_team_cloud forwards it to the script as HELMOR_EXISTING_COMPANION_TOKEN (env only, never logged) -> provision reuses it, so 'secret put' writes the value the desktop ALREADY holds. After that point every failure row has desktop == Worker; a pre-existing F-B mismatch even self-heals (the put forces the Worker back to the desktop's value). The step ORDER is deliberately unchanged: rotate-then-put stays for FRESH teams (nothing held -> nothing to lock out; 'wrangler secret put' before the first deploy also auto-creates the draft Worker, a load-bearing behavior both rollouts exercised). F-C's 401 propagation grace and destroy-warm keep their semantics — on the reuse path the propagation window physically disappears (same value), on the fresh path they still do their verified job. Forced rotation remains reachable via Leave team -> Create team (clears the token). resolveAdminToken extracted pure (cloud/scripts/admin-token.ts) with unit tests; the frontend wiring is pinned by team-create-flow tests (red-verified against the unwired call).