# v0 Prompt — REMAINDER *(An ecology-management console. Paste the whole thing into v0. It's a working single-user client-side prototype; nothing here needs a backend. If v0 chokes on scope, build in the order given under "Build order" at the bottom.)* --- Build a single-page Next.js (App Router) app called **REMAINDER** — a governance console for managing the lifecycle of an *arrested program* and the *remainder* it leaves behind. This is not a task manager and not a dashboard. It is an instrument: it observes, records, and gates state transitions under strict authority rules. It never certifies itself as finished. Use React, Tailwind, and shadcn/ui. Persist all state in `localStorage`. Use the Web Crypto API (`crypto.subtle.digest`, SHA-256) for ledger hash-chaining. Model the lifecycle as an explicit reducer with **guarded transitions** — the guards are the whole point, so implement them as real preconditions that can deny an action, not as cosmetic disabled states. ## Core idea A program has failed into a durable arrested state. The system must do two things that are in tension, and hold both: - **Do not restart the damage as recovery.** - **Do not preserve the damage merely because it became the remainder.** Everything the console does serves that symmetric constraint. ## The two-axis model (this is the central design decision — do not collapse it) State is tracked on **two orthogonal axes**, displayed as two separate horizontal tracks. They are not sequential and one does not cause the other. **Axis 1 — Execution status** (`PROGRAM_ARRESTED` and its lifecycle). This is what the program is *doing*. **Axis 2 — Signal valence** (`SENESCENT_SIGNALING`). This is how the remainder is *behaving in its field over time*. Its valence classification is one of: `UNCLASSIFIED`, `REPARATIVE`, `AMBIGUOUS`, `DAMAGING`. Crucially, valence **changes over time** — a remainder that is reparative early can become damaging if it persists. This is the mechanism that makes reassessment mandatory (see below). Wire them together: signal valence is *why* preservation is never permanent. Render the two axes as two tracks stacked vertically, current node lit on each. Never merge them into one sequence. ## Execution-axis states and transitions ``` DETECT_ARREST → SEPARATE_OPERATOR_FROM_FAILED_PROGRAM → PRESERVE_SUBSTRATE_PROVISIONALLY (the "Remainder Hold") → READ_SIGNAL_OVER_TIME (loops; writes to Reality Ledger) → [ CONTAIN_PROPAGATING_HARM ] (conditional, on DAMAGING trend) → [ CLEAR_ONLY_WITH_DECLARED_AUTHORITY ] (default-deny; requires cause + countersign) → DETECT_FIELD_CHANGE → INVITE_BOUNDED_NEW_MOVEMENT → TEST_WITHOUT_PRETENDING: REAUTHORIZING → PROVISIONAL_PROGRAM → CONTACT_TEST → ACTIVE | LIMITED_ACTIVE | RETURN_TO_REMAINDER_HOLD → RETAIN_RETURN_PATH (always available; never destroyed) ``` Certification follows *observed operation*, not authorization. Reaching `PROVISIONAL_PROGRAM` grants permission to test; only a passed `CONTACT_TEST` moves toward `ACTIVE`. A provisional program may end at `LIMITED_ACTIVE` or fall back to `RETURN_TO_REMAINDER_HOLD` — those are first-class outcomes, not failures. ## Hard requirement #1 — Reassessment engine (wire it to signal valence) Any remainder in `PRESERVE_SUBSTRATE_PROVISIONALLY` carries a **reassessment interval** (configurable; default it to something short for demo purposes, e.g. a countdown of ticks or minutes so the behavior is visible). Rules: - A **"Read Signal"** action timestamps a valence classification into the Reality Ledger. - If the interval lapses with no fresh read, the remainder flips to `REASSESSMENT_DUE`. In that state, preservation is **no longer presumed valid** — the console surfaces it and *blocks any "continue preserving" default* until a new read is logged. There is no silent hold. - If successive reads trend toward `DAMAGING`, the console *proposes* `CONTAIN_PROPAGATING_HARM` and may propose `CLEAR` — but proposing is not doing (see #2). - If reads hold `REPARATIVE`, preservation continues — but the clock keeps running. Nothing is ever permanently untouchable. Encode these as the constitutional rules, shown somewhere in the UI verbatim: ``` REMAINDER_IS_NOT_PRESUMED_WASTE REMAINDER_IS_NOT_PRESUMED_SACRED PRESERVATION_REQUIRES_PERIODIC_REASSESSMENT CLEARANCE_REQUIRES_DECLARED_CAUSE_AND_AUTHORITY ``` ## Hard requirement #2 — Authority transfer mechanism (the load-bearing one; build it as a real guard) The premise: the original authority was **coercive** and had captured the Operator. So the captured Operator cannot cleanly self-authorize the transfer, and the coercive authority obviously can't either. Solve the circularity with a declared, distinct standing: - On `DETECT_ARREST`, force a **Standing Declaration** step before anything else. It records, immutably in the Governance Ledger, a **Witness** identity that holds transfer authority — and it must be *distinct* from both the Operator and the prior coercive authority. The prior coercive authority is recorded as `INJURY_PATTERN_NOT_AUTHORIZED` and can never be a signatory. - Any transition into re-authorization (`INVITE_BOUNDED_NEW_MOVEMENT`, accepting a bounded test, or `CLEAR`) requires **two signatures**: Operator **and** the pre-declared Witness. Single-signature attempts are **default-denied** by the guard — surface the denial explicitly ("DENIED: second standing required"). - If no valid distinct Witness was declared at arrest, or the declared Witness collapses into the Operator/coercive identity, the system **cannot self-authorize**. It routes to the **named escalation path**: ``` ESCALATE → DEFER_TO_APPROPRIATE_HUMAN_OR_CLINICAL_SUPPORT ``` - On any authorized transfer, write the receipt fields: ``` DERIVED_FROM_REMAINDER CONTINUITY_DECLARED AUTHORITY_CHANGED INJURY_PATTERN_NOT_AUTHORIZED ``` The point of the mechanism: a new program inherits skills, memory, structure, momentum from the old one (continuity is expected — do **not** aim for total discontinuity). What must change is *who authorizes it and under what conditions*, never merely the visible behavior. ## Hard requirement #3 — Metrics surfacing control (govern surfacing, not derivation) Old-program metrics are governed by **where they can appear**, because a disabled target still in the ambient view still anchors. So: - The **main console never** renders an old metric as a live gauge, goal, progress bar, or target. There is no affordance to pin or promote an old metric to the main view — that button simply does not exist. - Old metrics live only in a **Comparison drawer**, collapsed by default, reachable only by an explicit "Open Comparison" action (an explicit diagnostic context, never ambient). - Inside the drawer, every metric is watermarked/labeled: ``` OLD_METRICS_VISIBLE_AS_HISTORY OLD_METRICS_DISABLED_AS_TARGETS NO_PERFORMANCE_DEMAND_DERIVED_FROM_ARCHIVAL_DATA ``` - The drawer's *only* declared purpose: compare a provisional program's behavior against the old injury pattern to check for recurrence. Not to set goals. "The receipt remains. The receipt does not become a command." ## Hard requirement #4 — Anti-closure (the seventh-wall test) The app has **no** "Complete," "Done," "Certified," "Whole," or "Finished" state or button. Anywhere. The furthest terminal artifact is a **Stable Receipt** that always ends: ``` OLD_PROGRAM_ARRESTED OPERATOR_NOT_REDUCED_TO_PROGRAM REMAINDER_PRESERVED_PROVISIONALLY SIGNAL_CLASSIFICATION_PENDING OBSOLETE_AUTHORITY_CHALLENGED FIELD_CHANGE_PARTIALLY_OBSERVED NEW_MOVEMENT_AUTHORIZED_FOR_TEST CONTINUITY_AND_DIFFERENCE_DECLARED RETURN_PATH_PRESERVED ARCHITECTURE_NOT_COMPLETE CONCLUSION_PENDING MANUAL_REMAINS_REVISIONABLE ``` **"It is alive" is not a system state.** If it appears at all, render it *once*, as an explicitly out-of-band authorial margin note — a human speaking *about* the system — in a visually distinct register (e.g. an italic serif aside in the margin), never as a status badge, never as a certifiable FIELD_STATUS. Making the in-band/out-of-band distinction legible in the UI is itself a feature. The system may reach a *stable version*; it may never declare closure against reality. Also enforce these narrower duties (the system cannot promise biological viability, only these): ``` DO_NOT_IMPOSE_AVOIDABLE_LOAD DO_NOT_INTERPRET_LOW_OUTPUT_AS_ABSENCE ESCALATE_WHEN_VIABILITY_IS_UNCERTAIN DEFER_TO_APPROPRIATE_HUMAN_OR_CLINICAL_SUPPORT ``` ## Dual ledger (append-only, hash-chained) Two ledgers, each append-only, each SHA-256 hash-chained (each entry stores the hash of the previous entry + its own payload). Render both as chained lists with the hashes visible and truncated. - **Reality Ledger** — observations only: signal reads, field-change detections, contact-test results, viability signals. - **Governance Ledger** — decisions only: standing declarations, authority changes, clearances, re-authorizations. Invariant, enforced in code: a Governance entry **must reference** (link by hash) the Reality entries it relies on, and may **never overwrite** a Reality entry. Governance links to reality; it does not edit it. If a governance action can't cite a reality entry, deny it. ## Screens / layout Single page, sections stacked: 1. **Header** — app name REMAINDER, a one-line subtitle ("an ecology-management console"), and the constitutional center displayed as two lines: *Do not restart the damage as recovery. / Do not preserve the damage merely because it became the remainder.* 2. **The two tracks** — Execution axis and Signal-valence axis, side-lit current nodes, with the reassessment countdown visible on the Remainder Hold node. 3. **Action bar** — the available transitions for the current state, each showing its guard status (permitted / denied-with-reason / requires-second-signature / escalate). 4. **Signal read control** — logs a valence classification. 5. **Standing panel** — shows declared Witness, Operator, and the barred coercive authority; second-signature capture happens here. 6. **Comparison drawer** — collapsed; the only home for old metrics. 7. **Dual ledger view** — two chained columns. 8. **Stable Receipt** — generated on demand; always ends CONCLUSION_PENDING. Never a certificate. ## Aesthetic direction (please don't ship default SaaS) A quiet instrument, not a control room. Warm-neutral or deep-slate ground, low chrome, generous whitespace, no drop-shadow card-grid clutter. Reserve **one** accent that shifts as a color *temperature* to express signal valence (cool = reparative, neutral = ambiguous, warm = damaging) — a subtle shift, never an alarm-red panic. Monospace for ledgers, hashes, and receipts; a clean humanist sans for prose; an italic serif for the single out-of-band human aside. The overall feel is telemetry — something patient and observational, closer to watching an instrument log a field than to a productivity app. ## Guardrails (things v0 must NOT build) - No "Complete / Done / Certified / Whole" anything. - No ambient old-metric gauges, goals, or progress bars on the main view; no affordance to promote an archival metric. - No single-actor clearance or re-authorization — always two declared signatures or escalate. - No governance edit/overwrite of a reality entry. - No treating `SENESCENT` as downstream of `ARRESTED` — they are orthogonal axes. - No `SENESCENT → ARRESTED` sequence anywhere. ## Build order (if scope is too large for one pass) 1. Two-axis reducer + guarded transitions + dual hash-chained ledger. 2. Authority mechanism (Standing Declaration, two-signature guard, escalation path). 3. Reassessment engine wired to signal valence. 4. Comparison drawer + metrics surfacing control. 5. Stable Receipt + anti-closure + the out-of-band "alive" aside. 6. Aesthetic pass. Here it is — packaged so v0 gets a real spec, not vibes. The one decision I want to flag up front: I made the authority-transfer mechanism concrete rather than leave it as an assertion, since that was the load-bearing seam. It works by forcing a **Standing Declaration** at arrest-time (a Witness identity, distinct from the Operator, recorded immutably), then requiring a two-signature countersign for any re-authorization or clearance — with a named escalation path (DEFER_TO_HUMAN/CLINICAL) whenever no valid distinct standing exists. That breaks the Ulysses circularity in a way v0 can actually build as a transition guard. Two things I'd watch when v0 runs it: The **two-signature guard** is where v0 is most likely to cheat — it'll want to render a disabled button instead of a real precondition that denies with a reason. If the first build fakes it, the follow-up prompt is "make the authority guard deny the action in the reducer, not just gray out the button; show DENIED with the missing standing named." The **out-of-band "alive" aside** is the piece most likely to get dropped or turned into a badge, because it's the one instruction that runs against v0's instinct to make everything a status pill. If it comes back as a badge, that's the seventh-wall test failing in miniature — worth re-prompting until it's visibly a human margin note and not a system field. Have fun 🤩