Skip to main content

0002 — Chunk Centralized SSO Token into Phase 1 (Q3, Launchpad) and Phase 2 (Q4, rest)

Delivery / Program Management — decision record (ADR-style).

Context​

Centralized SSO Token (Epic BIF-7802) is an all-FE-owned initiative on Syafrizal M., sized at 37.5 md total (FE 23 · BE 4.5 · QA 10) across four consuming surfaces that reconcile exactly against their per-repo task-breakdowns (rfcs/cross-repo.task-breakdown.md §1):

RepoTotalFEBEQA
Launchpad FE (pilot — Rollout step 4)9.56.50.52.5
CRM FE (step 5)9.55.52.02.0
Hub FE (step 5)7.05.002.0
Hub Chat v2 FE (step 5)11.56.02.03.5
GRAND37.523.04.510.0

The initiative's full FE 23 md is the single largest line item in Syafrizal M.'s Q3 load and is the direct cause of his over-commit (63 committed ÷ 52 effective = 1.21, ~11 days over; bifrost/delivery/capacity.md). It is also the FE serial-last item on his queue after the 2026-07-01 resequencing and was downprioritized to P12 on 2026-07-08 (decision 0001) as a no-instant-customer-value tech-debt effort. Launchpad is the cross-repo anchor and the pilot (Rollout step 4) — the other three surfaces onboard only after the Launchpad pilot proves the SDK (step 5).

Decision​

We chunk the initiative into two phases, keeping it as a single initiative (one folder, one jira_epic: BIF-7802, one set of per-repo RFCs — the folder is the durable identity):

  • Phase 1 — 2026-Q3: Launchpad only. FE 6.5 · BE 0.5 · QA 2.5 = 9.5 md. This is the pilot surface and the cross-repo anchor; it is the slice that must land first regardless.
  • Phase 2 — 2026-Q4: CRM + Hub + Hub Chat v2. FE 16.5 · BE 4.0 · QA 7.5 = 28 md. The three step-5 consumer surfaces move out of the Q3 window; they get picked up in Q4 planning.

The initiative's honest total stays 37.5 md on the README/timeline/roadmap (no scope is cut). Only the scheduling window of Phase 2 changes. This was agreed to address Syafrizal M.'s Q3 over-capacity — with only Phase 1's FE 6.5 remaining in Q3, his forward FE load clears to under.

Consequences​

  • Capacity (bifrost/delivery/capacity.md) — Q3 counts Phase 1 only; Phase 2 excluded as Q4-deferred (the same documented-exclusion mechanism self-topup's as-built FE uses in a doc titled "Capacity Plan 2026-Q3"):
    • Syafrizal M. (FE): 23 → 6.5 committed on this initiative → total 63 → 46.5 ÷ 52 = 0.89, under. This is the arithmetic that clears his over-commit. The unsized adhoc-q3-2026 FE stories now have real headroom to land against rather than piling onto an over-capacity engineer.
    • Satya (BE): 4.5 → 0.5 → total 33.5 → 29.5 ÷ 52 = 0.57, under.
    • Yoddi (QA): 10 → 2.5 → total 49.5 → 42 ÷ 52 = 0.81, under.
  • README keeps the full effort_* fields (37.5) and gains a ## Phasing body section recording the Phase 1 / Phase 2 split, per-repo effort, and quarter windows.
  • Timeline milestone table marks Launchpad = Phase 1 / 2026-Q3 and CRM · Hub · Hub Chat v2 = Phase 2 / 2026-Q4; the Allocation and E2E-gate notes are updated.
  • Roadmap keeps the 37.5 effort rollup (mirror of the README — a lint invariant) and updates the P12 note + program-risk / capacity-summary bullets that cited the 63/1.21 over-commit.
  • Health stays at-risk. Chunking removes the capacity driver but not the other one: the external Session Manager staging gate (SB-2) owned by SSO/Account still blocks Phase 1's end-to-end verification. Do not read this as on-track.
  • Q3 E2E-fit risk largely dissolves. With only Launchpad's 2.5 md E2E in Q3 (was the full 10 md), the Lane-B "integrated FE must finish by ~W10.3" pressure no longer binds this quarter.
  • Phase 2 (28 md) is deferred, not dropped. It stays visibly tracked via the README ## Phasing section, the Q4 timeline milestones, and this ADR. There is no Q4 capacity plan yet — Phase 2 staffing/scheduling is picked up in Q4 planning. qa_lane: B is unchanged.
  • Priority (P12) and target_quarter: 2026-Q3 are unchanged — the initiative's first landing (Phase 1) is still Q3; only Phase 2's window is Q4.