RFC Review: Centralized Web Session — Hub Chat v2 FE Integration

Executive Summary

• Overall Score: 8.0/10
• Rating: Ready with Minor Gaps
• RFC Type: frontend
• Sub-Type: enhancement
• Assessment Confidence: High
• Applied Caps/Gates: FMC < 7.0 gate (no error-message catalog / no defined org-company refetch-failure UI) still holds FMC at 6.5 — unrelated to the SDK correction, still a real gap. CNT gate REMOVED — the SDK contract is now grounded against the real mekari-account-web-sdk v0.3.0 source (was capped <7.0 for an unverified contract). DEP downgraded on retrospective judgment (see Scorecard) even though the dependency itself is now resolved.
• Implementation Readiness Verdict: PROCEED — Q1 (cross-domain fallback) and Q2 (SDK availability) are RESOLVED against the real SDK; the remaining gate is mandatory-approver assignment (Q8), plus two non-blocking external items (Q4, Q5).
• Report Path: /Users/mekari/Documents/hub-chat-v2/rfc-review-report.md
• RFC Author: syafrizal.abdillah@mekari.com | Reviewed: 2026-06-28 | Re-reviewed: 2026-07-02 (latest review — SDK reconciliation)

This RFC is among the best-anchored FE integration documents in this repo: every repo-code claim is grounded in a verified file:line, the scope is file-by-file, and the agent execution plan is ordered with assertable acceptance criteria. Update (2026-07-02, latest review): the two [critical] blockers this review originally raised — Q1 (cross-domain _mekari_account fallback) and Q2 (SDK availability/API) — are now RESOLVED against the real SDK mekari-account-web-sdk v0.3.0 (git dependency, ESM, main: dist/index.js; public API is exactly constructor({ currentUser, sessionUrl?, interval?, checkTimeout?, includeSessionId? }), destroy(), on(), off(); there is no refresh(), no switch_user status, and the SDK owns msli/session evaluation internally). This review did not consult the SDK source at the time of writing — it correctly flagged the contract as unverified but treated the resulting risk as a bounded "pending dependency" (DEP scored 5.0) rather than surfacing that the RFC's own code sketch (current_user, four events including a non-existent switch_user, a consumer-implementable event.origin guard) was, in several particulars, actively wrong, not merely unconfirmed. The RFC has since been corrected; this review is updated to reflect the grounded contract, delete the now-invalid switch_user findings, and record one genuine remaining open item: the real SDK does not validate event.origin — an upstream infosec finding for Account & Launchpad, not something hub-chat can implement.

---

Quick Verdict

Why this RFC can now be implemented agentically:

• Every chunk in §4.C names exact files, mock strategy (vi.mock('mekari-account-web-sdk')), and assertable acceptance criteria — now checked against the real SDK shape.
• Decisions are closed as 7 ADRs (§2.6) with options, rejection rationale, and reversibility; all anchored to real code (AuthStore.ts:42, AppConfigStore.ts:2, verified) or the real SDK contract.
• Rollout/rollback (§4.A/§4.D) is concrete: flag default off, numbered rollback, RUM verification signals.
• The SDK API is now pinned: mekari-account-web-sdk v0.3.0, currentUser/interval constructor options, single session.on("event", (data) => ...) subscription, data.status ∈ {logged_in, logged_out, server_down}.

Why this RFC will still cause minor agent guessing or rework:

• No error-message catalog / no defined UI behavior when the post-logged_in org/company refetch fails (retry vs log vs silent) — genuine gap, unrelated to the SDK correction.
• Q4 (current-company BE ownership) and Q5 (super_admin scope) remain open external questions.
• The mandatory infosec approver is still unassigned (Q8) — now additionally covering the newly-recorded event.origin upstream SDK gap (Q6).

---

PRD → RFC Traceability Matrix

Parent cross-product RFC (Confluence) is the authoritative PRD. It was not machine-readable for this review; mapping assessed against the in-RFC §1.A coverage table, which itself enumerates parent-RFC sections.

Standard format (PRD exists)

