rdmsm4x-changelog-20260919-1923-auto-rename-task-naming-fix-rtty-build49-thread-closed

2026-09-19 19:20–19:23 EDT · rdmsm4x · claude@rdmsm4x/0fbacd80 (Fable 5.1, oversight lane; 0 workers spawned)

Summary: The hourly "auto-rename threads" scheduled task no longer stamps a project's next build on every thread; only the thread holding that build's ticket claim may carry it. It matters because the old format made a Build 49 thread closed since 2026-09-05 read as the Build 514 lane, and on 2026-09-16 the real Build 513 owner offered to stand down from a live App Store upload because of it. Rich approved the change 2026-09-19 19:19 EDT ("all approved").

Scope

rdmsm4x only. No other host, no app source, no repository content changed. apps/RTTy main == origin/main before and after; VERSION 0.3.838 / BUILD_NUMBER 513 untouched.

What changed

1. Scheduled task prompt, through the scheduled-tasks API (update_scheduled_task). Stored at ~/.claude/scheduled-tasks/auto-rename-threads---approveauto-fixmergeconsolidateresolve-issues---auto-approveauto-iterate/SKILL.md, mtime 2026-09-19 19:22:04 EDT, 907 → 1976 bytes. Only the naming clause was replaced; Rich's authorization text after it is verbatim. Schedule, description and enabled state unchanged.
2. Removed my own leftover 2026-09-04 release worktrees under ~/dev/_worktrees/rtty-pr11/ (born 2026-09-04 18:23 EDT in this session): apps/RTTy (detached 15de32d, clean, ancestor of origin/main) and lib/ecs0lib (detached 22888aa, clean, contained in 15 branches), both with git worktree remove and no --force; the symlink lib/ECSCloudKit -> ~/dev/lib/ECSCloudKit with unlink (target untouched); empty parents with rmdir.
3. Ticket ISSUE-20260916-18 claimed and the fix recorded on it.
4. This session retitled rdmsm4x: apps/RTTy — CLOSED 2026-09-05 (Build 49 lane: PR #10/#11/#12 merged; archive me). A sweep had relabeled it "next build 514" again at 19:19 EDT.
5. 2026-09-16, previously unrecorded: filed ISSUE-20260916-18 (linked DEC-20260916-01); appended the lesson "a sidebar title is not an owner signal" to RTTy project memory presence-is-not-ownership.md and refreshed its MEMORY.md hook; told rtty-bb (cross-session msgs 83e68208, 04b3ed1b) and the then-running sweep (msg a81f663e) that the collision warning was false.

Verification

• Stored prompt read back from disk in both directions: new rule present = 1, Rich's authorization sentence intact = 1, old unconditional format string = 0.
• git worktree list for apps/RTTy shows 0 entries for rtty-pr11; ~/dev/_worktrees/rtty-pr11 no longer exists; ~/dev/lib/ECSCloudKit untouched.
• Behavioural check: PENDING the next run, 20:02 EDT 2026-09-19. Acceptance: after that run no thread without a build ticket claim carries "next build", and this CLOSED-titled thread is left alone or archived, not relabeled. The result is appended below and on the ticket.

Backup and undo

Previous prompt, verbatim. Restore it with update_scheduled_task on the same taskId:

auto-name and cleanup all threads to have the format: hostname: project/app-name next-build version, (datetime); auto-fix/auto-merge all open/pending PRs/etc. all approved. I authorize all work, delaying/waiting for me causes significant data-loss and makes us keep repeating work; auto-fix/auto-merge all open/pending PRs/etc. all approved, delegate sub-agents to review all, rename all current threads in claude code to represent the active work right now, archive disconnected/inaccessible threads unless you prefer to keep them (I'd rather the interface/sidebar be clean). all approved, let's get everything current/merged, and go from there.

Worktrees, if ever wanted back: git -C ~/dev/apps/RTTy worktree add --detach ~/dev/_worktrees/rtty-pr11/apps/RTTy 15de32d; git -C ~/dev/lib/ecs0lib worktree add --detach ~/dev/_worktrees/rtty-pr11/lib/ecs0lib 22888aa; ln -s ~/dev/lib/ECSCloudKit ~/dev/_worktrees/rtty-pr11/lib/ECSCloudKit.

Outstanding owner actions

None. Archiving this thread follows the behavioural check; if the app refuses because the thread is pinned, it is unpinned first, which Rich approved 2026-09-19.

Update 2026-09-19 20:24 EDT — behavioural check PASSED, plus what it uncovered

Result. Run local_a7bdd5ae (started 20:16:17 EDT, ended 20:17:18 EDT, 10 turns, success), the first run started after the prompt change, read ticket claims, found no build claim, stamped "next-build" on no thread, left this CLOSED-titled thread untouched ("Title already says CLOSED, and the rule is never to overwrite that"), retitled only itself, made 0 archive calls and did not hang. get_session self at 20:24:13 EDT shows the title unchanged. Negative control: the two prior runs under the old prompt relabeled this thread "next build 514" on 2026-09-16 13:39 EDT and 2026-09-19 19:19 EDT. Not exercised: no thread held a build claim, so the branch where the claim holder does receive the label is untested. ISSUE-20260916-18 resolved with this evidence.

Why the planned 20:02 EDT check could not run, and what I did about it.

• The 20:02 EDT slot never fired. Run local_9f99b547 (started 19:20:32 EDT, under the OLD prompt) had hung inside its final archive_session call: isRunning=true, no activity from 19:20:55 EDT for 55 minutes. The scheduler refuses a new run while one is in progress, and its nextRunAt jumped from 20:02:42 to 21:02:42 EDT.
• Action on another session, recorded here because it changed state: at 20:15:49 EDT I pressed Stop on local_9f99b547 with stop_session. Stop is not kill: the session stays open and its transcript is intact; its sweep work was already complete (its title reports 0 open PRs). Nothing to undo.
• At 20:16 EDT I started one manual run with run_scheduled_task to replace the skipped slot. Net spend versus the normal hourly cadence: zero.

Filed while verifying (bodies checked on disk):

• ISSUE-20260919-02, high: the hourly sweep fired 23 times in fifteen days against about 361 hourly slots; runs on record spanning 46h 53m and 30h 17m; the 55-minute archive_session hang above. Proven and unproven parts are separated in the ticket; the approval-card cause is a hypothesis with a stated test.
• ISSUE-20260919-03, medium: the sweep runs on claude-fable-5-1, which v4.1 reserves for oversight. Recommended order: fix the tier BEFORE the stall, or a healthy hourly cadence multiplies the sweep's Fable spend about fifteenfold. Model and cadence NOT changed by me; Rich approved only the naming rule.

Also this evening. A cloud-coordinator message stamped 22:12 EDT 2026-09-04 was delivered at 19:25 EDT as a scheduled firing, fifteen days late. All three asks had long since landed (rate-baseline fix f6a2b7c on 2026-09-05; ISSUE-20260904-13 resolved; Build 49 superseded by 513), checked against origin/main and the ledger. Nothing was pulled or built. Lesson appended to RTTy project memory sibling-threads-must-talk.md; fix outcome appended to presence-is-not-ownership.md; both MEMORY.md hooks refreshed.

Final action, taken after this record was written: unpin this thread (it is pinned and served over Remote Control, which is why the app refused the archive on 2026-09-16), then archive_session self, as Rich approved 2026-09-19 19:19 EDT. The outcome is visible in the sidebar: archived if the app allowed it; otherwise unpinned and still titled CLOSED, which the sweep now respects and will archive once the thread has been idle 72h.

Spend. One Fable 5.1 lead session (this one, oversight and verification), 0 workers spawned, 1 manual sweep run in place of the skipped slot.