#83 - Romantic intimacy awareness — conditions, scheduling & initiation support for long-term relationships - Mark/kimi_agent_kin_app_sync - cyguin git: Adlerian Hierarchical Self-Actualization Syllogism

## Summary A feature for romantic partners in long-term relationships where spontaneity is unreliable but intentionality is essential. Life (work, kids, stress, exhaustion) crowds out intimacy. This isn't about scheduling sex like a chore — it's about *protecting space for it* with awareness of the conditions that make it work for both people. The fundamental difference from #82: this deals with an intimate relationship where rejection sensitivity is high, conditions matter more than calendar slots, and the cost of a poorly-timed initiation can set things back. --- ### P1: Conditions & readiness signals Track the factors that create favorable conditions for intimacy, without being creepy. - [ ] Define condition categories: quality time spent together (shared meals, conversations, date nights), stress indicators (work hours logged, late nights), rest/recovery (early nights, relaxed weekends), privacy windows (kids asleep, no guests) - [ ] Users can tag interactions/events with an after-effect: "This date night usually leads to a good next morning"; "After a heavy work week, give it a day" - [ ] Learn personal patterns: "You tend to connect after date nights — you have one Friday" - [ ] Surface as a gentle awareness signal, not a notification: "You both had a relaxed evening — conditions look favorable" — no alerts, no badges, visible only when you open the app - [ ] Privacy-first: ALL condition data is on-device, never synced, can be biometric-gated ### P2: Scheduling around life When life is chaotic, scheduling becomes an act of care, not a lack of romance. - [ ] "Protect this time" mode: user blocks a window (e.g., Saturday afternoon) and the app helps set the stage — reminder to handle logistics (childcare, no over-scheduling), suggests framing ("It's been a while — want to plan a slow evening?") - [ ] Integration with calendar: detect busy/stressful periods and suggest windows when both people have lighter days - [ ] Recurring intimacy rhythm detection: "You tend to connect every 10-14 days" — if it stretches past the natural window, gentle awareness: "It's been a couple weeks — might be worth making space" - [ ] Not a demand or a nag. "You have a light Friday. Could be a good time to reconnect." ### P3: Rejection sensitivity & initiation support The biggest killer of intimacy in long-term relationships is that someone stops initiating because rejection hurts. - [ ] Track initiation (who, when) and outcome (receptive, neutral, decline) — purely for personal pattern awareness - [ ] If you've been declined a few times recently, the app should *not* suggest you try again. Instead: "You've initiated a few times without success — might be worth checking in about what's going on" - [ ] If you're the one declining, pattern awareness: "You've declined the last few advances — is everything okay?" — a prompt for self-reflection, not a guilt trip - [ ] Gentle recalibration after a dry spell: not "initiate NOW" but "conditions are good this weekend if you feel ready" - [ ] All initiation/outcome data is the most sensitive data in the app — must be behind the biometric vault gate (#26) ### P4: Mutual rhythm discovery Detect what naturally works for both of you, as a couple. - [ ] Over time, discover: time of day, day of week, after specific activities (date night, shared hobby, weekend morning) - [ ] Surface as shared pattern: "You both tend to connect on weekend mornings" — useful for protecting that time - [ ] Rhythm drift detection: if the natural rhythm shifts (e.g., weekends were working but now it's weeknights), flag it as a change worth noticing - [ ] Seasonal patterns: summer vs winter rhythms, holiday stress vs vacation relaxation ### P5: Protective barriers & safety These features handle the most sensitive data in the entire app. Must be designed with extreme care. - [ ] Every feature in this issue is opt-in, per-relationship, and default-off - [ ] All data stored on-device only, never exported, never backed up - [ ] Biometric/PIN gate to view any intimate condition data — reuse vault auth from #26 - [ ] Emergency stop: one tap hides all intimacy data and resets the feature to inactive - [ ] No notifications about intimacy ever — awareness signals are in-app only, never push - [ ] Ability to reset all data for a relationship ("fresh start") without losing other Kin data - [ ] Clear persistent labeling: "Private — never leaves this device" - [ ] Delete relationship = permanently delete all intimate condition data for that person ## Tech notes - Purely on-device computation over existing interaction/event timestamps - Condition detection requires no new permissions — uses logged interactions, calendar events, and user-tagged moments - Initiation tracking needs a new data field on interaction: `initiator: "me" | "them" | "mutual"` — currently not tracked - Readiness signals are pure pattern math (time-of-day clustering, inter-interval variance, event correlation) — no ML needed - All P5 protections must ship before any P1/P2/P3 feature is exposed to users - This feature should be gated behind the vault system (#26) as a precondition for use

