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

Relationship dynamic templates — pre-built configurations for diverse relationship structures #88

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

Summary

A configuration template system that lets users import pre-built relationship dynamic presets. Instead of manually configuring relationship types, boundary defaults, cadence settings, privacy levels, and guidance frameworks from scratch, users can download or select a template that maps out their preferred arrangement.

This is a meta-layer above #80-#87 — it wires up all those features into coherent configurations for specific relationship structures. The app ships with a small set of neutral, well-documented templates. Users can also create, export, and share custom templates.

P1: Template format & schema

Define what a template contains.

  • Template file format: JSON or YAML, human-readable and editable
  • Template fields:
    • templateName — human-readable label
    • templateVersion — semver for compatibility
    • description — what this configuration is for (neutral language)
    • relationshipDefaults — default sub-type, vocabulary, iconography
      • relationshipTypes — which relationship types are available and their labels
      • defaultLabels — what to call partners, metamours, etc. (neutral defaults: "partner", "connection")
    • featurePresets — which features from #80-#87 are enabled by default
      • goalsEnabled, cadenceEnabled, boundariesEnabled, guidanceEnabled, etc.
      • Each with sensible defaults for the template's context
    • boundaryDefaults — typical boundaries for this dynamic (from #86)
      • Pre-set time windows, frequency limits, channel preferences
    • cadenceDefaults — typical cadence parameters for this dynamic (from #81/#82/#84)
      • Base intervals, expansion factors, lock-in thresholds
    • privacyDefaults — vault requirements (#26), biometric gates, data isolation
    • vaultDefault — whether vault is recommended/required for this template
    • guidanceDefaults — if guidance (#87) is relevant, with appropriate sub-type
    • tags[] — discoverability tags (e.g., "long-distance", "cohabitating", "non-monogamous")
  • Schema validation: templates must pass structural validation before import
  • Template compatibility check: warns if importing a template requires features that don't exist yet (e.g., template needs vault but #26 not implemented)

P2: Template library (built-in)

Neutral, documented presets shipped with the app.

  • Built-in templates (neutral descriptions, no value judgments):
    • Monogamous partnership — traditional monogamous relationship defaults, shared life tracking, intimacy awareness (#83), basic boundaries
    • Long-distance relationship — adjusted cadence defaults (longer base intervals, emphasis on scheduled quality time), communication channel preferences, visit planning integration
    • Living together / nesting — shared calendar emphasis, proximity detection (#83 conditions), merged household tracking, different boundary needs (personal space, alone time)
    • Ethically non-monogamous (general) — multiple partner support, parallel vs kitchen table options, disclosure boundary defaults, metamour relationship type, scheduling awareness
    • Hierarchical polyamory — primary/secondary partner distinctions, veto boundary templates, time allocation tracking, holiday/special event scheduling
    • Relationship anarchy — minimal defaults, no hierarchy, bespoke per-relationship configuration, high flexibility, no prescriptive labels
    • Casual dating — light feature set, no escalation tracking, flexible boundaries, ghosting cleanup window
    • Queer platonic partnership (QPP) — life partner defaults without romantic/sexual assumptions, cohabitation support, next-of-kin tracking, shared financial boundary options
    • Chosen family / found family — family-type tracking without biological assumptions, holiday coordination, care network boundaries, shared responsibility tracking
    • Power exchange (D/s, M/s) — guidance framework (#87) enabled with appropriate defaults, boundary enforcement active, structured feedback, consent tracking, safe word integration, check-in cadence, contract/agreement templates
    • Mentorship / apprenticeship — guidance framework (#87), milestone-based progression, feedback loops, graduation path
    • Co-parenting — shared responsibility tracking, communication boundaries, scheduling coordination, child development milestones (future feature hook)
  • Each template includes a plain-language description of what it configures and what assumptions it makes
  • Templates are examples, not prescriptions — user can start from any template and customize

P3: Template import & application

How users apply a template to their Kin setup.

  • Template browser UI in Settings: list available templates with descriptions and tags
  • Before import: show a diff of what will change (relationship types, enabled features, boundary defaults)
  • Non-destructive import: templates set defaults but don't overwrite existing configuration unless user confirms
  • Partial import: user can select which aspects of a template to apply (e.g., boundaries only, not cadence)
  • After import: guided walkthrough to customize the template to their specific situation
  • Template update: if a template version changes, offer to apply updates (with conflict resolution)
  • Multi-template: advanced users can apply different templates to different relationships (e.g., monogamous with one partner, casual with another)

P4: Custom template creation & export

Users can create and share their own templates.

  • Template builder UI: fill in template fields through the app, preview the resulting configuration
  • Export as JSON: share with others via file or URL
  • Import from file: load a custom template from JSON
  • Community template directory: optional — if integrated, users could browse community-contributed templates (this would require a backend and review process — scope for later)
  • Template versioning: when app features change, templates can be updated and versioned
  • Template snapshots: store which template and version a relationship was configured with, for future compatibility

P5: Privacy & safety for templates

Templates encode relationship structures. Some users need discretion.

  • Template browsing is offline-first — no telemetry on which templates are used
  • No template usage data ever leaves the device
  • Template names in the built-in library are neutral — "ENM general" not "slutty poly" (user can rename)
  • Custom templates are stored on-device only unless user explicitly exports
  • If a template enables sensitive features (vault, intimate awareness, guidance), warn before applying: "This template enables private awareness features"
  • Ability to reset to app defaults at any time (removes template configuration, keeps data)

Tech notes

  • Templates are just JSON blobs that map to existing configuration schema — no new backend
  • Built-in templates ship as bundled JSON in the app, loaded on initialization
  • This feature depends on #26, #80, #81, #82, #83, #84, #85, #86, #87 all existing — it's a configuration layer on top of them
  • Template format needs to be designed for forward compatibility (templates written for future feature versions should degrade gracefully)
  • Community directory (P4) is explicitly future scope — not in v1
## Summary A configuration template system that lets users import pre-built relationship dynamic presets. Instead of manually configuring relationship types, boundary defaults, cadence settings, privacy levels, and guidance frameworks from scratch, users can download or select a template that maps out their preferred arrangement. This is a meta-layer above #80-#87 — it wires up all those features into coherent configurations for specific relationship structures. The app ships with a small set of neutral, well-documented templates. Users can also create, export, and share custom templates. --- ### P1: Template format & schema Define what a template contains. - [ ] Template file format: JSON or YAML, human-readable and editable - [ ] Template fields: - `templateName` — human-readable label - `templateVersion` — semver for compatibility - `description` — what this configuration is for (neutral language) - `relationshipDefaults` — default sub-type, vocabulary, iconography - `relationshipTypes` — which relationship types are available and their labels - `defaultLabels` — what to call partners, metamours, etc. (neutral defaults: "partner", "connection") - `featurePresets` — which features from #80-#87 are enabled by default - `goalsEnabled`, `cadenceEnabled`, `boundariesEnabled`, `guidanceEnabled`, etc. - Each with sensible defaults for the template's context - `boundaryDefaults` — typical boundaries for this dynamic (from #86) - Pre-set time windows, frequency limits, channel preferences - `cadenceDefaults` — typical cadence parameters for this dynamic (from #81/#82/#84) - Base intervals, expansion factors, lock-in thresholds - `privacyDefaults` — vault requirements (#26), biometric gates, data isolation - `vaultDefault` — whether vault is recommended/required for this template - `guidanceDefaults` — if guidance (#87) is relevant, with appropriate sub-type - `tags[]` — discoverability tags (e.g., "long-distance", "cohabitating", "non-monogamous") - [ ] Schema validation: templates must pass structural validation before import - [ ] Template compatibility check: warns if importing a template requires features that don't exist yet (e.g., template needs vault but #26 not implemented) ### P2: Template library (built-in) Neutral, documented presets shipped with the app. - [ ] Built-in templates (neutral descriptions, no value judgments): - **Monogamous partnership** — traditional monogamous relationship defaults, shared life tracking, intimacy awareness (#83), basic boundaries - **Long-distance relationship** — adjusted cadence defaults (longer base intervals, emphasis on scheduled quality time), communication channel preferences, visit planning integration - **Living together / nesting** — shared calendar emphasis, proximity detection (#83 conditions), merged household tracking, different boundary needs (personal space, alone time) - **Ethically non-monogamous (general)** — multiple partner support, parallel vs kitchen table options, disclosure boundary defaults, metamour relationship type, scheduling awareness - **Hierarchical polyamory** — primary/secondary partner distinctions, veto boundary templates, time allocation tracking, holiday/special event scheduling - **Relationship anarchy** — minimal defaults, no hierarchy, bespoke per-relationship configuration, high flexibility, no prescriptive labels - **Casual dating** — light feature set, no escalation tracking, flexible boundaries, ghosting cleanup window - **Queer platonic partnership (QPP)** — life partner defaults without romantic/sexual assumptions, cohabitation support, next-of-kin tracking, shared financial boundary options - **Chosen family / found family** — family-type tracking without biological assumptions, holiday coordination, care network boundaries, shared responsibility tracking - **Power exchange (D/s, M/s)** — guidance framework (#87) enabled with appropriate defaults, boundary enforcement active, structured feedback, consent tracking, safe word integration, check-in cadence, contract/agreement templates - **Mentorship / apprenticeship** — guidance framework (#87), milestone-based progression, feedback loops, graduation path - **Co-parenting** — shared responsibility tracking, communication boundaries, scheduling coordination, child development milestones (future feature hook) - [ ] Each template includes a plain-language description of what it configures and what assumptions it makes - [ ] Templates are examples, not prescriptions — user can start from any template and customize ### P3: Template import & application How users apply a template to their Kin setup. - [ ] Template browser UI in Settings: list available templates with descriptions and tags - [ ] Before import: show a diff of what will change (relationship types, enabled features, boundary defaults) - [ ] Non-destructive import: templates set defaults but don't overwrite existing configuration unless user confirms - [ ] Partial import: user can select which aspects of a template to apply (e.g., boundaries only, not cadence) - [ ] After import: guided walkthrough to customize the template to their specific situation - [ ] Template update: if a template version changes, offer to apply updates (with conflict resolution) - [ ] Multi-template: advanced users can apply different templates to different relationships (e.g., monogamous with one partner, casual with another) ### P4: Custom template creation & export Users can create and share their own templates. - [ ] Template builder UI: fill in template fields through the app, preview the resulting configuration - [ ] Export as JSON: share with others via file or URL - [ ] Import from file: load a custom template from JSON - [ ] Community template directory: optional — if integrated, users could browse community-contributed templates (this would require a backend and review process — scope for later) - [ ] Template versioning: when app features change, templates can be updated and versioned - [ ] Template snapshots: store which template and version a relationship was configured with, for future compatibility ### P5: Privacy & safety for templates Templates encode relationship structures. Some users need discretion. - [ ] Template browsing is offline-first — no telemetry on which templates are used - [ ] No template usage data ever leaves the device - [ ] Template names in the built-in library are neutral — "ENM general" not "slutty poly" (user can rename) - [ ] Custom templates are stored on-device only unless user explicitly exports - [ ] If a template enables sensitive features (vault, intimate awareness, guidance), warn before applying: "This template enables private awareness features" - [ ] Ability to reset to app defaults at any time (removes template configuration, keeps data) ## Tech notes - Templates are just JSON blobs that map to existing configuration schema — no new backend - Built-in templates ship as bundled JSON in the app, loaded on initialization - This feature depends on #26, #80, #81, #82, #83, #84, #85, #86, #87 all existing — it's a configuration layer on top of them - Template format needs to be designed for forward compatibility (templates written for future feature versions should degrade gracefully) - Community directory (P4) is explicitly future scope — not in v1
Mark 2026-06-13 13:52:01 +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#88
No description provided.