Skip to main content

0001 — One CID Multiple WABA (BIF-6428) Jira "Done" vs. plan-open conflict

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

Context​

The Epic BIF-6428 ("One CID Multiple WABA") has shown status: Done on the Jira board since Sprint 1's first reconciliation pass (2026-07-07), with zero children in-sprint. Every Sprint 1 sprint-plan row that treats this initiative as live, open work — Grehasta's BE queue (#2/#3 across Sprint 1/2), Syafrizal M.'s FE queue (blocked on the RFC review HOLD at Detail 2.F), and Izzul's QA queue (#2) — has continued to disagree with the board.

This is finding F-1 (blocked-done-conflict) in the Sprint 1 reconciliation ledger (bifrost/delivery/reconciliations/2026-07-06-sprint-01/). It has now been escalated across all 7 Sprint 1 reconciliation passes (2026-07-07 through 2026-07-17) with no response — past Sprint 1's own retro action #1 ("any finding still open on its 3rd recheck must route to a decisions/ ADR, dated status/ risk, or descope — not carry to the 6th+ pass"). The RFC itself is still status: draft (reviewed at 7.0/10 — BE PROCEED, FE HOLD on Detail 2.F component contracts/frames/UI states), and the initiative carries FE 7.0 · BE 12.5 · QA 6.0 = 25.5 md in capacity.md, landing on Grehasta (BE), Syafrizal M. (FE — already over capacity, no open slot regardless), and Izzul (QA).

Two possibilities, neither yet confirmed:

  1. The board is right and the plan is stale — the Epic is genuinely finished (or intentionally closed/deprioritized) and the docs (roadmap ## Priority P11, the initiative README, the engineer queues) should be updated to match, freeing Grehasta/Izzul from a phantom queue item and removing the FE HOLD as a live blocker.
  2. The board is wrong and the plan is right — BIF-6428 was closed prematurely or in error (e.g., a bulk-close, a mis-scoped duplicate, or Epic-vs-Story confusion) and should be reopened
    • re-pulled into the active sprint, with its children re-linked.

Sprint 2 planning (this repo, 2026-07-19) cannot resolve this from repo evidence alone — it requires the DRI to check the actual delivered scope against the RFC/PRD.

Decision​

A third option, confirmed 2026-07-19 by direct code-evidence audit (not repo docs alone): neither "board right, plan stale" nor "board wrong, dev still fully open" is quite true. BIF-6428 is genuinely the right epic for this initiative (its child Stories BIF-6919..BIF-6925 map 1:1 onto the RFC's WABA-S01..S07), and most of its child Tasks are legitimately Done and code-corroborated:

  • Done + code-corroborated: organization_package_id FK column (BIF-7169/7170, migration 20260113000000_add_organization_package_id_to_whatsapp_packages in qontak-billing), WABA-ID lookup + feature-flagged package lookup (BIF-7172/7173), contract renewal carry-over (BIF-7200), Postpaid Limit reset/aggregation (BIF-7204), waba_id in Broadcast/Conversation reports + CSV export incl. FE columns and QA execution (BIF-7210–7216, real merged commits in hub-service PR #2811 and hub-chat PR #1773), low-balance threshold update for the shared pool (BIF-7221).
  • Falsely marked Done: BIF-7223 "View Shared Balance Tooltip" — the only commit tagged with it (hub-chat 16343de66) only adds waba_id report columns; no SharedBalanceTooltip component exists anywhere in hub-chat. This is a real Jira/code mismatch, not just stale bookkeeping.
  • Explicitly descoped (Won't Fix), not built: aggregated balance display component, balance transaction history page, several QA test-plan tasks (BIF-7171, 7174, 7197–7199, 7201–7203, 7205–7206, 7217–7218).
  • Critical structural gap, not yet started: the 20260113000000 migration added the FK column but created idx_whatsapp_packages_organization_package_id as UNIQUE — this still structurally prevents 2+ WABAs from sharing one balance pool, the initiative's core value proposition (RFC Phase-1 Task 3/4: drop-unique-index + package-creation logic + backfill, 5.0 md, currently 0% per the RFC and confirmed absent in qontak-billing/hub-core). Also unstarted: the net-new balance_below_zero alert (qontak-billing), billing_version/show_waba_id store gating and the MCC filter/tooltip/banner FE components (all hub-chat, blocked on RFC Detail 2.F).
  • All 7 parent Stories sit at Waiting Confirmation, not Done — the Epic-level status: Done glosses over this. This is the real substance behind Sprint 1/2's blocked-done-conflict (F-1): the board wasn't simply wrong, and the plan wasn't simply stale — the Epic was closed with real completed work but real open work (the core sharing mechanism + Story confirmation) left inside it.

Resolution: BIF-6428 stays closed as the (mostly-complete) Phase-1 build epic. A new Epic, BIF-8910 ("26Q3 BIF – One CID Multiple WABA Rollout"), owns the 26Q3 remainder as one combined scope: the core sharing-mechanism gap (highest priority — rollout cannot proceed while the unique index blocks multi-WABA pooling), the other residual dev items above, and confirming/closing the 7 Waiting-Confirmation Stories via collaborative/UAT testing ahead of phased customer rollout.

Consequences​

  • Initiative README updated: jira_epic moves to BIF-8910 as the live executable anchor; BIF-6428 is recorded in the README body as the completed prior-phase epic for traceability. Progress is not set to 0% or 100% by fiat — the real, mixed state above is the record; a dated status entry captures it for the next cache refresh per the progress-evidence doctrine. RFC status stays draft (Detail 2.F still open) — nothing here resolves that HOLD.
  • Sprint 2 queue rows (Grehasta, Syafrizal M., Izzul) should stop citing this as a flat Jira Done / zero children blocker — the real state is "epic closed with real open work reassigned to BIF-8910" — but per sprint doctrine those free-form ledger updates and F-1's closure are left to the next sprint-resync pass, not hand-edited here.
  • F-1 is not closed by this ADR. Per sprint doctrine only a fresh sprint:reconcile recheck closes a findings-ledger entry; this record gives that pass the resolved context (BIF-8910 exists, scope is defined) to do so.
  • This ADR is the artifact retro action #1 asked for — F-1 should not carry to an 8th reconciliation pass without at least this record showing the decision is made and acted on.