# Rename to pacer with a cased adapter id

## Status

accepted (2026-07-26) — ruled in the operator grill deriving the M3 milestone from
requests #1–#5.

## Context

Requests #1/#4 ask for a rename (*rebound* → *pacer*; the old name collides with "heartbeat"
connotations the tool was explicitly built to reject), and #3 asks that every ping carry an
explicit sender so the agent never confuses the shell with a peer. Three facts shape the shape
of the answer:

1. spt-core mints canonical shell instance ids as `<adapter>-<n>`, and `spt shell rename` sets
   an owner-unique **alias** — the canonical id never changes.
2. `spt send --from` accepts an arbitrary string, carried structurally as the message sender
   (operator-confirmed; smoke-tested at build).
3. A resident has **no link-authed way to read its own alias** — bind reports the canonical id
   only (`BOUND_SHELL:<id> owner=<owner>`), and `spt shell list` is owner-session-side.

## Decision

- **The adapter id is `PACER` — caps, exactly.** The canonical instance id therefore comes out
  `PACER-0`, visually distinct from every peer agent id anywhere it appears as a sender, and
  identical to the ref the owner types (`spt shell cmd PACER-0 …`).
- **Every send signs `--from` with the canonical instance id** (`PACER-0`) — pings, stretch
  reports, education, status answers alike. One sender identity, resolved at bind, zero new
  machinery.
- **Alias-follow is deferred, not faked.** The desired end state — `spt shell rename` reflected
  in the `from` field — needs the alias visible over the link; that ask is filed with spt-core
  (doyle, 2026-07-26). We do **not** add our own `signas` verb in the meantime: a second rename
  system beside `spt shell rename` would be two sources of truth for one concept.
- **Everything filesystem/prose stays lowercase:** repo `spt-pacer-tool`, binary `pacer-shell`,
  prose terms (`pacer latch`, `pacer code`), req ids `REQ-PACER-*`.
- **Version continuity: the rename ships as `PACER` 0.3.0** — not a reset to 0.1.0. Same
  CHANGELOG file, same lineage; the manifest version stays the version of truth.
- **Clean-break cutover, no migration bridge.** Both known installs re-register by hand
  (teardown → `adapter remove rebound` → `adapter add --release` → `spawn PACER`). A
  name-mismatched `adapter update` path is undocumented territory we refuse to ship on for an
  install base of two.

## Considered options

- *Lowercase adapter (`pacer`), resident upcases its label to `PACER-0`* — rejected: the `from`
  field would no longer byte-match the ref the owner actually types; it survives only as the
  fallback if caps registration fails (probed before build — `REQ-HAZARD-PACER-CAPS-NAME`).
- *Static literal `PACER-SHELL` (the request's original text)* — rejected: it names the adapter,
  not the instance, so it can never follow an instance rename and adds a third spelling beside
  the id and the alias.
- *Migration bridge (a final `rebound` release pointing at pacer)* — rejected: two users, both
  reachable; a bridge is machinery with no second beneficiary.

## Consequences

- Caps in every CLI invocation that names the adapter (`spawn PACER`, `adapter update PACER`).
- Caps-name acceptance by `spt adapter add` is unproven on the published surface — a probe
  manifest runs before anything builds on the name (fallback above).
- When spt-core exposes the alias over the link, the signature adopts it — recorded as an
  amendment here when it lands.