[Review] detectConflictPrecursors / detectExcitementCycles length filters (3/4) interact badly with vault-locked scrubbed interactions #180

Closed
opened 2026-09-14 14:07:30 +00:00 by Mark · 1 comment
Owner

Finding

src/lib/intimate-state-engine.ts:308 (detectExcitementCycles) returns [] for fewer than 3 interactions. :394 (detectConflictPrecursors) returns null for fewer than 4. These filters exist for noise reduction.

When the vault is locked, the store scrubs safeInteractions (removes mood, intimacyLevel, isConflict, repairAttempt, conflictResolved, qualityRating) before passing them to the engines. The engines then run against scrubbed interactions and may return fewer insights not because they respect the privacy boundary, but because most real users have 0-2 interactions with any given person, so the length filter naturally drops them when the vault is locked.

This produces a UX surprise: users see fewer pattern insights overall when the vault is locked. Not a leak (the gate is correct on the data side), but the engines do too much filtering at the wrong layer.

Suggested fix

Two options:

A. Lower the length thresholds inside the engines when sensitive fields are unavailable — but that complicates the pure-function contract.

B. Document the behavior with a comment in intimate-state-engine.ts:308 and :394 noting that the length filters bias against small histories, and that the vault gate exacerbates this. Then accept it as the design tradeoff (privacy > insights for small histories).

Severity

Low. Documentation / commentary. Pick option B unless a future user reports the surprise.

Discovered by

Manual code review pass over #168/#169, 2026-09-14.

## Finding `src/lib/intimate-state-engine.ts:308` (`detectExcitementCycles`) returns `[]` for fewer than 3 interactions. `:394` (`detectConflictPrecursors`) returns `null` for fewer than 4. These filters exist for noise reduction. When the vault is locked, the store scrubs `safeInteractions` (removes `mood`, `intimacyLevel`, `isConflict`, `repairAttempt`, `conflictResolved`, `qualityRating`) before passing them to the engines. The engines then run against scrubbed interactions and may return fewer insights not because they respect the privacy boundary, but because **most real users have 0-2 interactions with any given person**, so the length filter naturally drops them when the vault is locked. This produces a UX surprise: users see fewer pattern insights overall when the vault is locked. Not a leak (the gate is correct on the data side), but the engines do too much filtering at the wrong layer. ## Suggested fix Two options: A. Lower the length thresholds inside the engines when sensitive fields are unavailable — but that complicates the pure-function contract. B. Document the behavior with a comment in `intimate-state-engine.ts:308` and `:394` noting that the length filters bias against small histories, and that the vault gate exacerbates this. Then accept it as the design tradeoff (privacy > insights for small histories). ## Severity Low. Documentation / commentary. Pick option B unless a future user reports the surprise. ## Discovered by Manual code review pass over #168/#169, 2026-09-14.
Mark 2026-09-14 14:07:30 +00:00
Author
Owner

Closed by watcher recovery: option-B doc comments landed on origin/main in commit ccc9ce4 (Apply changes from kilo-gsd.py run — note: commit message references #188 but the diff is the #180 patch). The local kilo-gsd runner commit 01d7aae (docs(#180): document vault-locked + small-history interaction at length filters) carries the same tree changes, so rebase detected it as already-applied and skipped; local and origin/main are now in sync at 4d07260.

Closed by watcher recovery: option-B doc comments landed on origin/main in commit `ccc9ce4` (Apply changes from kilo-gsd.py run — note: commit message references #188 but the diff is the #180 patch). The local kilo-gsd runner commit `01d7aae` (`docs(#180): document vault-locked + small-history interaction at length filters`) carries the same tree changes, so rebase detected it as already-applied and skipped; local and origin/main are now in sync at `4d07260`.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/kimi_agent_kin_app_sync#180
No description provided.