diff --git a/docs/false-claims/FC-001-determinism-constant.md b/docs/false-claims/FC-001-determinism-constant.md
new file mode 100644
index 0000000..6b879a7
--- /dev/null
+++ b/docs/false-claims/FC-001-determinism-constant.md
@@ -0,0 +1,159 @@
+# Falsification Audit: FA-001
+
+## Claim
+
+**"DETERMINISM = TRUE"** - Expressed in dispatcher.ts constant and architectural documentation
+
+**Where Expressed**:
+
+- `packages/core/src/dispatcher.ts` line 19: `DETERMINISM = TRUE`
+- README.md line 33: "ensures that your business logic remains pure...and your bugs are 100% reproducible via time-travel replay"
+- ARCHITECTURE.md line 3: "designed to be deterministic, race-condition resistant"
+
+## Enforcement Analysis
+
+**Enforcement**: Partially enforced by code
+
+- FIFO queue processing prevents race conditions
+- Message logging enables replay
+- Time/random providers capture entropy
+
+**Missing Enforcement**:
+
+- No verification that update functions are pure
+- No detection of side effects in update functions
+- Replay only validates final state, not intermediate states
+- Effects are not replayed (only messages are)
+
+## Mock/Test Double Insulation
+
+**Critical Reality Amputation**:
+
+- Tests use `vi.useFakeTimers()` - removes real timer behavior
+- Mock fetch/worker implementations remove network and concurrency failures
+- No tests with real I/O errors, timeouts, or partial failures
+- Stress tests use deterministic message patterns, not chaotic real-world inputs
+
+**What's NOT Tested**:
+
+- Network timeouts and connection drops
+- Worker crashes and memory limits
+- Timer precision issues across browsers
+- Concurrent access to shared resources
+- Memory pressure during high throughput
+- Browser event loop starvation
+
+## Falsification Strategies
+
+### 1. Property-Based Replay Testing
+
+```typescript
+// Generate chaotic message sequences with real timers
+test("replay preserves state under random async timing", async () => {
+ const realTimers = true;
+ const chaosFactor = 0.1; // 10% random delays
+
+ // Generate messages with unpredictable timing
+ const log = await generateChaoticSession(chaosFactor, realTimers);
+
+ // Replay should match exactly
+ const replayed = replay({ initialModel, update, log });
+ expect(replayed).toEqual(finalSnapshot);
+});
+```
+
+### 2. Effect Falsification
+
+```typescript
+// Test that effects don't break determinism
+test("effects are purely data, not execution", () => {
+ let effectExecutionCount = 0;
+ const effectRunner = (effect, dispatch) => {
+ effectExecutionCount++;
+ // Real network calls, timers, etc.
+ };
+
+ // Same message log should produce same effects regardless of execution
+ const effects1 = extractEffects(log1);
+ const effects2 = extractEffects(log1);
+ expect(effects1).toEqual(effects2);
+});
+```
+
+### 3. Concurrency Stress Testing
+
+```typescript
+// Real concurrent dispatch from multiple event sources
+test("determinism under real concurrency", async () => {
+ const sources = [
+ networkEventSource(),
+ timerEventSource(),
+ userEventSource(),
+ workerMessageSource(),
+ ];
+
+ // Run all sources concurrently with real timing
+ await Promise.all(sources.map((s) => s.start(dispatcher)));
+
+ // Verify replay produces identical state
+ const replayed = replay({ initialModel, update, log });
+ expect(replayed).toEqual(finalSnapshot);
+});
+```
+
+### 4. Memory Pressure Testing
+
+```typescript
+// Test determinism under memory constraints
+test("replay preserves state under memory pressure", async () => {
+ // Simulate memory pressure during replay
+ const memoryLimitedReplay = withMemoryLimit(() =>
+ replay({ initialModel, update, largeLog }),
+ );
+
+ expect(memoryLimitedReplay).toEqual(normalReplay);
+});
+```
+
+### 5. Real Network Failure Injection
+
+```typescript
+// Test with real network failures, not mocks
+test("determinism despite real network failures", async () => {
+ const flakyNetwork = new FlakyNetworkService({
+ failureRate: 0.1,
+ timeoutMs: 1000,
+ retryStrategy: "exponential-backoff",
+ });
+
+ // Run session with real network failures
+ await runSessionWithNetwork(dispatcher, flakyNetwork);
+
+ // Replay should be deterministic despite failures
+ const replayed = replay({ initialModel, update, log });
+ expect(replayed).toEqual(finalSnapshot);
+});
+```
+
+## Classification
+
+**Status**: Weakly Supported
+
+**Evidence**:
+
+- FIFO processing prevents race conditions
+- Message logging enables basic replay
+- Time/random capture preserves some entropy
+
+**Contradictions**:
+
+- Effects are not replayed, breaking full determinism
+- No enforcement of update function purity
+- Tests insulated from real-world failures
+- Phantom pending bug class documented in ideas.md
+
+**Falsification Risk**: HIGH - The claim overstates what's actually guaranteed. Real-world concurrency, network failures, and memory pressure are not tested or protected against.
+
+## Recommendation
+
+Replace "DETERMINISM = TRUE" with "MESSAGE_ORDERING_DETERMINISM = TRUE" and document that effect execution and external I/O are not deterministic.
diff --git a/docs/false-claims/FC-002-atomic-processing.md b/docs/false-claims/FC-002-atomic-processing.md
new file mode 100644
index 0000000..d3fe264
--- /dev/null
+++ b/docs/false-claims/FC-002-atomic-processing.md
@@ -0,0 +1,181 @@
+# Falsification Audit: FA-002
+
+## Claim
+
+**"Atomic Processing: Messages are processed one at a time via a FIFO queue, eliminating race conditions by design"**
+
+**Where Expressed**:
+
+- README.md line 39
+- ARCHITECTURE.md line 11: "Serialized Processing: Messages are processed one at a time via a FIFO queue in the Dispatcher. Re-entrancy is strictly forbidden."
+
+## Enforcement Analysis
+
+**Enforcement**: Strongly enforced by code
+
+- `isProcessing` flag prevents concurrent processing
+- Single `processQueue()` function with while loop
+- Re-entrancy handled via queueing, not immediate execution
+
+**Code Evidence**:
+
+```typescript
+const processQueue = () => {
+ if (isProcessing || isShutdown || queue.length === 0) return;
+ isProcessing = true;
+ try {
+ while (queue.length > 0) {
+ const msg = queue.shift()!;
+ // Process single message
+ }
+ } finally {
+ isProcessing = false;
+ }
+};
+```
+
+## Mock/Test Double Insulation
+
+**Minimal Insulation**:
+
+- Tests use real dispatcher logic
+- No mocks for core queue processing
+- Stress tests use actual message bursts
+
+**What's NOT Tested**:
+
+- Effect execution concurrency (effects run outside queue)
+- Subscription lifecycle during processing
+- Memory allocation during high-frequency processing
+- Event loop interruption during long-running updates
+
+## Falsification Strategies
+
+### 1. Concurrent Effect Execution Test
+
+```typescript
+// Test that effects don't break atomicity
+test("effects run outside atomic processing", async () => {
+ let effectConcurrency = 0;
+ const effectRunner = async (effect, dispatch) => {
+ effectConcurrency++;
+ await simulateAsyncWork();
+ effectConcurrency--;
+ dispatch({ kind: "EFFECT_DONE" });
+ };
+
+ // Dispatch multiple messages that trigger effects
+ for (let i = 0; i < 100; i++) {
+ dispatcher.dispatch({ kind: "TRIGGER_EFFECT" });
+ }
+
+ // Effects should be able to run concurrently
+ expect(effectConcurrency).toBeGreaterThan(1);
+ // But message processing should remain atomic
+ expect(dispatcher.getSnapshot().processedCount).toBe(100);
+});
+```
+
+### 2. Memory Allocation Stress Test
+
+```typescript
+// Test atomicity under memory pressure
+test("atomic processing under memory pressure", async () => {
+ const memoryHog = () => {
+ // Allocate large objects during update
+ return new Array(1000000).fill(0).map(() => ({
+ data: new Array(1000).fill(Math.random()),
+ }));
+ };
+
+ const updateWithAllocation = (model, msg) => {
+ if (msg.kind === "ALLOCATE") {
+ const largeData = memoryHog();
+ return {
+ model: { ...model, largeData },
+ effects: [],
+ };
+ }
+ return { model, effects: [] };
+ };
+
+ // Should not break atomicity despite GC pressure
+ for (let i = 0; i < 1000; i++) {
+ dispatcher.dispatch({ kind: "ALLOCATE" });
+ }
+
+ expect(dispatcher.getSnapshot().largeData).toBeDefined();
+});
+```
+
+### 3. Event Loop Starvation Test
+
+```typescript
+// Test that long updates don't break atomicity
+test("atomic processing with blocking updates", async () => {
+ let processingOrder = [];
+ const blockingUpdate = (model, msg) => {
+ processingOrder.push(msg.id);
+ // Simulate blocking operation
+ const start = Date.now();
+ while (Date.now() - start < 10) {} // Block for 10ms
+ return { model: { ...model, lastId: msg.id }, effects: [] };
+ };
+
+ // Dispatch multiple messages rapidly
+ for (let i = 0; i < 10; i++) {
+ dispatcher.dispatch({ kind: "BLOCK", id: i });
+ }
+
+ // Processing order should match dispatch order
+ expect(processingOrder).toEqual([0, 1, 2, 3, 4, 5, 6, 7, 8, 9]);
+});
+```
+
+### 4. Subscription Interference Test
+
+```typescript
+// Test subscription lifecycle during processing
+test("subscription changes don't break atomicity", async () => {
+ let subscriptionOrder = [];
+ const subscriptionRunner = {
+ start: (sub, dispatch) => {
+ subscriptionOrder.push(`START_${sub.key}`);
+ },
+ stop: (key) => {
+ subscriptionOrder.push(`STOP_${key}`);
+ },
+ };
+
+ // Messages that change subscriptions
+ dispatcher.dispatch({ kind: "ADD_SUB", key: "sub1" });
+ dispatcher.dispatch({ kind: "ADD_SUB", key: "sub2" });
+ dispatcher.dispatch({ kind: "REMOVE_SUB", key: "sub1" });
+
+ // Subscription changes should be atomic
+ expect(subscriptionOrder).toEqual(["START_sub1", "START_sub2", "STOP_sub1"]);
+});
+```
+
+## Classification
+
+**Status**: Likely True
+
+**Evidence**:
+
+- Strong code enforcement with `isProcessing` flag
+- Comprehensive stress testing validates FIFO behavior
+- No evidence of race conditions in tests
+- Architecture correctly identifies re-entrancy handling
+
+**Residual Risks**:
+
+- Effect execution happens outside atomic processing
+- Long-running updates could cause event loop issues
+- Memory pressure during processing not tested
+
+**Falsification Risk**: LOW - The core claim of atomic message processing is strongly enforced and well-tested.
+
+## Recommendation
+
+Keep the claim but clarify: "Atomic Processing: Messages are processed one at a time via a FIFO queue, eliminating race conditions in message processing. Effect execution and subscription lifecycle happen outside the atomic processing loop."
diff --git a/docs/false-claims/FC-003-deep-freeze-immutability.md b/docs/false-claims/FC-003-deep-freeze-immutability.md
new file mode 100644
index 0000000..2875a4d
--- /dev/null
+++ b/docs/false-claims/FC-003-deep-freeze-immutability.md
@@ -0,0 +1,247 @@
+# Falsification Audit: FA-003
+
+## Claim
+
+**"deepFreeze catches mutations in devMode"** - Implied guarantee of immutability enforcement
+
+**Where Expressed**:
+
+- `packages/core/src/dispatcher.ts` lines 85-102: `deepFreeze` implementation
+- Test names: "detects impurity in update function", "purity: deepFreeze catches mutations in devMode"
+- docs/notes/ideas.md line 21: "Deep Freezing: In devMode, the dispatcher recursively freezes the new model after every update. This guarantees immutability"
+
+## Enforcement Analysis
+
+**Enforcement**: Partially enforced by code
+
+- Recursive `Object.freeze()` called in devMode
+- Freezes nested objects and properties
+- Runs after each update in devMode
+
+**Missing Enforcement**:
+
+- Only freezes objects, not arrays or other data structures completely
+- Cannot freeze primitive values
+- No protection against mutation of external references
+- Freezing happens AFTER update, not during
+
+## Mock/Test Double Insulation
+
+**Complete Insulation**:
+
+- Tests only check for simple property mutations (`model.count++`)
+- No tests with complex object graphs
+- No tests with external references or shared objects
+- No tests with array methods that mutate (push, splice, etc.)
+
+**What's NOT Tested**:
+
+- Array mutation methods (push, pop, splice, sort)
+- Object property deletion/addition after freeze
+- Mutation of external references to model
+- Deep nested object mutation beyond freeze depth
+- Mutation through prototype chain
+
+## Falsification Strategies
+
+### 1. Array Mutation Bypass Test
+
+```typescript
+// Test that array mutations can bypass freeze
+test("array mutations bypass deep freeze", () => {
+ const model = {
+ items: [1, 2, 3],
+ nested: { data: [4, 5, 6] },
+ };
+
+ const impureUpdate = (model, msg) => {
+ if (msg.kind === "MUTATE_ARRAY") {
+ // These mutations should be caught but aren't fully
+ model.items.push(99); // Mutates frozen array
+ model.nested.data.sort(); // Mutates nested array
+ return { model, effects: [] };
+ }
+ return { model, effects: [] };
+ };
+
+ const dispatcher = createDispatcher({
+ model,
+ update: impureUpdate,
+ effectRunner: () => {},
+ devMode: true,
+ });
+
+ // Should throw but may not catch all array mutations
+ expect(() => dispatcher.dispatch({ kind: "MUTATE_ARRAY" })).toThrow();
+});
+```
+
+### 2. External Reference Mutation Test
+
+```typescript
+// Test mutation through external references
+test("external reference mutations bypass freeze", () => {
+ const externalRef = { shared: [1, 2, 3] };
+ const model = {
+ data: externalRef,
+ count: 0,
+ };
+
+ const impureUpdate = (model, msg) => {
+ if (msg.kind === "MUTATE_EXTERNAL") {
+ // Mutate through external reference
+ externalRef.shared.push(99);
+ return { model, effects: [] };
+ }
+ return { model, effects: [] };
+ };
+
+ const dispatcher = createDispatcher({
+ model,
+ update: impureUpdate,
+ effectRunner: () => {},
+ devMode: true,
+ });
+
+ dispatcher.dispatch({ kind: "MUTATE_EXTERNAL" });
+
+ // Model changed through external reference - not caught
+ expect(dispatcher.getSnapshot().data.shared).toEqual([1, 2, 3, 99]);
+});
+```
+
+### 3. Prototype Chain Mutation Test
+
+```typescript
+// Test mutations through prototype chain
+test("prototype chain mutations bypass freeze", () => {
+ const model = Object.create({ protoValue: 1 });
+ model.ownValue = 2;
+
+ const impureUpdate = (model, msg) => {
+ if (msg.kind === "MUTATE_PROTO") {
+ // Mutate prototype property
+ Object.getPrototypeOf(model).protoValue = 99;
+ return { model, effects: [] };
+ }
+ return { model, effects: [] };
+ };
+
+ const dispatcher = createDispatcher({
+ model,
+ update: impureUpdate,
+ effectRunner: () => {},
+ devMode: true,
+ });
+
+ dispatcher.dispatch({ kind: "MUTATE_PROTO" });
+
+ // Prototype mutation not caught by deep freeze
+ expect(dispatcher.getSnapshot().protoValue).toBe(99);
+});
+```
+
+### 4. Complex Object Graph Test
+
+```typescript
+// Test deep complex object graphs
+test("complex object graphs have freeze gaps", () => {
+ const model = {
+ level1: {
+ level2: {
+ level3: {
+ level4: {
+ data: [1, 2, 3],
+ map: new Map([["key", "value"]]),
+ set: new Set([1, 2, 3]),
+ },
+ },
+ },
+ },
+ };
+
+ const impureUpdate = (model, msg) => {
+ if (msg.kind === "DEEP_MUTATE") {
+ // Mutate deep structures that might not be frozen
+ model.level1.level2.level3.level4.data.push(99);
+ model.level1.level2.level3.level4.map.set("new", "value");
+ model.level1.level2.level3.level4.set.add(99);
+ return { model, effects: [] };
+ }
+ return { model, effects: [] };
+ };
+
+ const dispatcher = createDispatcher({
+ model,
+ update: impureUpdate,
+ effectRunner: () => {},
+ devMode: true,
+ });
+
+ // Some mutations may bypass freeze
+ dispatcher.dispatch({ kind: "DEEP_MUTATE" });
+
+ const result = dispatcher.getSnapshot();
+ expect(result.level1.level2.level3.level4.data).toContain(99);
+ expect(result.level1.level2.level3.level4.map.get("new")).toBe("value");
+ expect(result.level1.level2.level3.level4.set.has(99)).toBe(true);
+});
+```
+
+### 5. Property Deletion/Addition Test
+
+```typescript
+// Test property deletion and addition after freeze
+test("property deletion/addition after freeze", () => {
+ const model = {
+ required: "value",
+ optional: "present",
+ };
+
+ const impureUpdate = (model, msg) => {
+ if (msg.kind === "MODIFY_PROPS") {
+ delete model.optional; // Delete property
+ model.newProp = "added"; // Add new property
+ return { model, effects: [] };
+ }
+ return { model, effects: [] };
+ };
+
+ const dispatcher = createDispatcher({
+ model,
+ update: impureUpdate,
+ effectRunner: () => {},
+ devMode: true,
+ });
+
+ dispatcher.dispatch({ kind: "MODIFY_PROPS" });
+
+ const result = dispatcher.getSnapshot();
+ expect(result.optional).toBeUndefined();
+ expect(result.newProp).toBe("added");
+});
+```
+
+## Classification
+
+**Status**: Weakly Supported
+
+**Evidence**:
+
+- Basic object freezing implemented
+- Simple property mutations caught in tests
+- Recursive freezing for nested objects
+
+**Contradictions**:
+
+- Array mutations not fully prevented
+- External reference mutations bypass freeze
+- Prototype chain mutations not blocked
+- Complex data structures (Map, Set) not handled
+- Property deletion/addition after freeze not prevented
+
+**Falsification Risk**: HIGH - The immutability guarantee has significant gaps that allow mutations to bypass the freeze mechanism.
+
+## Recommendation
+
+Replace "guarantees immutability" with "provides basic immutability protection for simple object properties" and document the limitations. Consider using Proxy-based immutability for comprehensive protection.
diff --git a/docs/false-claims/FC-004-verify-determinism.md b/docs/false-claims/FC-004-verify-determinism.md
new file mode 100644
index 0000000..15b3d02
--- /dev/null
+++ b/docs/false-claims/FC-004-verify-determinism.md
@@ -0,0 +1,281 @@
+# Falsification Audit: FA-004
+
+## Claim
+
+**"verifyDeterminism()" method validates deterministic replay** - Implied guarantee of determinism verification
+
+**Where Expressed**:
+
+- `packages/core/src/dispatcher.ts` line 56: `verifyDeterminism(): DeterminismResult`
+- Method name implies comprehensive determinism verification
+- Return type `DeterminismResult` suggests binary validation
+
+## Enforcement Analysis
+
+**Enforcement**: Not enforced by code
+
+- Only compares final JSON state snapshots
+- No verification of intermediate states
+- No validation of effect execution
+- No check for message processing order
+
+**Code Evidence**:
+
+```typescript
+verifyDeterminism: () => {
+ const replayed = replay({
+ initialModel: options.model,
+ update: options.update,
+ log: msgLog,
+ });
+
+ const originalJson = JSON.stringify(currentModel);
+ const replayedJson = JSON.stringify(replayed);
+ const isMatch = originalJson === replayedJson;
+
+ return {
+ isMatch,
+ originalSnapshot: originalJson,
+ replayedSnapshot: replayedJson,
+ };
+},
+```
+
+## Mock/Test Double Insulation
+
+**Complete Insulation**:
+
+- No tests for `verifyDeterminism` method
+- No tests with real-world scenarios where determinism fails
+- Stress tests don't use verification
+- All tests assume determinism works
+
+**What's NOT Tested**:
+
+- Non-deterministic update functions
+- Random number generation variations
+- Time-dependent logic differences
+- Effect execution order differences
+- JSON serialization edge cases
+- Large object graph comparison failures
+
+## Falsification Strategies
+
+### 1. Non-Deterministic Update Function Test
+
+```typescript
+// Test verification with non-deterministic updates
+test("verifyDeterminism fails with non-deterministic updates", () => {
+ const nonDeterministicUpdate = (model, msg, ctx) => {
+ if (msg.kind === "RANDOM") {
+ // Use Math.random() instead of ctx.random()
+ return {
+ model: { ...model, value: Math.random() },
+ effects: [],
+ };
+ }
+ return { model, effects: [] };
+ };
+
+ const dispatcher = createDispatcher({
+ model: { value: 0 },
+ update: nonDeterministicUpdate,
+ effectRunner: () => {},
+ });
+
+ dispatcher.dispatch({ kind: "RANDOM" });
+
+ const result = dispatcher.verifyDeterminism();
+ expect(result.isMatch).toBe(false);
+});
+```
+
+### 2. Effect Execution Order Test
+
+```typescript
+// Test that effect execution order affects determinism
+test("verifyDeterminism misses effect execution differences", () => {
+ let effectOrder = [];
+ const effectRunner = (effect, dispatch) => {
+ effectOrder.push(effect.id);
+ setTimeout(() => dispatch(effect.result), Math.random() * 100);
+ };
+
+ const dispatcher = createDispatcher({
+ model: { effects: [] },
+ update: (model, msg) => ({
+ model,
+ effects: [{ id: msg.id, result: { kind: "DONE", id: msg.id } }],
+ }),
+ effectRunner,
+ });
+
+ // Dispatch multiple effects
+ dispatcher.dispatch({ kind: "EFFECT", id: 1 });
+ dispatcher.dispatch({ kind: "EFFECT", id: 2 });
+
+ // Wait for effects to complete
+ await new Promise((resolve) => setTimeout(resolve, 200));
+
+ const result = dispatcher.verifyDeterminism();
+
+ // verifyDeterminism won't catch effect order differences
+ // since it only compares final model state
+ expect(result.isMatch).toBe(true); // False positive
+});
+```
+
+### 3. JSON Serialization Edge Cases Test
+
+```typescript
+// Test JSON serialization limitations
+test("verifyDeterminism fails with JSON serialization edge cases", () => {
+ const modelWithSpecialValues = {
+ date: new Date(),
+ undefined: undefined,
+ symbol: Symbol("test"),
+ function: () => {},
+ map: new Map([["key", "value"]]),
+ set: new Set([1, 2, 3]),
+ };
+
+ const dispatcher = createDispatcher({
+ model: modelWithSpecialValues,
+ update: (model, msg) => ({ model, effects: [] }),
+ effectRunner: () => {},
+ });
+
+ dispatcher.dispatch({ kind: "NO_OP" });
+
+ const result = dispatcher.verifyDeterminism();
+
+ // JSON.stringify loses information, causing false positives
+ expect(result.isMatch).toBe(true); // But verification is meaningless
+ expect(result.originalSnapshot).not.toContain("Symbol(");
+ expect(result.originalSnapshot).not.toContain("Map");
+});
+```
+
+### 4. Large Object Graph Performance Test
+
+```typescript
+// Test verification performance with large objects
+test("verifyDeterminism performance issues with large objects", () => {
+ const largeModel = {
+ data: new Array(100000).fill(0).map((_, i) => ({
+ id: i,
+ nested: {
+ deep: new Array(100).fill(0).map((j) => ({ value: j })),
+ },
+ })),
+ };
+
+ const dispatcher = createDispatcher({
+ model: largeModel,
+ update: (model, msg) => ({ model, effects: [] }),
+ effectRunner: () => {},
+ });
+
+ dispatcher.dispatch({ kind: "NO_OP" });
+
+ const start = performance.now();
+ const result = dispatcher.verifyDeterminism();
+ const end = performance.now();
+
+ expect(end - start).toBeLessThan(1000); // May fail
+ expect(result.isMatch).toBe(true);
+});
+```
+
+### 5. Intermediate State Verification Test
+
+```typescript
+// Test that intermediate states are not verified
+test("verifyDeterminism misses intermediate state differences", () => {
+ let intermediateStates = [];
+
+ const updateWithSideEffects = (model, msg) => {
+ intermediateStates.push(JSON.stringify(model));
+
+ if (msg.kind === "INC") {
+ return {
+ model: { ...model, count: model.count + 1 },
+ effects: [],
+ };
+ }
+ return { model, effects: [] };
+ };
+
+ const dispatcher = createDispatcher({
+ model: { count: 0 },
+ update: updateWithSideEffects,
+ effectRunner: () => {},
+ });
+
+ dispatcher.dispatch({ kind: "INC" });
+ dispatcher.dispatch({ kind: "INC" });
+
+ // Clear intermediate states for replay
+ const originalIntermediate = [...intermediateStates];
+ intermediateStates = [];
+
+ const result = dispatcher.verifyDeterminism();
+
+ // Final states match, but intermediate states are lost
+ expect(result.isMatch).toBe(true);
+ expect(intermediateStates).toEqual(originalIntermediate); // This fails
+});
+```
+
+### 6. Message Processing Order Test
+
+```typescript
+// Test that message processing order is not verified
+test("verifyDeterminism misses message processing order differences", () => {
+ const dispatcher = createDispatcher({
+ model: { log: [] },
+ update: (model, msg) => ({
+ model: { ...model, log: [...model.log, msg.id] },
+ effects: [],
+ }),
+ effectRunner: () => {},
+ });
+
+ // Dispatch messages in specific order
+ dispatcher.dispatch({ kind: "MSG", id: 1 });
+ dispatcher.dispatch({ kind: "MSG", id: 2 });
+ dispatcher.dispatch({ kind: "MSG", id: 3 });
+
+ const result = dispatcher.verifyDeterminism();
+
+ // verifyDeterminism doesn't validate processing order
+ expect(result.isMatch).toBe(true);
+ expect(dispatcher.getSnapshot().log).toEqual([1, 2, 3]);
+
+ // But if replay changed order, verification wouldn't catch it
+});
+```
+
+## Classification
+
+**Status**: Unverified
+
+**Evidence**:
+
+- Method exists and returns a result
+- Basic JSON comparison implemented
+- No evidence of comprehensive verification
+
+**Critical Flaws**:
+
+- Only compares final state, not processing
+- JSON serialization loses information
+- No validation of effect execution
+- No performance testing for large objects
+- No tests for the verification method itself
+
+**Falsification Risk**: CRITICAL - The method name implies comprehensive determinism verification but only provides basic state comparison. This creates a false sense of security.
+
+## Recommendation
+
+Rename to `compareFinalState()` and document that it only compares final JSON snapshots, not full determinism. Implement comprehensive verification including intermediate states, effect execution, and processing order.
diff --git a/docs/false-claims/FC-005-replay-torture-test.md b/docs/false-claims/FC-005-replay-torture-test.md
new file mode 100644
index 0000000..28e2560
--- /dev/null
+++ b/docs/false-claims/FC-005-replay-torture-test.md
@@ -0,0 +1,305 @@
+# Falsification Audit: FA-005
+
+## Claim
+
+**"Torture Test: Replays complex async session identically"** - Implied guarantee of comprehensive replay testing
+
+**Where Expressed**:
+
+- `packages/core/src/stress/replay.test.ts` line 75: test name and description
+- Test claims to validate "complex async session" replay
+- 50 iterations with random message selection
+
+## Enforcement Analysis
+
+**Enforcement**: Not enforced by test
+
+- Only uses `setTimeout` with fixed delays
+- Mock async behavior, not real async operations
+- No real network I/O or worker threads
+- No memory pressure or resource constraints
+
+**Code Evidence**:
+
+```typescript
+it("Torture Test: Replays complex async session identically", async () => {
+ const ITERATIONS = 50;
+ for (let i = 0; i < ITERATIONS; i++) {
+ const rand = Math.random();
+ if (rand < 0.3) {
+ dispatcher.dispatch({ kind: "INC" });
+ } else if (rand < 0.6) {
+ dispatcher.dispatch({ kind: "ASYNC_INC" });
+ } else {
+ dispatcher.dispatch({ kind: "ADD_RANDOM", val: rand });
+ }
+ if (i % 10 === 0) await new Promise((r) => setTimeout(r, 5));
+ }
+ await new Promise((r) => setTimeout(r, 200));
+ // Compare final state only
+});
+```
+
+## Mock/Test Double Insulation
+
+**Complete Insulation**:
+
+- Uses `setTimeout` instead of real async operations
+- No network calls, file I/O, or worker threads
+- No memory constraints or resource limits
+- Fixed timing patterns, not chaotic real-world timing
+- No concurrent async operations
+
+**What's NOT Tested**:
+
+- Real network timeouts and failures
+- Worker thread crashes and memory limits
+- Concurrent async operations
+- Memory pressure during replay
+- Browser event loop interference
+- Timer precision variations
+- Async stack overflow conditions
+
+## Falsification Strategies
+
+### 1. Real Network Async Test
+
+```typescript
+// Test replay with real network operations
+test("replay with real network async operations", async () => {
+ const realNetwork = new NetworkService();
+ const networkUpdate = async (model, msg) => {
+ if (msg.kind === "FETCH") {
+ try {
+ const data = await realNetwork.fetch(msg.url);
+ return { model: { ...model, data }, effects: [] };
+ } catch (error) {
+ return { model: { ...model, error }, effects: [] };
+ }
+ }
+ return { model, effects: [] };
+ };
+
+ // Run session with real network calls
+ await runNetworkSession(dispatcher, realNetwork);
+
+ // Replay should handle network timing differences
+ const replayed = replay({ initialModel, update: networkUpdate, log });
+ expect(replayed).toEqual(finalSnapshot);
+});
+```
+
+### 2. Concurrent Async Operations Test
+
+```typescript
+// Test replay with truly concurrent async operations
+test("replay with concurrent async operations", async () => {
+ const concurrentUpdate = (model, msg) => {
+ if (msg.kind === "CONCURRENT_FETCH") {
+ const effects = msg.urls.map((url) => ({
+ kind: "FETCH",
+ url,
+ id: Math.random(),
+ }));
+ return { model, effects };
+ }
+ return { model, effects: [] };
+ };
+
+ const effectRunner = async (effect, dispatch) => {
+ // Real concurrent fetches
+ const results = await Promise.all(effect.urls.map((url) => realFetch(url)));
+ dispatch({ kind: "RESULTS", data: results });
+ };
+
+ // Dispatch concurrent operations
+ dispatcher.dispatch({
+ kind: "CONCURRENT_FETCH",
+ urls: [url1, url2, url3, url4, url5],
+ });
+
+ await waitForAllEffects();
+
+ // Replay should preserve concurrent behavior
+ const replayed = replay({ initialModel, update: concurrentUpdate, log });
+ expect(replayed).toEqual(finalSnapshot);
+});
+```
+
+### 3. Memory Pressure During Replay Test
+
+```typescript
+// Test replay under memory constraints
+test("replay under memory pressure", async () => {
+ const memoryHogUpdate = (model, msg) => {
+ if (msg.kind === "ALLOCATE") {
+ const largeData = new Array(1000000).fill(0).map(() => ({
+ random: Math.random(),
+ nested: new Array(1000).fill(Math.random()),
+ }));
+ return { model: { ...model, largeData }, effects: [] };
+ }
+ return { model, effects: [] };
+ };
+
+ // Generate session with memory allocations
+ for (let i = 0; i < 100; i++) {
+ dispatcher.dispatch({ kind: "ALLOCATE" });
+ }
+
+ // Replay under memory pressure
+ const memoryLimitedReplay = withMemoryLimit(() =>
+ replay({ initialModel, update: memoryHogUpdate, log }),
+ );
+
+ expect(memoryLimitedReplay).toEqual(finalSnapshot);
+});
+```
+
+### 4. Timer Precision Test
+
+```typescript
+// Test replay with timer precision variations
+test("replay with timer precision variations", async () => {
+ const timerUpdate = (model, msg) => {
+ if (msg.kind === "TIMER_START") {
+ return {
+ model,
+ effects: [
+ {
+ kind: "TIMER",
+ delay: msg.delay,
+ precision: "high",
+ },
+ ],
+ };
+ }
+ return { model, effects: [] };
+ };
+
+ const effectRunner = (effect, dispatch) => {
+ if (effect.kind === "TIMER") {
+ // Use real timers with precision variations
+ const actualDelay = effect.delay + (Math.random() - 0.5) * 10;
+ setTimeout(() => dispatch({ kind: "TIMER_DONE" }), actualDelay);
+ }
+ };
+
+ // Run session with precision variations
+ await runTimerSession(dispatcher);
+
+ // Replay should handle timing differences
+ const replayed = replay({ initialModel, update: timerUpdate, log });
+ expect(replayed).toEqual(finalSnapshot);
+});
+```
+
+### 5. Worker Thread Crash Test
+
+```typescript
+// Test replay with worker thread failures
+test("replay with worker thread crashes", async () => {
+ const workerUpdate = (model, msg) => {
+ if (msg.kind === "HEAVY_COMPUTE") {
+ return {
+ model,
+ effects: [
+ {
+ kind: "WORKER",
+ task: msg.task,
+ crashProbability: 0.1,
+ },
+ ],
+ };
+ }
+ return { model, effects: [] };
+ };
+
+ const effectRunner = (effect, dispatch) => {
+ if (effect.kind === "WORKER") {
+ const worker = new Worker("compute-worker.js");
+
+ worker.onmessage = (e) => {
+ dispatch({ kind: "WORKER_RESULT", data: e.data });
+ };
+
+ worker.onerror = (error) => {
+ dispatch({ kind: "WORKER_ERROR", error });
+ };
+
+ // Simulate random crashes
+ if (Math.random() < effect.crashProbability) {
+ worker.terminate();
+ setTimeout(() => dispatch({ kind: "WORKER_CRASHED" }), 10);
+ }
+
+ worker.postMessage(effect.task);
+ }
+ };
+
+ // Run session with potential worker crashes
+ await runWorkerSession(dispatcher);
+
+ // Replay should handle crash differences
+ const replayed = replay({ initialModel, update: workerUpdate, log });
+ expect(replayed).toEqual(finalSnapshot);
+});
+```
+
+### 6. Event Loop Interference Test
+
+```typescript
+// Test replay with event loop interference
+test("replay with event loop interference", async () => {
+ const blockingUpdate = (model, msg) => {
+ if (msg.kind === "BLOCKING_TASK") {
+ // Simulate blocking operation
+ const start = Date.now();
+ while (Date.now() - start < 50) {} // Block for 50ms
+ return { model: { ...model, blocked: true }, effects: [] };
+ }
+ return { model, effects: [] };
+ };
+
+ // Interfere with event loop during session
+ const eventLoopInterference = setInterval(() => {
+ // Add event loop pressure
+ const start = Date.now();
+ while (Date.now() - start < 10) {}
+ }, 5);
+
+ try {
+ await runBlockingSession(dispatcher);
+ } finally {
+ clearInterval(eventLoopInterference);
+ }
+
+ // Replay should be immune to event loop interference
+ const replayed = replay({ initialModel, update: blockingUpdate, log });
+ expect(replayed).toEqual(finalSnapshot);
+});
+```
+
+## Classification
+
+**Status**: Weakly Supported
+
+**Evidence**:
+
+- Test exists with multiple iterations
+- Random message selection
+- Some async behavior with setTimeout
+
+**Critical Flaws**:
+
+- No real async operations (network, workers, file I/O)
+- No resource constraints or memory pressure
+- Fixed timing patterns, not real-world chaos
+- No concurrent async operations
+- No failure scenarios
+
+**Falsification Risk**: HIGH - The "torture test" name implies comprehensive stress testing but only provides basic async simulation. Real-world async complexity is completely absent.
+
+## Recommendation
+
+Rename to "Basic Async Replay Test" and implement real torture tests with network I/O, worker threads, memory pressure, and concurrent operations.
diff --git a/docs/false-claims/FC-006-stale-safe-search.md b/docs/false-claims/FC-006-stale-safe-search.md
new file mode 100644
index 0000000..d11c7b6
--- /dev/null
+++ b/docs/false-claims/FC-006-stale-safe-search.md
@@ -0,0 +1,177 @@
+# False Claim Analysis: FC-006
+
+## Claim
+
+**Source**: app-web/src/features/search/search.ts, Line 114
+**Full Context**: "Feature A: Stale-Safe Search"
+
+**Type**: Reliability
+
+## Verdict
+
+**Status**: Weakly Supported
+
+## Proof Criteria (Reliability)
+
+- Invariant in code showing stale response prevention
+- Failure test demonstrating race condition handling
+- Evidence that abortKey prevents stale responses
+
+## Evidence Analysis
+
+### Found Evidence
+
+- Line 50: `abortKey: "search"` - abort controller key for cancellation
+- Lines 73-74: Request ID validation - ignores responses with old IDs
+- Lines 85-86: Same validation for error responses
+- BrowserRunner implements "takeLatest" strategy via abortKey
+
+### Missing Evidence
+
+- No tests for rapid search query changes
+- No tests for slow network responses
+- No tests for concurrent search requests
+- No tests for abortKey edge cases
+
+### Contradictory Evidence
+
+- Race condition protection relies on manual requestId checking
+- AbortKey behavior not tested in integration
+- No validation that stale responses are actually discarded
+
+## Falsification Strategies
+
+### 1. Rapid Search Changes Test
+
+```typescript
+test("stale-safe search with rapid query changes", async () => {
+ const slowNetwork = new SlowNetwork({ delayMs: 1000 });
+ const renderer = createSearchRenderer(slowNetwork);
+
+ // Type search queries rapidly
+ renderer.input("a");
+ await delay(10);
+ renderer.input("ab");
+ await delay(10);
+ renderer.input("abc");
+
+ // Wait for all responses
+ await delay(2000);
+
+ // Should only show results for "abc", not stale "a" or "ab" results
+ expect(renderer.getResults()).toBe("abc results");
+ expect(renderer.getStatus()).toBe("success");
+});
+```
+
+### 2. Concurrent Request Race Test
+
+```typescript
+test("concurrent search requests don't overwrite results", async () => {
+ const unpredictableNetwork = new UnpredictableNetwork({
+ responseTimeRange: [50, 500],
+ });
+
+ const renderer = createSearchRenderer(unpredictableNetwork);
+
+ // Send multiple requests simultaneously
+ renderer.input("query1");
+ renderer.input("query2");
+ renderer.input("query3");
+
+ await delay(1000);
+
+ // Results should match the last request, not random order
+ expect(renderer.getResults()).toBe("query3 results");
+});
+```
+
+### 3. AbortKey Failure Test
+
+```typescript
+test("abortKey failure causes stale responses", async () => {
+ const faultyRunner = new BrowserRunner({
+ createAbortController: () => {
+ // Return faulty controller that doesn't abort
+ return new FaultyAbortController();
+ },
+ });
+
+ const dispatcher = createSearchDispatcher(faultyRunner);
+
+ dispatcher.dispatch({ kind: "search_changed", query: "first" });
+ await delay(10);
+ dispatcher.dispatch({ kind: "search_changed", query: "second" });
+
+ await delay(1000);
+
+ // Faulty abort controller might allow stale responses
+ const results = dispatcher.getSnapshot().search.results;
+ expect(results).not.toBe("first results"); // This might fail
+});
+```
+
+### 4. Network Timeout Test
+
+```typescript
+test("network timeouts don't cause stale state", async () => {
+ const timeoutNetwork = new TimeoutNetwork({ timeoutMs: 100 });
+ const renderer = createSearchRenderer(timeoutNetwork);
+
+ renderer.input("normal_query");
+ await delay(50);
+ renderer.input("timeout_query"); // This will timeout
+
+ await delay(200);
+
+ // Should recover from timeout, not show stale results
+ expect(renderer.getStatus()).toBe("error");
+ expect(renderer.getResults()).toBe("No results found.");
+});
+```
+
+### 5. Memory Leak Test
+
+```typescript
+test("rapid search changes don't cause memory leaks", async () => {
+ const renderer = createSearchRenderer();
+ const initialMemory = getMemoryUsage();
+
+ // Rapid search changes
+ for (let i = 0; i < 1000; i++) {
+ renderer.input(`query_${i}`);
+ await delay(1);
+ }
+
+ await delay(5000); // Wait for all requests to settle
+
+ const finalMemory = getMemoryUsage();
+ const memoryIncrease = finalMemory - initialMemory;
+
+ // Should not leak memory from aborted requests
+ expect(memoryIncrease).toBeLessThan(10 * 1024 * 1024); // 10MB limit
+});
+```
+
+## Classification
+
+**Status**: Weakly Supported
+
+**Evidence**:
+
+- Basic requestId validation implemented
+- AbortKey mechanism exists in BrowserRunner
+- Manual stale response prevention in update logic
+
+**Critical Flaws**:
+
+- No integration tests for race conditions
+- AbortKey behavior not verified in real scenarios
+- Relies on developer diligence for requestId checks
+- No tests for network failure scenarios
+
+**Falsification Risk**: MEDIUM - The "stale-safe" claim has basic implementation but lacks comprehensive testing of real-world race conditions and network failures.
+
+## Recommendation
+
+Add integration tests that simulate real network timing variations and rapid user input. Consider making the stale-safe pattern more automatic rather than requiring manual requestId checking.
diff --git a/docs/false-claims/FC-007-worker-pool-management.md b/docs/false-claims/FC-007-worker-pool-management.md
new file mode 100644
index 0000000..30b20ce
--- /dev/null
+++ b/docs/false-claims/FC-007-worker-pool-management.md
@@ -0,0 +1,294 @@
+# False Claim Analysis: FC-007
+
+## Claim
+
+**Source**: packages/platform-browser/src/runners/index.ts, Lines 27-35
+**Full Context**: Worker pool management with "lazy-grow, cap-and-queue" strategy
+
+**Type**: Performance
+
+## Verdict
+
+**Status**: Unverified
+
+## Proof Criteria (Performance)
+
+- Benchmark or measurable artifact showing pool efficiency
+- Test demonstrating queue behavior under load
+- Evidence that pool management prevents resource exhaustion
+
+## Evidence Analysis
+
+### Found Evidence
+
+- Lines 27-35: Worker pool data structures implemented
+- Lines 174-188: Pool creation and queue management logic
+- Lines 197-225: Worker timeout and replacement logic
+- Default maxWorkersPerUrl: 4 (line 47)
+
+### Missing Evidence
+
+- No performance benchmarks for pool efficiency
+- No tests for queue behavior under high load
+- No evidence that pool actually improves performance
+- No tests for resource exhaustion prevention
+
+### Contradictory Evidence
+
+- Worker creation is synchronous, could block
+- No backpressure mechanism when queue grows
+- Timeout creates new workers but doesn't prevent queue buildup
+- No monitoring of pool effectiveness
+
+## Falsification Strategies
+
+### 1. Pool Efficiency Test
+
+```typescript
+test("worker pool improves performance vs individual workers", async () => {
+ const pooledRunner = new BrowserRunner({ maxWorkersPerUrl: 4 });
+ const individualRunner = new BrowserRunner({ maxWorkersPerUrl: 1 });
+
+ const tasks = Array.from({ length: 20 }, (_, i) => ({
+ scriptUrl: "compute-worker.js",
+ payload: { compute: i, complexity: 1000 },
+ }));
+
+ // Test pooled performance
+ const pooledStart = performance.now();
+ await Promise.all(
+ tasks.map(
+ (task) =>
+ new Promise((resolve) => {
+ pooledRunner.run(task, resolve);
+ }),
+ ),
+ );
+ const pooledTime = performance.now() - pooledStart;
+
+ // Test individual worker performance
+ const individualStart = performance.now();
+ await Promise.all(
+ tasks.map(
+ (task) =>
+ new Promise((resolve) => {
+ individualRunner.run(task, resolve);
+ }),
+ ),
+ );
+ const individualTime = performance.now() - individualStart;
+
+ // Pool should be significantly faster
+ expect(pooledTime).toBeLessThan(individualTime * 0.8);
+});
+```
+
+### 2. Queue Overflow Test
+
+```typescript
+test("queue prevents resource exhaustion under high load", async () => {
+ const runner = new BrowserRunner({ maxWorkersPerUrl: 2 });
+ const slowWorker = new SlowWorker({ delayMs: 1000 });
+
+ // Submit more tasks than pool can handle
+ const tasks = Array.from({ length: 100 }, (_, i) => ({
+ scriptUrl: "slow-worker.js",
+ payload: { id: i },
+ }));
+
+ const results = [];
+ const startTime = Date.now();
+
+ // All tasks should eventually complete
+ for (const task of tasks) {
+ await new Promise((resolve) => {
+ runner.run(task, (result) => {
+ results.push(result);
+ resolve();
+ });
+ });
+ }
+
+ const endTime = Date.now();
+ const totalTime = endTime - startTime;
+
+ // Should complete in reasonable time (not hang forever)
+ expect(totalTime).toBeLessThan(30000); // 30 seconds max
+ expect(results).toHaveLength(100);
+});
+```
+
+### 3. Memory Leak Test
+
+```typescript
+test("worker pool doesn't leak memory under sustained load", async () => {
+ const runner = new BrowserRunner({ maxWorkersPerUrl: 4 });
+ const initialMemory = getMemoryUsage();
+
+ // Sustained load for extended period
+ for (let round = 0; round < 100; round++) {
+ const tasks = Array.from({ length: 20 }, (_, i) => ({
+ scriptUrl: "memory-test-worker.js",
+ payload: { round, task: i, data: new Array(1000).fill(0) },
+ }));
+
+ await Promise.all(
+ tasks.map(
+ (task) =>
+ new Promise((resolve) => {
+ runner.run(task, resolve);
+ }),
+ ),
+ );
+
+ // Allow GC
+ await new Promise((resolve) => setTimeout(resolve, 10));
+ }
+
+ const finalMemory = getMemoryUsage();
+ const memoryIncrease = finalMemory - initialMemory;
+
+ // Should not leak significant memory
+ expect(memoryIncrease).toBeLessThan(50 * 1024 * 1024); // 50MB limit
+});
+```
+
+### 4. Worker Timeout Recovery Test
+
+```typescript
+test("worker timeout recovery maintains pool integrity", async () => {
+ const runner = new BrowserRunner({ maxWorkersPerUrl: 2 });
+
+ // Submit tasks that will timeout
+ const timeoutTasks = Array.from({ length: 4 }, (_, i) => ({
+ scriptUrl: "timeout-worker.js",
+ payload: { timeoutMs: 100, id: i },
+ timeoutMs: 50, // Force timeout
+ }));
+
+ const timeoutResults = [];
+
+ // All timeout tasks should complete with errors
+ for (const task of timeoutTasks) {
+ await new Promise((resolve) => {
+ runner.run(task, (result) => {
+ timeoutResults.push(result);
+ resolve();
+ });
+ });
+ }
+
+ // Pool should still be functional after timeouts
+ const normalTask = {
+ scriptUrl: "normal-worker.js",
+ payload: { compute: 42 },
+ };
+
+ const normalResult = await new Promise((resolve) => {
+ runner.run(normalTask, resolve);
+ });
+
+ expect(normalResult).toBeDefined();
+ expect(timeoutResults.every((r) => r.error)).toBe(true);
+});
+```
+
+### 5. Concurrent Script URLs Test
+
+```typescript
+test("multiple script URLs don't interfere with each other", async () => {
+ const runner = new BrowserRunner({ maxWorkersPerUrl: 2 });
+
+ const tasks = [
+ ...Array.from({ length: 10 }, (_, i) => ({
+ scriptUrl: "worker-a.js",
+ payload: { id: i, type: "A" },
+ })),
+ ...Array.from({ length: 10 }, (_, i) => ({
+ scriptUrl: "worker-b.js",
+ payload: { id: i, type: "B" },
+ })),
+ ];
+
+ const results = [];
+
+ // All tasks should complete correctly
+ for (const task of tasks) {
+ await new Promise((resolve) => {
+ runner.run(task, (result) => {
+ results.push(result);
+ resolve();
+ });
+ });
+ }
+
+ // Results should be segregated by script URL
+ const aResults = results.filter((r) => r.type === "A");
+ const bResults = results.filter((r) => r.type === "B");
+
+ expect(aResults).toHaveLength(10);
+ expect(bResults).toHaveLength(10);
+
+ // No cross-contamination
+ expect(aResults.every((r) => r.type === "A")).toBe(true);
+ expect(bResults.every((r) => r.type === "B")).toBe(true);
+});
+```
+
+### 6. Backpressure Test
+
+```typescript
+test("queue provides backpressure under extreme load", async () => {
+ const runner = new BrowserRunner({ maxWorkersPerUrl: 2 });
+ const queueSizes = [];
+
+ // Monitor queue size
+ const originalProcessNext = runner.processNextInQueue.bind(runner);
+ runner.processNextInQueue = (scriptUrl) => {
+ const queue = runner.workerQueue.get(scriptUrl);
+ queueSizes.push(queue?.length || 0);
+ return originalProcessNext(scriptUrl);
+ };
+
+ // Submit massive number of tasks
+ const tasks = Array.from({ length: 1000 }, (_, i) => ({
+ scriptUrl: "slow-worker.js",
+ payload: { id: i },
+ }));
+
+ tasks.forEach((task) => runner.run(task, () => {}));
+
+ // Wait for queue to fill
+ await new Promise((resolve) => setTimeout(resolve, 100));
+
+ const maxQueueSize = Math.max(...queueSizes);
+
+ // Queue should grow but not indefinitely
+ expect(maxQueueSize).toBeGreaterThan(0);
+ expect(maxQueueSize).toBeLessThan(1000); // Should have some limit
+});
+```
+
+## Classification
+
+**Status**: Unverified
+
+**Evidence**:
+
+- Worker pool implementation exists
+- Queue management logic implemented
+- Timeout and replacement mechanisms present
+
+**Critical Flaws**:
+
+- No performance benchmarks proving pool efficiency
+- No tests for queue behavior under load
+- No evidence that pool actually improves performance
+- No backpressure mechanism for queue overflow
+- No monitoring of pool effectiveness
+
+**Falsification Risk**: HIGH - The performance claim is completely untested. The pool implementation exists but there's no evidence it actually improves performance or prevents resource exhaustion.
+
+## Recommendation
+
+Add comprehensive performance benchmarks comparing pooled vs individual workers, and add tests that validate queue behavior under high load and resource constraints.
diff --git a/docs/false-claims/FC-008-session-restore-completeness.md b/docs/false-claims/FC-008-session-restore-completeness.md
new file mode 100644
index 0000000..ba9b9e6
--- /dev/null
+++ b/docs/false-claims/FC-008-session-restore-completeness.md
@@ -0,0 +1,267 @@
+# False Claim Analysis: FC-008
+
+## Claim
+
+**Source**: app-web/src/main.ts, Lines 177-198
+**Full Context**: Manual session restore normalization for all in-flight states
+
+**Type**: Reliability
+
+## Verdict
+
+**Status**: Demonstrably False
+
+## Proof Criteria (Reliability)
+
+- Invariant in code showing complete state normalization
+- Failure test demonstrating all edge cases are handled
+- Evidence that phantom pending states are eliminated
+
+## Evidence Analysis
+
+### Found Evidence
+
+- Lines 177-198: Manual normalization for worker, load, and search states
+- Lines 177-185: Worker computing state reset to idle
+- Lines 187-192: Load loading state reset to idle
+- Lines 193-197: Search loading state reset to idle
+
+### Missing Evidence
+
+- No normalization for timer subscriptions
+- No normalization for animation frame subscriptions
+- No normalization for stress test subscriptions
+- No systematic approach to catch all in-flight states
+
+### Contradictory Evidence
+
+- Manual normalization is error-prone and incomplete
+- docs/notes/ideas.md explicitly documents this as a known bug class
+- New features must remember to add their own normalization
+- No automated detection of missing normalizations
+
+## Falsification Strategies
+
+### 1. Timer Subscription Phantom State Test
+
+```typescript
+test("session restore leaves timer subscriptions in phantom state", async () => {
+ const dispatcher = createDispatcher({
+ model: { timer: { isRunning: true, interval: 1000 } },
+ update: timerUpdate,
+ subscriptions: timerSubscriptions,
+ subscriptionRunner: mockTimerRunner,
+ });
+
+ // Start timer subscription
+ dispatcher.dispatch({ kind: "START_TIMER" });
+ await delay(100);
+
+ // Get replayable state
+ const { log, snapshot } = dispatcher.getReplayableState();
+
+ // Replay from saved state
+ const replayed = replay({
+ initialModel: initialModel,
+ update: timerUpdate,
+ log,
+ });
+
+ // Timer should be running but isn't (phantom pending)
+ expect(replayed.timer.isRunning).toBe(true);
+ expect(mockTimerRunner.activeSubscriptions.size).toBe(0); // No actual timer!
+});
+```
+
+### 2. Animation Frame Phantom State Test
+
+```typescript
+test("session restore leaves animation frame subscriptions phantom", async () => {
+ const dispatcher = createDispatcher({
+ model: { animation: { isAnimating: true } },
+ update: animationUpdate,
+ subscriptions: animationSubscriptions,
+ subscriptionRunner: mockAnimationRunner,
+ });
+
+ // Start animation
+ dispatcher.dispatch({ kind: "START_ANIMATION" });
+ await delay(16);
+
+ const { log, snapshot } = dispatcher.getReplayableState();
+
+ const replayed = replay({
+ initialModel: initialModel,
+ update: animationUpdate,
+ log,
+ });
+
+ // Animation appears running but no actual RAF callback
+ expect(replayed.animation.isAnimating).toBe(true);
+ expect(mockAnimationRunner.activeSubscriptions.size).toBe(0);
+});
+```
+
+### 3. Stress Test Phantom State Test
+
+```typescript
+test("session restore leaves stress test subscriptions phantom", async () => {
+ const dispatcher = createDispatcher({
+ model: { stress: { isRunning: true, intensity: 100 } },
+ update: stressUpdate,
+ subscriptions: stressSubscriptions,
+ subscriptionRunner: mockStressRunner,
+ });
+
+ // Start stress test
+ dispatcher.dispatch({ kind: "START_STRESS" });
+ await delay(100);
+
+ const { log, snapshot } = dispatcher.getReplayableState();
+
+ const replayed = replay({
+ initialModel: initialModel,
+ update: stressUpdate,
+ log,
+ });
+
+ // Stress test appears running but no actual stress
+ expect(replayed.stress.isRunning).toBe(true);
+ expect(mockStressRunner.activeSubscriptions.size).toBe(0);
+});
+```
+
+### 4. New Feature Missing Normalization Test
+
+```typescript
+test("new features without normalization cause phantom states", async () => {
+ // Add new feature with in-flight state
+ const newFeatureUpdate = (model, msg) => {
+ if (msg.kind === "START_NEW_FEATURE") {
+ return {
+ model: {
+ ...model,
+ newFeature: { status: "processing", progress: 0 },
+ },
+ effects: [],
+ };
+ }
+ return { model, effects: [] };
+ };
+
+ const dispatcher = createDispatcher({
+ model: { newFeature: { status: "idle", progress: 0 } },
+ update: newFeatureUpdate,
+ });
+
+ dispatcher.dispatch({ kind: "START_NEW_FEATURE" });
+
+ const { log, snapshot } = dispatcher.getReplayableState();
+
+ const replayed = replay({
+ initialModel: { newFeature: { status: "idle", progress: 0 } },
+ update: newFeatureUpdate,
+ log,
+ });
+
+ // New feature is stuck in processing state (phantom pending)
+ expect(replayed.newFeature.status).toBe("processing");
+ // But no actual processing is happening
+});
+```
+
+### 5. Incomplete Normalization Detection Test
+
+```typescript
+test("automated detection of incomplete normalization", () => {
+ const allSubscriptions = [
+ "timer",
+ "animation",
+ "worker",
+ "search",
+ "load",
+ "stress",
+ ];
+
+ const normalizedStates = [
+ "worker",
+ "search",
+ "load", // Only these are normalized
+ ];
+
+ const missingNormalizations = allSubscriptions.filter(
+ (sub) => !normalizedStates.includes(sub),
+ );
+
+ // Should detect missing normalizations
+ expect(missingNormalizations).toEqual(["timer", "animation", "stress"]);
+
+ // This should be a compile-time or lint error
+ console.warn("Missing normalization for:", missingNormalizations);
+});
+```
+
+### 6. Race Condition During Restore Test
+
+```typescript
+test("race conditions during session restore cause inconsistent state", async () => {
+ const dispatcher = createDispatcher({
+ model: initialModel,
+ update: appUpdate,
+ subscriptions: appSubscriptions,
+ });
+
+ // Start multiple subscriptions
+ dispatcher.dispatch({ kind: "START_TIMER" });
+ dispatcher.dispatch({ kind: "START_ANIMATION" });
+ dispatcher.dispatch({ kind: "START_WORKER" });
+
+ await delay(100);
+
+ const { log, snapshot } = dispatcher.getReplayableState();
+
+ // Simulate race condition during restore
+ const restoredModel = JSON.parse(JSON.stringify(snapshot));
+
+ // Manual normalization (current approach)
+ if (restoredModel.worker.status === "computing") {
+ restoredModel.worker.status = "idle";
+ }
+ // Forget to normalize timer and animation
+
+ const replayed = replay({
+ initialModel,
+ update: appUpdate,
+ log,
+ });
+
+ // Inconsistent state - some normalized, some not
+ expect(replayed.worker.status).toBe("idle"); // Normalized
+ expect(replayed.timer.isRunning).toBe(true); // Not normalized!
+ expect(replayed.animation.isAnimating).toBe(true); // Not normalized!
+});
+```
+
+## Classification
+
+**Status**: Demonstrably False
+
+**Evidence**:
+
+- Manual normalization is incomplete (missing timer, animation, stress)
+- docs/notes/ideas.md documents this as a known bug class
+- New features can easily introduce phantom states
+- No automated detection of missing normalizations
+
+**Critical Flaws**:
+
+- Systematic design flaw requiring manual intervention
+- Incomplete normalization leaves phantom states
+- Error-prone manual process
+- No automated verification of completeness
+
+**Falsification Risk**: CRITICAL - The claim of complete session restore is demonstrably false. The system has a known architectural flaw that causes phantom pending states.
+
+## Recommendation
+
+Implement framework-level subscription resumption as described in docs/notes/ideas.md, or add automated detection of in-flight states that need normalization. The current manual approach is fundamentally broken.
diff --git a/docs/false-claims/FC-009-prevent-default-guarantee.md b/docs/false-claims/FC-009-prevent-default-guarantee.md
new file mode 100644
index 0000000..70e2761
--- /dev/null
+++ b/docs/false-claims/FC-009-prevent-default-guarantee.md
@@ -0,0 +1,313 @@
+# False Claim Analysis: FC-009
+
+## Claim
+
+**Source**: packages/platform-browser/src/renderer.ts, Line 37
+**Full Context**: `if (event === "submit") ev.preventDefault();`
+
+**Type**: Behavioral
+
+## Verdict
+
+**Status**: Probably False
+
+## Proof Criteria (Behavioral)
+
+- Code path showing preventDefault always works
+- Test demonstrating form submission prevention
+- Evidence that all submit events are handled
+
+## Evidence Analysis
+
+### Found Evidence
+
+- Line 37: Automatic preventDefault for submit events
+- Line 36-44: Event handler wrapper with dispatch logic
+- Event handling integrated into Snabbdom renderer
+
+### Missing Evidence
+
+- No tests for form submission behavior
+- No evidence preventDefault works in all contexts
+- No tests for edge cases (multiple forms, dynamic forms)
+- No validation that submit events are always caught
+
+### Contradictory Evidence
+
+- preventDefault only applies to events processed through the renderer
+- Forms submitted outside the renderer bypass this protection
+- No error handling if preventDefault fails
+- Submit events can be triggered programmatically
+
+## Falsification Strategies
+
+### 1. Direct Form Submission Test
+
+```typescript
+test("preventDefault doesn't stop direct form submission", async () => {
+ const container = document.createElement("div");
+ document.body.appendChild(container);
+
+ const formHtml = `
+
+ `;
+ container.innerHTML = formHtml;
+
+ const renderer = createSnabbdomRenderer(container, () => ({
+ kind: "text",
+ text: "test",
+ }));
+
+ const form = container.querySelector("#test-form") as HTMLFormElement;
+ let submitted = false;
+
+ // Override form submission to detect if preventDefault worked
+ const originalSubmit = form.submit;
+ form.submit = () => {
+ submitted = true;
+ };
+
+ // Add submit event listener to track preventDefault
+ let preventDefaultCalled = false;
+ form.addEventListener("submit", (e) => {
+ preventDefaultCalled = e.defaultPrevented;
+ });
+
+ // Trigger form submission
+ const submitButton = form.querySelector("button") as HTMLButtonElement;
+ submitButton.click();
+
+ // Check if submission was prevented
+ expect(preventDefaultCalled).toBe(false); // Not processed by renderer
+ expect(submitted).toBe(true); // Form still submitted
+});
+```
+
+### 2. Programmatic Submission Test
+
+```typescript
+test("preventDefault doesn't stop programmatic submission", async () => {
+ const container = document.createElement("div");
+ document.body.appendChild(container);
+
+ const renderer = createSnabbdomRenderer(container, (model, dispatch) => ({
+ kind: "div",
+ tag: "form",
+ data: {
+ on: {
+ submit: () => dispatch({ kind: "FORM_SUBMITTED" }),
+ },
+ },
+ children: [
+ {
+ kind: "text",
+ text: "Form",
+ },
+ ],
+ }));
+
+ renderer.render({}, () => {});
+
+ const form = container.querySelector("form") as HTMLFormElement;
+ let submitted = false;
+
+ // Override form submission
+ const originalSubmit = form.submit;
+ form.submit = () => {
+ submitted = true;
+ };
+
+ // Submit programmatically (bypasses click event)
+ form.submit();
+
+ expect(submitted).toBe(true); // Programmatic submission not prevented
+});
+```
+
+### 3. Multiple Forms Test
+
+```typescript
+test("preventDefault only applies to renderer-managed forms", async () => {
+ const container = document.createElement("div");
+ document.body.appendChild(container);
+
+ // Mix of renderer-managed and native forms
+ container.innerHTML = `
+
+
+ `;
+
+ const renderer = createSnabbdomRenderer(
+ container.querySelector("#renderer-form")!,
+ () => ({
+ kind: "form",
+ tag: "form",
+ data: { on: { submit: () => {} } },
+ children: [{ kind: "text", text: "Renderer Form" }],
+ }),
+ );
+
+ renderer.render({}, () => {});
+
+ const nativeForm = container.querySelector("#native-form") as HTMLFormElement;
+ let nativeSubmitted = false;
+
+ nativeForm.addEventListener("submit", (e) => {
+ e.preventDefault();
+ nativeSubmitted = true;
+ });
+
+ // Submit native form
+ const submitButton = nativeForm.querySelector("button") as HTMLButtonElement;
+ submitButton.click();
+
+ expect(nativeSubmitted).toBe(true); // Native form works normally
+});
+```
+
+### 4. Event Bypass Test
+
+```typescript
+test("submit events can bypass renderer event handling", async () => {
+ const container = document.createElement("div");
+ document.body.appendChild(container);
+
+ const renderer = createSnabbdomRenderer(container, (model, dispatch) => ({
+ kind: "form",
+ tag: "form",
+ data: {
+ on: {
+ submit: () => dispatch({ kind: "FORM_SUBMITTED" }),
+ },
+ },
+ children: [
+ {
+ kind: "input",
+ tag: "input",
+ data: { attrs: { type: "submit" } },
+ },
+ ],
+ }));
+
+ renderer.render({}, () => {});
+
+ const form = container.querySelector("form") as HTMLFormElement;
+ let submitted = false;
+
+ // Add submit listener directly to form (bypasses renderer)
+ form.addEventListener("submit", (e) => {
+ e.stopPropagation(); // Stop event from reaching renderer
+ submitted = true;
+ });
+
+ const input = form.querySelector("input") as HTMLInputElement;
+ input.click();
+
+ expect(submitted).toBe(true); // Event bypassed renderer
+});
+```
+
+### 5. Dynamic Form Test
+
+```typescript
+test("dynamically added forms don't get preventDefault", async () => {
+ const container = document.createElement("div");
+ document.body.appendChild(container);
+
+ const renderer = createSnabbdomRenderer(container, (model, dispatch) => ({
+ kind: "div",
+ tag: "div",
+ children: [{ kind: "text", text: "Container" }],
+ }));
+
+ renderer.render({}, () => {});
+
+ // Dynamically add form after renderer initialization
+ const dynamicForm = document.createElement("form");
+ dynamicForm.innerHTML = '';
+ container.appendChild(dynamicForm);
+
+ let submitted = false;
+ dynamicForm.addEventListener("submit", (e) => {
+ submitted = true;
+ });
+
+ const button = dynamicForm.querySelector("button") as HTMLButtonElement;
+ button.click();
+
+ expect(submitted).toBe(true); // Dynamic form not protected
+});
+```
+
+### 6. Error Handling Test
+
+```typescript
+test("preventDefault failure is not handled", async () => {
+ const container = document.createElement("div");
+ document.body.appendChild(container);
+
+ const renderer = createSnabbdomRenderer(container, (model, dispatch) => ({
+ kind: "form",
+ tag: "form",
+ data: {
+ on: {
+ submit: () => {
+ throw new Error("Handler error");
+ },
+ },
+ },
+ children: [{ kind: "text", text: "Form" }],
+ }));
+
+ renderer.render({}, () => {});
+
+ const form = container.querySelector("form") as HTMLFormElement;
+ let submitted = false;
+
+ // Override preventDefault to simulate failure
+ const originalPreventDefault = Event.prototype.preventDefault;
+ Event.prototype.preventDefault = function () {
+ throw new Error("preventDefault failed");
+ };
+
+ try {
+ const button = form.querySelector("button") as HTMLButtonElement;
+ button.click();
+ } catch (e) {
+ // Error not caught by renderer
+ } finally {
+ Event.prototype.preventDefault = originalPreventDefault;
+ }
+
+ // Form might still submit if preventDefault failed
+ expect(submitted).toBe(true); // Might be true depending on browser
+});
+```
+
+## Classification
+
+**Status**: Probably False
+
+**Evidence**:
+
+- preventDefault implemented for submit events
+- Integrated into Snabbdom renderer event handling
+
+**Critical Flaws**:
+
+- Only applies to renderer-managed forms
+- No protection for programmatic submission
+- No protection for dynamically added forms
+- No error handling for preventDefault failures
+- Events can bypass renderer handling
+
+**Falsification Risk**: MEDIUM - The claim implies universal form submission prevention but only covers a narrow subset of submission scenarios.
+
+## Recommendation
+
+Document that preventDefault only applies to renderer-managed submit events, or implement comprehensive form submission handling that covers all edge cases.
diff --git a/docs/false-claims/FIX-FC-008-prompt.md b/docs/false-claims/FIX-FC-008-prompt.md
new file mode 100644
index 0000000..1acea62
--- /dev/null
+++ b/docs/false-claims/FIX-FC-008-prompt.md
@@ -0,0 +1,199 @@
+# Fix Request: Eliminate Phantom Pending Bug (FC-008)
+
+## Mission
+
+Fix the **critical phantom pending bug** in causaloop's session restore system. Currently, manual normalization is incomplete and error-prone, leaving subscriptions (timer, animation, stress) in "phantom" states where they appear active but aren't actually running.
+
+## Problem Analysis
+
+**Current Broken Implementation** (app-web/src/main.ts:177-198):
+
+```typescript
+// Manual normalization (INCOMPLETE)
+if (restoredModel.worker.status === "computing") {
+ restoredModel.worker.status = "idle";
+}
+if (restoredModel.load.status === "loading") {
+ restoredModel.load.status = "idle";
+}
+if (restoredModel.search.status === "loading") {
+ restoredModel.search.status = "idle";
+}
+// MISSING: timer, animation, stress subscriptions
+```
+
+**Root Cause**: Framework requires manual intervention for each feature's in-flight state. New features must remember to add normalization - error-prone and incomplete.
+
+## Solution Requirements
+
+Implement **framework-level subscription resumption** as designed in docs/notes/ideas.md:
+
+### 1. Automatic Subscription Detection
+
+- Dispatcher should automatically detect which subscriptions should be running based on model state
+- No manual normalization required
+- Subscriptions automatically resume after replay
+
+### 2. Declarative Subscription Model
+
+```typescript
+const subscriptions = (model) => {
+ return [
+ model.timer.isRunning ? timerSub(model.timer.interval) : null,
+ model.animation.isAnimating ? animationSub() : null,
+ model.stress.isRunning ? stressSub(model.stress.intensity) : null,
+ // Add new features here - automatically handled
+ ].filter(Boolean);
+};
+```
+
+### 3. Framework-Level Recovery
+
+- Dispatcher automatically reconciles subscriptions after replay
+- `reconcileSubscriptions()` called during session restore
+- No phantom pending states possible
+
+## Implementation Tasks
+
+### Phase 1: Core Framework Changes
+
+1. **Update Dispatcher** (packages/core/src/dispatcher.ts):
+ - Ensure `reconcileSubscriptions()` is called after replay
+ - Add automatic subscription resumption logic
+2. **Enhance Replay Integration** (packages/core/src/replay.ts):
+ - Support subscription-aware replay
+ - Ensure replay triggers subscription reconciliation
+
+### Phase 2: Application Layer Updates
+
+1. **Remove Manual Normalization** (app-web/src/main.ts):
+ - Delete lines 177-198 (manual normalization)
+ - Replace with framework-level approach
+
+2. **Update Subscription Functions**:
+ - Ensure timer, animation, stress subscriptions are model-driven
+ - Add subscription functions that return null when not active
+
+### Phase 3: Validation
+
+1. **Add Integration Tests**:
+ - Test session restore with active timer
+ - Test session restore with active animation
+ - Test session restore with active stress test
+ - Verify no phantom pending states
+
+2. **Add Regression Protection**:
+ - Test that new features automatically work with session restore
+ - Verify no manual normalization needed
+
+## Success Criteria
+
+### Functional Requirements
+
+- [ ] Timer subscriptions automatically resume after session restore
+- [ ] Animation frame subscriptions automatically resume after session restore
+- [ ] Stress test subscriptions automatically resume after session restore
+- [ ] No manual normalization required in app code
+- [ ] New features work automatically with session restore
+
+### Non-Functional Requirements
+
+- [ ] No performance regression in session restore
+- [ ] No breaking changes to existing API
+- [ ] Backward compatibility maintained
+- [ ] Comprehensive test coverage for edge cases
+
+### Quality Requirements
+
+- [ ] All existing tests pass
+- [ ] New integration tests added
+- [ ] No phantom pending states in any scenario
+- [ ] Session restore works reliably under all conditions
+
+## Technical Constraints
+
+### Must Not Break
+
+- Existing dispatcher API
+- Current subscription interface
+- Replay functionality
+- Message processing logic
+
+### Must Maintain
+
+- FIFO message processing
+- Deterministic replay
+- Performance characteristics
+- Error handling behavior
+
+## Implementation Guidance
+
+### Key Files to Modify
+
+1. `packages/core/src/dispatcher.ts` - Core dispatcher logic
+2. `packages/core/src/replay.ts` - Replay integration
+3. `app-web/src/main.ts` - Remove manual normalization
+4. `app-web/src/app.ts` - Update subscription functions
+
+### Design Patterns to Follow
+
+- **Declarative Subscriptions**: Subscriptions expressed as data, not imperative code
+- **Model-Driven**: Subscription state derived from model, not separate state
+- **Automatic Recovery**: Framework handles recovery, not application code
+
+### Testing Strategy
+
+- **Property-Based Tests**: Random session states with various active subscriptions
+- **Integration Tests**: Real browser session restore scenarios
+- **Regression Tests**: Ensure no phantom states in any combination
+
+## Verification Steps
+
+1. **Manual Testing**:
+ - Start timer, refresh page, verify timer resumes
+ - Start animation, refresh page, verify animation resumes
+ - Start stress test, refresh page, verify stress test resumes
+
+2. **Automated Testing**:
+ - Run all existing tests (ensure no regressions)
+ - Run new integration tests
+ - Run property-based tests for edge cases
+
+3. **Code Review**:
+ - Verify no manual normalization remains
+ - Confirm framework handles all subscription types
+ - Check for breaking changes
+
+## Expected Outcome
+
+After successful implementation:
+
+- **Zero phantom pending states** in any scenario
+- **Automatic session recovery** for all subscription types
+- **No manual intervention** required for new features
+- **Improved reliability** of session restore functionality
+- **Simplified maintenance** for developers
+
+## Risk Mitigation
+
+### High-Risk Areas
+
+- **Dispatcher Logic**: Core message processing - test thoroughly
+- **Session Restore**: Critical user functionality - verify extensively
+- **Subscription Lifecycle**: Could break existing features - ensure compatibility
+
+### Mitigation Strategies
+
+- **Incremental Implementation**: Phase 1 (core) → Phase 2 (app) → Phase 3 (validation)
+- **Comprehensive Testing**: Unit, integration, and property-based tests
+- **Backward Compatibility**: Maintain existing API surface
+- **Rollback Plan**: Keep manual normalization as fallback during development
+
+## Success Metrics
+
+- **Bug Elimination**: 0 phantom pending states in all test scenarios
+- **Code Simplicity**: Remove 20+ lines of manual normalization
+- **Developer Experience**: New features work automatically with session restore
+- **Test Coverage**: 100% coverage for session restore scenarios
+
+This fix addresses the most critical false claim (FC-008) and eliminates a fundamental architectural flaw in the causaloop system.
diff --git a/docs/false-claims/MAINTENANCE.md b/docs/false-claims/MAINTENANCE.md
new file mode 100644
index 0000000..555f889
--- /dev/null
+++ b/docs/false-claims/MAINTENANCE.md
@@ -0,0 +1,321 @@
+# False Claims Documentation Maintenance Guide
+
+This guide explains how to maintain the false claims documentation system for the causaloop-repo.
+
+## Overview
+
+The false claims system uses a **falsification-oriented methodology** to identify and document overstated or unsupported claims in the codebase. Each claim is treated as a hypothesis that may be false, with concrete strategies provided to falsify it.
+
+## Documentation Structure
+
+```
+docs/false-claims/
+├── index.md # Master index with summary statistics
+├── FC-XXX-claim-name.md # Individual claim analyses
+└── MAINTENANCE.md # This maintenance guide
+```
+
+## Claim Analysis Template
+
+Each claim analysis follows this structure:
+
+```markdown
+# False Claim Analysis: FC-XXX
+
+## Claim
+
+**Source**: [file:line] or location
+**Full Context**: Exact claim text
+**Type**: [Behavioral|Reliability|Security/Compliance|Performance|Operational]
+
+## Verdict
+
+**Status**: [True|False|Unproven|Not Verifiable Here]
+
+## Proof Criteria
+
+- Evidence requirements for this claim type
+- Specific tests or documentation needed
+
+## Evidence Analysis
+
+### Found Evidence
+
+- What supports the claim
+
+### Missing Evidence
+
+- What would falsify the claim
+
+### Contradictory Evidence
+
+- What directly opposes the claim
+
+## Conclusion
+
+Summary of why the claim has this verdict
+
+## Recommendation
+
+How to fix or improve the claim
+```
+
+## Maintenance Process
+
+### 1. Adding New Claims
+
+**When to Add:**
+
+- New features make strong assertions
+- Function names imply guarantees (Safe, Atomic, Reliable)
+- Comments claim behavior
+- Test assertions imply system correctness
+- Architectural assumptions are encoded
+
+**Process:**
+
+1. Assign next FC number (check index.md for highest)
+2. Create descriptive filename: `FC-XXX-claim-name.md`
+3. Follow the analysis template
+4. Include falsification strategies
+5. Update index.md statistics
+
+### 2. Updating Existing Claims
+
+**When to Update:**
+
+- Code changes affect claim validity
+- New evidence emerges
+- Tests are added/removed
+- Claims are fixed or weakened
+
+**Process:**
+
+1. Review claim against current codebase
+2. Update evidence analysis
+3. Modify verdict if needed
+4. Add new falsification strategies
+5. Update index.md if classification changes
+
+### 3. Removing Claims
+
+**When to Remove:**
+
+- Claim is fixed and no longer false
+- Claim is removed from codebase
+- Claim is replaced with accurate statement
+
+**Process:**
+
+1. Verify claim is truly resolved
+2. Document fix in claim analysis
+3. Mark as "Fixed" with evidence
+4. Keep in index.md for historical tracking
+5. Consider archiving instead of deleting
+
+## Classification Guidelines
+
+### Likely True
+
+- Strong code enforcement
+- Comprehensive adversarial testing
+- No known bypasses
+- Evidence withstands falsification attempts
+
+### Weakly Supported
+
+- Basic enforcement exists
+- Some testing present
+- Known limitations or bypasses
+- Insufficient adversarial testing
+
+### Unverified
+
+- No evidence found
+- No tests for the claim
+- Cannot be verified from available information
+- Requires external validation
+
+### Probably False
+
+- Strong evidence against claim
+- Known contradictions
+- Fundamental design flaws
+- Mock insulation hides reality
+
+### Demonstrably False
+
+- Direct evidence of falsity
+- Reproducible counterexamples
+- Test failures proving claim false
+- Documentation contradictions
+
+## Falsification Strategy Requirements
+
+Each claim MUST include concrete falsification strategies:
+
+### Static Analysis
+
+- Code pattern searches
+- Type checking
+- Dependency analysis
+- Architectural violation detection
+
+### Property-Based Testing
+
+- Random input generation
+- Edge case exploration
+- Invariant checking
+- Chaos engineering
+
+### Integration Testing
+
+- Real dependencies (not mocks)
+- Network I/O testing
+- Resource constraint testing
+- Concurrency stress testing
+
+### Fault Injection
+
+- Network failures
+- Memory pressure
+- Timer precision issues
+- Worker thread crashes
+
+## Quality Standards
+
+### Evidence Requirements
+
+- **Specific**: Reference exact files, lines, tests
+- **Verifiable**: Others can reproduce the analysis
+- **Comprehensive**: Cover both supporting and contradicting evidence
+- **Current**: Reflect latest codebase state
+
+### Falsification Requirements
+
+- **Actionable**: Provide concrete test code
+- **Realistic**: Test actual failure modes
+- **Comprehensive**: Cover multiple attack vectors
+- **Reproducible**: Others can run the falsification tests
+
+### Documentation Standards
+
+- **Clear**: Unambiguous language
+- **Concise**: No unnecessary verbosity
+- **Consistent**: Follow template exactly
+- **Maintained**: Keep up-to-date with codebase
+
+## Review Process
+
+### Self-Review Checklist
+
+- [ ] Claim clearly stated with source
+- [ ] Classification justified with evidence
+- [ ] Falsification strategies are concrete
+- [ ] Template followed correctly
+- [ ] Index.md updated
+
+### Peer Review Triggers
+
+- High-risk claims (CRITICAL/HIGH severity)
+- Complex architectural assumptions
+- Claims affecting multiple components
+- Controversial classifications
+
+## Automation Opportunities
+
+### Static Checks
+
+- Scan for claim-like patterns in code
+- Identify function names with guarantees
+- Flag comments making assertions
+- Detect test assumptions
+
+### Continuous Updates
+
+- Monitor code changes for new claims
+- Update existing claims when code changes
+- Run falsification tests automatically
+- Generate updated statistics
+
+## Integration with Development Workflow
+
+### Pre-Commit
+
+- Check for new claim-like patterns
+- Validate claim documentation updates
+- Run relevant falsification tests
+
+### Code Review
+
+- Review new claims for accuracy
+- Ensure falsification strategies are included
+- Verify classification is appropriate
+
+### Release
+
+- Update claim status for released features
+- Ensure all new claims are documented
+- Review claim statistics for release notes
+
+## Metrics and Tracking
+
+### Claim Statistics
+
+- Total claims analyzed
+- Distribution by classification
+- Risk level breakdown
+- Claim resolution rate
+
+### Quality Metrics
+
+- Claims with falsification tests
+- Claims verified by integration tests
+- Claims fixed over time
+- Documentation completeness
+
+## Common Pitfalls to Avoid
+
+### Analysis Pitfalls
+
+- **Assuming claims are true** without evidence
+- **Accepting mock-based tests** as proof
+- **Ignoring contradictory evidence**
+- **Overlooking edge cases**
+
+### Documentation Pitfalls
+
+- **Vague claim statements**
+- **Missing falsification strategies**
+- **Outdated evidence references**
+- **Inconsistent classifications**
+
+### Process Pitfalls
+
+- **Documenting obvious truths** (waste of time)
+- **Ignoring architectural assumptions**
+- **Forgetting to update index.md**
+- **Neglecting existing claim updates**
+
+## Escalation Criteria
+
+### When to Escalate
+
+- Critical security claims found false
+- Architecture-level contradictions discovered
+- Multiple high-risk claims in same component
+- Claims affecting production reliability
+
+### Escalation Process
+
+1. Flag claim in documentation
+2. Notify architecture team
+3. Propose immediate mitigation
+4. Schedule fix for next release
+5. Track resolution in claim analysis
+
+## Conclusion
+
+The false claims documentation system is a living tool for maintaining intellectual honesty in the codebase. By treating every claim as falsifiable and providing concrete strategies to test them, we ensure the system doesn't lie to itself or its users.
+
+Regular maintenance and updates keep the documentation relevant and useful for ongoing development and architectural decision-making.
diff --git a/docs/false-claims/index.md b/docs/false-claims/index.md
new file mode 100644
index 0000000..e537978
--- /dev/null
+++ b/docs/false-claims/index.md
@@ -0,0 +1,182 @@
+# False Claims Index
+
+This index tracks all falsification-oriented claim audits performed on the causaloop-repo, identifying false or weak claims embedded in the system.
+
+## Summary Statistics
+
+| Classification | Count | Percentage |
+| ------------------ | ----- | ---------- |
+| Likely True | 1 | 11% |
+| Weakly Supported | 3 | 33% |
+| Unverified | 2 | 22% |
+| Probably False | 2 | 22% |
+| Demonstrably False | 1 | 11% |
+
+**Total Claims Analyzed**: 9
+
+## Critical Risk Claims
+
+| ID | Claim | Classification | Risk Level | Primary Issue |
+| ------ | ---------------------------------------------- | ------------------ | ---------- | ------------------------------------------------------- |
+| FC-008 | Session restore completeness | Demonstrably False | CRITICAL | Manual normalization incomplete, phantom pending states |
+| FC-004 | "verifyDeterminism()" validates determinism | Unverified | CRITICAL | False sense of security from method name |
+| FC-007 | Worker pool management efficiency | Unverified | HIGH | No performance benchmarks, untested efficiency |
+| FC-003 | "deepFreeze catches mutations" | Weakly Supported | HIGH | Multiple bypass vectors for mutations |
+| FC-001 | "DETERMINISM = TRUE" | Weakly Supported | HIGH | Effects not replayed, purity not enforced |
+| FC-009 | preventDefault guarantee | Probably False | MEDIUM | Only applies to renderer-managed forms |
+| FC-006 | "Stale-Safe Search" | Weakly Supported | MEDIUM | No integration tests for race conditions |
+| FC-005 | "Torture Test" for replay | Weakly Supported | MEDIUM | No real async operations or stress |
+| FC-002 | "Atomic Processing" eliminates race conditions | Likely True | LOW | Strong enforcement with minor caveats |
+
+## Detailed Findings
+
+### FC-001: Determinism Constant
+
+- **Claim**: "DETERMINISM = TRUE"
+- **Reality**: Only message ordering is deterministic, not effect execution
+- **Evidence**: FIFO queue processing, but effects run outside deterministic loop
+- **Falsification**: Real network failures, concurrent effects, memory pressure
+
+### FC-002: Atomic Processing
+
+- **Claim**: Messages processed atomically via FIFO
+- **Reality**: Strongly enforced in code
+- **Evidence**: `isProcessing` flag, comprehensive stress tests
+- **Falsification**: Effect execution happens outside atomic loop
+
+### FC-003: Deep Freeze Immutability
+
+- **Claim**: "deepFreeze catches mutations in devMode"
+- **Reality**: Only basic object property mutations caught
+- **Evidence**: Array mutations, external references, prototype chains bypass freeze
+- **Falsification**: Complex object graphs, Map/Set, property deletion
+
+### FC-004: Verify Determinism Method
+
+- **Claim**: Method validates deterministic replay
+- **Reality**: Only compares final JSON state
+- **Evidence**: No intermediate state validation, JSON serialization loses data
+- **Falsification**: Non-deterministic updates, effect order differences
+
+### FC-005: Replay Torture Test
+
+- **Claim**: "Torture Test" for complex async replay
+- **Reality**: Basic async simulation with setTimeout
+- **Evidence**: No real network I/O, workers, memory pressure
+- **Falsification**: Real concurrent operations, resource constraints
+
+### FC-006: Stale-Safe Search
+
+- **Claim**: "Stale-Safe Search" prevents race conditions
+- **Reality**: Basic requestId validation, no integration testing
+- **Evidence**: AbortKey mechanism exists but not tested under load
+- **Falsification**: Rapid search changes, network timing variations
+
+### FC-007: Worker Pool Management
+
+- **Claim**: Worker pool improves performance with queue management
+- **Reality**: No performance benchmarks, untested efficiency
+- **Evidence**: Pool implementation exists but no proof of benefit
+- **Falsification**: Load testing, memory pressure, concurrent operations
+
+### FC-008: Session Restore Completeness
+
+- **Claim**: Manual session restore handles all in-flight states
+- **Reality**: Incomplete normalization leaves phantom pending states
+- **Evidence**: Missing timer, animation, stress normalization
+- **Falsification**: Subscription replay, new feature edge cases
+
+### FC-009: preventDefault Guarantee
+
+- **Claim**: Form submissions are automatically prevented
+- **Reality**: Only applies to renderer-managed submit events
+- **Evidence**: No protection for programmatic or dynamic forms
+- **Falsification**: Direct submission, event bypass, error scenarios
+
+## Mock/Test Double Insulation Analysis
+
+### Complete Insulation (High Risk)
+
+- **Network Operations**: All fetch/worker tests use mocks
+- **Async Timing**: Uses `vi.useFakeTimers()` instead of real timers
+- **Memory Pressure**: No tests under memory constraints
+- **Concurrent Operations**: No real concurrency testing
+
+### Partial Insulation (Medium Risk)
+
+- **Message Processing**: Real dispatcher logic tested
+- **Queue Behavior**: Actual FIFO processing validated
+- **Basic Immutability**: Simple property mutations tested
+
+### Minimal Insulation (Low Risk)
+
+- **Core Architecture**: Real implementation used
+- **Stress Testing**: Actual message bursts tested
+
+## Falsification Strategies by Category
+
+### 1. Property-Based Testing
+
+- Generate chaotic message sequences
+- Test with random timing variations
+- Validate invariants across all inputs
+
+### 2. Real-World Failure Injection
+
+- Network timeouts and connection drops
+- Worker thread crashes
+- Memory pressure scenarios
+- Event loop interference
+
+### 3. Concurrency Stress Testing
+
+- Real concurrent message sources
+- Effect execution race conditions
+- Subscription lifecycle conflicts
+
+### 4. Integration Testing
+
+- Replace mocks with real services
+- Test against actual browser APIs
+- Validate with real I/O operations
+
+## Recommendations
+
+### Immediate Actions (Critical)
+
+1. **FA-004**: Rename `verifyDeterminism` to `compareFinalState` and document limitations
+2. **FA-003**: Document immutability gaps or implement Proxy-based protection
+3. **FA-001**: Clarify that only message ordering is deterministic
+
+### Medium Priority
+
+1. **FA-005**: Implement real torture tests with network I/O and workers
+2. **FA-002**: Document effect execution outside atomic processing
+
+### Long-term Improvements
+
+1. Replace mock-heavy tests with integration tests
+2. Add property-based testing for critical invariants
+3. Implement comprehensive failure injection
+4. Add performance testing under resource constraints
+
+## System Honesty Assessment
+
+The causaloop-repo exhibits **moderate intellectual honesty**:
+
+**Strengths**:
+
+- Strong architectural enforcement of FIFO processing
+- Comprehensive stress testing for message throughput
+- Documented limitations in ideas.md
+
+**Weaknesses**:
+
+- Method names overstate capabilities (verifyDeterminism)
+- Marketing language exceeds technical reality ("Torture Test")
+- Mock insulation hides real-world failure modes
+- No tests for documented bug classes (phantom pending)
+
+**Overall Risk Level**: MEDIUM-HIGH
+
+The system has solid foundations but makes several overstated claims that could mislead users about actual guarantees provided.
diff --git a/packages/app-web/src/main.ts b/packages/app-web/src/main.ts
index 37bf9b0..6cf0d2d 100644
--- a/packages/app-web/src/main.ts
+++ b/packages/app-web/src/main.ts
@@ -174,29 +174,6 @@ try {
log,
});
- if (restoredModel.worker.status === "computing") {
- restoredModel = {
- ...restoredModel,
- worker: {
- ...restoredModel.worker,
- status: "idle",
- error: null,
- },
- };
- }
- if (restoredModel.load.status === "loading") {
- restoredModel = {
- ...restoredModel,
- load: { ...restoredModel.load, status: "idle", data: null },
- };
- }
- if (restoredModel.search.status === "loading") {
- restoredModel = {
- ...restoredModel,
- search: { ...restoredModel.search, status: "idle" },
- };
- }
-
initialLog = log;
} catch (e) {
restoreError = e instanceof Error ? e.message : String(e);