PRD Element (parent-RFC section)	RFC Section	Coverage
Overview / Success Criteria	§1.0, §1.A	Full
Proposal / SDK usage	§2.1, §2.2	Full — SDK init + real API pinned (mekari-account-web-sdk v0.3.0)
SDK contract (3 real statuses: logged_in/logged_out/server_down)	§2.2 event→action map	Full — grounded against real SDK source (was "4 events" incl. a non-existent switch_user)
FE Integration Flows (SDK flow)	§2.3 diagrams	Full
FE Integration Flows (Web Session / current-company)	§2.2, §2.3, §2.6-A7	Partial — ownership of current_company sync unresolved (Q4)
OAuth2 auth-code flow	§2.2, §2.6-A6	Full — reuses /sso-callback
User Logout From Product	§2.4	Full — already implemented, verified pages/logout.vue:315
User Switch Account	§2.2, §2.6-A6	Full — resolved: delivered as logged_out (SDK cannot distinguish switch from logout, never exposes the new ssoId); no dedicated flow needed
HA & Security	§3	Full (FE share); event.origin recorded as an upstream SDK gap, not a hub-chat defect (§3.3, §5 Q6)
Rollout Plan	§4	Full — hub-chat is step 5, not first pilot
Open Questions	§5	Full — Q1/Q2/Q3 resolved or moot against the real SDK; Q4/Q5/Q8 remain genuine
Local Storage msli / cookies	§2.2	Full — resolved: msli is SDK-internal, no cross-domain conflict (was Q1 [critical])
Database Model	—	n/a — no DB (FE repo)
Multiple sessions per account	—	n/a — server/SSO concern
Out-of-scope: auto token revoke on idle	§1.A	Full — carried verbatim

Summary: ~13 of 14 parent items fully covered, 1 partial (current-company ownership, tied to the genuine external Q4 dependency — unrelated to the SDK correction), 0 silently dropped. No RFC decision lacks a parent-RFC driver — zero scope creep. PRT is strong; the one remaining partial is upstream-owned, not an authoring gap.

---

Scorecard

Frontend Scorecard (11 categories)

Category	Score	Evidence-Based Rationale
PRT — PRD Traceability	8.0	§1.A forward+reverse matrix, UI/role/lifecycle sub-tables. Reverse traceability explicit ("no RFC decision without PRD driver"). Capped under 9 only because parent PRD not directly verifiable here.
TDC — Technical Decisions	8.5	7 ADRs (§2.6) with options/rejection/reversibility, all now cleanly closed against the real SDK: D5 (logged_out→/logout, server_down→fail-open) is a firm decision, no longer "suggested"; D6 correctly resolves to "no dedicated event" instead of a fictional switch_user flow. D7 still depends on Q4 (genuine external dependency).
CNT — Contract Specificity	8.5	event→action map (§2.2) is now pinned against the real SDK source: currentUser/interval/checkTimeout constructor options, single session.on("event", (data) => ...) subscription, data.status ∈ {logged_in, logged_out, server_down}. Gate removed. Data-fetching = store refetch (OK).
SCB — Scope Boundaries	9.0	§2.0 Repo Map + §4.C chunks name every file to create/modify; non-goals explicit (§2.4 "already implemented", §1.A n/a rows). Agent can produce file-by-file plan directly.
DEP — Dependencies	3.5	Downgraded on retrospective judgment. The original score of 5.0 treated the SDK gap as a bounded "pending external dependency." In fact the RFC's own code sketch encoded a wrong contract in several particulars (current_user vs real currentUser; four events including a non-existent switch_user; a consumer-implementable event.origin guard that the real SDK's architecture makes structurally impossible) — that is a correctness defect, not merely an unconfirmed detail, and this review should have required SDK-source verification before treating it as "honest but blocked." The dependency itself is now resolved in the corrected RFC (mekari-account-web-sdk v0.3.0, git install, confirmed API) — this score is a historical/methodology correction, not a live blocker.
FMC — Failure Mode Coverage	6.5	Covers server_down (now correctly fail-open per PRD 6.10) and logged_out (forced sign-out, covers account switch too) (§2.2). Gate: <7.0 — still no error-message catalog and still no defined UI/behavior for the org/company refetch call failing after logged_in. (The previously-listed "toast copy TBD" gap no longer applies — the toast has been removed entirely, not merely deferred, since there is no dedicated switch-user surface.)
NFS — Non-Functional Specificity	6.5	§3.3 correctly keeps CSP and no-token-in-logs coverage, but the original "composable MUST verify event.origin" claim assumed a capability the SDK's own listener architecture does not allow — the real SDK checks only event.data.source and owns the message listener itself, so a consumer-side origin guard was never implementable. Corrected to an honest upstream infosec finding (§3.3, §5 Q6). Perf throttle is now resolved via the interval constructor option (was Q3 "TBD"). Still missing: browser matrix, a11y (n/a — no UI left to fail), i18n (n/a — no toast left).
TPS — Test Plan Specificity	8.0	§4.C per-chunk assertable acceptance now matches the real API (e.g. "SDK constructed with currentUser === user.sso_id and interval set", "subscribed via the single session.on(\"event\", ...) call"). The old "postMessage mismatched origin is ignored" AC is removed — it was unimplementable and has been replaced with a real, testable assertion. Maps to vitest commands. Missing: explicit failure-path E2E naming.
ROL — Rollout & Rollback	8.5	Flag default off (§4.A), numbered agent-executable rollback (§4.D), config contract = centralized_session flag, verification signals via RUM. hub-chat sequenced as step 5 behind Launchpad.
OBS — Observability	7.5	3 named RUM actions w/ thresholds (§3.4); no-token payload rule. Deduction: action names unconfirmed (Q7); no dashboard/alert wiring named.
CPA — Pattern Alignment	9.0	§2.0 "Patterns to Follow" mirrors datadog.client.ts, seamless_auth_first gating (verified AppConfigStore.ts:7), useEventBus, pages/logout.vue reuse. Code will look native.

