fix(home): withdraw the adoption mechanism; keep election and honest reporting (#449)

Codex review of 4629117 raised three P1s and two P2s. All three P1s are
properties of the Home adoption mechanism rather than bugs in it, so the
mechanism is withdrawn rather than patched. What remains is wire-compatible
and does NOT claim to fix #449.

P1 — signed-record compatibility (owner_sync.rs:250). `HomeInvite` was inserted
BEFORE `IssuanceJournal`, shifting its bincode discriminant 3 -> 4. JSON-
persisted records still load, but `verify()` reconstructs different signed
bytes, invalidating pre-upgrade issuance signatures even after both devices
upgrade. Appending would fix the ordering, but any change to a signed value's
shape sits in this hazard class and needs an old-record fixture.

P1 — protocol compatibility (owner_sync.rs:183). A fifth closed-enum kind rode
an unchanged protocol version 2, so an older peer cannot decode the version
vector and aborts the entire owner-sync session — including unrelated names,
profile and journal sync. The kind needs negotiation or a staged rollout.

P1 — no trustworthy cross-device device/rider signal (sync.rs:316). The rider
exclusion trusted `OwnerIssuedCert.mode`, but `apply_journal_line` materializes
synced issuance records with `mode: Acp, not_after: None`
(owner_sync.rs:2567-2577), and `owner_issued_certificates()` treats journal
records as authoritative on ties. A Rider issued on device A therefore arrives
on device B indistinguishable from a device agent and would have received an
automatic Home invite — the filter was defeated in exactly the multi-device
case it existed for. The certificate carries no hosting mode either, so no
sound basis for a device-only auto-invite exists today, and inventing one here
would have silently amended ADR-0039's mode-agnostic Home eligibility and
deny-by-default rider scope.

Removed: SyncKind::HomeInvite (Tier-1 returns to FOUR kinds, restoring
IssuanceJournal's discriminant), SyncValue::HomeInvite, its apply arm,
home_invite_is_actionable, SyncDaemonView::{apply_home_invite,
reconcile_home_invites} and their DaemonView impls, mint_home_invite,
is_owner_device_cert, and the associated tests.

P2 FIXED — withdrawn canonical Home pointer (sync.rs:179). The publisher now
carries the same `!withdrawn` guard as `find_home`. Withdrawal keeps `home`
and `members_v2` populated, so a retired Home could be republished as
canonical; because provisioning yields to a named canonical Home, every device
would then refuse a replacement while GET /home reported `elsewhere` — the
owner left with no Home and no way to get one. Regression test added.

P2 MOOT — deferred invite retry: removed with the mechanism.

CI — rustdoc failed on a private intra-doc link from the public
HOME_POINTER_KEY; reproduced locally under RUSTDOCFLAGS="-D warnings" and
fixed. The treekem_home_rename e2e failure is #316/#311-class load flakiness,
not attributed to this diff.

ADR-0060 rewritten (still Proposed): amends ADR-0038 only — NO ADR-0041
amendment (Tier-1 stays at four kinds) and NO ADR-0039 change. Adoption,
retirement and any device-vs-rider Home eligibility rule are recorded as
explicitly undecided, to be reconciled with ADR-0039 rather than bypassed.

WHAT THIS DOES NOT DO: #449 is NOT fixed. A second device still holds its own
Home and reports `adoption_pending`; it does not join the owner's Home, and
the duplicate persists. #449 stays open.

Gates on this exact tree, separate commands, actual exits:
  cargo fmt --all                                                     -> 0
  cargo clippy --all-features --all-targets -- -D warnings            -> 0
  cargo clippy --all-features --lib --bins -- -D warnings
      -D clippy::panic -D clippy::unwrap_used -D clippy::expect_used  -> 0
  cargo check --workspace --all-targets                               -> 0
  RUSTDOCFLAGS="-D warnings" cargo doc --all-features --no-deps       -> 0
  cargo nextest run --workspace --all-features --no-fail-fast         -> 0
      (3319 passed, 0 failed, 295 skipped)

Refs #449

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_017ovKUXBeg5GZ51YECS9p51

Author: dirvine

docs/adr/0060-one-home-per-owner.md

@@ -1,16 +1,17 @@
-# ADR 0060: One Home Per Owner — Cross-Device Election and Adoption
+# ADR 0060: The Owner's Home Is Elected, Not Per-Install
 
 - **Status:** Proposed
 - **Date:** 2026-09-05
 - **Decision owners:** David Irvine (direction), Claude (drafting)
-- **Reviewers:** —
+- **Reviewers:** — (Codex review of PR #507 at `4629117`; Jarvis Senior Engineer ADR conformance pending)
 - **Supersedes:** none
 - **Superseded by:** none
-- **Amends:** [ADR 0038](./0038-home-owner-certified-personal-space.md)
-  (the unit of Home), [ADR 0041](./0041-cross-machine-state-sync-tiers.md)
-  (Tier-1 surface widened to five kinds)
-- **Related:** issue #449; #435 (the per-machine dedup marker), #447
-  (certified join needs a second announce), #446;
+- **Amends:** [ADR 0038](./0038-home-owner-certified-personal-space.md) — the unit of
+  Home. **No amendment to [ADR 0041](./0041-cross-machine-state-sync-tiers.md)**
+  (the Tier-1 surface stays at four kinds) and **none to
+  [ADR 0039](./0039-agent-harness-boundary.md)** (Home eligibility stays
+  mode-agnostic) — see *Deliberately not decided here*.
+- **Related:** issue #449; #435, #447, #446, #506;
   `docs/design/449-single-home-per-owner.md`
 
 ## Context
@@ -24,123 +25,128 @@ ADR 0038 says two things that cannot both hold:
 
 The first sentence makes Home a property of the *install*; the second promises
 it is a property of the *user*. Issue #449 is that contradiction reaching
-production: three daemons sharing one owner `user.key` each auto-provisioned
-their own Home, because dedup was a marker file in the instance data dir plus
-a scan of the LOCAL roster (`find_home`). Nothing consulted the owner's other
-devices, so an owner with N devices got N competing Homes, and `GET /home` on
-each device confidently returned its own duplicate — two authoritative answers,
-no error anywhere.
-
-The transport that could have carried the answer already existed and was
-inert: ADR 0041 Tier-1 replicates a `HomePointer` record between enrolled owner
-devices, but its apply arm was a documented no-op ("cross-machine Home adoption
-… deliberately out of Tier-1 scope (gapcheck blocker 32)").
-
-Confirming #449 surfaced three further defects. The `HomePointer` register is
-keyed by the constant `"home"` — one LWW slot per owner — and `mint()` takes
-the slot at `version + 1` whenever the value differs, on a 60s reconcile tick.
-Two enrolled devices with different Homes therefore fought over that slot
-without end, re-signing and re-persisting a record every minute each. The
-published pointer was also selected with `.find()` over an unordered map using
-a weaker predicate than `find_home`, so a device could advertise a Home it was
-not even a member of. And `find_home` had no `!withdrawn` filter while
-withdrawal keeps `members_v2` and `home` populated, so retiring a Home through
-the existing delete path would have wedged `GET /home` and re-provisioning
-permanently.
+production: daemons sharing one owner `user.key` each auto-provisioned their
+own Home, because dedup was a marker file in the instance data dir plus a scan
+of the LOCAL roster. `GET /home` on each device then returned its own duplicate
+as authoritative — several answers, no error anywhere.
+
+Confirming #449 surfaced three further defects: the constant-key `("home")`
+Tier-1 register oscillated forever between devices holding different Homes
+(each 60s pass re-signing and re-persisting a record); the published pointer
+was selected nondeterministically with a weaker predicate than `find_home`; and
+`find_home` had no `!withdrawn` filter, so retiring a Home through the existing
+delete path would have wedged `GET /home` and re-provisioning permanently.
 
 ## Decision Drivers
 
-- The ADR 0038 promise is per-OWNER; the implementation was per-install.
-- MLS state cannot be merged. Home is Hidden + MlsEncrypted, which routes to
-  real TreeKEM; the only entries into a tree are `create` and
-  `join_from_welcome`. There is no merge path, so the answer is
-  join-one-and-retire-the-other, never reconcile-two.
-- An offline or un-synced device must still get a working Home. Suppression
+- ADR 0038's promise is per-OWNER; the implementation was per-install.
+- An offline or un-synced device must still get a working Home; suppression
   alone would leave an unreachable device with none, which is worse than a
   duplicate.
 - Nothing may be destroyed before a real seat in the canonical Home exists.
-- The owner layer must stay strictly opt-in: an install with no `user.key`
-  provisions no Home and mints no owner-sync records.
+- The owner layer must stay strictly opt-in: no `user.key`, no Home, no records.
+- **Old-version compatibility is a hard constraint.** Owner-sync records are
+  owner-signed and their signatures cover serialized bytes.
 
 ## Considered Options
 
-1. **Suppress provisioning when a peer Home is known.** Necessary but not
-   sufficient — an un-synced device knows nothing and still provisions.
-2. **Deterministic owner-derived `group_id`** (`H(owner_pk)`) so every device
-   "creates" the same Home.
-3. **Never auto-provision**; require the owner to create Home explicitly.
-4. **One agent key on every device** (ADR 0043 key move), so there is only one
-   agent and therefore one Home.
-5. **Optimistic provisioning + election + winner-driven adoption.**
+1. Suppress provisioning when a peer Home is known.
+2. Deterministic owner-derived `group_id` so every device "creates" the same Home.
+3. Never auto-provision; require the owner to create Home explicitly.
+4. One agent key on every device (ADR 0043 key move).
+5. Optimistic provisioning + election on the existing register, with adoption
+   of the losing device deferred to a follow-up.
 
 ## Decision
 
-We will adopt option 5: **the unit of Home is the owner, not the install.**
+We will adopt option 5: **the unit of Home is the owner, not the install, and
+the owner's canonical Home is elected on the existing Tier-1 register.**
 
 - Auto-provisioning stays, but is **optimistic and subject to election**. A
-  device provisions only when no owner device has advertised a Home; absence
-  of a register value means "unknown", never "none exists".
+  device provisions only when no owner device has advertised a Home. Absence of
+  a register value means "unknown", never "none exists".
 - The Tier-1 `(HomePointer, "home")` register is the **canonical pointer**. A
   device mints into it only when the register is empty, when it is that Home's
   designated primary agent and the value changed, or when its own Home is
   strictly preferable under `(provisioned_at_ms, group_id)` — oldest wins, id
   breaks ties. Both devices compare the same tuples, so they elect the same
   winner; the value strictly decreases, so the register converges.
+- The publisher and the resolver share one predicate, including `!withdrawn`:
+  a retired Home is never advertised as canonical and never resolves locally.
 - `GET /home` reports a **state** — `local`, `adoption_pending`, `elsewhere` —
   with 200. "The Home is on another device" is an answer, not a 404.
-- **Adoption is winner-driven.** Only a device seated in the canonical Home can
-  seal `MemberAdded`, so it issues the invites. Tier-1 gains a fifth kind,
-  `SyncKind::HomeInvite` (0x05), keyed by joiner agent hex, carrying an
-  addressed v4 `SignedInvite`. A group id alone cannot admit a device: the join
-  path needs the invite's `genesis_creation_nonce`, `base_state_revision` and
-  `base_state_hash`, which `HomePointer` does not carry.
-- **A refused or deferred admission retries and never falls back to minting a
-  new Home.** #447's cert-blob race delays admission; without this rule the fix
-  reintroduces the bug under a race.
-- Retirement of the losing duplicate is **gated**: join first, retire second,
-  and only when the duplicate is provably empty. Anything else stays as a
-  `conflict` for the owner to resolve.
+
+**This ADR does not decide how a losing device joins the winner's Home.** That
+mechanism is deferred (see below), so a second device today converges on the
+correct *answer* and reports it honestly, but does not yet become a member.
+
+## Deliberately not decided here
+
+A first implementation added a fifth Tier-1 record kind carrying an addressed
+invite, plus a filter excluding ADR-0039 `Rider` agents from automatic Home
+invites. Independent review of `4629117` found three blocking defects, and all
+three are properties of that mechanism rather than bugs in it:
+
+1. **Signed-record compatibility.** Inserting a variant ahead of
+   `IssuanceJournal` shifted its bincode discriminant, so `verify()`
+   reconstructed different signed bytes and invalidated pre-upgrade issuance
+   signatures. Appending fixes the ordering, but any change to a signed value's
+   shape is in this hazard class.
+2. **Protocol compatibility.** A fifth closed-enum kind under an unchanged
+   protocol version cannot be decoded by older peers, aborting the whole
+   owner-sync session — including unrelated names, profile and journal sync.
+   The new kind needs negotiation or a staged rollout.
+3. **No trustworthy cross-device device/rider signal.** `apply_journal_line`
+   materializes synced issuance records with `mode: Acp`, and
+   `owner_issued_certificates()` treats journal records as authoritative on
+   ties. A Rider issued on device A therefore arrives on device B indis-
+   tinguishable from a device agent. The certificate does not carry hosting
+   mode either, so **no sound basis exists today for a device-only
+   auto-invite** — and inventing one in the implementation would have silently
+   amended ADR-0039's mode-agnostic Home eligibility and its deny-by-default
+   rider scope.
+
+Consequently, adoption, retirement and any device-vs-rider Home eligibility
+rule are **out of scope for this ADR** and must be decided explicitly — with
+ADR-0039 reconciled rather than bypassed — before implementation.
 
 ## Consequences
 
 ### Positive
 
-- An owner with N devices converges on one Home, and a device that has not yet
-  joined says so instead of forking.
+- An owner with N devices converges on one canonical *answer*, and a device
+  that is not a member says so instead of forking.
 - The register war ends by construction: once every device desires the same
-  value, `mint()`'s equality check holds the slot stable.
-- `find_home` becomes deterministic and withdrawal-aware, closing the wedge
-  that any retire-based fix would otherwise have hit.
+  value, the store's equality check holds the slot stable.
+- `find_home` becomes deterministic and withdrawal-aware, closing the wedge any
+  retire-based fix would otherwise hit.
+- Wire-compatible: no new record kind, no change to any signed value's shape,
+  no protocol version change.
 
 ### Negative / Trade-offs
 
-- Tier-1 is no longer four kinds. The deny-by-default allowlist is a
-  deliberate structural guarantee, so widening it is a real cost, paid here
-  because no existing kind can carry join material.
-- Adoption requires the winning device online at least once; until then the
-  loser holds a usable but non-canonical Home.
+- **#449 is not fully fixed.** A second device still holds its own Home and
+  reports `adoption_pending`; it does not join the owner's Home. The duplicate
+  persists.
 - A register naming a Home whose only member is permanently gone is sticky —
-  no surviving device can lower it. The manual override is `POST /home/adopt`.
-- Dedup only reaches ENROLLED devices. Devices that merely share a `user.key`
-  never sync, so they cannot be deduplicated; enrollment
-  (`POST /sync/devices/enroll`) is the owner's explicit assertion that two
-  machines are theirs, and is the trust anchor for this whole mechanism.
+  no surviving device can lower it, and no manual override exists yet.
+- Election only reaches ENROLLED devices; devices merely sharing a `user.key`
+  never sync and are unaffected.
 
 ### Neutral / Operational
 
 - The owner layer stays opt-in and is regression-tested as such.
-- Mixed fleets: an old daemon keeps writing the `"home"` slot unconditionally;
-  a new daemon simply declines to fight it.
+- Mixed fleets: an old daemon keeps writing the register unconditionally; a new
+  daemon declines to fight it.
 
 ## Validation
 
-- Two devices sharing an owner key, cross-enrolled, converge on exactly one
-  Home; the assertion is the invariant, not which id won.
-- The `"home"` record's `version` stops advancing once converged (pre-fix it
+- The `"home"` record's version stops advancing once devices agree (pre-fix it
   grew once per device per minute, without end).
-- A second device with the owner's Home advertised provisions nothing, and
+- Two daemons holding the same two Homes publish the same pointer — a property
+  the previous unordered-map selection could not provide.
+- A second device with the owner's Home advertised provisions nothing and
   `GET /home` reports `elsewhere` with 200.
-- A withdrawn Home never resolves as a device's Home.
-- An invite addressed to another agent, or expired, is refused rather than
-  redeemed.
+- A withdrawn Home neither resolves locally nor is advertised as canonical.
 - A daemon with no `user.key` provisions no Home and mints no records.
+- `SyncKind::ALL.len() == 4` — the Tier-1 tripwire remains untripped.

docs/adr/README.md

@@ -67,7 +67,7 @@ This directory contains architecture decision records for x0x.
 - [ADR 0057: Local Apps Reach the Daemon via REST/WS with Filesystem Discovery; `serve()` Is the Embedded Form](./0057-embedded-serve-library-local-apps.md) (proposed 2026-08-29) — `api.port`/`api-token` discovery over the ADR-0044 plane; embedded `server::serve()` disables self-update and hands `ServerHandle` to the caller; `/apps` static hosting remains proposal-only
 - [ADR 0058: The Constitution Is Embedded Compile-Time in Every Binary](./0058-compile-time-embedded-constitution.md) (proposed 2026-08-29) — `include_str!` constants in the shared library surfaced via `GET /constitution`, `GET /constitution/json`, and `x0x constitution`; status constant (currently Draft) is the stage of record
 - [ADR 0059: Invite Authentication and Seating Provenance](./0059-invite-authentication-and-seating-provenance.md) (proposed 2026-09-02) — InviteV4 signs the whole invite minus signatures with inline id-bound inviter/owner keys; Home-join mode pins the admission owner; every invite-derived seat records local, bootstrap-stripped `invite_lineage` with deduplicated authenticated fork evidence (observability only, no eviction); amends ADR 0016 §7; the stale-base residual and old-admin-key caveat are deferred to #472
-- [ADR 0060: One Home Per Owner — Cross-Device Election and Adoption](./0060-one-home-per-owner.md) (proposed 2026-09-05) — the unit of Home is the OWNER, not the install (#449): auto-provisioning becomes optimistic and subject to election on the Tier-1 `("home")` register, `GET /home` reports `local`/`adoption_pending`/`elsewhere` instead of a bare 404, and adoption is winner-driven over a new fifth Tier-1 kind `SyncKind::HomeInvite` (a group id alone cannot admit a device, so `HomePointer` could elect but never seat); a deferred admission retries and never falls back to minting a second Home; amends ADR 0038 (unit of Home) and ADR 0041 (Tier-1 widened to five kinds); retirement of the losing duplicate is gated and still open
+- [ADR 0060: The Owner's Home Is Elected, Not Per-Install](./0060-one-home-per-owner.md) (proposed 2026-09-05) — the unit of Home is the OWNER, not the install (#449): auto-provisioning becomes optimistic and subject to election on the Tier-1 `("home")` register, publisher and resolver share one `!withdrawn` predicate, and `GET /home` reports `local`/`adoption_pending`/`elsewhere` instead of a bare 404. Amends ADR 0038 (unit of Home) ONLY — no Tier-1 surface change (ADR 0041 stays at four kinds) and no change to ADR 0039 Home eligibility. How a losing device JOINS the winner's Home, retirement of the duplicate, and any device-vs-rider eligibility rule are explicitly deferred: review of PR #507 showed the first implementation broke signed-record and protocol compatibility and had no trustworthy cross-device device/rider signal. #449 stays open.
 
 ## Errata (Accepted ADRs are immutable; corrections recorded here)
 

docs/design/449-single-home-per-owner.md

@@ -361,8 +361,8 @@ history rows, no KV, no tasks), so the common case retires cleanly.
 |---|---|---|
 | **P0** ✅ | D3 + D4: stop the register war, make the published pointer deterministic | — |
 | **P1** ✅ | Election + `GET /home` states + suppression at provisioning | P0 |
-| **P2** ✅ | Invite delivery channel (§5.4) — `SyncKind::HomeInvite`; needs the ADR-0041 amendment | P1 |
-| **P3** ✅ | Winner-driven adoption + D5 (`!withdrawn` filter) | P2, #447 |
+| **P2** ⛔ | Invite delivery channel (§5.4) — WITHDRAWN, see below | P1 |
+| **P3** ⛔ | Winner-driven adoption — WITHDRAWN. D5 (`!withdrawn` filter) landed with P1 | P2, #447 |
 | **P4** | Retirement gate + D6/D7 cleanup; `conflict` state and forced adopt/retire endpoints | P3 |
 
 P0 is small, independently shippable, and blocks a regression that lands the
@@ -388,20 +388,33 @@ both its old duplicate and the canonical Home during adoption could answer with
 either. `resolve_home` additionally prefers the canonical Home whenever we are
 seated in it, so the transition settles deterministically.
 
-Adoption rides `SyncKind::HomeInvite` (0x05), keyed by joiner agent hex.
-The seated device enumerates the owner's agents from synced `IssuanceJournal`
-records — the daemon journals its own certificate (`lib.rs:12029-12055`), so a
-peer's agent id is already known without any new discovery — and mints an
-addressed v4 invite for each agent not yet seated. `DaemonView::apply_home_invite`
-redeems it in `mode: "home"` with the owner pinned. Both sides are idempotent
-and fire every sync pass until the join lands; a refusal (#447's cert-blob
-race) retries and never falls back to minting.
-
-**Still open (P4):** retirement. The loser keeps its duplicate group after
-adopting — unused, and no longer Home-resolved, but present. Retiring it needs
-D6 (retiring a Hidden Home publishes a public card) and D7 (history,
-delegations, task lists and rider grants are orphaned) fixed first, plus the
-`conflict` state and the forced adopt/retire endpoints.
+**P2/P3 WITHDRAWN after review of `4629117`.** An implementation of §5.4 as a
+fifth Tier-1 kind (`SyncKind::HomeInvite`) plus a `CertMode::Acp` filter was
+written, reviewed, and removed. Three blocking defects, all properties of the
+mechanism rather than bugs in it:
+
+1. **Signed-record compatibility.** The new variant was inserted ahead of
+   `IssuanceJournal`, shifting its bincode discriminant so `verify()`
+   reconstructed different signed bytes and invalidated pre-upgrade issuance
+   signatures. Appending fixes the ordering, but any change to a signed value's
+   shape sits in this hazard class and needs an old-record fixture.
+2. **Protocol compatibility.** A fifth closed-enum kind under an unchanged
+   protocol version 2 cannot be decoded by older peers, aborting the entire
+   owner-sync session — including unrelated names, profile and journal sync.
+   The kind needs negotiation or a staged rollout.
+3. **No trustworthy cross-device device/rider signal.** `apply_journal_line`
+   materializes synced issuance records with `mode: Acp`
+   (`owner_sync.rs:2567-2577`), and `owner_issued_certificates()` treats
+   journal records as authoritative on ties. A Rider issued on device A
+   therefore arrives on device B indistinguishable from a device agent, so the
+   filter was defeated in exactly the multi-device case it existed for. The
+   certificate does not carry hosting mode either. Inventing a device-only
+   rule in the implementation would have silently amended ADR-0039's
+   mode-agnostic Home eligibility and deny-by-default rider scope.
+
+So adoption, retirement, and any device-vs-rider Home eligibility rule are
+deferred and must be decided explicitly — with ADR-0039 reconciled, not
+bypassed. **#449 remains open.**
 
 Known limitation carried into P1: because a yielding device publishes nothing
 and only strict improvements take the slot, a register naming a Home whose