Mark commented

2026-06-09 02:38:19 +00:00

Owner

Summary

A feature for romantic partners in long-term relationships where spontaneity is unreliable but intentionality is essential. Life (work, kids, stress, exhaustion) crowds out intimacy. This isn't about scheduling sex like a chore — it's about protecting space for it with awareness of the conditions that make it work for both people.

The fundamental difference from #82: this deals with an intimate relationship where rejection sensitivity is high, conditions matter more than calendar slots, and the cost of a poorly-timed initiation can set things back.

P1: Conditions & readiness signals

Track the factors that create favorable conditions for intimacy, without being creepy.

Define condition categories: quality time spent together (shared meals, conversations, date nights), stress indicators (work hours logged, late nights), rest/recovery (early nights, relaxed weekends), privacy windows (kids asleep, no guests)
Users can tag interactions/events with an after-effect: "This date night usually leads to a good next morning"; "After a heavy work week, give it a day"
Learn personal patterns: "You tend to connect after date nights — you have one Friday"
Surface as a gentle awareness signal, not a notification: "You both had a relaxed evening — conditions look favorable" — no alerts, no badges, visible only when you open the app
Privacy-first: ALL condition data is on-device, never synced, can be biometric-gated

P2: Scheduling around life

When life is chaotic, scheduling becomes an act of care, not a lack of romance.

"Protect this time" mode: user blocks a window (e.g., Saturday afternoon) and the app helps set the stage — reminder to handle logistics (childcare, no over-scheduling), suggests framing ("It's been a while — want to plan a slow evening?")
Integration with calendar: detect busy/stressful periods and suggest windows when both people have lighter days
Recurring intimacy rhythm detection: "You tend to connect every 10-14 days" — if it stretches past the natural window, gentle awareness: "It's been a couple weeks — might be worth making space"
Not a demand or a nag. "You have a light Friday. Could be a good time to reconnect."

P3: Rejection sensitivity & initiation support

The biggest killer of intimacy in long-term relationships is that someone stops initiating because rejection hurts.

Track initiation (who, when) and outcome (receptive, neutral, decline) — purely for personal pattern awareness
If you've been declined a few times recently, the app should not suggest you try again. Instead: "You've initiated a few times without success — might be worth checking in about what's going on"
If you're the one declining, pattern awareness: "You've declined the last few advances — is everything okay?" — a prompt for self-reflection, not a guilt trip
Gentle recalibration after a dry spell: not "initiate NOW" but "conditions are good this weekend if you feel ready"
All initiation/outcome data is the most sensitive data in the app — must be behind the biometric vault gate (#26)

P4: Mutual rhythm discovery

Detect what naturally works for both of you, as a couple.

Over time, discover: time of day, day of week, after specific activities (date night, shared hobby, weekend morning)
Surface as shared pattern: "You both tend to connect on weekend mornings" — useful for protecting that time
Rhythm drift detection: if the natural rhythm shifts (e.g., weekends were working but now it's weeknights), flag it as a change worth noticing
Seasonal patterns: summer vs winter rhythms, holiday stress vs vacation relaxation

P5: Protective barriers & safety

These features handle the most sensitive data in the entire app. Must be designed with extreme care.

Every feature in this issue is opt-in, per-relationship, and default-off
All data stored on-device only, never exported, never backed up
Biometric/PIN gate to view any intimate condition data — reuse vault auth from #26
Emergency stop: one tap hides all intimacy data and resets the feature to inactive
No notifications about intimacy ever — awareness signals are in-app only, never push
Ability to reset all data for a relationship ("fresh start") without losing other Kin data
Clear persistent labeling: "Private — never leaves this device"
Delete relationship = permanently delete all intimate condition data for that person

Tech notes

Purely on-device computation over existing interaction/event timestamps
Condition detection requires no new permissions — uses logged interactions, calendar events, and user-tagged moments
Initiation tracking needs a new data field on interaction: initiator: "me" | "them" | "mutual" — currently not tracked
Readiness signals are pure pattern math (time-of-day clustering, inter-interval variance, event correlation) — no ML needed
All P5 protections must ship before any P1/P2/P3 feature is exposed to users
This feature should be gated behind the vault system (#26) as a precondition for use