Caps applied: CNT gate removed — the SDK contract is now grounded against real source, no longer "shape, not final code." FMC remains held below 7.0 by rubric gate — the missing error-message catalog and undefined refetch-failure UI are real gaps, unrelated to the SDK correction. DEP is deliberately downgraded to reflect that this review's original "pending dependency" framing understated a contract that was, in several particulars, actively wrong — not simply awaiting confirmation; this is a retrospective judgment on review methodology, not a statement that the dependency is currently blocking (it is now resolved in the corrected RFC). Overall raised from 6.5 to 8.0: with Q1 and Q2 resolved, end-to-end agentic execution is achievable today; the remaining gaps (FMC, Q4, Q5, Q8) are real but non-blocking to compile.

---

Decision Closure Assessment

Decision Index

#	Decision	Status	Critical Gaps
D1	SDK init in plugins/mekariSession.client.ts	Resolved	none
D2	Gate via AppConfigStore.centralized_session	Resolved	none
D3	useCentralizedSession + useEventBus delivery	Resolved	session:* bus keys "only if needed" — slightly open; no app-wide toast exists to justify them today
D4	currentUser = user.sso_id (camelCase)	Resolved	none (verified AuthStore.ts:42; SDK option name corrected from current_user)
D5	logged_out → /logout; server_down → fail-open	Resolved	none — server_down is a firm fail-open decision (PRD 6.10), no longer "suggested" or Q1-entangled
D6	Account-switch handling — no dedicated event, delivered as logged_out	Resolved	none — corrected: the original decision assumed a switch_user event that does not exist on the real SDK
D7	Current-company = refetch org+company stores, decoupled from the SDK	Partial	depends on BE setting current company (Q4) — genuine external dependency, not an SDK gap (R10)
Dx	SDK package identity + API surface	Resolved	none — mekari-account-web-sdk v0.3.0 confirmed (was [critical], Q2)
Dy	Cross-domain _mekari_account fallback boundary	Resolved/Moot	none — the real SDK owns msli/session evaluation entirely inside the iframe; hub-chat never reads _mekari_account (was [critical], Q1)

Aggregate: 8 Resolved (incl. 2 formerly Dangling and 2 formerly Partial), 1 Partial (D7, genuinely external), 0 Dangling.

---

Decision: Dx — SDK package identity & API surface

