#168 - [feature] Intimate-state awareness — cycle tracking, mood cycles, conflict prediction - Mark/kimi_agent_kin_app_sync - cyguin git: Adlerian Hierarchical Self-Actualization Syllogism

Mark commented

2026-09-10 02:12:54 +00:00

Owner

Update (2026-09-09)

User clarified: intimate-state awareness should live in the Little Black Book vault, not the main DB. The vault is already implemented:

Separate IndexedDB kin_vault (src/vault/vault-db.ts:11) — physically isolated from KinDatabase. Inspecting the main DB reveals nothing about vault existence or content.
Schema mirrors main DB: vaultPeople, vaultInteractions, vaultGifts, vaultDates, vaultNotes (with a vaultNotes extension).
VaultStoreImpl (src/vault/VaultStore.ts:23) — singleton, throws VaultLockedError unless explicitly unlocked for the session.
Auto-lock lifecycle (src/vault/lifecycle.ts) — locks on background (default 60s, configurable 0/60/300).
Architectural invariant: src/lib/db.ts does NOT import the vault module — separation is enforced by import boundaries.

This means the right place for cycle/fertility/depression/conflict-precursor tracking is:

Cycle/fertility data: new vaultCycles table (or vaultNotes extension) — opt-in per person, never exposed via main-DB metrics
Mood-cycle + depression detection: a vault-scoped metrics engine that ONLY runs when the vault is unlocked and ONLY surfaces its results inside the vault view
Conflict precursors: the existing behavior-pattern-engine.ts should have a vault-mode variant that operates on vault-only data

Original spec still stands, but with this redirection

All 5 gaps below should be implemented as vault-only features:

Cycle tracking → vaultCycles table, phase computation happens in vault context
Mood-cycle / depression detection → vault-scoped metrics engine
Excitement cycles → vault-scoped Emergent Observations
Conflict precursors → vault-mode behavior-pattern-engine
Wire the existing behavior-pattern-engine → wire a vault-aware variant; keep the main-DB version public-safe (no mood patterns, only cadence)

Privacy architecture

The vault is the right home because:

Data never leaves the device unless the user explicitly syncs (vault sync is opt-in and separate from main sync)
Vault state is ephemeral — auto-locks, requires unlock to read
Schema is hidden from main-DB inspection (separate database name, separate import boundary)
This matches user intent: "intimate-state awareness" is precisely the kind of data that should NEVER be in the regular log

Implementation sketch

Extend vault-db.ts schema:

vaultCycles: "++id, personId, startDate, cycleLength, lutealPhase, createdAt",
vaultMood: "++id, personId, date, mood, note",
vaultPredictions: "++id, personId, type, payload, createdAt, expiresAt",

Add VaultCycleStore, VaultMoodStore, VaultPredictionStore to VaultStore.ts — each gated by assertUnlocked()
New vault-metrics-engine.ts — runs cycle phase + mood trend + precursor detection ONLY against vault data
New <IntimateInsights /> component — renders inside the vault view, shows mood trend / cycle phase / conflict precursor alerts
Settings page: explicit toggle "Enable intimate-state tracking" per person, default OFF, with clear copy about what it does
Behavior-pattern-engine wiring: keep main-DB version (cadence only); add vault variant that consumes vault mood + conflict data

Severity

High — same as before. The bones exist (vault) but the intimate-state features themselves are not built. Without them, the vault is just a place to hide data; with them, it's the engine that actually makes use of it.

## Update (2026-09-09) User clarified: intimate-state awareness should live in the **Little Black Book** vault, not the main DB. The vault is already implemented: - Separate IndexedDB `kin_vault` (`src/vault/vault-db.ts:11`) — physically isolated from `KinDatabase`. Inspecting the main DB reveals nothing about vault existence or content. - Schema mirrors main DB: `vaultPeople`, `vaultInteractions`, `vaultGifts`, `vaultDates`, `vaultNotes` (with a `vaultNotes` extension). - `VaultStoreImpl` (`src/vault/VaultStore.ts:23`) — singleton, throws `VaultLockedError` unless explicitly unlocked for the session. - Auto-lock lifecycle (`src/vault/lifecycle.ts`) — locks on background (default 60s, configurable 0/60/300). - Architectural invariant: `src/lib/db.ts` does NOT import the vault module — separation is enforced by import boundaries. This means the **right place** for cycle/fertility/depression/conflict-precursor tracking is: - Cycle/fertility data: new `vaultCycles` table (or vaultNotes extension) — opt-in per person, never exposed via main-DB metrics - Mood-cycle + depression detection: a vault-scoped metrics engine that ONLY runs when the vault is unlocked and ONLY surfaces its results inside the vault view - Conflict precursors: the existing `behavior-pattern-engine.ts` should have a vault-mode variant that operates on vault-only data ## Original spec still stands, but with this redirection All 5 gaps below should be implemented as **vault-only features**: 1. Cycle tracking → `vaultCycles` table, phase computation happens in vault context 2. Mood-cycle / depression detection → vault-scoped metrics engine 3. Excitement cycles → vault-scoped Emergent Observations 4. Conflict precursors → vault-mode behavior-pattern-engine 5. Wire the existing behavior-pattern-engine → wire a vault-aware variant; keep the main-DB version public-safe (no mood patterns, only cadence) ## Privacy architecture The vault is the right home because: - Data never leaves the device unless the user explicitly syncs (vault sync is opt-in and separate from main sync) - Vault state is ephemeral — auto-locks, requires unlock to read - Schema is hidden from main-DB inspection (separate database name, separate import boundary) - This matches user intent: "intimate-state awareness" is precisely the kind of data that should NEVER be in the regular log ## Implementation sketch 1. Extend `vault-db.ts` schema: ```ts vaultCycles: "++id, personId, startDate, cycleLength, lutealPhase, createdAt", vaultMood: "++id, personId, date, mood, note", vaultPredictions: "++id, personId, type, payload, createdAt, expiresAt", ``` 2. Add `VaultCycleStore`, `VaultMoodStore`, `VaultPredictionStore` to `VaultStore.ts` — each gated by `assertUnlocked()` 3. New `vault-metrics-engine.ts` — runs cycle phase + mood trend + precursor detection ONLY against vault data 4. New `<IntimateInsights />` component — renders inside the vault view, shows mood trend / cycle phase / conflict precursor alerts 5. Settings page: explicit toggle "Enable intimate-state tracking" per person, default OFF, with clear copy about what it does 6. Behavior-pattern-engine wiring: keep main-DB version (cadence only); add vault variant that consumes vault mood + conflict data ## Severity High — same as before. The bones exist (vault) but the intimate-state features themselves are not built. Without them, the vault is just a place to hide data; with them, it's the engine that actually makes use of it.

Mark

2026-09-10 02:12:54 +00:00

closed this issue
added the
enhancement
label

Mark referenced this issue from a commit

2026-09-10 02:41:05 +00:00

feat(#168): intimate-state awareness — cycle, mood trends, conflict precursors

Mark referenced this issue

2026-09-10 02:52:52 +00:00

[privacy-audit] Privacy-sensitive fields leak into main DB and PersonDetail metrics — link to Little Black Book #169

Mark commented

2026-09-10 02:53:20 +00:00

Author

Owner

↳ Parent issue: #169 (privacy audit — every privacy-sensitive field traced back to the Little Black Book). All work on this issue should reference #169's field-by-field audit and the architectural fix sketch.