Mark/kimi_agent_kin_app_sync
1
0
Fork 0
Code Issues 3 Pull requests Projects Releases 2 Packages Wiki Activity Actions

Early-stage & casual relationship navigation — timing, calibration & awareness for new connections #84

New issue
Closed
opened 2026-06-09 02:41:09 +00:00 by Mark · 0 comments
Mark commented 2026-06-09 02:41:09 +00:00
Owner
Copy link

Summary

#83 covers long-term romantic relationships where you have history, shared infrastructure, and established patterns. This is the counterpart for everything before that — early dating, casual connections, situations where you're still figuring each other out.

The rules are different here: no history to learn from, higher rejection sensitivity, different timing dynamics, and often multiple simultaneous connections. The app can't detect "we had a relaxed evening" because you don't share a life yet. It has to work with less data and provide lighter-touch awareness.

P1: Interest & reciprocation calibration

When you don't know someone well yet, you're reading signals. The app can help spot patterns you might miss.

  • Track response-time trends per person: "Alex usually replies within 2 hours — current reply is 3 days old. Might be worth checking in gently or giving space."
  • Initiation ratio with a grain of salt (small sample size warning): "You've initiated 4/5 interactions — early days, but worth noticing if it persists"
  • Conversation momentum indicators: thread depth, topic engagement, who extends conversations
  • Ghosting/fading detection: if someone who was responsive goes silent past their typical window, flag as possible fade-out (not a demand, just pattern awareness)
  • All signals are explicitly labeled as suggestive, not definitive — "This is a pattern, not a verdict"

P2: Timing & pacing awareness

Early dating timing is fragile. Too eager reads as desperate, too aloof reads as disinterest.

  • Per-person cadence discovery from scratch: as interactions accumulate, detect the natural interval and surface it after 3-5 touchpoints: "You and Alex tend to connect every 3-4 days"
  • If you're overdue past the detected cadence, gentle nudge: "It's been 6 days since you texted — your typical window is 3-4"
  • Pacing suggestions based on context: if you've gone on 2 dates, suggest a next-date window that matches the established rhythm rather than pushing too fast or slow
  • Avoid over-messaging detection: "You've sent 3 messages without a reply — consider giving it a day" (only if the user opts into this kind of nudge)
  • Post-date follow-up window suggestion: "Great date — a brief follow-up text within 24h tends to work well here"

P3: Escalation awareness & progression tracking

Track the natural arc of a developing connection — not as a checklist, but as situational awareness.

  • Optional milestone tracking per connection: first message, first date, first kiss, first overnight, exclusivity talk, meet friends, meet family — user tags these when they happen
  • Progression pacing: if milestones are happening faster or slower than typical for the relationship's age, surface it neutrally: "You've been seeing Alex for 3 months and haven't had the exclusivity talk yet — is that intentional?"
  • Stalled progression detection: if interactions continue but no new milestones in 2x the time of the previous gap, flag: "You and Alex have been in the same phase for a while — might be worth checking in"
  • No prescriptive "right" timeline — just awareness of pace relative to the connection's own history

P4: Multiple connection management

Dating multiple people introduces complexity that the app can help organize.

  • Per-connection tagging: active, paused, fizzled, ended, friend-zoned — clear status taxonomy
  • Dashboard view of active connections with last-contact timestamps and cadence status
  • Avoid confusing contacts: when logging an interaction, the person picker should be clear enough you don't mix up who you're logging for
  • If a connection ends or fizzles, graceful archive: keeps the data but removes from active view
  • No cross-connection analytics — the app shouldn't compare people or suggest you're "spending too much time on X vs Y" — that's for your own awareness, not the app's judgment
  • Ghosting cleanup: if a connection has gone silent for 4+ weeks with no explicit close, suggest archiving

P5: Casual relationship mode

