instar 1.3.1339 → 1.3.1341

package/upgrades/side-effects/files-never-serve-key-material.md

@@ -0,0 +1,399 @@
+# Side-Effects Review — Key material is never served, backed up or listed (a2a-single-agent-identity §5)
+
+**Version / slug:** `files-never-serve-key-material`
+**Date:** `2026-10-09`
+**Author:** Echo (instar-dev agent)
+**Second-pass reviewer:** reviewer subagent (see "Second-pass review" below)
+
+## Summary of the change
+
+Section 5 of `docs/specs/a2a-single-agent-identity.md` (converged, approved). One new
+module, `src/core/keyMaterialPaths.ts`, holds the list of key-bearing files under
+`.instar/` — the agent identity (`identity.json` and its `.superseded-*` / `.invalid-*` /
+temp siblings), the legacy threadline mirror, the threadline HMAC / invitation / token files,
+the dedicated SSH keys, the headless key vault (`local-state/`), origin-session credentials,
+the inbound-delivery and conversation-bind secrets, the manifest signing key, the machine
+key pair, the remediation key vault's flatfile and the telemetry HMAC secret. Four consumers derive their own spelling from that ONE list: the dashboard file
+routes' code-owned `NEVER_SERVED_PREFIXES` (`src/server/fileRoutes.ts`), `BackupManager`'s
+never-backup prefix set, `GITIGNORE_ENTRIES` at init plus `migrateGitignore` for existing
+agents (`src/core/MachineIdentity.ts`, `src/core/PostUpdateMigrator.ts`), and the git-sync
+`FileClassifier`'s secret patterns.
+
+The file routes also close the §5.2 gaps: `blockedFilenames` and the never-served check run
+on the requested AND the resolved path in read/download/list/link; `list` resolves each entry
+and OMITS one whose realpath fails or is denied; `link` resolves before minting; a `realpath`
+failure refuses (403) instead of a 500; and read/download open the file FIRST, `fstat` the
+descriptor, refuse unless its device+inode equals the stat taken at validation, refuse a
+multi-link inode that equals any listed key file, and serve FROM THAT DESCRIPTOR
+(`handle.readFile()` / `handle.createReadStream()`), never a by-path re-open.
+
+`src/commands/init.ts` gets a one-line fix the §5.4 walk found: the standalone init path
+called `ensureGitignore(stateDir)`, which wrote the project-relative entries into
+`.instar/.gitignore` where they match nothing; it now also calls `ensureGitignore(projectDir)`
+like the other two init paths. The CLAUDE.md template and migrator carry a "Never served" row.
+
+Tests: `tests/unit/file-routes-never-served-key-material.test.ts` (static list parity on all
+four surfaces + the route behaviour by direct path, symlink, hard link, swapped descriptor,
+dangling symlink, config narrowing), `tests/integration/file-routes-never-served-walk.test.ts`
+(the §5.4 walk: real init + real sealer/installer pairing + every in-tree key producer, then
+every 0600 / private-field / key-named file asserted refused, excluded, ignored, classified),
+`tests/e2e/files-never-serve-key-material-alive.test.ts` (production `AgentServer` boot: 200 on
+an allowed file, 403 on the identity, migration idempotency).
+
+## Decision-point inventory
+
+- `isNeverServed` / `NEVER_SERVED_PREFIXES` (`src/server/fileRoutes.ts`) — modify — the
+  enumerated deny gains the key-material prefixes.
+- `validatePath` (`src/server/fileRoutes.ts`) — modify — carries the resolved `stat`; a
+  non-ENOENT realpath failure now refuses (403) instead of 500.
+- `openCheckedDescriptor` (`src/server/fileRoutes.ts`) — add — descriptor identity proof
+  (device+inode) and the multi-link key-inode refusal; read/download consume it.
+- `resolveListEntry` (`src/server/fileRoutes.ts`) — add — per-entry admission for `list`
+  (omit on denied/unresolvable/blocked requested-or-resolved path).
+- `GET /api/files/link` — modify — full `validatePath` resolution before minting.
+- `BLOCKED_PATH_PREFIXES` (`src/core/BackupManager.ts`) — modify — key prefixes in both spellings.
+- `DEFAULT_SECRET_PATTERNS` (`src/core/FileClassifier.ts`) — modify — key prefixes as globs.
+- `GITIGNORE_ENTRIES` / `ensureGitignore` (`src/core/MachineIdentity.ts`) — modify — key entries.
+- `PostUpdateMigrator.migrateGitignore` / `migrateClaudeMd` — modify — key entries both repos; the "Never served" row.
+- standalone `initProject` gitignore step (`src/commands/init.ts`) — modify — also writes the project `.gitignore`.
+
+---
+
+## 1. Over-block
+
+**What legitimate inputs does this change reject that it shouldn't?**
+
+- A document the operator placed under one of the listed PREFIXES — e.g. a note saved as
+  `.instar/identity.json.notes.md` or anything inside `.instar/local-state/` — is refused by the
+  Files tab. Spec §Rollback states this cost explicitly: a false positive is fixed by moving
+  the document, never by serving keys. The prefixes are narrow (`identity.json`,
+  `origin-sessions-`, `machine-ssh/`, `local-state/`, …) and every listed directory is one
+  Instar itself owns for key storage.
+- `realpath` failure now 403s instead of 500. A transient EACCES on an allowed file reads as
+  "could not be resolved" rather than an internal error; the file is not served either way,
+  so nothing that used to work stops working — only the status code changes (500 → 403).
+- A multi-link file whose inode equals a listed key file is refused even when reached through
+  an innocent name outside `.instar/`. That is the intended refusal; an unrelated multi-link
+  file (asserted in the unit test) is still served.
+- `list` omits a dangling symlink and a symlink into denied material instead of listing the
+  name. An operator who expected to SEE the dangling name will not; nothing was readable
+  through it before either.
+- `conversations.json`, `trust-profiles.json`, thread history, `AGENT.md`, `config`-adjacent
+  docs: asserted servable in all three tiers (no over-block on the audit surfaces).
+
+---
+
+## 2. Under-block
+
+**What failure modes does this still miss?**
+
+- A key file produced by a path the §5.4 walk does not drive. The walk drives the real init
+  (machine key pair, manifest key, pairing session), the real pairing sealer/installer (the
+  agent identity), and these runtime producers by name: `InvitationManager`,
+  `SecureInvitationManager`, `loadOrCreateDeliveryHmacKey`, `ensureBindTokenSecret`,
+  `ManifestIntegrity`, `MachineSshIdentity`, `WorktreeKeyVault` (flatfile),
+  `RemediationKeyVault` (env-passphrase flatfile) and `TelemetryAuth.provision` — the last
+  two were ADDED after the second-pass review found `remediation-keys.age` and
+  `telemetry/local-secret` neither driven nor listed — plus the relay-token writer and the
+  legacy threadline mirror/inbox key written through the same owner-only writer. This is the
+  producer set a grep for `mode: 0o600` / `writeFileAtomicOwnerOnly` across `src/` yields
+  today; it is a list maintained by audit, not a proof of completeness. A generator added
+  later that writes somewhere new fails the walk only if it is also called from the walk:
+  one wired into init is caught automatically (the walk boots the real init); one reached
+  only at runtime must be added to the walk's step 3 (the test header says so).
+- `telemetry/install-id` (a bare UUID, 0600) and `state/identity-epochs.json` (public
+  verification material, 0600) are excused from the walk by a per-file proof predicate
+  re-run on the live bytes, and stay servable on purpose — the list is kept to key material.
+- A key file written OUTSIDE `.instar/` (e.g. `~/.ssh`) is out of scope by design — the Files
+  tab is jailed to the project directory and the list is `.instar/`-relative.
+- The hard-link check compares the opened inode against the static `KEY_MATERIAL_FILES`
+  (now including `machine/secrets-master.key` and `secrets/passkeys/store.enc`, added on the
+  reviewer's finding) PLUS, on the same rare `nlink > 1` path, a `readdir` of `machine-ssh/`
+  (generation-named `<kind>-ed25519-g<N>` keys) and of the stateDir root for
+  `origin-sessions-<digest>` files — the two name shapes a static list cannot enumerate. What
+  remains outside the inode check: a hard link to a `.superseded-*` / `.invalid-*` / temp
+  sibling of `identity.json` (not enumerated per request). Every such sibling is still refused
+  by every PATH check; only a hard link to it under an innocent name OUTSIDE `.instar/`
+  escapes. Hard links require write access on the same filesystem as the agent home, i.e. the
+  operator's own account — the cost is stated, not hidden.
+- The descriptor proof defeats a symlink swap between check and open; it does not defend
+  against a file being REPLACED IN PLACE (same inode, rewritten bytes) — that is not a
+  confused-deputy problem, it is the operator editing their own file.
+
+---
+
+## 3. Level-of-abstraction fit
+
+This is a low-level, enumerated, deterministic deny at the serving chokepoint, which is the
+right layer: the question "is this byte sequence a private key?" has an exact answer here
+(the file IS the key file by path or inode), so no higher-level reasoning gate should own it.
+The existing primitives are reused rather than re-implemented — `isNeverServed` for the deny,
+`validatePath` for traversal/realpath, `BackupManager`'s prefix set, `FileClassifier`'s
+patterns, `addGitignoreEntry` for migration. The one new abstraction (`keyMaterialPaths.ts`)
+exists so four surfaces read ONE list and cannot drift; the walk test is the instrument that
+can disagree with that list.
+
+---
+
+## 4. Signal vs authority compliance
+
+**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
+
+**Does this change hold blocking authority with brittle logic?**
+
+- [ ] No — this change produces a signal consumed by an existing smart gate.
+- [ ] No — this change has no block/allow surface.
+- [x] Yes — but the logic is an enumerated floor, not a heuristic: exact path prefixes and
+      inode equality, over files Instar itself writes. (Spec §5.1: "Exact-path access control,
+      not a meaning filter — Signal vs. Authority does not apply to an enumerated floor.")
+- [ ] ⚠️ Yes, with brittle logic — STOP.
+
+The deny decides on identity (path prefix, device+inode), never on content interpretation.
+There is nothing to misjudge about a listed path; the only failure class is an INCOMPLETE
+list, and that is covered by the walk test rather than by giving the gate judgment. No config
+key can loosen it (`PATCH /api/files/config` narrows `allowedPaths`; the deny is consulted
+independently) — by design, since a loosening lever would be the first thing a compromised
+operator session reaches for.
+
+---
+
+## 4b. Judgment-point check (Judgment Within Floors standard)
+
+No new static heuristic at a competing-signals decision point. Every decision here is
+enumerable (a listed path, an equal inode) — an invariant, not a judgment.
+
+---
+
+## 5. Interactions
+
+- **Shadowing:** `isNeverServed` already ran before `allowedPaths`; the new prefixes join the
+  same list, so ordering is unchanged. In `list`, the per-entry resolution runs where the
+  `blockedFilenames` + stat-skip used to run; the output shape is identical for every entry
+  that was listed before and is still admissible. In `link`, the full `validatePath` replaces
+  the lighter `checkRelativePathAllowed` pre-check; every refusal the pre-check produced is
+  still produced (the pre-check is the first layer inside `validatePath`), plus the resolved-
+  path refusals. `isNeverEditable` already included `isNeverServed`, so the save route refuses
+  the new prefixes with no change.
+- **Double-fire:** the backup exclusion and the classifier exclusion both apply to the same
+  files; both are "skip", so a double-skip is harmless. The migrator's gitignore step and
+  `ensureGitignore` at init may both write the same entries; both are idempotent (existence
+  check), asserted by the E2E double-run.
+- **Races:** the check-then-serve race is the one this change CLOSES (descriptor proof). The
+  `list` route performs realpath per entry (≤500) — more syscalls than before, bounded by the
+  existing 500-entry cap.
+- **Feedback loops:** none — nothing here writes state that feeds a later decision.
+- **`IDENTITY_AUTO_ACCEPT_PROTECTED_PATHS`** already denied `.instar/machine/` and
+  `.instar/identity.json` on the routes; the new list overlaps it for those two and extends to
+  the rest. Overlap is additive, never contradictory.
+- **Classifier label for `origin-sessions-*`:** these files were classified `exclude`
+  (generated, via `ORIGIN_LOCAL_PROJECT_GLOBS`); the secret check runs first, so they are now
+  `never-sync`. `GitSync` treats the two strategies identically at both callsites (staging skip
+  and conflict resolution), so behaviour is unchanged; only the label and the degradation
+  reason text differ. `tests/unit/telegram-origin/local-custody.test.ts` pinned the old label
+  and is updated to pin the new one for those two files (found by CI shard 4/4).
+
+---
+
+## 6. External surfaces
+
+- Other agents on the same machine: none — the file routes serve this agent's project dir only.
+- Users of the install base: the dashboard Files tab now returns 403 on key files that were
+  previously readable through a symlink or a crafted listing; direct paths were already
+  refused for `identity.json`/`machine/`. A 500 on an unresolvable path becomes a 403. The
+  "Never served" CLAUDE.md row (template + migration) tells the agent to explain a 403 there
+  as correct.
+- External systems: none.
+- Persistent state: `.gitignore` (project) and `.instar/.gitignore` gain entries on update —
+  additive lines, idempotent. No other durable state.
+- Timing/runtime: the descriptor proof relies on `fstat` device+inode — stable on every
+  filesystem Instar runs on (APFS, ext4); on a filesystem that reports `nlink` unreliably the
+  worst case is an extra dozen `stat`s per request, never a false admit.
+- **Operator surface:** no new operator-facing action — the change only refuses. "No
+  operator-facing actions" applies.
+
+---
+
+## 6b. Operator-surface quality (Operator-Surface Quality standard)
+
+No operator surface — not applicable. No `dashboard/*` file is touched; the dashboard Files
+tab receives the same 403 JSON shape it already renders for never-served paths.
+
+---
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+
+**machine-local BY DESIGN**, for a security-boundary reason: key material lives on the disk
+of the machine that holds it, and the deny guards THAT machine's serving, backup, gitignore
+and sync surfaces. The list itself is code (identical on every machine at the same version);
+no state replicates because there is no state. Multi-machine consequence worth stating: the
+gitignore + classifier arms are exactly what keep a key from riding git-sync to a sibling, so
+this change REDUCES cross-machine leakage rather than needing a replication path. No
+user-facing notices (nothing to one-voice-gate), no durable state to strand on transfer, no
+generated URLs (the `link` route mints the same relative dashboard URL it did before and
+refuses for denied paths).
+
+---
+
+## 8. Rollback cost
+
+- **Hot-fix release:** revert the code; ship as the next patch. Spec §Rollback: "no lever by
+  design; a false positive is fixed by moving the document, not by serving keys."
+- **Data migration:** none. The added `.gitignore` lines are inert if the code is reverted and
+  harmless to leave.
+- **Agent state repair:** none. The CLAUDE.md row describes a 403 that, after a revert, would
+  simply stop occurring.
+- **User visibility:** a reverted install would again serve key material through the symlink/
+  listing gaps — that is the regression the floor exists to prevent, so the back-out is a
+  deliberate operator decision, never automatic.
+
+---
+
+## Conclusion
+
+The review produced two rounds of design change. First, the §5.4 walk disagreed with the
+list twice and both disagreements were real — the manifest signing key (`state/.manifest-key`)
+and the machine key pair (`machine/`) were not in the spec's §5.1 enumeration and are now on
+the list, and the standalone init path was writing the project-relative gitignore entries into
+the wrong file (fixed in `init.ts`). Second, the independent second-pass review found two
+producers the walk never drove (`remediation-keys.age`, `telemetry/local-secret`): both are
+now listed on all four surfaces and driven in the walk, two more static names joined the
+inode set, and the hard-link check now enumerates the generation-named SSH keys and the
+origin-session files at request time. The remaining findings are the stated costs (an operator
+document under a listed prefix must be moved; a hard link to an `identity.json` sibling under
+an innocent name outside `.instar/` is not inode-checked) and are recorded in §2. Clear to
+ship once the second-pass reviewer confirms the resolutions.
+
+---
+
+## Second-pass review (if required)
+
+**Reviewer:** reviewer subagent (independent read)
+**Independent read of the artifact: concern**
+
+Independent audit against the diff, `src/core/keyMaterialPaths.ts`, `src/server/fileRoutes.ts`
+(validatePath, openCheckedDescriptor, resolveListEntry, the four handlers) and the three test
+tiers (`tests/unit/file-routes-never-served-key-material.test.ts` re-run: 19/19 green). The
+over-block, signal-vs-authority, §5 Interactions and §7 multi-machine conclusions hold. The
+concern is the §2 under-block inventory and the §5.4 walk's producer coverage: two in-tree
+key producers under `.instar/` are neither driven by the walk nor covered by the list, and the
+artifact's claim that the walk drives "every in-tree generator found by audit" is therefore
+not true as written.
+
+- **Concern 1 — `remediation-keys.age` is served, synced and backed up.**
+  `src/remediation/RemediationKeyVault.ts:392` writes the env-passphrase flat-file key vault
+  to `path.join(stateDir, 'remediation-keys.age')` with mode 0600 (`:280`, `SECURE_FILE_MODE`
+  at `:51`). Probed against the built predicates: `isNeverServed('.instar/remediation-keys.age')`
+  → `false`; `FileClassifier.classify(...)` → `llm` (git-sync WOULD replicate it); it is in no
+  gitignore entry and no backup prefix. It is the same class as `local-state/keys.enc`, which
+  the list does include (`keyMaterialPaths.ts:48,84`). The walk never constructs the vault on
+  that backend, so the "a key file the list does not cover fails the build" guarantee is blind
+  to it. Resolution: add `remediation-keys.age` to `KEY_MATERIAL_PATHS` and `KEY_MATERIAL_FILES`,
+  and drive `RemediationKeyVault` (env-passphrase backend) in the walk's step 3.
+- **Concern 2 — `telemetry/local-secret` is served.** `src/monitoring/TelemetryAuth.ts:28,63`
+  writes a 32-byte HMAC secret to `.instar/telemetry/local-secret` (0600). Probed:
+  `isNeverServed('.instar/telemetry/local-secret')` → `false` (read/download/link/list reach
+  it); the classifier already says `never-sync`, so only the route floor and backup/gitignore
+  are open. The walk does not drive `TelemetryAuth`, and its name predicate (`\.secret$`) would
+  not match `local-secret` even if it did (the 0600 arm would). Resolution: add
+  `telemetry/local-secret` to the list (and `KEY_MATERIAL_FILES`), drive `TelemetryAuth.ensure`
+  in the walk.
+- **Concern 3 — §2 understates the hard-link inode gap.** §2 names only a `.superseded-*`
+  sibling as outside `KEY_MATERIAL_FILES`. Also outside it: `machine/secrets-master.key`
+  (`src/core/SecretStore.ts:120` — the master key for the encrypted secret store), every
+  `machine-ssh/<kind>-ed25519-g<N>` private key (`src/core/MachineSshIdentity.ts:84`, generation-
+  named so not statically enumerable), `secrets/passkeys/store.enc`
+  (`src/core/PasskeyCredentialStore.ts:45`) and the `origin-sessions-<digest>.json` file
+  (`OriginSessionRegistry.ts:57`). All are refused by every PATH check; only a hard link under an
+  innocent name outside `.instar/` escapes (`fileRoutes.ts:337-350` compares the opened inode
+  against `KEY_MATERIAL_FILES` only). Resolution: add `machine/secrets-master.key` and
+  `secrets/passkeys/store.enc` to `KEY_MATERIAL_FILES` (static names), and either readdir
+  `machine-ssh/` on the rare `nlink > 1` path or state the SSH-key and origin-session cases
+  explicitly in §2 as the same operator-write-access cost.
+- **Concern 4 — the "every in-tree generator found by audit" sentence (§2, first bullet).**
+  Rewrite to name the producers actually driven (the walk's step 3 list) and the two above as
+  added, so the artifact does not certify a completeness the grep (`mode: 0o600` /
+  `writeFileAtomicOwnerOnly` across `src/`) does not support.
+
+Non-blocking notes (verified, no change required):
+- Over-block: none found. `conversations.json`, `trust-profiles.json`, thread history,
+  `invitations.json`, `AGENT.md` and ordinary docs stay servable (unit `:92-100`, walk `:273-278`,
+  e2e `:97-103`). The `realpath` non-ENOENT → 403 change (`fileRoutes.ts:292-298`) only
+  re-codes what was a 500 (ELOOP/EACCES); a dangling symlink still answers 404 (lstat succeeds,
+  realpath ENOENT), so no previously-served case stops serving.
+- Under-block through the four routes by PATH: none found. Every handler goes through
+  `validatePath` (requested-path deny at `:220`, resolved-path deny at `:283`, resolved
+  `blockedFilenames` at `:649`/`:992`/`:1060`), `list` admits per entry via `resolveListEntry`
+  (`:368-388`) in both the root and the sub-directory branch, `read`/`download` serve from the
+  proven descriptor (`:678-690`, `:1014-1029`), `link` resolves before minting and its
+  `editable` flag consults the resolved path (`:1074-1077`). `isNeverServed` case-folds
+  (`:151-158`), so the macOS case gap is closed.
+- Signal-vs-authority: an enumerated floor (prefix list + device/inode equality); no heuristic.
+- §5 Interactions and §7 posture match the code: `isNeverEditable` delegates to `isNeverServed`
+  (`:458`), the list is code with no replicated state, the gitignore/classifier arms are what
+  keep the key off a sibling.
+- (f) Deferral scan: neither the artifact nor `upgrades/next/files-never-serve-key-material.md`
+  contains a pattern the pre-commit check matches (`scripts/instar-dev-precommit.js:901-914`:
+  "deferred", "out of scope today/for now", "not in this PR", "follow-up"); the artifact's
+  "out of scope by design" (§2) is not a match, and the check reads the SPEC (`:645,666`), not
+  the artifact.
+
+**Author's resolution of the concerns (same change, before commit):**
+
+- Concern 1 — `remediation-keys.age` added to `KEY_MATERIAL_PATHS` and `KEY_MATERIAL_FILES`
+  (`src/core/keyMaterialPaths.ts`); the walk now drives
+  `RemediationKeyVault.forStateDir(stateDir, { forceBackend: 'env-passphrase', … })` and
+  asserts the file is found.
+- Concern 2 — `telemetry/local-secret` added to both lists; the walk drives
+  `new TelemetryAuth(stateDir).provision()`; `telemetry/install-id` (a bare UUID) is excused by
+  a UUID-shape predicate, re-run on the live bytes, so it stays servable without hiding a key.
+- Concern 3 — `machine/secrets-master.key` and `secrets/passkeys/store.enc` added to
+  `KEY_MATERIAL_FILES`; `openCheckedDescriptor` now builds its inode candidates from the static
+  list PLUS a `readdir` of `machine-ssh/` and of the stateDir root for `origin-sessions-*`
+  (`keyInodeCandidates` in `src/server/fileRoutes.ts`), on the `nlink > 1` path only. §2
+  states the remaining `identity.json`-sibling case as a cost.
+- Concern 4 — the §2 sentence now names the producers the walk drives and says the list is
+  maintained by audit, not a proof of completeness.
+
+**Reviewer re-read after the resolutions: concur**
+
+Each resolution verified from the code, not the description; the walk and unit files re-run
+green together (26/26).
+- Concern 1/2 closed: `remediation-keys.age` and `telemetry/local-secret` are in
+  `KEY_MATERIAL_PATHS` (`src/core/keyMaterialPaths.ts:69,73`) and `KEY_MATERIAL_FILES`
+  (`:99,100`); the walk drives `RemediationKeyVault.forStateDir(..., forceBackend:
+  'env-passphrase')` and `new TelemetryAuth(stateDir).provision()`
+  (`tests/integration/file-routes-never-served-walk.test.ts:164-165`) and asserts both files
+  are found (`:220-221`). `telemetry/install-id` is excused only while its live bytes match the
+  UUID-shape predicate (`:71`, re-run at `:192-195`), so the excuse cannot rot into hiding a key.
+- Concern 3 closed: `machine/secrets-master.key` and `secrets/passkeys/store.enc` are in
+  `KEY_MATERIAL_FILES` (`:97-98`); `openCheckedDescriptor` now iterates
+  `keyInodeCandidates(stateDir)` (`src/server/fileRoutes.ts:339`, builder at `:365-378`) = the
+  static list + a `readdir` of `machine-ssh/` (`KEY_MATERIAL_DYNAMIC_DIRS`,
+  `keyMaterialPaths.ts:111`) + stateDir-root names starting `origin-sessions-`
+  (`KEY_MATERIAL_ROOT_NAME_PREFIXES`, `:112`), on the `nlink > 1` path only; a missing dir is
+  skipped, never a 500.
+- Concern 4 closed: §2 now names the driven producers and calls the list audit-maintained,
+  not a completeness proof.
+- Non-blocking: the `machine-ssh/` readdir also enumerates its non-key files
+  (`directional-proofs.json`, `peer-admissions.json`, `identity.json` metadata) as inode
+  candidates — a hard link to one of those is refused too. That is an over-refusal on a
+  never-served directory, not an admit, so it is within the stated floor.
+
+---
+
+## Evidence pointers
+
+- `tests/unit/file-routes-never-served-key-material.test.ts` — static parity + route behaviour.
+- `tests/integration/file-routes-never-served-walk.test.ts` — the §5.4 walk over a real init + pair (7 tests).
+- `tests/e2e/files-never-serve-key-material-alive.test.ts` — production boot, feature-is-alive, migration idempotency.
+- Existing coverage re-run green: `fileRoutes-never-served`, `fileRoutes-link-allowed-paths`,
+  `file-editor-never-editable-bypasses`, `identity-protected-files-routes`, `file-viewer-e2e`,
+  `BackupManager-*`, `backup-manager`, `file-classifier`, `PostUpdateMigrator-gitignore`.
+
+---
+
+## Class-Closure Declaration (display-only mirror)
+
+No agent-authored-artifact defect — not applicable. This change adds no self-triggered
+controller (no loop, monitor, sentinel, reaper, scheduler or recovery path; it only refuses
+requests synchronously), so the `unbounded-self-action` class is not touched either.

package/upgrades/side-effects/telegram-origin-forward-to-holder.md

@@ -0,0 +1,151 @@
+# Side-Effects Review — Telegram origin: a reply from a non-lease machine is forwarded to the holder; a failed forward is held durably and reported (ACT-058)
+
+**Version / slug:** `telegram-origin-forward-to-holder`
+**Date:** `2026-10-09`
+**Author:** Echo (builder for CMT-706, §4 of `docs/specs/a2a-single-agent-identity.md`)
+**Second-pass reviewer:** Echo review subagent (independent read; verdict appended below)
+
+**Spec:** `docs/specs/a2a-single-agent-identity.md` §4 (converged + approved, ELI16 beside it). This PR builds §4 ONLY; §1/§2/§3/§5 are other builders' PRs on the same spec.
+**Files:** `src/messaging/telegram-origin/OriginForwardToHolder.ts` (new), `OriginMesh.ts`, `OriginMeshRelay.ts`, `OriginStore.ts`, `OriginStore.worker.ts`, `OriginStoreBackend.ts`, `StoreTypes.ts`, `TelegramOriginBoot.ts`, `TelegramOriginRuntime.ts`, `TelegramOriginService.ts`, `OriginConfig.ts`, `OriginAwareness.ts`, `types.ts`, `src/messaging/TelegramAdapter.ts`, `src/commands/server.ts`, `src/server/routes.ts`, `src/scaffold/templates.ts`, `src/core/PostUpdateMigrator.ts`, `src/testing/selfActionRegistry.ts`, three new test files + one updated migration test.
+
+## Summary of the change
+
+Today a Telegram reply authored on a machine that holds the bot token but NOT the serving lease is refused by `authorize` and parked in an in-memory `destination-not-authorized` hold: silent to the user, lost on restart, and replayed every 15 min only to be refused again while the machine stays standby (the 2026-10-08 incident). §4 makes that machine FORWARD the sealed operation to the lease holder over the existing signed origin mesh (`capabilities` + `submit`), with `executionOwnerMachineId = holder`; the holder now runs the SAME lease check the direct path runs and answers a typed `not-lease-holder`. The reply request runs a bounded lease-settling window (≤15 s) plus ONE forward attempt (≤30 s); any failure becomes a DURABLE hold through the existing `recordOperationState('held')` with a new `hold_reason = lease-not-held` (+ a `holdDetail` carrying what recovery needs), the fixed outage notice goes THROUGH the holder, and ONE `high` attention item `telegram-origin-held:<topic>` is raised (three topics on one machine within an hour collapse to one). Recovery re-forwards the SAME operation (quick ladder at +10 s/+20 s from the 5 s boot tick, then the existing 15-min schedule); an attempt the holder never confirmed is resolved at that holder's `receipt`, never re-sent blind; after a lease move the old record is durably SUPERSEDED and a new one bound to the new holder lands once. Expiry goes through the existing `expireOperation` and is reported once with honest wording. `/health → telegramOrigin.heldForward`, `/telegram/origins/status.held[]` (now a union of the in-memory cache and the durable rows, each with its reason) are the read surfaces. The forward is switchable (`messaging[].config.messageOrigin.forwardToHolder.enabled`, default true, live); the durable held state, its reason and the notice are NOT behind the flag.
+
+A latent bug found by the integration tier and fixed here: the store's recovery reconstruction added `allowedDerivations: []` to an ordinary child, which the original sealed admission omits, so every store-reconstructed replay failed the holder's seal check (`origin-plan-invalid`). The reconstruction now reproduces the sealed shape exactly.
+
+## Decision-point inventory
+
+- `TelegramAdapter.sendToTopic` / `willRelay()` — **modify** — the send decision becomes "no usable token OR (pool enabled AND this machine does not hold the lease)". `willRelay()` is true only for a DEFINITE forward (a healthy peer holds the lease); a still-settling lease keeps the local tone gate.
+- `OriginMesh.handleOriginMesh` (holder-side `submit`) — **modify** — adds the lease check (`not-lease-holder`, typed, retryable) AFTER `execution-owner-mismatch` and BEFORE any store write. It executed unchecked before.
+- `TelegramOriginService.#holdUnauthorized` — **add** — names WHY `authorize` refused: `lease-not-held` (durable, recoverable, notified) vs `destination-not-authorized` (foreign chat — unchanged, never forwarded).
+- `OriginForwardToHolder.forwardReplyToHolder` — **add** — settle → one attempt → durable hold. `recoverForwardedHold` — **add** — receipt-first on outcome-unknown; same-operation re-forward; supersede on holder change. Pure orchestration; every side effect is injected.
+- `OriginStoreBackend.supersedeOperation` / `recordForwardedAcceptance` / `listHeldOperations` / `heldForwardAdmissions` — **add** — durable state transitions; `supersede` refuses a row with any child not `queued` or any claimed entry.
+- `TelegramOriginRuntime.runForwardLadder` — **add** — the 5 s tick driver, single-flight with `recoverHeld`.
+- Attention item raise (`telegram-origin-held:<topic>` / aggregate) — **add** — signal only; hub-only, collapsed.
+
+---
+
+## 1. Over-block
+
+- **A standby whose lease view is briefly stale** (holder expired but not yet re-elected) is `settling`: the request waits up to 15 s before anything is written. A legitimate local send on the machine that is ABOUT to win the lease is delayed by at most that window, never refused: a window that settles to self sends locally (`OriginForwardSettledLocallyError` → the adapter continues the local path).
+- **A standby that cannot name any holder for 15 s** holds durably (`lastAttempt: unsettled`) rather than sending locally. This is the spec's deliberate choice: a dead holder whose lease has not expired must not be bypassed by a bootleg local send. The hold is reported and the ladder/schedule carry it; the first real holder is bound by the supersede path.
+- **`willRelay()` returns true for a DEFINITE forward**, which skips the LOCAL tone gate (the holder's full outbound gate still runs on every forwarded operation — `authorizeSendPolicyDispatch` + `runtime.service.admit` + the holder's own policy). If the lease then settles on THIS machine (or the decision flips between the route's read and the send), the adapter refuses to send locally with a typed `OriginForwardSettledLocallyError` when the caller passed `gateSkippedForRelay`; the route catches it, runs the gate, and re-sends. No message is gated zero times (second-pass finding 3).
+- **Media, edits and pins from a standby** are not forwarded in v1 (spec §4.1): they take the durable, reported hold. Over-block by design; the spec names them.
+
+## 2. Under-block
+
+- **A holder that accepts a forward but whose Telegram call fails after admit** is the holder's own existing outbox problem (its recovery), not this layer's; the standby's `receipt` RPC will read the holder's state honestly.
+- **A transport timeout on `submit` is `outcome-unknown`**: never retried, resolved at the SAME holder's `receipt` on the next step. If the holder stays unreachable for the whole 6 h deadline, the row expires `effect-unknown` and is reported with the "may or may not have been delivered" wording. Exactly one copy may have reached the user; a second is structurally impossible on this path.
+- **The in-memory `heldStatus` cache can list a row the store has since resolved** for one refresh interval (≤30 s). The union dedupes on operation id and the durable row wins the `hold_reason`; the dashboard read is observability only.
+- **A standby with the forward switched OFF, a pool-dark two-machine agent, or a lease lost between the adapter's decision and `authorize`** takes the DIRECT-path hold: `#holdUnauthorized` records the row `held` with `lease-not-held`. Its sealed owner is this machine, so it cannot be forwarded; `recoverHeld` RE-ADMITS it the moment `holdsLease()` is true again and the ordinary replay delivers it (the claim fence admits `admitted|partial` only — without the re-admit this was a guaranteed 6 h loss, second-pass finding 1). While not the holder it waits (no reserve spent), and it is reported ONCE via `onLeaseHoldObserved` (notice through the holder if one is reachable, else the collapsed item). The kill switch therefore restores today's local wait minus the silence (the spec's point).
+- **A refusal that names our operation id** (the holder's `admit` ran, or its outbox/credential refused after it) is custody at the holder: treated as `outcome-unknown`, resolved at that holder's `receipt`, never re-forwarded; a receipt of `admitted`/`held`/`partial` there is `owned-by-holder` (its own recovery delivers) and keeps the row without re-sending (finding 4). Only `no-record` (a new distinct receipt answer) / `not-admitted` / terminal non-delivery frees a re-forward; `origin-receipt-unavailable` is ambiguous (a store outage looks like absence) and keeps waiting.
+
+## 3. Level-of-abstraction fit
+
+Right layer. The forward rides the EXISTING signed origin mesh (`capabilities` + `submit` + `receipt`) and the EXISTING durable operation-state writer, recovery scheduler, expiry path and attention queue; nothing is re-implemented. `submitOriginToHolder` is ONE transport shared by the request-time relay (`relayOriginBot`) and the recovery re-forward, so "what a refusal means" cannot drift between the two. The holder-side lease check is the SAME predicate the direct path uses (`holdsLease` threaded from boot). The quick ladder is scheduling state stored in the row's own `holdDetail`, not a second queue.
+
+## 4. Signal vs authority compliance
+
+**Required reference:** [docs/signal-vs-authority.md](../../docs/signal-vs-authority.md)
+
+- [x] No — this change produces a signal consumed by an existing smart gate.
+- [ ] No — this change has no block/allow surface.
+- [ ] Yes — but the logic is a smart gate with full conversational context.
+- [ ] ⚠️ Yes, with brittle logic.
+
+The only new refusal (`not-lease-holder`) is a deterministic ownership invariant (the lease), not a content judgment, and it is TYPED and RETRYABLE — the forwarding side re-resolves the holder and tries again; it never drops the message. Everything content-related (tone gate, send policy, credential wall) stays where it was: on the holder's full gate for every forwarded operation. The attention item and the outage notice are signals. No brittle logic holds blocking authority.
+
+## 4b. Judgment-point check (Judgment Within Floors standard)
+
+No new static heuristic at a competing-signals decision point. The lease is an invariant (one holder, fenced epoch), the settle window and the ladder delays are safety bounds on an irreversible action (a user-visible send), and the ONLY competing-signal choice — "did the old holder deliver it?" — is resolved by asking that holder (`receipt`), never by a heuristic; an unanswerable question stays held, never guessed.
+
+---
+
+## 5. Interactions
+
+- **Shadowing:** the holder-side lease check runs AFTER `execution-owner-mismatch` (kept — the receipt dedupe depends on it) and BEFORE `origin-plan-invalid` / store writes, so a refused submit leaves NO record at the holder. The standby's `#holdUnauthorized` runs only where `destination-not-authorized` ran before; with `holdsLease()` true (single machine, no coordinator) behaviour is byte-identical.
+- **Double-fire:** `runForwardLadder` (5 s tick) and `recoverHeld` (sentinel, ~5 min) share the runtime's `recovering` flag (single-flight). Both can select the same `held` row (the ladder never calls `reserveRecoveryAttempt`), but the holder dedupes on operation id (idempotent `admitInternal` + its claim fence), so a double visit costs one refused RPC at most, never a second post. The LOCAL send path (lease came back here) has no holder fence, so it writes a durable `local-sent` marker BEFORE sending and refuses any later send of that row — a failed `resolve` or a crash after the send can only ever leave an honest "may or may not" expiry, never a second copy (finding 2). The notice is sent through the holder and is itself an origin operation (dedup + policy at the holder).
+- **Races:** the holder change is ONE store transaction (`supersedeWithAdmission`): refuse unless the old row is still plainly held (every child `queued`, nothing `claimed`), admit the NEW sealed admission, record it `held` with its reason + detail, mark the old row `superseded` linked to the new id. Either both rows move or neither does; a refused supersede admits the new operation NOWHERE and forwards nothing (finding 5). `recordForwardedAcceptance` refuses non-queued children. The in-request `hold` returns the state writer's boolean; a `false` (claimed entry) is audited `hold-not-recorded` and the row stays `admitted` for the ordinary replay (finding 6).
+- **Feedback loops:** a held forward raises one deduped item and the fixed notice ONCE at hold time (never on each ladder step). Attempts are bounded by the ladder (2) + the 15-min schedule + the 6 h deadline (modeled in `selfActionRegistry` as `telegram-origin-forward-ladder`, bound 27 per operation, horizon-independent).
+
+## 6. External surfaces
+
+- **Other agents / users:** a user on a standby-owned topic now receives their reply (via the holder) instead of silence; on failure they receive the fixed notice (through the holder, so it carries the normal origin footer), never free text.
+- **External systems:** Telegram sees the SAME single `sendMessage`, executed by the holder's token. A new mesh refusal reason (`not-lease-holder`) and two new response fields (`deliveryMachineId`, `forwardedFromMachine`) are ADDITIVE; an older peer ignores them. An older standby that never sends `expectedOwner` is still answered correctly.
+- **Persistent state:** three additive nullable columns on `telegram_origin_operations` (`hold_reason`, `hold_detail_json`, `hold_expiry_reported_at`; `ALTER TABLE … ADD COLUMN` guarded by `PRAGMA table_info`), a new terminal operation state `superseded` (archivable/cleanable like `expired`), new child/entry state `superseded`. An older reader treats a held row with an unknown reason as the ordinary hold (additive). Audit file `logs/telegram-origin-held.jsonl` (content-free rows: ids, reasons, phases).
+- **Timing:** the reply request is bounded at settle (≤15 s) + one attempt (≤30 s: per-RPC timeout clamped to 15 s so `capabilities`+`submit` fit) + the notice through the holder (three RPCs at 5 s each — `relayOriginBot`'s own `capabilities` plus `submitOriginToHolder`'s `capabilities`+`submit` — ≤15 s): worst case ≈60 s, under the route's 120 s, so a caller never times out before the hold is written and re-runs with a NEW operation id (finding 7).
+- **Operator surface (Mobile-Complete):** no new operator ACTION. The read surfaces are the existing dashboard Message-origins tab (held listing now carries `hold_reason`) and the attention hub item. Nothing PIN-gated was added.
+
+## 6b. Operator-surface quality
+
+No operator surface file touched — not applicable (no `dashboard/*` markup changed; the held listing's new fields ride the existing status JSON the tab already renders).
+
+## 7. Multi-machine posture (Cross-Machine Coherence)
+
+**proxied-on-read + machine-local durable state by design.** The held row lives on the machine that authored the reply (it is that machine's outbox; the sealed payload is there), and the pool-wide answer is the existing `?scope=pool` origin status/audit merge plus the attention hub. The forward itself IS the multi-machine mechanism. One-voice: the notice and the item are raised by the holding standby ONCE per hold (collapsed per machine per hour); the holder sends nothing of its own. Topic transfer: a held row is bound to an execution owner, and a lease move is handled by the supersede path (old row terminal + linked, new row bound to the new owner); it does not strand. URLs: none generated. Single machine: `holdsLease()` is true with no coordinator, `holderForwardPolicy` is only wired when a mesh identity exists → strict no-op.
+
+## 8. Rollback cost
+
+- **Kill switch (live, no restart):** `messaging[].config.messageOrigin.forwardToHolder.enabled: false` → no forward; a non-holder reply becomes today's local wait, now DURABLE (`held`, `lease-not-held`), reported once, and RE-ADMITTED + replayed when the lease returns (the pre-PR row was replayed every 15 min and refused while standby; the behaviour is unchanged, the silence is gone). The holder-side lease check stays (it is a safety floor; the direct path already ran it).
+- **Code revert:** pure revert + patch release. The three columns are nullable and ignored by older code; `superseded` rows are terminal and archived by the existing retention; `logs/telegram-origin-held.jsonl` is append-only observability. No data migration, no agent state repair. Rows held `lease-not-held` at revert time stay listed in the durable held listing and expire on their normal deadline.
+
+---
+
+## Conclusion
+
+The review changed two things in the inherited draft: (1) the in-request ladder (3×10 s inside the reply request) was moved OUT of the request to the recovery tick, per the converged §4.2 wording (one attempt in-request, +10 s/+20 s from the tick, then the schedule), so the route can never time out before the hold is written; (2) the holder-change path was changed from "re-bind the same operation id" to the spec's supersede, which keeps the holder-side `execution-owner-mismatch` guard meaningful. The integration tier surfaced a pre-existing reconstruction bug that made every store-replayed forward fail the holder's seal; fixed. The second-pass review then found three blocking defects and three cheap ones (below); all six were fixed before commit: the direct-path hold is re-admitted when the lease returns and reported once; the local re-send is fenced by a durable `local-sent` marker; a skipped gate is re-run through a typed error; holder custody is receipt-first with a distinct `no-record` answer; the supersede is one atomic store transaction that forwards nothing when refused; the hold boolean is honoured and audited; the notice RPCs are shortened. Tests cover each (unit + the integration direct-path/supersede/custody scenarios).
+
+---
+
+## Second-pass review (if required)
+
+**Reviewer:** Echo review subagent (independent read)
+**Independent read of the artifact: concur**
+
+- **CONCERN — a direct-path `lease-not-held` hold is now a guaranteed 6 h loss (Q2, §2 bullet 4, §8).** `TelegramOriginService.ts:400-404` `#holdUnauthorized` flips the local row to `state='held'`; `OriginStoreBackend.ts` `claim()` (~:534) admits only `admitted|partial`, and nothing ever writes `admitted` back (grep: zero callers). The local replay (`TelegramOriginRuntime.ts:452-466` → `OriginBotEgress.ts:114` → `executePreparedBot` → claim) therefore answers `outbox-not-ready` every tick until the 6 h expiry. This path is taken with the kill switch OFF, on a DEFAULT pool-dark two-machine agent (`server.ts:26242` returns `'local'` when `_sessionPoolStage()==='dark'`), and when the lease is lost between the adapter decision and `authorize`. Before this PR the row stayed `admitted` and was delivered once the lease returned (the old reason was in the recoverable list, `TelegramOriginService.ts:416` pre-diff). No notice/item fires on that path either: `TelegramOriginRuntime.ts:137-139` excludes `lease-not-held`. Resolution: in `recoverHeld`'s local branch re-admit a `lease-not-held` owner-self row (`recordOperationState({state:'admitted'})`) once `holdsLease()` is true (or do not flip state in `#holdUnauthorized`), and raise the notice/item there.
+- **CONCERN — the local-send recovery path can double-post (Q1).** `OriginForwardToHolder.ts:299-304`: route `self` → `sendLocal` = a NEW origin op via `telegram.sendToTopic` (`server.ts:26274-26277`, random op id, no logical-send key) → `resolve`, whose result is ignored (:302). `runForwardLadder` (`TelegramOriginRuntime.ts:321-331`) reserves nothing before the attempt — `nextAt` advances only inside `retain` — so if `resolve` throws (store worker restart) or returns false the next 5 s tick sends again. The holder's claim fence protects forwards; nothing fences the local send. Resolution: derive the local op id from the held row via the logical-send key so a repeat replays the receipt (`TelegramOriginService.ts:486-492`), or rehold `lastAttempt:'local-sent'` BEFORE the send and refuse a second.
+- **CONCERN — a message can be gated zero times (Q4, §1 bullet 3).** `routes.ts:17377-17384` skips `checkOutboundMessage` AND the credential wall when `willRelay()` is true; `TelegramAdapter.ts:1413` re-reads `decide()` later and the relay may throw `OriginForwardSettledLocallyError` (`server.ts:26294`), after which the send proceeds locally (`TelegramAdapter.ts:1444-1447`) with no gate. A lease move between the two reads is the ancestor incident's own shape. Resolution: the route passes `gatedLocally:false`; the adapter refuses a local fallback in that case with a typed error the route answers by gating and retrying.
+- **False expiry report.** A holder post-admit refusal (`credential-capacity-unavailable`, `outbox-not-ready`) leaves the holder's row `admitted`; the holder's OWN `recoverHeld` delivers it (`TelegramOriginRuntime.ts:452-466`), but the standby consults `receipt` only when `lastAttempt==='outcome-unknown'` (`OriginForwardToHolder.ts:286`); every re-forward then hits the claim fence until expiry → "I could not deliver my reply" for a delivered reply, and `/health.heldForward` stays non-zero 6 h. Resolution: receipt-first for any attempt that reached the holder's `admit` (its response carries `operationId`, `OriginMesh.ts:140`).
+- `recoverForwardedHold` forwards `next` even when `supersede` returned false (`OriginForwardToHolder.ts:328-330`); a refusal means the old row left `queued` or is claimed, i.e. may be delivered. Abort the forward of `next` on `superseded===false`.
+- `hold` ignores `recordOperationState`'s boolean (`server.ts:26232`); a `false` (claimed entry) leaves an `admitted` row with no reason or detail and returns as if held.
+- §6 timing is understated: the notice via `relayOriginBot` (`OriginMeshRelay.ts:24,57`) adds up to three more 15 s RPCs (its own `capabilities` is repeated inside `submitOriginToHolder`), worst case ≈90 s — still under the route's 120 s.
+- Summary's "never retried" is inaccurate: the old `destination-not-authorized` row was `admitted` and replayed every 15 min (retried, refused while standby) — which is exactly what makes bullet 1 a regression.
+- **Verified true:** Q3 — lease check `OriginMesh.ts:118` sits after `execution-owner-mismatch` (:112) and before `putVerifiedEvidence`/`admit` (:128-129). Holder dedupe = idempotent `admitInternal` (`inserted:false`) + the claim fence reached through `OriginBotEgress.ts:114`. Q5 — `MultiMachineCoordinator.ts:1018` falls back to `_role==='awake'` (:401 on a single machine); `holderForwardPolicy` is wired only with `meshSelfId` (`server.ts:26240`) and returns `'local'` when the pool is dark. Q6 — the only consumer of reconstructed admissions is `recoverHeld`; `allowedDerivations` readers use `?.includes` (`OriginBrowserRenewal.ts:52`, `OriginBotCompanion.ts:15`) and non-empty arrays round-trip unchanged — safe.
+- **Recommendation:** do not ship until bullets 1-3 are fixed (1 is a regression on the default config; 2 and 3 break the "second copy structurally impossible" and "never gated zero times" claims); 4-6 are cheap and should ride the same PR.
+
+**Author's resolution (all findings fixed in this PR before commit):**
+- Finding 1 → `TelegramOriginRuntime.recoverHeld` local branch: a durable `lease-not-held` owner-self row is skipped while `holdsLease()` is false (no reserve spent) and re-admitted (`recordOperationState({state:'admitted'})`) the moment it is true, then replayed through the ordinary path (`authorize` afresh). `refreshHeldForward` reports each such row ONCE through the new `onLeaseHoldObserved` hook (server: notice via the holder when reachable, else the collapsed item). Integration: "a DIRECT-path lease hold is re-admitted and delivered … once its lease returns" (+ once-only hook).
+- Finding 2 → `recoverForwardedHold` writes `lastAttempt:'local-sent'` via `rehold` BEFORE `sendLocal`, refuses any later send of a `local-sent` row, honours `resolve`'s boolean in the audit; expiry wording treats `local-sent` as "may or may not". Unit: the two local-sent tests.
+- Finding 3 → `TelegramAdapter.sendToTopic` option `gateSkippedForRelay`: throws `OriginForwardSettledLocallyError` instead of sending locally when the route skipped its gate; `/telegram/reply` catches it, runs `gateLocally()` (tone gate + wall, releasing the in-flight reservation on a block) and re-sends with the flag off. Unit: the gateSkippedForRelay adapter test.
+- Finding 4 → `submitOriginToHolder`: a refusal naming our operation id is `outcome-unknown` + `admittedAtHolder`; `not-lease-holder` no longer carries an operation id; the holder's `receipt` answers `no-record` for an unknown id (distinct from `origin-receipt-unavailable`); the standby maps `admitted/held/partial` to `owned-by-holder` (retain) and only definite non-admission to a re-forward. Unit: custody + owned-by-holder tests; integration: `no-record`.
+- Finding 5 → `OriginStoreBackend.supersedeWithAdmission` (one transaction; refused ⇒ nothing admitted, nothing forwarded). Unit: store + "REFUSED supersede forwards NOTHING".
+- Finding 6 → `hold` returns the boolean; `forwardReplyToHolder` audits `hold-not-recorded`.
+- Finding 7 → notice RPCs at 5 s (§6 timing corrected to ≈60 s worst case). Finding 8 → Summary corrected.
+
+**Re-review (after the author's fixes) — verified against the working tree:**
+- F1 ✓ `TelegramOriginRuntime.ts:478-485`: a durable `lease-not-held` owner-self row is skipped (no reserve) while `holdsLease()` is false and re-admitted (`recordOperationState({state:'admitted'})`, which clears the reason) when true, then replayed through `authorize`; `refreshHeldForward` (:310-321) reports each direct row once via `onLeaseHoldObserved`; `server.ts:26292-26303` sends the notice through the holder when a peer holds the lease and the switch is on, else the collapsed item.
+- F2 ✓ `OriginForwardToHolder.ts` recovery: `rehold(lastAttempt:'local-sent')` lands BEFORE `sendLocal`; a `local-sent` row is retained and never sent again; `resolve`'s boolean is audited; `expiredForwardWording` treats `local-sent` as "may or may not".
+- F3 ✓ `TelegramAdapter.ts:1421` throws `OriginForwardSettledLocallyError` when `gateSkippedForRelay` and the route is now `'local'`; :1453 rethrows a settle-to-self; `routes.ts:17455-17464` catches it, runs `gateLocally()`, releases the content reservation on a block, re-sends with the flag off.
+- F4 ✓ `submitOriginToHolder`: a refusal carrying our operation id → `outcome-unknown` + `admittedAtHolder`; `OriginMesh.ts:124-127` `not-lease-holder` carries no id; receipt answers `no-record` for an unknown id (:55-59); `server.ts:26266-26273` maps `admitted/held/partial/accepted-unconfirmed` → `owned-by-holder` (retain), only definite non-admission → re-forward, `origin-receipt-unavailable` → unreachable.
+- F5 ✓ `OriginStoreBackend.supersedeWithAdmission` is one `db.transaction` (preconditions → `admitInternal` + hold → retire old); `recoverForwardedHold` returns `'retained'` without submitting when it is false. F6 ✓ `server.ts:26231-26234` returns the boolean; `OriginForwardToHolder.ts:243-244` audits `hold-not-recorded`. F7 ✓ `server.ts:26242` notice RPCs at `sendToHolder(holder, 5_000)` → ≈60 s worst case.
+- Residual (non-blocking): a `sendLocal` that throws BEFORE the ordinary path admits its own durable op (advisory refusal, pre-admit hold) leaves the row `local-sent` → expires "may or may not" though nothing was sent (safe direction, reported); `#observedLeaseHolds` is in-memory, so a still-held direct row is re-reported once per restart (item id dedups); `supersedeWithAdmission` bypasses `service.admit`'s `putVerifiedEvidence` for the new self-sealed row (audit-only).
+- Final verdict: **concur** — no double-post path, no silent loss, no zero-gate path remains that I could trace.
+
+---
+
+## Evidence pointers
+
+- `tests/unit/telegram-origin-forward-on-standby.test.ts` — 46 tests: settling states, settle window, one-attempt request, ladder state, recovery (same op / supersede / receipt-first), transport meanings, item collapse, expiry wording, config switch + array-aware migration, durable store rows (reason, acceptance, expiry-reported-once, ladder candidates, supersede), service `lease-not-held` vs `destination-not-authorized`, adapter send decision.
+- `tests/integration/telegram-origin-forward-on-standby.test.ts` — 4 tests over the REAL signed mesh HTTP pipeline + real stores/routes: lands via holder (`forwardedFromMachine`); `not-lease-holder` → one attempt → ladder step lands once; lease move → superseded + lands once via the new holder; holder down → 409 `telegram-origin-held {lease-not-held}` on status + `/health` → delivered once by the schedule; notice via holder.
+- `tests/e2e/telegram-origin-forward-lifecycle.test.ts` — 3 tests on the production init path (`bootTelegramOrigin` + `createRoutes`): feature alive (200, never 503), `lease-not-held` durable across a runtime restart, wiring integrity of the lease predicate; migration parity lands once + idempotent; operator opt-out survives.
+- `tests/unit/self-action-convergence.test.ts` — the ratchet proves `telegram-origin-forward-ladder` settles (≤27 per operation, horizon-independent, restart-safe).
+
+---
+
+## Class-Closure Declaration (display-only mirror)
+
+- **`defectClass`:** `unbounded-self-action` — this change ADDS a self-triggered retry controller (the forward ladder + schedule re-forward).
+- **`closure`:** `guard`
+- **`guardEvidence`:** `{ enforcementType: ratchet, citation: tests/unit/self-action-convergence.test.ts, howCaught: "control-loop edge = a held forward row whose holdDetail.ladder.nextAt is due (5 s tick) or whose 15-min reserveRecoveryAttempt interval elapsed; steady-state bound = 1 in-request + 2 ladder + ⌊6 h / 15 min⌋ = 27 attempts per operation, then expireOperation makes the row terminal so nothing fires again (count does not scale with the horizon); settling brake = the ladder state and the schedule interval are persisted in the row (restart-safe), the holder dedupes on operation id so a double visit never double-posts, and a holder change supersedes (one durable row at a time) instead of fanning out" }`
+- **`gap`:** not applicable.