01-projects/life/family-history

extended family feature spec

·project·status: draft-for-founder-confirmation

Extended-family toggle — feature spec (roots.rdco.dev)

Founder-directed 2026-07-22. The tree today is a pure ahnentafel (direct ancestors only: 2 parents per person, no siblings). This adds aunts/uncles/great-aunts/cousins behind a toggle, with relation-to-Ben labels. Founder rulings captured verbatim below; open decisions flagged for his call.

Founder rulings (verbatim intent)

Data model

Direct ancestors stay in ANC (ahnentafel, untouched). Extended family goes in a new parallel KIN array — extended people don't fit ahnentafel numbering (siblings share parents but aren't ancestors).

KIN = [
  { n:'Name', b:1850, d:1910, eb:, ed:,           // same date fields + estimate rules as ANC
    gender:'m'|'f',                                // explicit (can't derive from ahn parity here)
    region:'...', segs:[...],                       // same color/region system
    rel:{ kind:'sibling', of:<ahn#> },             // sibling of direct ancestor <ahn#> → shares parents 2*ahn / 2*ahn+1
    // OR rel:{ kind:'child', of:'<kin-key>' }     // cousin = child of another KIN person
    story:'...', conf:'CONFIRMED|PROBABLE|POSSIBLE',
    living:false }                                  // living-person flag (see Open Decision 1)
]

Relation-label computation (the headline feature)

Computed, not hand-typed, from position:

Direct ancestors (ahn n, generation g = floor(log₂ n), gender from parity even=m/odd=f):

Siblings of ancestors (aunts/uncles — the bulk of phase 1):

Cousins (children of aunts/uncles): "Nth cousin M× removed" via the nearest-common-ancestor algorithm. Clean but the fiddly part — phase 2 (arrives when we add children-of-siblings). Phase 1 ships ancestors + their siblings (labels are all clean there); cousins fall back to "cousin (extended family)" until phase 2.

View behavior

People index treatment (founder's direct question)

Recommendation: a separate collapsed "Extended family" section below the direct-ancestor list (or a filter toggle on the index mirroring the view toggle). Rationale: the index is already ~120 long; folding 100+ extended people inline would bury the direct spine, which is the thing you scan for. Separate section keeps the ancestor line clean AND matches the toggle mental model everywhere. (This is my rec; easy to do inline-with-tag instead if you prefer.)

Research process

The sibling strategy is already proven (2026-07-21 round — a sibling's death cert naming shared parents is how we CONFIRMED direct-line parents). Formalize it:

  1. For each direct ancestor, research their siblings: census households enumerate all children; wills name children; a sibling's death/marriage cert names the shared parents (this is the two-for-one — it enriches AND corroborates the direct line).
  2. Add found siblings to KIN, confidence-tagged, same POSSIBLE-off-viz discipline.
  3. /family-research-round gets sibling targets on its frontier (re-aim from the tapped-out deep frontier toward the sibling-rich 1800s middle band).
  4. Enrichment falls out for free: siblings' occupations/migrations color the family story.

Open decisions for founder

  1. Living relatives — RESOLVED 2026-07-22 (founder): option (a), include everyone fully. "I'm not sure why we need to obscure living people. This site is just for me behind a login wall." So living relatives display on the gated site with full dates. NUANCE that still holds: living people are added by HAND from founder knowledge (they're not in historical records); research agents still don't send living-person data to external services. Living branch (his aunts/uncles/cousins, Anne + kids) = founder supplies; deceased siblings = research.
  2. Primary relation-label phrasing: standard genealogical ("3rd-great-grandmother") vs founder's "Nth-generation grandma" gloss as the headline. (Compute both regardless; default to showing both, founder can pick the headline later.)

Phasing