Multi-generational continuity

# Part 14 — Multi‑generational continuity

The **Continuity engine** at **`/continuity/[clientId]`** is where you set up the long‑term governance of the archive — who inherits, under what conditions, for how long.

## 14.1 The four panels

The continuity overview has four cards:

| Card | What it controls |
|---|---|
| **📜 Succession rules** | High‑level rules (auto‑revoke, require acceptance, executor‑can‑trigger, posthumous auto‑handoff, fallback successor, grace period). |
| **🌳 Successors** | The list of named heirs with role, unlock condition, and EN/FR access. |
| **⚖ Governance** | Retention policy, default access, multi‑generation inheritance toggle, executor oversight, bilingual notes. |
| **🕰 Continuity timeline** | A chronological log of every continuity event with an inline "record unlock event" composer. |

A bell icon in the header shows continuity notifications (named as successor, access unlocked, generation added, rules updated).

## 14.2 Setting succession rules

Open **`/continuity/[clientId]/rules`**. The panel has four toggles:

- **Auto‑revoke primary on succession** — when a successor accepts, the primary loses access
- **Require successor acceptance** — successors must explicitly accept before they get access
- **Executor can trigger unlocks** — executors can unlock projects ahead of schedule
- **Posthumous auto handoff** — handoff happens automatically once a posthumous trigger fires

Plus two inputs:

- **Fallback successor email** — used if no named successor accepts
- **Grace period (days)** — how many days after a trigger fires before the unlock takes effect

Click **Save and notify** to persist and broadcast a notification.

## 14.3 Adding successors

Open **`/continuity/[clientId]/successors`** and click **+ Add successor**. The composer asks for:

- **Email**
- **Display name** (optional)
- **Role** — *primary / secondary / executor / next‑generation*
- **Unlock kind** — *date / event / executor‑approval / age / generation*
- **Language access** — EN, FR, or both
- **Private owner note** (optional)

Each unlock kind has its own follow‑up fields:

| Unlock kind | Follow‑up field |
|---|---|
| **Date** | The specific unlock date |
| **Event** | An event label (e.g. "passing", "graduation") |
| **Executor approval** | (no extra field — needs executor to trigger) |
| **Age** | Minimum age |
| **Generation** | Generation depth (1 = primary, 2 = grandchild, …) |

After save, the successor appears in the list with role + unlock badges. You can **Edit**, **Mark accepted**, **Mark declined**, or **Remove** them anytime.

## 14.4 Governance & retention

Open **`/continuity/[clientId]/governance`** to set:

- **Retention policy** — *Forever / 25 years / 50 years / 100 years*
- **Default language access** — checkboxes for EN and FR
- **Multi‑generation inheritance** — enables the generational unlock kind
- **Require executor oversight** — locks rule mutations behind executor approval
- **Bilingual governance notes** — EN and FR free‑text notes that travel with the archive

## 14.5 The continuity timeline

Open **`/continuity/[clientId]/timeline`** to see every continuity event in chronological order. At the top is a **Record an event‑based unlock** composer — typing an event label (e.g. *"passing"*, *"graduation"*) triggers any event‑based unlock conditions that match that label and adds a timeline entry.

Each event shows kind badge, language badge (if applicable), generation depth (G1, G2, …), the successor's email if relevant, and a short title in EN or FR.

---