Not every connection is headed toward depth. Casual relationships have different rules.

  • Dedicated "casual" relationship type with appropriate vocabulary and defaults
  • Cadence for casual: longer intervals by default, lower lock-in expectations, no escalation tracking unless opted in
  • Boundaries awareness: optional note field for unspoken boundaries, dealbreakers, or things you're figuring out — private to you
  • Reconnection after a gap: casual connections often have long silences followed by a warm reconnection. The app shouldn't flag a 3-week gap as "overdue" in casual mode — it should recognize the rhythm as normal
  • FWB / situationship mode: even lighter touch — no escalation tracking, no cadence pressure, just a contact log with optional intimacy-aware features from #83

P6: Privacy & safety for early-stage connections

These are often the most sensitive because you're sharing data about people who don't know they're being tracked.

  • Default-off for every feature in this issue — nothing activates unless the user explicitly opts in per-connection
  • Biometric gate for the entire early-stage feature set — this is vault-level sensitive (#26)
  • Clear UI language: "Private awareness — for your eyes only. These people don't know you're tracking this."
  • Emergency hide: one tap hides all active connection data
  • When a connection ends, offer to archive or fully delete all associated data
  • No data about a connection ever leaves the device — not in export, not in backup, not in share
  • If you enter a long-term relationship with someone who was an early-stage connection, offer to migrate their data to the #83 model (which has different privacy rules)

Tech notes

  • Reuses #81's cadence engine but with different defaults: longer base intervals, wider variance tolerance, no lock-in scoring until enough data exists
  • Reuses #26's vault infrastructure for privacy gating
  • Reuses #83's initiation tracking and responsiveness detection but adapted for smaller sample sizes
  • No new permissions needed — all data comes from existing interaction logging plus new status/phase fields
  • The escalation milestone system is a new data type (or extension of existing Event model) — needs schema additions
  • Casual mode is primarily a set of UI labels, default intervals, and disabled features rather than a separate codebase
## Summary #83 covers long-term romantic relationships where you have history, shared infrastructure, and established patterns. This is the counterpart for everything before that — early dating, casual connections, situations where you're still figuring each other out. The rules are different here: no history to learn from, higher rejection sensitivity, different timing dynamics, and often multiple simultaneous connections. The app can't detect "we had a relaxed evening" because you don't share a life yet. It has to work with less data and provide lighter-touch awareness. --- ### P1: Interest & reciprocation calibration When you don't know someone well yet, you're reading signals. The app can help spot patterns you might miss. - [ ] Track response-time trends per person: "Alex usually replies within 2 hours — current reply is 3 days old. Might be worth checking in gently or giving space." - [ ] Initiation ratio with a grain of salt (small sample size warning): "You've initiated 4/5 interactions — early days, but worth noticing if it persists" - [ ] Conversation momentum indicators: thread depth, topic engagement, who extends conversations - [ ] Ghosting/fading detection: if someone who was responsive goes silent past their typical window, flag as possible fade-out (not a demand, just pattern awareness) - [ ] All signals are explicitly labeled as suggestive, not definitive — "This is a pattern, not a verdict" ### P2: Timing & pacing awareness Early dating timing is fragile. Too eager reads as desperate, too aloof reads as disinterest. - [ ] Per-person cadence discovery from scratch: as interactions accumulate, detect the natural interval and surface it after 3-5 touchpoints: "You and Alex tend to connect every 3-4 days" - [ ] If you're overdue past the detected cadence, gentle nudge: "It's been 6 days since you texted — your typical window is 3-4" - [ ] Pacing suggestions based on context: if you've gone on 2 dates, suggest a next-date window that matches the established rhythm rather than pushing too fast or slow - [ ] Avoid over-messaging detection: "You've sent 3 messages without a reply — consider giving it a day" (only if the user opts into this kind of nudge) - [ ] Post-date follow-up window suggestion: "Great date — a brief follow-up text within 24h tends to work well here" ### P3: Escalation awareness & progression tracking Track the natural arc of a developing connection — not as a checklist, but as situational awareness. - [ ] Optional milestone tracking per connection: first message, first date, first kiss, first overnight, exclusivity talk, meet friends, meet family — user tags these when they happen - [ ] Progression pacing: if milestones are happening faster or slower than typical for the relationship's age, surface it neutrally: "You've been seeing Alex for 3 months and haven't had the exclusivity talk yet — is that intentional?" - [ ] Stalled progression detection: if interactions continue but no new milestones in 2x the time of the previous gap, flag: "You and Alex have been in the same phase for a while — might be worth checking in" - [ ] No prescriptive "right" timeline — just awareness of pace relative to the connection's own history ### P4: Multiple connection management Dating multiple people introduces complexity that the app can help organize. - [ ] Per-connection tagging: active, paused, fizzled, ended, friend-zoned — clear status taxonomy - [ ] Dashboard view of active connections with last-contact timestamps and cadence status - [ ] Avoid confusing contacts: when logging an interaction, the person picker should be clear enough you don't mix up who you're logging for - [ ] If a connection ends or fizzles, graceful archive: keeps the data but removes from active view - [ ] No cross-connection analytics — the app shouldn't compare people or suggest you're "spending too much time on X vs Y" — that's for your own awareness, not the app's judgment - [ ] Ghosting cleanup: if a connection has gone silent for 4+ weeks with no explicit close, suggest archiving ### P5: Casual relationship mode Not every connection is headed toward depth. Casual relationships have different rules. - [ ] Dedicated "casual" relationship type with appropriate vocabulary and defaults - [ ] Cadence for casual: longer intervals by default, lower lock-in expectations, no escalation tracking unless opted in - [ ] Boundaries awareness: optional note field for unspoken boundaries, dealbreakers, or things you're figuring out — private to you - [ ] Reconnection after a gap: casual connections often have long silences followed by a warm reconnection. The app shouldn't flag a 3-week gap as "overdue" in casual mode — it should recognize the rhythm as normal - [ ] FWB / situationship mode: even lighter touch — no escalation tracking, no cadence pressure, just a contact log with optional intimacy-aware features from #83 ### P6: Privacy & safety for early-stage connections These are often the most sensitive because you're sharing data about people who don't know they're being tracked. - [ ] Default-off for every feature in this issue — nothing activates unless the user explicitly opts in per-connection - [ ] Biometric gate for the entire early-stage feature set — this is vault-level sensitive (#26) - [ ] Clear UI language: "Private awareness — for your eyes only. These people don't know you're tracking this." - [ ] Emergency hide: one tap hides all active connection data - [ ] When a connection ends, offer to archive or fully delete all associated data - [ ] No data about a connection ever leaves the device — not in export, not in backup, not in share - [ ] If you enter a long-term relationship with someone who was an early-stage connection, offer to migrate their data to the #83 model (which has different privacy rules) ## Tech notes - Reuses #81's cadence engine but with different defaults: longer base intervals, wider variance tolerance, no lock-in scoring until enough data exists - Reuses #26's vault infrastructure for privacy gating - Reuses #83's initiation tracking and responsiveness detection but adapted for smaller sample sizes - No new permissions needed — all data comes from existing interaction logging plus new status/phase fields - The escalation milestone system is a new data type (or extension of existing Event model) — needs schema additions - Casual mode is primarily a set of UI labels, default intervals, and disabled features rather than a separate codebase
Mark closed this issue 2026-06-13 15:40:47 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
v1.1.0
v1.0.0
Labels
Clear labels   
blocked:depends-p1

Depends on #139 (P1) landing first. Picker should not auto-dispatch.

  
blocked:gate-research

   
blocked:lint-failed

   
blocked:needs-decision

   
blocked:needs-human

   
blocked:verify-failed

   
bug

   
data-loss

Data integrity or data loss risk

  
documentation

   
enhancement

   
feature-request

   
in-progress

   
needs-decompose

Issue needs decompose processing

  
needs-triage

   
pwa

Progressive Web App functionality

  
quickfix

   
security

Security vulnerability or hardening

  
security/high

High severity security issue

  
security/medium

Medium severity security issue

  
test

   
test-coverage

Test coverage review / gap report

  
triage-approved

Approved for automated fix pipeline

  
vault

Requires vault/LBB authentication (#26) — discretion-sensitive feature

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
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#84
No description provided.