core-debugging

name	core/debugging
description	Inspect runtime state via window.svelteRedux.reduxContext after Store.initDevTool() exposes an initialized Store instance. Multiple exposed stores produce a reduxContext array and a console.error. Use reducer tests for reference-equality diagnostics. Public Store API: @augmentcode/themis/svelte-store; devtools registration is package-internal implementation context.
type	sub-skill
library	themis
requires	["core"]
sources	["@augmentcode/themis/svelte-store","package-internal devtools registration"]
triggers	["svelteRedux api","reduxContext inspect","reducer reference equality"]

Debugging — window.svelteRedux and inspection

Runtime debugging hooks are registered by Store.initDevTool() after Store.init(). No localStorage-gated reference-check middleware or debug toggle is wired.

1. window.svelteRedux — console API

After store.initDevTool() runs in a browser, Store-owned devtools registration attaches a svelteRedux object to window where supported. The debugging-relevant field is:

window.svelteRedux = {
  reduxContext: Store instance | Store instance[],
};

reduxContext stores the public Store instance, not the internal Redux store context. Use the Store.state and Store.dispatch APIs from the console.

1.1 Inspect state from the console

// Current state snapshot (plain object)
window.svelteRedux.reduxContext.state;

// Dispatch an action manually (useful when a button is broken)
window.svelteRedux.reduxContext.dispatch({ type: "my/action", payload: [...] });

1.2 Multiple-store detection

Devtools registration treats the first Store as the canonical one. If a second Store is exposed before cleaning up the previous devtools registration, registerGlobalDevTools reports "Multiple Redux stores initialized:" with the list. Seeing that error in the console means two Store instances are being exposed — fix by consolidating registrations onto one Store.

2. Reference-equality diagnostics

No runtime debug toggle is wired for reducer reference checks. Keep no-op reducer contracts in tests instead:

expect(reducer(initialState, noOpAction)).toBe(initialState);

3. Setup — minimum working inspection

After a store exists and devtools are registered:

// 1. App code runs store.init(), then store.initDevTool().
// 2. Open DevTools.
// 3. Inspect state.
window.svelteRedux.reduxContext.state;

4. Core patterns

4.1 Diagnose a selector that won't update

1. Reproduce the action and inspect the state snapshot from window.svelteRedux.reduxContext.state.
2. If the slice didn't change → reducer missed the case. Check the action type namespace (sliceName/actionName).
3. If the slice changed but your selector didn't fire → selector memoization key didn't change; inspect what .select(state) returns from the console.

4.2 Diagnose "multiple stores initialized"

Check the log for "Multiple Redux stores initialized:". Root cause is always two store.init() calls without disposing the first:

• Two store.init() calls with different Store instances, or
• A test that didn't call the disposer returned from store.init().

Store.dispose() runs Store-owned cleanup and clears the initialized runtime context for that Store instance.

4.3 Confirm state is serializable

Use reducer tests or console inspection to verify state remains plain and JSON-shaped after the suspected action. See core/state-serialization for the allowed and forbidden state shapes.

4.4 Check reducers that break reference equality

Write reducer tests for no-op paths and assert the incoming state reference is returned unchanged. Runtime devtools inspection does not emit reducer reference warnings.

5. Common Mistakes

Expecting runtime debugging to diagnose reducer drift

Mechanism: window.svelteRedux exposes Store inspection only; it does not install a reducer-reference checker.

// ❌ WRONG — expects browser debugging to enforce reducer contracts
window.svelteRedux.reduxContext.state;

// ✅ CORRECT
expect(reducer(initialState, noOpAction)).toBe(initialState);

Public facade: @augmentcode/themis/svelte-store; devtools registration is package-internal implementation context.

Expecting reduxContext to always be an object

Mechanism: when two stores initialize without disposing, reduxContext may be reassigned to an array of Store instances. Code that reads reduxContext.state without guarding then crashes. Always guard, or fix the duplicate-init root cause.

// ❌ WRONG
const s = window.svelteRedux.reduxContext.state;

// ✅ CORRECT (diagnostic)
const ctx = window.svelteRedux.reduxContext;
const s = Array.isArray(ctx) ? ctx[0].state : ctx.state;
// then fix the duplicate init — don't keep the guard.

Source: Store-owned runtime context handling.

Using initialized store access for debug reads

Mechanism: store.state and store.dispatch are only available after the app's Store.init() completes. In application code, pass or import the same initialized Store instance. In the browser console, use window.svelteRedux.reduxContext only after devtools registration exposes it.

// ✅ Application code after Store.init()
store.dispatch(action);
const state = store.state;

// ✅ Browser console diagnostic
window.svelteRedux.reduxContext.dispatch(action);

Public API: @augmentcode/themis/svelte-store (Store.state, Store.dispatch).

6. See also

• Selected Store family lifecycle skill — store.init(), why multiple root lifecycle entries calling store.init() is the usual "multiple stores initialized" root cause.
• core/reducers — the same-reference on no-op contract that reducer tests should enforce.
• core/state-serialization — the serializability rule reducers and tests should preserve.
• core/testing — assertions that mirror reducer and serialization contracts in unit tests.