Skip to main content

Self Top-up Improvement — Test Case Gap Analysis (vs. PRD, RFC, Task Breakdown & JIRA)

Generated: 2026-07-21 19:11 WIB (UTC+7) · AUGFLOW-187

Scope analyzed: bifrost/self-topup/testcases/self-topup-improvement.md (TC-001–TC-047) and bifrost/self-topup/testcases/self-topup-max-purchase.md (TC-01–TC-31) against bifrost/self-topup/prds/*.md (3 files), bifrost/self-topup/rfcs/self-topup.md + self-topup.task-breakdown.md, bifrost/self-topup/delivery/decisions/*.md + delivery/status/*.md, and Jira epic BIF-7797 (live state, 2026-07-21).

Status: 5 parallel investigations across hub-chat, hub-core, qontak-billing, moderator-be, hub-service + a live Jira sweep, then direct primary-source reads of the highest-stakes files, then one adversarial verification pass (Step 4) with fresh context. All four findings put to that pass came back CONFIRMED; one (the confirmation-popup finding) came back with stronger evidence than the draft had. Corrections/additions from that pass are folded in below.

0. Ground truth​

Design-pivot timeline (each claim cited):

  • 2026-06-29: Confluence PRD reformatted to Qontak ADJUSTMENT template (PRD v1.1); billing_version string corrected "3" → "3.0.0".
  • 2026-06-30 / 07-01: Task-breakdown v2.0–v2.3 — reconciled as-built against 5 repos, corrected Epic (BIF-5840→BIF-7797), found 10/10 PRD-cited Stories resolved Done in Jira (as of 07-01).
  • 2026-07-02: RFC published with an embedded independent security review the same day — 11 findings (SEC-F1–F11), 4 rated Critical/High and required "before Internal Alpha."
  • 2026-07-07 (code pivot the docs don't know about): commit 5f3f7cbd83 (BIF-8705) changed the V3 routing gate in hub-core/app/core/domains/interactors/billings/orders/user_create_top_up_order.rb:41 from AND to OR between the global billing_new_topup flag and the per-org bifrost_new_topup setting. Confirmed via direct read of hub-core/app/core/domains/services/preference.rb:61-71 (and re-confirmed adversarially) that the flag-check call site passes no organization_id, so it resolves to a bare fleet-wide Flipper.enabled?. This postdates the RFC's own security review by 5 days and widens exactly the gate SEC-F1 already flagged as Critical.
  • 2026-07-09 to 07-13: three more hub-chat commits (service-fee/tax-base change, credit-type excess pricing fix, a UI-alignment pass that created TopupOrderSummary.vue and rewrote TopupDynamic.vue/TopupDynamicStep2.vue) — none reflected in the task-breakdown's "Non-PRD scope additions" table, which stops at BIF-8558.
  • 2026-07-20: delivery status doc itself documents drift ("the previous 'only BIF-8382 remains' statement is stale").
  • 2026-07-21 (live, this analysis): BIF-8844 progressed to In Testing; BIF-8845 remains To Do and spawned a clone (BIF-9013); and — not caught by either internal doc — BIF-7879 (STP-S01) is Waiting Confirmation, not Done, contradicting both docs' "10 of 10" claim.

What's current now: the task-breakdown's "materially complete, QA-gated only" framing is directionally right for STP-S02, S03, S06 (partially), S08 (partially), S09, but wrong in three specific, evidenced places: (1) STP-S01's own Jira story isn't closed, and the mechanism it covers weakened after the RFC's security review, not before it; (2) STP-S07's confirmation-popup requirement was never built, at any point in git history — the task-breakdown's evidence citation for it is a misattribution to an unrelated modal; (3) two sibling PRDs (BIF-8787, BIF-8788) sit entirely outside this reconciliation's scope with zero engineering start. The test-case suite (testcases/self-topup-improvement.md) has no version marker, so it can't be dated directly against these pivots — but its content matches the RFC/PRD's original design intent, not the shipped reality, for S01 and S07 specifically.

1. Missing test cases​

#GapWhy it mattersAnchor
1.1No TC exercises the Mekari Billing pricing cache-poisoning failure modeRFC's own Failure Mode Catalog (§3.A) documents "Mekari Billing API unavailable at cache miss" as an expected, designed-for failure — but the actual behavior is worse than documented: qontak-billing/internal/app/usecase/topup_configuration/fetch_configuration.go:82-140 caches the partial/empty result unconditionally, confirmed by an executed test showing dataCount=0 cached for a full-hour TTL. Only the happy path (TC-006/007) is tested.fetch_configuration.go:82-140; executed test run log
1.2No TC targets MUV or User-Quota excess specificallySTP-S08/PRD names 5 balance types for excess display (wa_balance, muv_extra, agent_extra, chatbot_ai_extra, voice_call_extra); TC-042/043's precondition ("at least one component") passes trivially without ever exercising MUV or User Quota, and ExcessQuotaTopup structurally has no repository method for either — confirmed twice, independently, including under adversarial re-verification (querier.go lists exactly 3 GetRemaining* methods; MUV-adjacent methods exist for other purposes but none computes excess).excess_quota_topup.go:26-58; querier.go (GetRemaining* list)
1.3No TC covers any of SEC-F1–F6All 6 assessable security findings from the RFC's own review remain open in code, yet none of the ~78 combined test cases exercises a routing-gate bypass, a tampered-Redis-price scenario, a double-submit/idempotency case, an entitlement-bypass POST, an oversized-qty submission, or a silently-skipped Paid PI.user_create_top_up_order.rb:41; fetch_config.rb:9-22; new_billing_topup.rb
1.4No TC exercises the custom-MCC WA-minimum override branchFinancesTopupPage.vue:293: minimumTopup.value.wa_balance = mcc?.is_enabled ? mcc.minimum_value : 1000000 — the 1,000,000 minimum is only the default; a per-CID override path exists and has zero coverage. TC-011/012/013 all assume the default.FinancesTopupPage.vue:293

2. Test cases that exist but are not complete enough (or now assert the wrong thing)​

TC rangeStoryProblem
TC-037, TC-038, TC-039STP-S07Confirmed absent, adversarially re-verified with fresh git-history search. These assert a pre-submit "confirm your payment, redirected to Mekari Pay" popup. It does not exist anywhere in current code or at any point in this feature's git history (checked from the feature's very first commit, 61c42247a). TopupDynamicStep2.vue has no submit button; FinancesTopupPage.vue:handleNext() calls handleSubmit() directly at step 2 with zero modal in between; TopupModals.vue contains only an exit-confirmation modal and a post-submit response modal. Root cause of the doc drift, found under adversarial re-check: the task-breakdown cites ticket BIF-8558 as evidence this popup shipped — but BIF-8558's actual diff (39f89e736) modifies the post-submit "Awaiting payment" response modal, and that commit's own test file names its describe block "FinancesTopupPage.vue — confirmation modal (BIF-8558)" — engineers were colloquially calling the post-submit modal "the confirmation modal," and the task-breakdown read that ticket title as evidence of the pre-submit payment-confirmation popup the PRD describes. Two different UI elements, conflated. TC-035 and TC-036 (order details / shipping info shown) were individually re-read and remain accurate — not swept into this finding.
TC-016–TC-019STP-S03Individually re-read: all four are behaviorally accurate, but the mechanism differs by flow without the TCs distinguishing it — legacy flow hides MUV via a frontend-computed flag (isToggleForHideMUV); the new dynamic flow relies entirely on the backend omitting the row (component-code filtering server-side in qontak-billing). A regression in either could pass/fail independently of the other.
TC-011–TC-015STP-S02Individually re-read: TC-011/013/014/015 hold as written. TC-012 ("999999 shows error") is correct only for the default-minimum path — it doesn't test the custom-MCC-override branch (see Missing 1.4), so it's incomplete rather than wrong.

What does not need re-writing beyond the above: every other TC range checked (TC-001–010, TC-020–034, TC-040–047) was read individually and found either accurate against current code or already covered under §1/§3 as a different category of finding (missing coverage or implementation gap, not a wrong assertion).

3. Gaps in the implementation (test cases/stories exist, but engineering's task breakdown missed them — or tracked-but-still-open)​

#FindingEvidence
3.1BIF-8787 (MAXPUR-S01) — TC-01 through TC-18 (18 cases) have zero engineering task anywhere. Confirmed by exhaustive grep across all 5 checked-out repos (hub-chat, hub-core, qontak-billing, moderator-be, hub-service) for max_purchase/maxPurchase/purchase_limit/purchase_count — zero hits; no DB column for a purchase cap exists anywhere, even at schema level.Jira: To Do, High-P1, zero subtasks, zero issue links (live-confirmed)
3.2BIF-8788 (RECUR-S01) — TC-19 through TC-31 (13 cases) have zero engineering task anywhere. The only adjacent artifact, package_type, is a fixed classification string already used for STP-S05/S06 — confirmed dead code (not even SELECTed by the only query against the table).Jira: To Do, High-P1, zero subtasks/links, and the ticket's own description still carries 2 unresolved Open Questions — requirements aren't locked, let alone engineered
3.3STP-S04 contract-end-date (TC-023) — this one is tracked, not silently missing (task-breakdown Task L2 item 1 / Task L4 conditional fix). But independently confirmed by two separate investigations plus a direct read: neither side of the integration has the field — hub-core's outbound Paid-PI payload (user_paid_topup_invoice.rb:211-220, 8 keys) and moderator-be's inbound CreatePi dry-validation contract (create_pi.rb:2-13, same 8 keys) both lack end_date/period_end/contract_end_date. A third leg (the actual billing-mekari/M1 consumer) isn't checked out anywhere in this workspace to confirm it could even accept the field if added.user_paid_topup_invoice.rb:211-220; create_pi.rb:2-13
3.4STP-S08 excess for MUV/User Quota — same underlying fact as Missing-1.2, restated as an implementation gap: the story is Done in Jira (BIF-8175) but 2 of the 5 named balance types have no excess-computation path at all, confirmed at the repository/querier layer, adversarially re-verified.excess_quota_topup.go, querier.go

4. Test cases available, PRD needs update​

#PRD sectionWhat's staleStatus of the fix
4.1PRD §6 / §8.2 STP-S07 (Review Order confirmation popup)The PRD/RFC describe a pre-submit confirmation popup as a shipped, Done feature (§2 above). This needs a DRI call, not a silent PRD edit: either (a) it was an intentional simplification during the BIF-8324/post-RFC UI-alignment passes and the PRD should be updated to describe the actual click-through flow, or (b) it's an unintentional regression and belongs as a bug, not a doc fix. Fully open — source alone can't determine which; see Open Items.
4.2PRD OQ-1/OQ-2 (User Quota package codes, "Blocker — TBD")This is the inverse of the usual case. The PRD's "still blocked" framing is arguably still accurate — no migration/seed anywhere in qontak-billing populates a real agent_extra package code (confirmed, adversarially re-verified: zero INSERT statements for this table anywhere in version control, and the Go-based seeder function is an empty no-op). It's the task-breakdown's "BIF-7898 (Done)" claim that has drifted from what's in source control, not the PRD. Partially/informally landed at best — cannot rule out an out-of-band DB seed in staging/production, but nothing in version control corroborates it.

What does not need a PRD update: the Non-Goals (§3 — mobile, downgrade, payment-page-unchanged) all still hold; the V3 billing_version gate concept (§4 Constraints) remains directionally correct even though its enforcement has a confirmed code-side security gap (SEC-F1) — that's a security finding, not a PRD-accuracy issue; the 5-balance-type scope (§6) is still the right target, even where 2 of 5 aren't fully wired for excess (an implementation gap, §3 above, not a staleness issue).

5. Open items for you to weigh in on (not silently resolved)​

  1. Was the STP-S07 confirmation popup intentionally dropped, or is it a regression? Undetermined from source alone — git history shows it never existed at any commit, which argues against "dropped after being built," but doesn't rule out "designed away before ever being implemented, informally, without a PRD/RFC update." Recommend asking the FE lead/DRI directly. Default absent other input: treat as a real gap requiring either a fix or an explicit descope, not close it out silently.
  2. Are BIF-8787/BIF-8788 in scope for the 26Q3 commitment? Both are High-P1 with zero engineering start and (for 8788) unresolved requirements. This is a PM/TPM scope call, not something this audit should default on its own.
  3. Is agent_extra's package code actually seeded out-of-band in staging/production? Cannot be confirmed from source. If yes, the PRD's "Blocker — TBD" framing should be closed with a pointer to wherever that seed lives (a runbook, an admin-tool action); if no, this blocks STP-S04 in any real environment today.
  4. Does BIF-7879's Waiting Confirmation status relate to the AND→OR routing-gate change? The timing is suggestive (gate changed 2026-07-07, story still open 2026-07-21) but there is no direct evidence connecting the two — worth a direct question to whoever owns that story before assuming causation.

6. Traceability matrix (condensed, by story)​

StoryJira StoryTCsVerdict
STP-S01BIF-7879 — Waiting ConfirmationTC-001–003Implemented, but routing gate weakened post-RFC (AND→OR) and story remains open — consistent with an unresolved concern, not just paperwork lag
STP-S02BIF-7871 — DoneTC-011–015Solid; one uncovered branch (custom MCC minimum override)
STP-S03BIF-7872 — DoneTC-016–019Solid; mechanism differs by flow, TCs don't distinguish
STP-S04BIF-7873 — DoneTC-020–023Confirmed gap: contract end_date absent on both sides of the hub-core↔moderator-be integration
STP-S05BIF-7874 — DoneTC-024–029Code path exists; no committed seed data for the Voice row (min_value/package_code)
STP-S06BIF-7875 — DoneTC-030–034Same seed-data gap as S05; ×1000 scaling is entirely data-driven with no data in version control
STP-S07BIF-7876 — DoneTC-035–039TC-035/036 solid; TC-037/038/039 assert a mechanism that has never existed in shipped code
STP-S08BIF-8175 — DoneTC-042–047Implemented for 3 of 5 balance types; MUV and User Quota excess absent at the data-access layer
STP-S09BIF-7869 — DoneTC-006–007Core happy path solid (87.9%/100% test coverage); cache-poisoning failure mode has zero TC coverage
MAXPUR-S01BIF-8787 — To DoTC-01–18Zero engineering anywhere across 5 repos
RECUR-S01BIF-8788 — To DoTC-19–31Zero engineering anywhere across 5 repos; requirements still open

7. Verification note​

Step 4's adversarial pass ran with genuinely fresh context (a separate agent given only the 4 draft findings + file paths, explicitly instructed to refute, not confirm). Result: all 4 findings put to it came back CONFIRMED — none was weakened or withdrawn. One (Finding A, the confirmation popup) came back strengthened: the adversarial pass found the exact misattribution mechanism (BIF-8558's own test file names its describe block "confirmation modal") that the first pass had not cited. The adversarial pass also independently checked the legacy flow (TopupStepTwo.vue, useTopupOrder.ts) for the same popup and confirmed its absence there too, which the first pass had not explicitly checked. No finding required correction or was withdrawn as a result of this pass.