fix(bin): retire public follow-ups in remote homes

[kunchenguid]

Intent

Fix a fundamental design gap in bin/fm-public-followup.sh: retire can never complete for a public-followup loop whose work lives in a REMOTE secondmate home, and --force does not cover the failing step.

Reported symptom: 'fm-public-followup.sh retire pf-backpass-hermes --reason ...' (state=delivered, work_home=secondmate:mini-default, a REMOTE route) dies with 'could not clear the legacy X link ... retained for reconciliation', so the loop can never be retired. deliver hit the same step AFTER posting the public reply, stranding the loop at posted with the reply already public.

Root cause: clear_public_followup_link() required an absolute recorded work_home_path for a 'secondmate:*' work home, but a REMOTE secondmate route records work_home_path= (empty) at registration because a remote home has no local path on this machine.

Delivered work, in the order the user authorized it:

1. The clear now runs in the remote home over that route's transport via bin/fm-on.sh, with the established unknown-completion semantics (fm-on.sh passes ssh's status through; 255 means completion unknown, so the close refuses and retains rather than reporting success or a definite failure, matching bin/fm-teardown.sh and bin/fm-remote-readiness-lib.sh). Route placement is decided from data/secondmates.md BEFORE any local path is consulted, so a same-named local directory can never stand in for a remote home. The user explicitly REJECTED the alternative of persisting route identity in the registration record, because it would not retire the registrations already stuck on disk with no route recorded, which is the reported bug.

2. Identity guard, authorized after review: the remote clear verifies the target's Relay request identity against the registration's existing request_id before mutating. This closes a reassignment hazard where a reused stable secondmate ID could clear an unrelated replacement home's link. No new durable registration data was added; the registration's existing request_id is the only identity source.

3. Guarded-mode strictness, authorized after further review: readable state with no link succeeds (nothing to mutate); readable state with a matching link is cleared; identity mismatch, unreadable or unsafe state, non-writable state, and unknown transport completion all REFUSE through the existing retained-for-reconciliation path. Never clear on uncertainty, and never report success for a clear that did not happen.

