Feature: Interaction metrics engine — predictions, scoring, suggestions #31
Labels
No labels
blocked:depends-p1
blocked:gate-research
blocked:lint-failed
blocked:needs-decision
blocked:needs-human
blocked:verify-failed
bug
data-loss
documentation
enhancement
feature-request
in-progress
needs-decompose
needs-triage
pwa
quickfix
security
security/high
security/medium
test
test-coverage
triage-approved
vault
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
Mark/kimi_agent_kin_app_sync#31
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Goal
Compute metrics from existing interaction data to surface actionable observations — predictions about when you'll next interact, scoring for relationship health, suggestions for who needs attention.
Metrics (computed on-device from existing data)
Per-person
Cross-person
Cycle/rhythm detection
Features
Suggestions
Predictions
Scoring
Cross-method correlation (the data, not woo)
Privacy
Implementation
All pure client-side from existing Interaction + Person data. No new collection, no backend, no sync.
⏸ Needs Decision
Blocking factors:
Scope: medium Risk: low Spec: aligned Type: feature
Summary: Add a pure computation layer that derives per-person and cross-person metrics (engagement, cadence, trend, preferred methods, predictions, suggestions) from existing interaction/people data and surfaces them via new UI sections on the Home dashboard and PersonDetail pages.
Suggestion: Implement as a single metrics.ts module with composable pure functions (computeCadence, computeTrend, computeEngagementScore, generateSuggestions, predictNextInteraction) that accept Person[] and Interaction[] and return derived data. Surface via React hooks (useMetrics, usePersonMetrics) wrapping useMemo for zero-cost re-derivation on data changes. Add UI as new sections on Home (suggestions panel, leadership board) and PersonDetail (health score card, trend arrow) — no new store state or DB changes needed since everything is computed from existing selectors.
Rationale: Medium scope because it touches ~8-12 files: a new lib module, new types, and UI additions to Home (suggestions + engagement sections) and PersonDetail (health score + trend). Risk is low — pure additive computation on existing data with zero schema changes, no breaking changes to any existing path, and the existing overdue/priority logic on Home is a direct foundation. Fully aligned with the PRM concept of deriving insights from tracked relationships. The issue's own framing as 'pure computation, no new data collection' confirms the additive, non-risky nature.
Action: Review each blocking factor above. Remove
blocked:needs-decisionlabel to route back to triage.GSD RESEARCH: API call failed.
]11;?\API call failed after 3 retries: HTTP 429: Error code: 429 - {'status': 429, 'title': 'Too Many Requests'}