Repository navigation
Fleet Studio completion: stable peer identity, keeper authority, and roster repair #1477
Description
Important
Problem — Fleet Studio presently treats mutable hostnames and canonical hosts as machine identity. This produced duplicate Mac Studio rows and self-canonical drift in live use. The keeper pointer cannot prove which serving machine it denotes, and collision handling can select an arbitrary row.
Approach — Introduce stable peer identity plus alias history and explicit keeper reconciliation. A machine’s hostname, SSH alias, endpoint, and display name become mutable reach/display attributes; only stable identity keys trust, grants, and keeper authority.
Scope — in: stable identity, keeper binding, roster collision/staleness/repair states, and standalone-serving advertisement. · out: changing the fleet.json role union, the never-fork guard, peer tokens, or transport supervision.
Assumptions — existing roster and projection foundations remain; thin-client/hub remains supported.
Acceptance Criteria
- A serving peer has a stable identity distinct from hostname, alias, endpoint, and display name.
- A changed hostname or alias for the same stable identity produces one named repair/reconciliation state, never a second live device.
- The same alias or endpoint claimed by different stable identities is refused as a named conflict; no row is selected arbitrarily.
- Keeper authority resolves to one stable serving identity; a stale/missing/conflicting keeper is a named repair state.
- An engine-owning standalone peer can advertise serving capability without taking a new
fleet.jsonrole. - Existing hub/client semantics and the never-fork guard remain unchanged.
Testing Decisions
Extend roster and sidebar model coverage with identity-change, alias-conflict, duplicate-identity, stale-alias, and keeper-mismatch fixtures. Add projection tests proving no ambiguous row reaches peer selection.
Key Decisions
Stable identity is the trust key; aliases are reconciled metadata. A human confirms ambiguous alias reconciliation.
Constraints & Invariants
No display-name, hostname-similarity, IP-address, or raw alias heuristic may merge two identities. This slice changes no token or control authorization behavior.
Prior Art
ADR 0027, ADR 0029, ADR 0031, and the #1475 deliberation identity audit.
Source
Part of #1475. ADR 0034. Durable deliberation amendment: spec-20260923-fleet-studio-base-peer-control-amendment-1.
Notes
First completion slice; no blockers.
Binding Amendment
Stable identity is a persisted cryptographic public-key fingerprint. Every roster self-report and keeper binding proves possession of that identity; a peer may update only its own identity record. Clone, key change, or conflict suspends grants and requires explicit re-admit.
Activity
jeonghun-jj-lee commentedon Sep 23, 2026
Implementation attempt failed its integration gate and is being replaced from a fresh isolated worktree.
Evidence:
pnpm --filter amicode test -- test/sidebar_fleet_section.test.tspassed 128/128, butpnpm --filter amicode run typecheckfailed with TS6133 insidebar_fleet_section.ts:391, andgit diff --checkreported trailing whitespace. Independent review also found the branch changes only sidebar source/tests; the persisted roster identity, proof-of-possession, keeper routing, peer selection, grant-suspension, and re-admit paths remain untouched.Draft PR #1491 is closed without merge. The published #1477 decision surface remains the recovery contract.
fix(fleet): enforce stable identity contract — fingerprint validation…
feat: stable peer identity, keeper authority, roster repair (#1477) (#…
jeonghun-jj-lee commentedon Sep 23, 2026
Landed via PR #1492 (squash e05406a into feature/free-tier-fleet). Non-default base merge doesn't auto-close.