rdmpw3265m-changelog-20260905-2107-claude-config-convergence-closeout-and-icloud-correction
When: 2026-09-05 21:07:18 EDT
Session: claude@rdmpw3265m
(ecdf565b) — resumed the 2026-08-20 fleet Claude-config
work to close it out. Where state changed: all writes
landed on rdmsm4x. Nothing was modified on rdmpw3265m
or any other host.
What changed
NEW
rdmsm4x:~/dev/fleet/CLOSEOUT-claude-config-convergence-20260905.md(8,808 B, md5918fa97b5795f46887de25ef875e667a) Closeout for the 08-20 convergence work: verified fleet state, the context-size number after the v4.0 re-packaging, what shipped, what was deliberately not built and why it must not be revived as designed, and the list of confident-wrong-answers that session produced.EDITED
rdmsm4x:~/dev/_migration/conflicts/rdmsm4x-20260903-nested-review-and-ingest-estates/fleet/_review/mac-fleet-claude-config/ISSUES.md171 → 193 lines (+22, exactly the block added; 26 top-level entries before and after, headers intact). An inline correction was added to the~/DocumentsiCloud entry. The original claim was wrong.NEW
…/mac-fleet-claude-config/CLOSED-SEE-FLEET-CLOSEOUT.md(1,813 B) Marks that archived folder closed and points at the live closeout, so nobody resumes from it.
No files were deleted. No settings were touched on any host.
The correction
This session had recorded that ~/Documents iCloud
replication was degraded and not to be relied on. That
was wrong and never verified. It came from running a
bare brctl status, which enumerates ~278
containers and times out for that reason alone — the timeout was read as
a blocked daemon — and then relaying a peer session's unverified reading
onward as fact.
Scoped measurement, rdmsm4x, 2026-09-05 20:58:49 EDT,
timeout 30 brctl status com.apple.CloudDocs:
client:idle, caught-up,
last-sync 2026-09-05 20:58:49,
appuninstalled:(null). Syncing normally. Not
degraded.
Two smaller real findings the wrong claim had hidden: a legacy second
CloudDocs container (_7cf15faa…) is caught-up but last
synced 2026-07-31 and looks dormant; and several /Documents
items sit in Needs Apply Changes → pending-scan for ~24 h,
all flagged quarantine:Download|Sandbox|Track — a
Gatekeeper scan queue, not a sync failure.
Fleet
state verified this session (read-only, one zsh -lc SSH
probe per host)
| Host | permissions.defaultMode |
~/.claude/CLAUDE.md |
|---|---|---|
| rdmsm4x | bypassPermissions | v4.2 · 25,380 B |
| rdmbair13m5 | bypassPermissions | v4.2 · 25,380 B |
| rdmbair15m5 | bypassPermissions | v4.2 · 25,380 B |
| jdmbair13m5 | bypassPermissions | v4.2 · 25,380 B |
| rdmpw3265m | bypassPermissions | v4.2 · 25,380 B |
| rdmpw3275m | bypassPermissions | v4.2 · 25,380 B |
6/6 converged on both. Observed only; the mode key was not written on any host, per the standing rule.
Always-loaded context is now 25,380 chars (~6,345 est. tokens) — down ~32% from the 37,545-char peak the 08-20 convergence itself caused, still roughly 2x the 12,334-char pre-cleanup baseline. The file legitimately carries more binding rules now, so this is recorded as a number, not as a defect.