Skip to content

T 026

uid: T-026 title: Re-introduce the firestore.rules CI auto-deploy workflow status: done area: auth-rbac created: 2026-06-13 updated: 2026-06-23 related: T-022

RBAC sequence: supporting tooling for T-022's Rules deploy β€” no hard precede/succeed: the strict Rules can ship via manual firebase deploy, so this only AUTOMATES it and can land independently (currently blocked on cross-session coordination). See the sequence map in T-022. (Marked by EOP Local Assistance, 2026-06-23.)

Goal

Bring back the GitHub Actions workflow that auto-deploys firestore.*.rules on push, so the strict Rules authored in T-022 actually ship without manual firebase deploy.

Context (SA agent, 2026-06-13)

  • Scaffolding is ALREADY in place: SA firebase-rules-deployer@ (role firebaserules.admin only) + GH Actions repo secrets FIREBASE_DEPLOY_KEY + FIREBASE_ADMIN_PROJECT_ID.
  • The workflow FILE was reverted at commit 93e64a2 on branch claude/audit-user-access-control-cch7t. The user-access-control session was meant to re-introduce it β†’ coordinate there, NOT with the SA agent.
  • firebase.json already maps per-DB rule files (firestore.tebs-erl.rules, tebs-mel, tebs-epl, aote-system) β€” the workflow likely needs a glob over firestore.*.rules.

Log

  • 2026-06-13 created (split out of T-022). Blocked on cross-session coordination.
  • 2026-06-23 closed β€” workflow shipped via the user-access-control session ([[#420]]).

Decision log

2026-06-23 β€” closed (workflow shipped via [[#420]])

  • βœ… Attestation (User Management): read AGENTS.md; checked the board by scope β€” T-026 was the blocked-on coordination this session held; closing because the work landed.
  • Source: User Management Β· https://claude.ai/code/session_01GGT5n9vCxKWoUQSRAfMSiW
  • Proposed by: User Management. Approved by: the owner.
  • Outcome / verdict: the GH Actions workflow file .github/workflows/deploy-firestore-rules.yml (90 lines; firebase deploy --only firestore:rules on push to main touching firestore.*.rules, firebase.json, or .firebaserc) was restored at commit d4da0a0 on branch claude/audit-user-access-control-cch7t, squashed into 22cf2bf on main via PR #420. Cred prerequisites (FIREBASE_DEPLOY_KEY + FIREBASE_ADMIN_PROJECT_ID in the repo's GH Actions secrets) were staged by a local agent on 2026-05-14 before the file was re-introduced. Verified: the workflow file is present on main at the documented path; the workflow fired green on the PR #424 firestore.aote-system.rules edit shortly after #420 merged.
  • Why the path was this and not the original revert-author re-introducing: the original revert (93e64a2) explicitly noted "until creds are ready"; once a local agent staged the SA + secrets, re-introducing the file was a 1-file commit on top of the already-open audit PR β€” cheaper than spinning a new PR.
  • Blast-radius note for other agents: every future push to main (including PR squashes) that touches firestore.*.rules, firebase.json, or .firebaserc now auto-runs firebase deploy --only firestore:rules against project aote-pms. Agents editing those files should expect their merge to ship Firestore rules to prod within a couple of minutes β€” verify in Actions β†’ "Deploy Firestore rules" after every such merge. If the workflow fails, the most likely cause is a bootstrap admin missing the role: admin | super_admin custom claim β€” see PR #420's test-plan note. The firebase-rules-deployer@aote-pms SA holds only roles/firebaserules.admin, so a compromised workflow can't touch Firestore documents, IAM, or any other GCP surface.
  • Evidence β€” owner, 2026-06-23 (verbatim):

    "Proceed with with 1-3 first then" (in reply to my task-triage recommending: 1) close T-026, 2) T-094, 3) T-095)