Status: Resolved (was Dangling)

What was decided

The RFC now specifies mekari-account-web-sdk v0.3.0, installed via npm install git+https://<user>:<pass>@bitbucket.org/mid-kelola-indonesia/mekari-account-web-sdk#<version> (bundled git dependency, ESM, main: dist/index.js). §2.1/§2.2 paste the real public API.

Alternatives considered

NO ALTERNATIVES — external mandated dep from the parent RFC. The integration mode (bundled git dependency, no CDN, no registry) is now decided with certainty (R2), collapsing the earlier "npm vs CDN" framing.

Grounding in existing code

Grounded in the real SDK source (mekari-account-web-sdk/src/session.ts, src/index.ts, README.md) rather than repo grep — this is an external dependency not yet added to hub-chat-v2, and that absence is expected (new dep to add in Chunk 2), not a blocker.

Interface specification

COMPLETE. Constructor: new Session({ currentUser, sessionUrl?, interval?, checkTimeout?, includeSessionId? }). Events: session.on("event", (data) => void) / off(). EventData = { status, sessionId? }, status ∈ { "logged_in", "logged_out", "server_down" }. Teardown: destroy(). Singleton: a 2nd new Session() returns the 1st instance and ignores new options — destroy() resets it.

Failure handling

Complete — server_down mapped to fail-open (PRD 6.10); no refresh()/ getToken()/logout()/login() exist, so no speculative failure paths for methods that don't exist.

Challenge results

• Scale: n/a (single client instance, singleton-enforced).
• Reversibility: high — delete plugin+composable+dep.
• Consistency: consistent with *.client.ts precedent.
• Agent implementability: YES — the constructor, subscription shape, and vi.mock('mekari-account-web-sdk') target are all now pinned.

Gaps and suggestions

Missing: nothing blocking. Historical note: the original RFC draft and this review both worked from an unverified sketch; future RFCs for this initiative should paste the SDK's actual public surface (or .d.ts excerpt) before scoring DEP/CNT above a "pending" floor. Open questions: none (was Q2, resolved).

---

Decision: Dy — Cross-domain _mekari_account fallback boundary

Status: Resolved/Moot (was Dangling)

What was decided

The real SDK owns msli (localStorage key "msli", 2h expiry) and all session evaluation internally, inside the iframe. hub-chat consumes only session.on("event", ...) and must not read/write msli or any _mekari_account cookie — there was never a hub-chat-side evaluation to design.

Grounding in existing code

Grounded in the real SDK source (session.ts) rather than the memory sso-cross-domain-cookies inference the original RFC/review relied on. The cross-domain constraint (COOKIE_DOMAIN=.qontak.com) is still real, but it is moot here because hub-chat was never expected to evaluate the cookie.

Interface specification

COMPLETE — msli write/read/fallback logic lives entirely inside the SDK; §2.2 now states the "must not touch" rule explicitly.

Failure handling

Complete — server_down is fail-open (PRD 6.10); no soft-grace window exists or needs to exist in hub-chat.

Challenge results

• Reversibility: n/a — this is a correction, not a choice.
• Consistency: consistent with cross-tab logout precedent (app.vue:216, verified) for the logged_out path, which now also covers account switches.
• Agent implementability: YES — nothing to build for this boundary beyond "don't touch msli."

Gaps and suggestions

Missing: nothing blocking. Open questions: none (was Q1, resolved/moot).

---

Decision: D5 — logged_out → /logout; server_down → fail-open

Status: Resolved (was Partial) logged_out→/logout is fully resolved (verified pages/logout.vue:315) and now also explicitly covers the account-switch case (§2.2). server_down is a firm fail-open decision (PRD constraint 6.10) — no longer "suggested," and no longer entangled with the (now-moot) msli/Q1 grace policy.

Decision: D7 — Current-company sync via store refetch

Status: Partial Reuse of OrganizationStore.getDetail() + CompanyStore.getCompanyDetail() is sound, and is now explicitly decoupled from the SDK event (R10 — the SDK exposes no company data at all). Correctness still depends on hub-core setting current company server-side before refetch (Q4) — a genuine BE/SSO dependency, unrelated to the SDK correction. If not, refetch returns stale company → silent wrong-org bug.

