RFC Review: Centralized Web Session — CRM Frontend Integration of mekari-account-web-sdk Session
Executive Summary
- Overall Score:
7.5/10 - Rating:
Needs Work - RFC Type:
frontend - Sub-Type:
enhancement - Assessment Confidence:
High - Applied Caps/Gates:
CNT = 6.5 (below 7.0 → no soft cap triggered). No hard cap fired; overall held to 7.5 by judgment — 3 critical blockers remain (Q2–Q4, down from 4), and a new upstream security finding (Q10) is tracked separately and does not block CRM's own execution chunks. - Implementation Readiness Verdict:
HOLD — resolve Q2–Q4 (critical) before full agent execution; chunk 5 (observability) and the shell of chunk 2 (plugin scaffold + toggle gate) are independently executable now - Report Path:
/Users/mekari/Documents/crm/rfc-review-report.md - RFC Author:
Qontak CRM Frontend| Reviewed:2026-06-28| Re-reviewed:2026-07-02(latest review SDK reconciliation)
Re-review note (2026-07-02): the version of this review dated 2026-06-28
scored and praised an RFC contract that turned out to be fictional — package
@mekari/sdk, a CDN alternative at account.mekari.com/sm/sdk.js, constructor
option current_user, a switch_user event with an "interim vs seamless
SSO-autologin" decision (D5), a session.refresh() method with a
router-afterEach refresh hook, and a CRM-owned msli/_mekari_account
fallback helper. None of this exists in the real SDK
(mekari-account-web-sdk v0.3.0). The original review did not consult the SDK
source — it only checked internal consistency and CRM-repo anchors, both of
which were sound, but the contract itself was wrong, which is a correctness
blocker, not the "pending dependency" framing used at the time. This review
has been re-scored against the corrected RFC (grounded in
mekari-account-web-sdk v0.3.0 session.ts). The repo-anchor verifications
(file:line evidence for userLogout, custom_features, plugin registration,
etc.) were correct then and remain correct now.
This RFC is a disciplined integration spec: it carries a full Repo Reading
Guide (§2.0), a Source Verification table that distinguishes verified anchors
from UNVERIFIED unknowns, seven ADR blocks (two now resolved as "not a CRM
decision" once the real SDK contract was known), a per-story change map, and
a numbered rollback recipe. An AI agent could execute chunk 5 (observability)
and the shell of chunk 2 (plugin scaffold + toggle gate) today without asking
a question. It cannot complete the integration's core purpose —
constructing new Session({ currentUser: ssoId }) — because the source of the
SSO id in CRM's /users/me response is explicitly UNVERIFIED (§2.0 Source
Verification, Q2). The biggest strength is anti-hallucination honesty: every
unknown is flagged rather than invented, and the correction pass replaced
every invented SDK behavior with the verified real contract rather than
patching around it. The remaining gap is that one of the three original
decisions (D7 current_company) is still genuinely blocked pending a
cross-team contract, plus two unresolved verification items (Q2, Q3) and one
newly-recorded, non-blocking upstream security finding (Q10: the SDK does not
validate event.origin and CRM has no way to add that check itself). The one
thing that must change before agentic execution: confirm the SSO id's field
path in /users/me (Q2) — without it the SDK input is a guess and the
logged_in/logged_out comparison is against an unknown.
Quick Verdict
Why this RFC can be implemented agentically:
- Scope, file list, plugin registration point (
nuxt.config.js:58), and reuse targets (store/user.js:userLogout) are pinned to verified line numbers. - The event contract is now correct and minimal: one
session.on("event", (data) => …)subscription, three possibledata.statusvalues, no second callback argument — this is easier to implement than the original four-event, two-argument fiction. - Each execution chunk (§4.C, 5 chunks after the
msli-helper chunk was removed) has an assertable acceptance criterion tied to a realpackage.jsonscript.
Why this RFC will cause agent guessing or rework:
- The SDK constructor input
currentUser(the CRM user's SSO id) has no verified source — agent would guess a field on$auth.user(CNT, Q2). - Exact
centralized_sessioncode string and the git ref/credentials formekari-account-web-sdkare placeholders (DEP, Q3/Q6). current_companysync remains a genuine cross-team dependency — the SDK itself has no company API, so no amount of SDK-side re-reading resolves it (TDC, Q4).
PRD → RFC Traceability Matrix
PRD exists (Confluence driver RFC, linked §1.5). Standard format applies.
| PRD Element | RFC Section | Coverage |
|---|---|---|
| Overview / known stale-session issues | §1.1 | Full — CRM-relevant cases mapped (logout, switch account) |
| Success Criteria | §1.2 | Partial — FE-slice subset; SDK/Redis criteria correctly excluded as A&L-owned |
| Out of Scope | §1.3 | Full — inherited + CRM additions |
| Dependencies (SDK, SM, Redis) | §2.0 / §5 | Partial — SDK consumed via the correct git-install path; SM+Redis flagged as A&L deps (Q6 git-access confirmation open) |
| How to use the SDK | §2.4 / §2.2 | Full — mapped to plugin + single session.on("event", …) |
Local Storage (msli) | §2.3 | Full — correctly reassigned to SDK-internal ownership; no CRM artifact |
| SDK event contract (3 statuses) | §2.4 Inbound | Full — all three (logged_in/logged_out/server_down) handled with payload + CRM action; the fictional switch_user is gone |
| FE Web Session Flow | §2.5 / §5 Q1 | Resolved — CRM's token-based model needs no SSO-autologin mapping; an account switch is a plain logged_out |
| OAuth2 Authz-Code Flow | §5 Q1 | Full — CRM does not use authz-code; now explicitly moot rather than blocking |
| current_company sync | §2 ADR-7 / §5 Q4 | Missing — deferred, no CRM endpoint exists, and the SDK itself has no company surface (Q4 critical) |
| Database Model (no changes) | §2.3 | Full — confirmed no DDL |
| HA & Security | §3 | Partial — FE CSP/origin corrected to sm.mekari.com; a genuine upstream origin-validation gap is now recorded (Q10) instead of a mandated-but-impossible CRM-side check |
| Rollout Plan | §4 | Full — CRM = step 5 post-Launchpad |
Summary: ~12 of 13 mapped PRD elements fully covered or resolved, 1 missing (current_company, the sole remaining critical-tagged cross-team item). No RFC decision lacks PRD justification — no scope creep detected. (The former "3 missing" — Web Session Flow, OAuth2 flow, User Switch Account — are now resolved because the real SDK's logged_out status already covers the account-switch case.)
Scorecard
Frontend Scorecard (11 categories)
| Category | Score | Evidence-Based Rationale |
|---|---|---|
| PRT — PRD Traceability | 8.5 | Detail 1.A gives a full bidirectional PRD-section coverage matrix; reverse mapping clean (no unjustified additions). Improved from 7.5 — the account-switch mapping ("critical gap") is now resolved instead of missing; only current_company remains genuinely unmapped. |
| TDC — Technical Decisions | 8.0 | 7 ADR slots with options + rationale + reversibility. Improved from 6.0 — D5 (switch_user) is no longer "interim pending Q1," it's resolved (folded into D4) by SDK ground truth; D6 (msli) is resolved as "not a CRM decision." Only D7 (current_company) remains genuinely deferred pending a cross-team contract. |
| CNT — Contract Specificity | 6.5 | SDK event payload is now correctly tabulated as a single {status, sessionId?} shape with three possible statuses (§2.4 Inbound) — verified against real SDK source, not invented. Improved from 5.5 because the contract itself is now right, not just internally consistent. Still docked: the constructor input currentUser (SSO id) source is UNVERIFIED (§2.0, Q2) — the single most important remaining contract hole. |
| SCB — Scope Boundaries | 8.5 | Repo Map (§2.0) names every file with create/modify/read tags; non-goals explicit (§1.3, now correctly states there is no new UI surface); "CRM frontend repository only" scope guard at top; per-story change map (Detail 1.C, now 6 stories instead of 7 — S6 msli-helper removed). Agent can produce file-by-file plan. |
| DEP — Dependencies | 7.0 | A&L deps (SM, Redis, Kong) named and bounded; reused CRM endpoints verified with line numbers. Improved from 6.5 — the dependency itself (mekari-account-web-sdk, git-installed) is now correctly named and the install mechanism is real; what remains open is git credential/ref confirmation (Q6), a smaller ask than "does this package exist at all." |
| FMC — Failure Mode Coverage | 7.5 | server_down fail-open behavior is explicit and simpler than the original two-tier (msli-then-sign-out) design (§2.4, §2.6); fail-closed toggle-read (§2.7); cross-origin logout path diagrammed. Improved from 7.0 — the former dock ("toast failure-to-render path not addressed," "no aria-live") no longer applies because there is no toast at all now (the toast was invented for the fictional switch_user). |
| NFS — Non-Functional Specificity | 6.0 | SDK init explicitly non-blocking (§3.3); security threat (iframe/CSP) modeled with the corrected sm.mekari.com host. Docked from 6.5: the original review credited "postMessage origin validation (mandatory)" as a CRM-side control (§3.1) — verified against session.ts, this control is impossible for CRM to implement: the SDK owns the window message listener internally and checks only event.data.source, never event.origin, with no consumer hook to intercept it. The RFC now correctly reframes this as an upstream infosec finding (Q10) rather than a CRM action item, which is the right call, but it means CRM ships with a real, unmitigated gap that the original review missed entirely (it assumed the mandate was achievable). CSP delivery mechanism still unconfirmed (Q8). |
| TPS — Test Plan Specificity | 7.5 | Per-chunk assertable criteria (§4.C, now 5 chunks); per-status test list (§2.4 → chunk 3); named spec files (tests/plugins/mekari-session.spec.js). The removed msli-helper spec file simplifies rather than weakens the test plan. |
| ROL — Rollout & Rollback | 8.0 | 4 staged rollout with go/no-go evidence (§4.A, now correctly gating on the sm.mekari.com frame-ancestors whitelist); numbered agent-executable rollback (§4.D) with toggle-off as instant primary lever; pre-merge command list verified against package.json (§4.B, msli-helper test-file line removed). Config contract = the toggle. |
| OBS — Observability | 7.0 | Named RUM action mekari_session.event + error on server_down (§3.2); reuses plugins/datadog-rum.js convention; post-deploy signals enumerated (§4.D). Docked from 7.5: the original review credited "error on server_down and origin-mismatch" — the origin-mismatch error is not implementable (CRM cannot observe it; see NFS), and the corrected RFC removes that claim. |
| CPA — Pattern Alignment | 8.5 | "Patterns to Follow" table (§2.0) maps every remaining concern to a reference file, with two corrected anchors (feature-flag read now cites the real .some(...)/:48–49 shape; external redirect cites only the verified redirect-to-v3.js:65 idiom, dropping the unverified version-switcher.js:13 citation); reuses userLogout, datadog-rum init, custom_features read. The msli-helper and _mekari_account-cookie patterns are removed (they no longer exist). Excellent for an enhancement — no new pattern remains at all. |
Decision Closure Assessment
Decision Index
| # | Decision | Status | Critical Gaps |
|---|---|---|---|
| D1 | SDK delivery (git-installed mekari-account-web-sdk + Nuxt plugin) | Partial | Git credential/ref confirmation unconfirmed (Q6) |
| D2 | Feature gating via custom_features code centralized_session | Partial | Exact code string unverified (Q3) |
| D3 | SDK mount point + event wiring (plugin after auth, single on("event", …) subscription) | Resolved | None outstanding |
| D4 | logged_out/server_down → reuse userLogout + SSO redirect | Resolved | Impact on other userLogout callers open (Q7, important); account.mekari.com/sign_out URL is unverified external |
| D5 | switch_user action | Resolved | None — the real SDK has no switch_user; an account switch is a plain logged_out |
| D6 | msli fallback storage | Resolved | None — msli is SDK-internal; CRM must not touch it |
| D7 | current_company sync | Dangling | Deferred; no CRM endpoint/field exists, and the SDK has no company surface either (Q4 critical) |
Aggregate: 4 of 7 Resolved (D3, D4, D5, D6), 2 Partial (D1, D2), 1 Dangling (D7). Improved from the original 3 Resolved / 2 Partial / 2 Dangling — the SDK-grounding pass resolved D5 and D6 outright; D7 is the sole remaining genuine gap because it depends on a CRM/BE contract the SDK cannot supply regardless of how carefully the SDK source is read.
Decision: D5 — Account-switch handling (RESOLVED — no longer a live decision)
Status: Resolved
The original review analyzed this as Dangling, with a full alternatives/
interface/failure-handling/challenge breakdown of an "interim sign-out + toast
vs. seamless SSO-autologin" choice (ADR-5, then tied to §5 Q1). That entire
analysis assumed a switch_user event that does not exist in
mekari-account-web-sdk v0.3.0. The real SDK has exactly three statuses
(logged_in, logged_out, server_down); it compares the iframe's ssoId to
the configured currentUser internally, and any mismatch — including a
genuine account switch — surfaces as an ordinary logged_out, with the other
account's id never exposed to the consumer. There is therefore no seamless-
vs-interim tradeoff to make, no autologin contract to define, and no
"user has changed" toast to build (there is nothing that lets CRM detect a
switch specifically). The RFC's ADR-5 now correctly documents this as a
resolution note rather than a decision, folded into ADR-4. §5 Q1 and Q5 (the
toast component confirmation, previously flagged for a11y aria-live
treatment in Priority Action 4) are closed as moot — deleted from this
review's open-items list rather than carried forward.
Decision: D7 — current_company sync
Status: Dangling
What was decided
Defer — out of FE-deliverable scope; CRM uses teams, no current_company
endpoint found (ADR-7, §5 Q4).
Alternatives considered
(a) Implement once BE exposes endpoint; (b) map to CRM team context; (c) defer — chosen. Evaluated against verified absence of any current_company field (only /users/crm_teams, /crm/teams found, store/user.js:244,261,274).
Grounding in existing code
Grounded in the absence — Source Verification marks it UNVERIFIED/absent. Now additionally grounded in the SDK's own public API surface (constructor, destroy(), on(), off() — no company method exists), which confirms this was never an SDK gap, only a genuine CRM/BE dependency.
Interface specification
N/A — deferred; no interface invented.
Failure handling
After a logged_out-driven re-login (§2.4), company context resolves via CRM's normal login — acceptable interim behavior.
Challenge results
- Reversibility: N/A (deferred).
- Consistency: Consistent — no longer tied to a
switch_userre-login path specifically; anylogged_out→re-login resolves it the same way. - Agent implementability: Agent correctly does nothing here; building it would require inventing a contract on both the CRM BE side and, previously, an SDK company API that doesn't exist either.
Gaps and suggestions
Missing: Whether CRM even has a per-company switch equivalent; need for a BE RFC.
Suggested resolution: Confirm with CRM BE whether current_company maps to a team-context switch; if a real need exists, raise a separate BE RFC and link it in S4.
Open questions for the author: Q4 — is a BE RFC required, and what is CRM's company-context equivalent?
Decision: D1 — SDK delivery into CRM
Status: Partial
What was decided
git-installed mekari-account-web-sdk (npm install git+https://...#<version>), imported in new plugins/mekari-session.js (ADR-1).
Alternatives considered
None — the SDK ships only as a bundled git dependency; there is no CDN or npm-registry alternative to weigh. (The original review evaluated a fictional "(a) npm @mekari/sdk vs (b) <script src> CDN tag" choice — neither the package name nor the CDN option exists; ADR-1 now correctly states there is no alternative to evaluate.)
Grounding in existing code
Grounded in plugins/datadog-rum.js pattern + nuxt.config.js:58 registration. The dependency name/install path is now grounded in the real SDK's own README.md/session.ts, not assumed.
Interface specification
Plugin shape specified. Constructor input incomplete — depends on Q2 (SSO id source for currentUser).
Failure handling
Toggle off / read error → fail-closed (SDK not loaded), no regression. Good.
Challenge results
- Reversibility: High — remove plugin + dep, toggle off.
- Agent implementability: Cannot run the git install until credentials/ref are confirmed (Q6) — a narrower, more concrete ask than the original "confirm it's in a private registry."
Gaps and suggestions
Missing: Confirmed git access + pinned version ref.
Suggested resolution: Verify CI/CD and local-dev git credentials for bitbucket.org/mid-kelola-indonesia/mekari-account-web-sdk; pin an exact ref in chunk 1 before any other chunk.
Open questions for the author: Q6.
Decision: D2 — Feature gating
Status: Partial
What was decided
Reuse custom_features from /users/me/feature_enabled, check code centralized_session (ADR-2).
Alternatives considered
(a) reuse custom_features — chosen; (b) env flag; (c) packageFeatures entry — both rejected with server-rollout rationale.
Grounding in existing code
Grounded: store/user.js:67 getCustomFeature, middleware/redirect-to-v3.js:48–49 read pattern (corrected in the RFC from a .find(...) shape to the real .some((f) => f.code === … && f.enabled) over store.state.user?.custom_features). Strong.
Interface specification
Read mechanism specified. Exact code string unverified (Q3) — format ambiguity between CP-QONTAKCRM-YYYY-NNNN and plain string codes (e.g. use_central_contact_data).
Failure handling
Fail-closed on read error — SDK not loaded. Good.
Challenge results
- Reversibility: High — server toggle.
- Agent implementability: Agent would guess the code string; left as placeholder (correct, but blocks the gate test).
Gaps and suggestions
Missing: Exact centralized_session code value.
Suggested resolution: Confirm with backend toggle owner; until then, parameterize the code as a constant in assets/variables/ so the guess is single-sourced.
Open questions for the author: Q3.
UI State Audit
The corrected RFC has no user-visible surface at all. The original "
switch_usertoast" was the RFC's only rendered component, and it does not survive SDK grounding — the real SDK gives CRM nothing that distinguishes an account switch from a plain logout, so there is no event to hang a toast on.
| Component | Loading | Empty | Error | Partial | Success | Assessment |
|---|---|---|---|---|---|---|
| (none — no UI surface remains) | n/a | n/a | n/a | n/a | n/a | N/A — logged_out/server_down both silently reuse the existing sign-out flow; nothing renders |
Summary: The RFC is now fully behavior-centric (statuses → store/nav only), with zero rendered surfaces — simpler and lower-risk than the original design, and the a11y gap flagged previously (missing aria-live on the toast) no longer applies because the toast doesn't exist.
Performance Budget Check
| Metric | Target | Current Baseline | Source | Assessment |
|---|---|---|---|---|
| LCP / INP / CLS | not stated | not stated | — | Not specified — acceptable: §3.3 commits to non-blocking async SDK init, no render-path change |
| Bundle size delta | not stated | — | — | Missing — adding mekari-account-web-sdk introduces a git-installed dep with unquantified size; add a budget note in chunk 1 |
Assessment: NO QUANTIFIED PERFORMANCE BUDGET — low impact for this sub-type since SDK init is async/non-blocking, but the bundle delta of mekari-account-web-sdk should be measured at chunk 1.
Accessibility Review
| Aspect | Specified? | Details | Assessment |
|---|---|---|---|
| Keyboard navigation | n/a | — | N/A — no interactive surface exists in the corrected RFC |
| Focus management | n/a | — | N/A — the only prior interactive concern (the switch_user toast preceding a forced sign-out) no longer exists |
| ARIA / screen reader | n/a | — | N/A — no toast, no component, nothing to announce |
| Color contrast / motion | n/a | — | N/A |
Assessment: No a11y surface at all now that the fictional switch_user
toast has been removed. The original review's "must announce via aria-live"
finding (Priority Action 4) is deleted, not carried forward, because the
underlying surface it was about does not exist.
Pattern Alignment Check
| Pattern | RFC Approach | Assessment |
|---|---|---|
| Third-party SDK init | follows (plugins/datadog-rum.js) | Strong — conditional gate, default-export init fn |
| Feature-flag read | follows (middleware/redirect-to-v3.js:48–49) | Strong — corrected to the real .some((f) => f.code === X && f.enabled) shape over store.state.user?.custom_features |
| Sign-out orchestration | extends (store/user.js:userLogout) | Good — adds SSO redirect to existing path; verify other callers (Q7) |
| External redirect | follows (window.location.href) | Strong — corrected to cite only the verified middleware/redirect-to-v3.js:65 idiom (the earlier middleware/version-switcher.js:13 citation was unverified and has been dropped) |
| Observability | follows (@datadog/browser-rum) | Strong — reuses service convention; the unimplementable "origin-mismatch error" claim is removed (§3.2) |
Assessment: Excellent pattern adherence — and now stronger than the
original review credited, because the msli-helper "new pattern" (previously
justified as isolated-but-new) is gone entirely: the corrected RFC introduces
zero new patterns, reusing existing conventions end-to-end.
Cross-Layer Note (frontend RFC — out of scope by design)
The SSO/Session Manager/Redis/Kong-MAG layers are A&L-owned and READ-ONLY here (scope guard). Two cross-layer dependencies leak into FE readiness and are correctly flagged: the sm.mekari.com CSP frame-ancestors whitelist must include CRM's domain before stage-1 pilot (§4.A) — corrected from the wrong account.mekari.com host in the original draft — and the current_company endpoint (Q4) is a genuine BE/SSO prerequisite for the deferred path. Additionally, the postMessage origin-validation gap (Q10) is now correctly recorded as an upstream finding against the SDK owner (Account & Launchpad) — CRM has no mechanism to fix it from its own repo, since the SDK owns the window message listener internally.
Agentic Readiness Deep-Dive
Vague Word Audit
| # | Word/Phrase | Location | Impact | Concrete Replacement |
|---|---|---|---|---|
| 1 | "[REQUIRED field — §5 Q2]" currentUser source | §2.2 | Agent cannot fill SDK input | Pin exact $auth.user.<field> path |
Total vague words in spec sections: 1 (down from 3). Removed: the
session.refresh() "throttled" interval vagueness (Q9) is moot now that the
SDK uses a fixed, spec'd interval constructor option; the toast-component
vagueness (Q5) is moot now that there is no toast.
Dangling Alternatives
| # | Alternatives | Location | Impact |
|---|---|---|---|
| 1 | current_company: implement vs map-to-team vs defer | ADR-7 / Q4 | Agent does nothing (correct) |
Total dangling alternatives: 1 (down from 2). The switch_user
"full autologin vs interim sign-out" alternative is removed — the real SDK
makes the choice moot (both "alternatives" collapse into the same
logged_out path).
Task Decomposition Assessment
| Chunk | Acceptance Criteria | Assessment |
|---|---|---|
| 2 plugin + gate | toggle off→no Session; on→Session w/ currentUser + interval; single "event" subscription registered | verifiable (but blocked on Q2 for the currentUser assertion) |
| 3 event handlers | per-status tests (logged_in/logged_out/server_down); server_down fail-open | verifiable |
| 4 logout→SSO redirect | after sign_out resolves, window.location.href set | verifiable |
| 5 observability | RUM action emitted (mock datadogRum) | verifiable |
| 1 add dependency | dep present at pinned git ref, frozen-lockfile passes | blocked on Q6 |
Assessment: Strong decomposition with dependency ordering stated (§4.C, now 5 chunks — the msli-helper chunk is removed entirely, not just renumbered). Chunk 5 and the shell of chunk 2 executable now; 1, 3, 4 gated on critical answers or the git dependency landing.
Strengths
- Source Verification table (§2.0), now doubly credible — it already separated verified anchors (with file:line) from UNVERIFIED unknowns, and this reconciliation pass additionally verified the SDK-facing claims against the real
mekari-account-web-sdksource rather than the PRD's prose alone. This is the single best agentic-readiness feature in this RFC. - Reuse-first pattern alignment (§2.0 Patterns, ADR-4) — every remaining concern maps to an existing file (
userLogout, datadog-rum, custom_features), so generated code will look native to the codebase. Stronger than before: zero new patterns remain (themslihelper is gone). - Numbered, toggle-first rollback recipe (§4.D) with server-side toggle-off as the instant primary lever and PR revert as secondary — executable without the author.
- Anti-hallucination discipline extended to the correction itself — rather than patching the wrong SDK contract in place, the RFC records what was wrong and why (ADR-1, ADR-5, ADR-6 resolution notes; §5 Q1/Q5/Q9 marked resolved-with-trace), which is exactly the traceability an agent (or a future reviewer) needs.
Biggest Gaps
currentUser(SSO id) source UNVERIFIED (§2.0, §2.2, Q2) — the SDK constructor input has no confirmed field on/users/me; only company-levelexternal_company_idis verified. Without it the entire integration object is a guess. Blocks chunks 1, 2, 3.current_companysync remains genuinely open (ADR-7, Q4) — no CRM endpoint/field exists, and now confirmed the SDK itself has no company API either, so this cannot be resolved by re-reading the SDK; it needs a CRM BE contract.centralized_sessionexact code + git access/pinned ref (Q3, Q6) — the feature-gate string is a placeholder and the git credentials/ref formekari-account-web-sdkare unconfirmed, so chunk 1 (dependency install) and the gate test in chunk 2 cannot be authored deterministically.- New: upstream
postMessageorigin-validation gap (Q10) — not something this RFC or CRM can fix, but it is a real, previously-uncaught security finding: the SDK does not validateevent.originand owns its own listener, so no consumer-side mitigation is possible. Should be escalated to Infosec/Account & Launchpad independent of this RFC's execution readiness.
Priority Actions
- Q2 / §2.0 Source Verification — Confirm the exact field exposing the user's SSO id in the
/users/me(crmAuthScheme.fetchUser) response and pin it in §2.2 as thecurrentUservalue. Unblocks SDK construction and every status comparison; without it chunks 2 and 3 are guesses. - Q4 / ADR-7 — Confirm with CRM BE whether a
current_companyequivalent exists (team-context mapping) or whether a separate BE RFC is required. This is the sole remaining Dangling decision and cannot be resolved from the FE side or from the SDK. - Q3 / ADR-2 — Confirm the literal
centralized_sessionfeature code with the toggle owner; store it as a single constant. Unblocks the gate test in chunk 2. - Q6 / chunk 1 — Confirm CI/CD and local-dev git access to
bitbucket.org/mid-kelola-indonesia/mekari-account-web-sdkand pin an exact version ref. Separately, escalate Q10 (theevent.originvalidation gap) to Infosec/Account & Launchpad — it does not block this RFC's chunks but should gate the SDK-wide security sign-off before broad rollout.
Implementation Readiness Checklist
Unblocked (agent can proceed)
- PRD → RFC traceability matrix present (Detail 1.A)
- Scope boundaries / file list pinned (§2.0 Repo Map, Detail 1.C)
- Pattern alignment verified (§2.0 Patterns) — zero new patterns remain
- Rollout plan + rollback mechanism (§4.A, §4.D)
- Observability metrics named (§3.2)
- Task decomposition with per-chunk acceptance criteria (§4.C, 5 chunks)
- SDK event contract verified against real source (§2.4) — three statuses, single-arg callback
-
server_downfail-open behavior specified (ADR-6 resolution note, §2.4, §2.7) - Config contract:
centralized_sessiontoggle, fail-closed default - Account-switch handling resolved (ADR-5 resolution note) — no longer blocking
Blocked (must fix first)
-
currentUser(SSO id) source unverified — SDK constructor input cannot be filled (Q2, critical) -
current_companysync deferred with no contract (Q4, critical) -
centralized_sessionexact code unverified (Q3, critical) -
mekari-account-web-sdkgit access + pinned ref unconfirmed (Q6, important)
Tracked separately (not a CRM execution blocker)
- Upstream
postMessageevent.originvalidation gap in the SDK (Q10, infosec finding against Account & Launchpad)
Verdict: Fix 3 critical blockers (Q2–Q4) first — chunk 5 and the shell of chunk 2 may proceed in parallel; escalate Q10 to Infosec independently.
Task Manifest
RFC specifies decomposition in §4.C; verified and reproduced with readiness tags.
| Order | Chunk | Files to Create/Modify | Acceptance Criteria | Dependencies |
|---|---|---|---|---|
| 1 | Add dependency | package.json, yarn.lock | mekari-account-web-sdk pinned at a git ref; yarn install --frozen-lockfile passes | Blocked on Q6 |
| 2 | SDK plugin + toggle gate | plugins/mekari-session.js, nuxt.config.js, tests/plugins/mekari-session.spec.js | toggle off→no Session; on→Session built with currentUser + interval; single "event" subscription registered | currentUser assertion blocked on Q2 |
| 3 | Event handlers | plugins/mekari-session.js | per-status tests pass per §2.4; server_down fail-open (no dispatch, no redirect) | Chunk 2 |
| 4 | Logout → SSO redirect | store/user.js:userLogout | after sign_out resolves, window.location.href = account.mekari.com/sign_out | Verify other callers (Q7) |
| 5 | Observability | plugins/mekari-session.js | RUM mekari_session.event emitted (mock datadogRum) | Chunk 2, 3 |
RFC SPECIFIES decomposition — verified against package.json scripts; the
former chunk 2 (msli fallback helper) is removed entirely, not renumbered
around, because the SDK owns msli internally.
Dangling Decisions Log
| # | Decision | Location | Owner | Deadline |
|---|---|---|---|---|
| 1 | current_company sync | ADR-7 / Q4 | CRM BE + A&L | before GA (or confirm not needed) |
| 2 | centralized_session exact code | ADR-2 / Q3 | Toggle owner | before chunk 2 test |
| 3 | mekari-account-web-sdk git access + pinned ref | ADR-1 / Q6 | A&L (SDK) | before chunk 1 |
| 4 | SDK postMessage event.origin validation gap | §3.1 / Q10 | Account & Launchpad (SDK owner) + Infosec | before broad rollout (cross-RFC, not a CRM chunk) |
The former "
switch_userseamless flow (token model)" row is removed — resolved outright, not deferred, once the real SDK contract was known.
Open Questions
| # | Question | Category | Severity |
|---|---|---|---|
| 2 | Source of the current user's SSO id (currentUser) in /users/me? | CNT | Blocking |
| 3 | Exact centralized_session feature code string? | DEP / CNT | Blocking |
| 4 | current_company CRM equivalent; BE RFC needed? | TDC | Blocking |
| 6 | Git access/credentials + pinned ref for mekari-account-web-sdk? | DEP | Important |
| 7 | Do existing userLogout callers break with SSO redirect? | FMC / CPA | Important |
| 8 | CSP delivery mechanism (edge vs meta) for sm.mekari.com? | NFS | Important |
| 10 | SDK does not validate event.origin — upstream infosec finding, not a CRM fix | NFS | Blocking (cross-RFC, not this RFC's chunks) |
Q1 (
switch_user/autologin contract), Q5 (toast component), and Q9 (session.refresh()throttle) are removed from this list — all three are resolved as moot by the real SDK contract, not merely deprioritized.
Evidence Notes
- §2.0 Source Verification — strongest evidence; verified anchors carry file:line, and this reconciliation additionally cross-checked every SDK-facing claim against
mekari-account-web-sdkv0.3.0 (session.ts,README.md) rather than relying on the PRD's prose. Drove the CNT (6.5, up from 5.5) and TDC (8.0, up from 6.0) score changes and the narrowed HOLD verdict (3 blockers instead of 4). - §4.C Agent Execution Plan + §4.B commands — assertable acceptance criteria tied to real
package.jsonscripts kept TPS (7.5) and ROL (8.0) high; the removal of themsli-helper chunk simplified rather than weakened the plan. - §5 Open Questions — three
[critical]items (Q2, Q3, Q4) map cleanly to the §7 failing gates; a fourth (Q10) is a genuine but non-blocking upstream security finding this review did not catch in its first pass. Their presence is why this scores Needs Work rather than Ready — the gaps are identified, not hidden. - §1.4 / former toast component — the absence of a toast entirely (not just an unconfirmed component) resolved the FMC dock and the a11y gap from the prior review pass; there is nothing left to confirm.
- Process note: the 2026-06-28 version of this review is superseded by this re-review. Reviewers should always verify a third-party SDK's actual public API/README before scoring an RFC's contract sections — internal consistency and correct repo anchors (both present in the original review) are necessary but not sufficient.