4. Bounded lock wait, authorized explicitly as a reliability fix at cause after an advisory reviewer finding was verified against the code: the writability precondition narrows but cannot close the wedge window, because the parent can turn non-writable between that check and lock creation and a live lock holder is indistinguishable from it at the acquire. fm_lock_acquire_wait is an unbounded 'while ! try; do sleep 0.1; done', so either case retried forever and deliver/retire WEDGED with nothing reported. The guarded clear now acquires through fm_lock_acquire_wait_bounded (the primitive main gained in fix(bin): bound wake drain presentation lock waits #3475), with FMX_LINK_CLEAR_LOCK_TIMEOUT defaulting to 10 seconds, and refuses on timeout. A wedge is worse than either outcome the guard defines, and this path runs unattended over the transport. Current main was merged in to obtain that primitive.

Deliberate decisions a reviewer reading only the diff would not know:

• Unguarded local callers deliberately keep the ordinary UNBOUNDED wait. Only guarded mode is bounded. This is required: the local path must behave exactly as today, and two existing tests assert its exact refusal text.
• The bounded primitive's header comment previously claimed presentation-only scope. It was corrected to name this second authorized caller. Nothing else in the shared lock infrastructure was changed, deliberately.
• Every LOCAL refusal message is byte-identical to before the branch; pf_link_clear_note prints nothing for any non-255 code precisely to preserve that.
• --force is deliberately UNCHANGED throughout. It governs ONLY the unresolved-obligation refusal and does NOT cover the link clear or any of these guards; a link still verifiably in place keeps the loop open either way. That is pre-existing behavior, preserved on purpose, not an oversight.
• A remote home running an older Firstmate will not recognize the guarded clear flag and fails closed through the same retained-for-reconciliation message. There is deliberately NO unguarded fallback, since a fallback would defeat the guard.

Known residual, deliberately deferred by the user to a separate follow-up ship item and NOT to be fixed here:

• Route placement resolution is binary, so an unreadable or malformed secondmate registry falls through to the local branch instead of refusing. The user weighed this and chose to ship: the hazard PRE-DATES this branch (before it, that case went local unconditionally with the registry never consulted at all), this change narrows it to the registry-unreadable window, and the tri-state remedy would change LOCAL behavior for malformed registries, which collides with the standing 'local behaves exactly as today' constraint.
• The narrower concurrent-publisher gap on the no-link path is filed on that same follow-up item.

Constraints honored throughout: bash 3.2 safe (macOS default), no bash-4+ constructs; bin/*.sh shellcheck-clean via bin/fm-lint.sh; one sentence per line in tracked Markdown with plain dashes, never em dashes; tests colocated in tests/ extending the existing suite rather than a new runner; the maintainer-verification record docs/verification/public-followup.md updated because behavior changed; and no co-author trailer of any kind on any commit.

Acceptance criteria met: the bug was reproduced END-TO-END FIRST (a registration with a REMOTE secondmate work home and an empty work_home_path, failing before and completing after); local-secondmate and main work-home closes behave identically to before; and the regressions exercise the remote route hermetically, faking only the ssh binary at the FM_SSH_BIN process seam (the seam tests/fm-on.test.sh already uses) and then running the REAL tracked fm-remote-entrypoint.sh against a local checkout, so the clear genuinely executes in the remote home. The bounded-wait regression holds the metadata lock with a live process while leaving the state directory writable, so its refusal can only come from the bound; against the unbounded wait that case does not terminate at all. 61 cases pass in tests/fm-public-followup.test.sh, plus fm-x-mode (110) and fm-wake-queue (32), with bin/fm-lint.sh and bin/fm-doc-audience-check.sh clean.

What Changed

• Route legacy Relay link cleanup through fm-on.sh for remote secondmate work homes, allowing delivery and retirement without a local work path.
• Guard remote clears by Relay request identity, fail closed on uncertain state or transport completion, and bound lock acquisition to prevent hangs.
• Document the remote cleanup contract and add hermetic regressions for successful clears, refusal cases, --force, and unknown completion.

Risk Assessment

✅ Low: The guarded remote clear is well-bounded, preserves local behavior, verifies identity before mutation, handles no-op absence correctly, and fails closed on unsafe state or bounded-lock failure.

Testing

The initial 180-second public-followup run exceeded its command limit, then the complete targeted suite passed with a longer limit alongside focused X-mode and wake-lock tests; a manual CLI transcript demonstrated that a remote secondmate registration with an empty local path retires successfully, clears its remote link, removes the open registration, and writes the receipt.

Evidence: Remote retirement end-to-end CLI transcript

Source: Remote retirement end-to-end CLI transcript

=== Before retire ===
route: - mini-default - remote lane (host: remote-mac; root: /private/var/folders/5x/4nqprlbx0518k3ybcb1sz6gr0000gn/T/fm-public-followup.NierA8/remote-root; home: /private/var/folders/5x/4nqprlbx0518k3ybcb1sz6gr0000gn/T/fm-public-followup.NierA8/reviewer-remote-retire-remote-mini-default; scope: relay work; projects: firstmate; added 2026-08-02)
recorded work_home_path: <>
remote task link: x_request=req-demo
=== End-user command ===
retired pf-demo reason=remote work complete
=== After retire ===
remote task link: cleared
open registration: removed
retirement receipt:
reason=remote work complete
retired_at=2026-08-24T02:40:00Z

Evidence: Targeted public-followup behavioral test transcript

Source: Targeted public-followup behavioral test transcript

ok - outcome text is collapsed to one line, bounded by codepoint, and never corrupts characters
ok - restart end-to-end: typed result reconciles from disk and delivers one reply to the original thread
ok - duplicate terminal results, restart replay, and repeated delivery are all no-ops
ok - wrong source, wrong work id, stale generation, malformed, unsupported deliverable, and forged identity are all refused
ok - a relay transport failure is held as retryable with no false completion, and the retry posts once
ok - a dry-run records no public delivery and leaves the commitment retryable
ok - a late success receipt closes the exact attempt with no second post, and a mismatched attempt is refused
ok - typed terminal cleanup clears the legacy link without posting
ok - a delivery interrupted between post and receipt refuses to repost
ok - a child home reports typed results but can never become the outward-post owner
ok - typed delivery refuses to post when its cleanup registration is missing
ok - marked secondmate teardown resolves its parent and fails closed when unavailable
ok - local seeding publishes durable parent state before its identity marker
ok - a lost launch-time parent binding is recovered from the durable local record
ok - a durable local parent record does not bypass a genuinely missing parent-side registration
ok - unknown durable parent fields remain forward-compatible
ok - conflicting live and durable parent bindings fail closed
ok - unsafe durable parent records fail closed before cleanup
ok - a NUL-bearing durable parent record fails closed before cleanup
ok - relay-disabled unmarked teardown runs no public-followup work
ok - a marked child proceeds without tasks-axi when its parent relay is disabled
ok - secondmate parent resolution matches the durable registry id literally
ok - traversal-shaped registrations are rejected before path construction or posting
ok - pending keeps registrations when tasks-axi returns malformed JSON
ok - the retained private request context keeps the original thread deliverable after inbox cleanup
ok - cleanup refuses while a public reply is owed and proceeds once it has landed
ok - a relay-disabled home runs no tasks-axi call, prints nothing, and gains no artifact
ok - a relay-enabled home with no commitments makes no backlog call and stays silent
ok - a relay-exhausted follow-up binding is escalated rather than retried into the thread
ok - the relay poll stays inert without a token, silent with no commitments, and surfaces a new result once
ok - startup surfaces unresolved public commitments only in a relay home that owes one
ok - typed public-followup records carry only public-safe summaries and deliverables
ok - dropped-baton regression: delivery retains the loop and pending prints open-loop
ok - CONTROL: the identical teardown REFUSES the moment a commitment is registered
ok - rechain posts the shipped follow-on into the same thread
ok - rechain resumes the same obligation after an interrupted bind
ok - concurrent rechains cannot fork one delivered source
ok - failed rechain retirement keeps the source claimed by one resumable destination
ok - first register succeeds with an empty lock list under /bin/bash
ok - registration replay preserves delivered and retired loop states
ok - redelivery does not report a retired loop as open
ok - retire closes delivered loops after secondmate home removal
ok - retire fails closed for an unbound existing secondmate
ok - retire fails closed when a secondmate ID is reassigned
ok - rechain refuses an unrelated existing destination
ok - pending skips a registration retired during settlement
ok - retire --reason closes the loop and drops the open-loop line
ok - retention creates no false teardown refusal and pending no longer prunes
ok - expiry escalation is pinned by FMX_NOW_OVERRIDE
ok - brief fails explicitly when typed deliverable keys are unavailable
ok - pre-change registrations are open loops and un-rechainable, never a crash
ok - teardown reports an unreconciled legacy Relay link
ok - secondmate promotion matches teardown parent resolution
ok - a public loop bound to a remote secondmate home delivers and retires
ok - --force still covers only the unresolved obligation, not the link clear
ok - retire fails closed when a remote route is reassigned
ok - retire fails closed when remote state is unreadable
ok - retire fails closed when remote state is non-writable
ok - retire accepts link absence in non-writable remote state
ok - the guarded remote clear refuses a lock it cannot acquire instead of hanging
ok - an unconfirmed remote clear is unknown completion, never a silent close

Evidence: Targeted X-mode test transcript

Source: Targeted X-mode test transcript

ok - fm-x-poll is a hard no-op without a token (inert default)
ok - fm-x-poll treats an explicitly empty env token as configured
ok - fm-x-poll stays silent on HTTP 204 (the common case)
ok - fm-x-poll lets an explicitly empty relay env override .env
ok - fm-x-poll surfaces auth/config errors once and clears on recovery
ok - fm-x-poll diagnostic markers use private guarded publication
ok - fm-x-poll stashes the question and prints the compact marker
ok - fm-x-poll wakes once per durable request offer across inbox cleanup
ok - fm-x-poll retains offer claim diagnostics until recovery
ok - fm-x-poll preserves in_reply_to conversation context in the inbox
ok - fm-x-poll preserves inbound attachment URLs for the responder
ok - fm-x-poll reports inbox commit failures without emitting a mention wake
ok - fm-x-poll publishes inbox records only through private guarded artifacts
ok - fm-x-poll requires a non-empty question before waking
ok - fm-x-poll rejects an unsafe request_id (path-traversal guard)
ok - fm-x-reply posts a request-bound answer and echoes only the request_id
ok - fm-x-reply accepts the reply via --text-file and stdin (safe, unexpanded)
ok - fm-x-reply exits non-zero on a non-2xx relay response
ok - fm-x-reply cleans up auth header temp files on interrupted posts
ok - fm-x-reply rejects missing arguments with a usage error
ok - fm-x-reply --help makes image support discoverable
ok - fm-x-reply rejects whitespace-only reply text
ok - fm-x-reply dry-run records the would-be reply and never posts
ok - fm-x-reply dry-run works without a token
ok - fm-x-reply honors FMX_DRY_RUN from .env
ok - fm-x-reply lets an explicitly empty dry-run env override .env
ok - fm-x-reply dry-run fails when it cannot record the preview
ok - fm-x-reply dry-run publishes outbox records only through private guarded artifacts
ok - fmx_split_thread: word-boundary, fence-aware, within-limit, numbered, lossless, capped
ok - fm-x-reply keeps a concise reply as a single unnumbered tweet
ok - fm-x-reply auto-splits a long reply into a numbered thread (texts[])
ok - fm-x-reply uses the Discord inbox platform budget instead of the X tweet budget
ok - fm-x-reply keeps numeric X requests on the X tweet budget
ok - fm-x-reply prefers an explicit relay-provided reply limit
ok - fm-x-reply rejects unsafe inbox context artifacts
ok - fm-x-reply clamps a below-floor max to 50 characters
ok - fm-x-reply posts a thread payload (texts[]) to the relay
ok - fm-x-reply --image posts an image object on answer
ok - fm-x-reply streams large image payloads outside curl argv
ok - fm-x-reply dry-run records compact image metadata for threaded replies
ok - fm-x-reply cleans image and payload temp files
ok - fm-x-reply --image rejects missing and unsupported image paths clearly
ok - fm-x-reply --followup posts to /connector/followup with the same request-bound body
ok - fm-x-reply maps a followup_unavailable follow-up 409 to exit 9
ok - fm-x-reply maps every follow-up 409 to exit 9 even without the marker
ok - fm-x-reply treats answer-endpoint 409 as a generic failure
ok - fm-x-reply --followup --image posts an image object
ok - fm-x-reply --followup is accepted in any position and leaves the answer path default
ok - fm-x-reply --followup dry-run marks the endpoint without changing the answer path
ok - fm-x-reply --followup auto-splits a long follow-up into a marked thread
ok - fm-x-reply followup dry-run keeps endpoint marker and compact image metadata
ok - fm-x-poll records the durable per-request reply context from the relay payload
ok - context registry publishes records only through private guarded artifacts
ok - context registry reads only private single-link artifacts
ok - private artifact publisher is compatible with the system bash path
ok - context registry retention is bounded to the seven-day follow-up window
ok - context registry rewrites preserve the first-seen timestamp
ok - context retention starts only when a live initial answer succeeds
ok - a delayed Discord follow-up stays one message after inbox cleanup via the durable registry
ok - an X follow-up over 280 still splits correctly after inbox cleanup
ok - every unresolved follow-up is refused before posting
ok - a partial registry platform combines with the relay's authoritative budget
ok - concurrent requests each recover their own platform/budget with no cross-overwrite
ok - fm-x-dismiss clears the durable per-request context (a dismissed mention gets no follow-up)
ok - fm-x-dismiss posts a request-bound dismiss and echoes only the request_id
ok - fm-x-dismiss dry-run records the would-be body and never posts
ok - fm-x-dismiss dry-run works without a token
ok - fm-x-dismiss dry-run publishes outbox records only through private guarded artifacts
ok - fm-x-dismiss exits non-zero on a non-2xx relay response
ok - fm-x-dismiss exits non-zero on a transport failure
ok - fm-x-dismiss rejects an unsafe request_id (path-traversal guard)
ok - fm-x-dismiss rejects missing or extra arguments with a usage error
ok - fm-x-link records and refreshes the X-request link without disturbing meta
ok - fm-x-link records Discord platform context so follow-ups keep the Discord budget
ok - fm-x-link resolves the platform by request_id so a post-cleanup link keeps the Discord budget
ok - fm-x-link warns loudly and the follow-up is held (not wrongly split) when the platform is unknown
ok - fm-x-link paired carry flags preserve a prior task's follow-up binding onto a successor
ok - fm-x-link recovery relink preserves Discord platform context after inbox drain
ok - fm-x-link rejects malformed or unpaired carry flags
ok - meta rewrites are independent of TMPDIR
ok - x-lib meta helpers refuse a symlinked task record and leave its target untouched
ok - fm-x-link rejects unsafe ids, missing meta, and missing arguments
ok - fm-x-link keeps the plain missing-task error when no second mate is registered
ok - fm-x-link refuses a second-mate-routed task and points at the promised-final path
ok - fm-x-link points an unlocatable task at the promised-final path when second mates exist
ok - fm-x-followup --check reports postable / not-linked correctly
ok - fm-x-followup --check prunes a link past the 7-day window
ok - fm-x-followup --check prunes a link that already reached the follow-up cap
ok - fm-x-followup posts a follow-up, increments the counter, and keeps the link under the cap
ok - fm-x-followup --final clears the link after one post regardless of the remaining count
ok - fm-x-followup clears the link once the third follow-up reaches the cap
ok - fm-x-followup --image forwards the attachment through fm-x-reply --followup
ok - fm-x-followup keeps the link and counter when the post fails
ok - fm-x-followup tombstones the link when a post-success counter write fails
ok - fm-x-followup treats a relay cap/window rejection as an already-exhausted link, not a retry
ok - fm-x-followup skips silently and clears the link past the 7-day window
ok - fm-x-followup is a no-op for a task with no X link
ok - fm-x-followup dry-run records the follow-up and increments the counter, keeping the link
ok - fm-x-followup dry-run --final clears the link just as a live post would
ok - fm-x-followup rejects malformed invocations
ok - bootstrap activates X mode from an .env token, idempotently
ok - bootstrap ignores CDPATH when writing absolute FM_HOME into the durable X-mode poll shim
ok - bootstrap reports missing X-mode dependencies before arming
ok - bootstrap does not report X mode on when activation artifacts cannot be written
ok - bootstrap rejects linked X artifacts without touching their targets
ok - bootstrap is inert without a non-empty .env token (non-X users unaffected)
ok - bootstrap cleans up X artifacts on opt-out and is silent once off
ok - bootstrap reports failed X artifact cleanup on opt-out

Evidence: Targeted wake-queue and bounded-lock test transcript

Source: Targeted wake-queue and bounded-lock test transcript

ok - an abandoned same-process lock hold is reclaimed; a parent's live hold is not
ok - bounded acquire hands ownership to the waiting caller after contention
ok - presentation lock waits are bounded and retriable without weakening acknowledgement atomicity
ok - malformed presentation locks report acquire failure instead of contention
ok - foreign secondmate queue stalls notify once, remain byte-stable, and stay quiet when empty or healthy
ok - secondmate stall markers reject symlinks without touching their targets
ok - stall publication acknowledgement closes the pre-marker crash window
ok - empty prefix mate cleanup preserves another mate's stall receipt
ok - self-announced appends suppress only their own bytes and fail toward waking
ok - historical annotations replay nothing already announced and keep everything new
ok - concurrent append plus drain preserves durable records through acknowledgement
ok - signal written while no watcher runs is caught on next run
WAKE_ACK_REQUIRED: after handling completes run bin/fm-wake-drain.sh --ack-through 1 --recovery-generation 4273.1788310594.5lx53q
●━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
●  WATCHER DOWN - SUPERVISION IS OFF
●  1 task(s) in flight, but no live watcher process holds this home lock (last beat: 2s ago).
●  Trust the emitted supervision protocol for this harness; do not use shell & for watcher repair.
●  This is a supervision warning only; the guarded operation WILL still run.
●  After draining queued wakes, repair a missing or failed watcher cycle with the Pi tool fm_watch_arm_pi, or restart Pi with -e /var/folders/5x/4nqprlbx0518k3ybcb1sz6gr0000gn/T//fm-wake-tangle-root.2JGhXF/.pi/extensions/fm-primary-turnend-guard.ts -e /var/folders/5x/4nqprlbx0518k3ybcb1sz6gr0000gn/T//fm-wake-tangle-root.2JGhXF/.pi/extensions/fm-primary-pi-watch.ts if the extensions are not loaded.
●━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
WARNING: queued wakes pending - drain them with bin/fm-wake-drain.sh before anything else.
ok - stale wake is queued before suppressor state is advanced
WAKE_ACK_REQUIRED: after handling completes run bin/fm-wake-drain.sh --ack-through 1 --recovery-generation 10675.1788310597.KDRiBB
●━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
●  WATCHER DOWN - SUPERVISION IS OFF
●  1 task(s) in flight, but no live watcher process holds this home lock (last beat: 2s ago).
●  Trust the emitted supervision protocol for this harness; do not use shell & for watcher repair.
●  This is a supervision warning only; the guarded operation WILL still run.
●  After draining queued wakes, repair a missing or failed watcher cycle with the Pi tool fm_watch_arm_pi, or restart Pi with -e /var/folders/5x/4nqprlbx0518k3ybcb1sz6gr0000gn/T//fm-wake-tangle-root.2JGhXF/.pi/extensions/fm-primary-turnend-guard.ts -e /var/folders/5x/4nqprlbx0518k3ybcb1sz6gr0000gn/T//fm-wake-tangle-root.2JGhXF/.pi/extensions/fm-primary-pi-watch.ts if the extensions are not loaded.
●━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
WARNING: queued wakes pending - drain them with bin/fm-wake-drain.sh before anything else.
ok - a not-provably-working stale wake is queued before its suppressor is advanced
WAKE_ACK_REQUIRED: after handling completes run bin/fm-wake-drain.sh --ack-through 1 --recovery-generation 18281.1788310600.25zJkA
ok - registered custom check output is queued before cadence suppression
ok - concurrent drains replay until one post-handling acknowledgement consumes records
WAKE_ACK_REQUIRED: after handling completes run bin/fm-wake-drain.sh --ack-through 4 --recovery-generation 24956.1788310603.WFlTiP
ok - drain collapses obvious duplicate heartbeat and signal records
ok - drain asserts watcher liveness: warns on a lapse, stays silent for a live watcher with a fresh beacon
WAKE_ACK_REQUIRED: after handling completes run bin/fm-wake-drain.sh --ack-through 8 --recovery-generation 26935.1788310604.7Mxy2N
ok - structural signal enrichment is separate, deduped, home-local, and tier-zero for other wakes
WAKE_ACK_REQUIRED: after handling completes run bin/fm-wake-drain.sh --ack-through 13 --recovery-generation 29556.1788310606.1h90Fy
ok - every readable unread status line is annotated in full while invalid status files preserve their raw wakes
WAKE_ACK_REQUIRED: after handling completes run bin/fm-wake-drain.sh --ack-through 1 --recovery-generation 36409.1788310612.PYR3Id
WAKE_ACK_REQUIRED: after handling completes run bin/fm-wake-drain.sh --ack-through 2 --recovery-generation 36409.1788310612.PYR3Id
ok - slow annotation releases the append lock and a deleted status file fails open
ok - a branch-actor scoped ack never swallows an unacked main-owned row, and main's later drain sees exactly what remains
ok - main drain and acknowledgement exclude an active branch grant
ok - branch grant cannot take a row already claimed by main
ok - actor ownership filtering precedes same-key deduplication
ok - main reclaims rows granted to an exited branch owner
ok - a branch-actor drain with no eligible-row snapshot refuses loudly instead of draining nothing
WAKE_ACK_REQUIRED: after handling completes run bin/fm-wake-drain.sh --ack-through 1 --recovery-generation existing
ok - wake append publishes atomic recovery evidence before durable rows
ok - wake drain: generation-less legacy wakes are adopted and acknowledged
ok - wake drain: a stale acknowledgement cannot retire or consume a newer recovery episode
ok - wake drain: recovery acknowledgement failures are explicit and retryable
ok - interruptions preserve durable rows until post-handling acknowledgement

Pipeline

Updates from git push no-mistakes

✅ **intent** - passed

✅ No issues found.

✅ **Rebase** - passed

✅ No issues found.

🔧 **Review** - 2 issues found → auto-fixed (2) ✅

• 🚨 bin/fm-x-lib.sh:996 - This contradicts the required criterion that readable remote state with no link must succeed regardless of writability. A mode-0555 readable state containing an unlinked task record fails the unconditional -w check, so retirement retains the registration despite requiring no mutation. Apply writability only after confirming a matching link is present, and restore the corresponding success regression and verification text; the current test at tests/fm-public-followup.test.sh:2556 asserts the opposite behavior.
• ⚠️ tests/fm-public-followup.test.sh:2608 - The lock-timeout regression has no independent test-harness deadline: its elapsed-time assertion runs only after the synchronous command returns. If guarded acquisition becomes unbounded again, the live holder remains unreaped and the suite stalls instead of reporting failure. Run the command under an external deadline and guarantee holder cleanup on timeout.

🔧 Fix: Harden lock-timeout regression with independent deadline
1 error still open:

• 🚨 bin/fm-x-lib.sh:996 - The intent requires “readable state with no link succeeds ... regardless of whether the state directory is writable,” but guarded clear unconditionally requires -w before inspecting the record. A readable mode-0555 state containing an unlinked task therefore retains the registration forever despite needing no mutation. Apply writability only when clearing a present matching link, and restore the corresponding success expectation in tests/fm-public-followup.test.sh:2592 and documentation. This directly contradicts authoritative behavior, so the correction requires user review.

🔧 Fix: Restore no-op guarded clears on read-only state
✅ Re-checked - no issues remain.

✅ **Test** - passed

✅ No issues found.

• tests/fm-public-followup.test.sh with a 180-second limit (timed out after remote reassignment coverage due to the command limit)
• tests/fm-public-followup.test.sh rerun with a 600-second limit
• tests/fm-x-mode.test.sh
• tests/fm-wake-queue.test.sh
• Manual end-to-end remote-route retirement using the real fm-public-followup.sh, fm-on.sh, and tracked remote entrypoint through the fake SSH process seam; verified empty work_home_path, remote link removal, registration removal, and persisted retirement receipt

✅ **Document** - passed

✅ No issues found.

✅ **Lint** - passed

✅ No issues found.

✅ **Push** - passed

✅ No issues found.

[greptile-apps]

Confidence Score: 4/5

The PR does not yet appear safe to merge because guarded no-link retirement can still race concurrent publication and remove the only reconciliation registration before a live link is installed.

The guarded path returns success at bin/fm-x-lib.sh:1007 before acquiring the metadata lock, while link publication later acquires that lock and can atomically install a link; the previously reported absence-publication race therefore remains outstanding.

Files Needing Attention: bin/fm-x-lib.sh

_{Reviews (5): Last reviewed commit: "no-mistakes(document): Clarify remote pu..." | Re-trigger Greptile}