---

UI State Audit

This enhancement adds essentially no new data-driven component (SDK iframe invisible; reuses existing screens; there is no toast at all — the "user has changed" surface has been removed, not deferred).

Component	Loading	Empty	Error	Partial	Success	Assessment
Re-auth loading (CommonSsoCallbackLoading, normal /sso-callback login — not switch-triggered)	reused	n/a	missing	n/a	reused	3/5 — no error state if a normal /sso-callback re-auth fails
Org/company refetch (background)	not defined	not defined	not defined	not defined	implicit	0/5 — refetch failure after logged_in has no defined UI

Summary: The refetch-failure path (org/company store rejects after logged_in) still has no specified UI state — genuine gap, unrelated to the SDK correction. Add: on refetch error, behavior = retry? force logout? log only? Currently agent would leave a silent stale-org state. The former "'user has changed' toast" row is removed entirely — there is no such surface anymore.

---

Performance Budget Check

Metric	Target	Current Baseline	Source	Assessment
SDK init blocking	"must not block first paint"	not stated	§3.2	qualitative only — no ms target
Periodic re-validation cadence	interval ≥1000ms, recommended 5 * 60 * 1000 per PRD 6.9	existing 1s tick (AuthStore.ts:509) is a separate token-refresh mechanism, unaffected	§2.1/§3.2 (was Q3, now moot)	RESOLVED — no session.refresh() exists; interval bounds the SDK's own check frequency
Bundle size delta (SDK bundled)	not stated	—	§3.1	MISSING — SDK is bundled (§3.1) but no kB budget; unrelated to the SDK correction
LCP / INP / CLS	not stated	—	—	n/a for this change, but bundle delta should be tracked

The refresh-cadence gap is now resolved via the interval constructor option. The bundle-size budget gap remains genuinely open and should be added once the mekari-account-web-sdk package size is known (it is a small dependency per the real source, but no kB figure has been quoted in this RFC).

---

Accessibility Review

Aspect	Specified?	Details	Assessment
Keyboard navigation	no	reuses existing redirect/logout	acceptable — no new interactive surface
Focus management	n/a	no toast exists — the "user has changed" surface was removed entirely (§2.2), not deferred	n/a — nothing to announce
ARIA labels	n/a	—	n/a — no new custom controls
Heading hierarchy	n/a	—	n/a
Color contrast	n/a	—	n/a
Motion sensitivity	n/a	—	n/a
Screen reader	n/a	no toast to announce	n/a — resolved by removal, not by design work

Low blast-radius (reuses existing screens; zero new visual surface). No a11y action needed.

---

Pattern Alignment Check

Pattern	RFC Approach	Assessment
Feature-flag gating	follows seamless_auth_first (verified AppConfigStore.ts:7)	aligned
Client-only boot	follows *.client.ts (datadog precedent)	aligned
Cross-feature events	reuses useEventBus/AppEventMap (plugins/eventBus.ts:6)	aligned — currently unused since no toast exists; kept for future cross-feature needs
Forced logout	reuses pages/logout.vue rather than re-implementing	aligned — avoids parallel cleanup path
Store error handling	"mirror CompanyStore.ts"	aligned but unspecified — which error pattern exactly?
Datadog RUM	follows datadogRum.setUser (app.vue:152)	aligned; action naming is new (Q7)
Analytics events preserved	no existing events dropped	aligned

Strongest dimension. No parallel systems introduced.

---

Data Flow Trace

The original "Flow: switch_user" trace below is removed: it was built on a switch_user event that does not exist on the real SDK (mekari-account-web-sdk v0.3.0 defines only logged_in/logged_out/ server_down, and the payload never exposes the incoming user's ssoId). There is no dedicated switch flow to trace — an account switch is delivered as an ordinary logged_out and follows the same forced sign-out path already covered in the corrected RFC's §2.3 sequence diagram. No replacement trace is needed beyond that diagram.

Gaps carried forward (unrelated to the SDK correction): (1) org/company refetch-failure branch (after logged_in) is still undefined; (2) current-company correctness still assumes BE pre-sets it (Q4); (3) a normal /sso-callback re-auth failure (plain login, not switch-triggered) has no defined recovery.

---

Strengths

• Scope + grounding discipline (§2.0, §4.C): every repo-code anchor is a verified file:line (spot-checked AuthStore.ts:42 sso_id ✓, AppConfigStore.ts:7 seamless_auth_first ✓, listenForLogout present ✓). Agent can navigate without searching.
• Decision closure as ADRs (§2.6): 7 decisions with options, rejection rationale, reversibility — well above repo norm, and now all correctly closed against the real SDK contract.
• Rollout/rollback realism (§4.A/§4.D): dark-by-default flag, numbered agent-executable rollback, RUM verification signals, correct sequencing behind Launchpad.
• Self-aware blocker honesty (original §5/§7): the RFC flagged its own [critical] gaps and refused to set status:yes — exactly right procedurally, even though the underlying contract detail (four events, current_user, origin guard) turned out to need correction once the real source was consulted.

---

Biggest Gaps

• FMC — no error-message catalog + undefined refetch-failure UI (UI State Audit): org/company refetch failure after logged_in has no specified behavior → silent stale-org risk. This is the largest remaining gap and is unrelated to the SDK correction.
• NFS/Q6 — event.origin is an unfixable upstream SDK gap, not a hub-chat defect: the real SDK's own message listener checks only event.data.source and never validates event.origin; hub-chat cannot intercept or override it. This must be tracked as an infosec finding against Account & Launchpad (§3.3, §5 Q6), not implemented in the composable.
• Q4/Q5/Q8 — genuine open external items: current-company BE ownership, super_admin scope, and mandatory-approver assignment remain unresolved and should close before rollout, though none block agent execution of Chunks 1–6.

---

Priority Actions

1. Q8 — Assign approvers, incl. the mandatory infosec approver (CSP / iframe / event.origin). This approver review must now explicitly cover the Q6 upstream SDK finding (event.origin not validated) as an accepted, tracked risk against Account & Launchpad — not something hub-chat can remediate.
2. FMC — Add an error-message catalog / defined behavior for the org/company refetch call failing after logged_in (retry vs log-only vs forced logout). Unblocks Chunk 3 + UI State completeness.
3. Q4 — Confirm whether hub-core sets current_company server-side before refetch (else add an explicit FE/BE contract). Removes the one remaining behavioral guess in Task/Chunk 3 territory.
4. Q5 — Confirm whether centralized session applies to super_admin sessions.

(Removed: the former "Q2 / Decision Dx" and "Q1 / Decision Dy" priority actions — both are resolved; see Decision Closure Assessment above.)

---

Implementation Readiness Checklist

Unblocked (agent can proceed)

• PRD → RFC traceability matrix complete (§1.A)
• Rollout plan with feature flag + rollback (§4.A/§4.D)
• Observability metrics defined (§3.4, naming pending Q7)
• Task decomposition with acceptance criteria per chunk (§4.C)
• Pattern alignment verified (§2.0)
• Configuration contract: centralized_session flag, default off
• SDK API pinned against real source (mekari-account-web-sdk v0.3.0 — §2.1/§2.2)
• Cross-domain fallback semantics resolved (msli is SDK-internal — §2.2)
• All UI states defined — org/company refetch-failure state still missing
• Performance budget quantified — bundle-size delta still missing (cadence is resolved)
• Zero vague words — remaining: RUM action naming (Q7, nice-to-have only)

Blocked (must fix first)

• Q8 — approvers incl. mandatory infosec unassigned (CSP/iframe/event.origin)

Verdict: Proceed — assign the infosec approver (Q8) before sign-off; Q4/Q5 should close before rollout but do not block agent execution of Chunks 1–6.

---

Task Manifest

Verifying the RFC's own §4.C decomposition — it is sound; reproduced with dependency notes, updated against the real SDK contract.

Order	Chunk	Files to Create/Modify	Acceptance Criteria	Dependencies
1	Feature flag	common/store/AppConfigStore.ts (+centralized_session?), __tests__/AppConfigStore.spec.ts	type-check passes; field reads, undefined→off	None
2	useCentralizedSession + SDK lifecycle (TDD)	common/composables/useCentralizedSession.ts (+spec)	SDK constructed w/ currentUser===sso_id + interval; subscribed via single session.on("event", ...); destroy() called on teardown	None (Q2 resolved)
3	event→action map (TDD)	extend composable + spec	logged_out→/logout (covers account switch); server_down→fail-open (no action, PRD 6.10); logged_in→refetch	Q4
4	Plugin wiring (client-only)	plugins/mekariSession.client.ts (+spec)	SDK starts only when flag ON ∧ authed ∧ sso_id	Chunk 1,2; Q5
5	Observability/RUM	composable (+spec)	RUM action per event, no token/sso_id in payload	Chunk 3; Q7
6	Docs	docs/architecture/flows/login/README.md and/or auth-sso/README.md	spoke updated, status: ready, diagram added	Chunk 1–5

RFC specifies this decomposition; verified executable in order — Q1 and Q2 are now resolved; only Q4/Q5/Q7/Q8 remain as external, non-blocking items.

---

Dangling Decisions Log

Both formerly-dangling SDK decisions (package identity, cross-domain fallback) are now Resolved — see Decision Closure Assessment. Only one genuinely dangling item remains:

#	Decision	Location	Owner	Deadline
1	Current-company sync ownership (FE call vs BE pre-set)	§2.6-A7, §5 Q4	hub-core + A&L	unset

Resolved (formerly dangling/partial):

• SDK package identity + API surface (§2.1, §5 Q2) — resolved: mekari-account-web-sdk v0.3.0.
• Cross-domain _mekari_account fallback boundary (§2.2, §5 Q1) — resolved/moot: SDK-internal, no cross-domain read needed.
• server_down final action (§2.6-A5) — resolved: fail-open (PRD 6.10), no longer entangled with Q1.

---

Open Questions

#	Question	Category	Severity
Q1	Is _mekari_account evaluated only inside SDK/iframe?	TDC/FMC	Resolved/Moot — msli/session evaluation is entirely SDK-internal
Q2	mekari-account-web-sdk package name, registry/access, version, entry, event API?	DEP/CNT	Resolved — v0.3.0, git install, ESM, API pinned in §2.1/§2.2
Q3	Agreed periodic re-validation cadence?	NFS	Moot — no refresh(); use constructor interval
Q4	Does hub-core set current_company server-side before refetch, or must FE call SSO?	TDC	Important
Q5	Does centralized session apply to super_admin (today bypasses billing/MQTT)?	SCB/CPA	Important
Q6	The real SDK does not validate event.origin (checks only event.data.source); hub-chat cannot intercept/override the SDK's own listener. Upstream infosec finding for Account & Launchpad.	NFS/Security	Important
Q7	Datadog custom action naming convention?	OBS	Nice-to-have
Q8	Assign approvers incl. mandatory infosec (now also covering Q6)?	ROL/Security	Important

---

Evidence Notes

• §2.0 Existing Code Anchors / Source Verification — spot-checked and confirmed: AuthStore.ts:42 sso_id ✓, AppConfigStore.ts:2/7 AppConfig+ seamless_auth_first ✓, listenForLogout present ✓. Raised PRT/CPA/SCB scores.
• Package name correction: all prior references to @mekari/sdk in this review's evidence trail are superseded — the real package is mekari-account-web-sdk v0.3.0 (bundled git dependency; verified against mekari-account-web-sdk/src/session.ts, src/index.ts, README.md).
• §5 Concerns — Q1 and Q2 were self-flagged as [critical] in the original RFC; both are now RESOLVED against the real SDK, which is why the overall verdict moved from HOLD to PROCEED. The DEP score is nonetheless downgraded on retrospective judgment (see Scorecard) because the original contract was wrong, not merely pending — this review should have required source verification before scoring DEP as a bounded, honest gap.
• §1.D / UI surfaces — no new visual surface exists at all (the toast was removed, not deferred); the absent refetch-failure UI state is now the primary remaining FMC/UI-State deduction.
• §4.C/§4.D — concrete chunked plan + numbered rollback; raised TPS/ROL.