[sreejithraman]

Chief of Staff now starts each program owner as its own top-level session. Inside that session, the owner runs Implement, and Implement uses subagents for its helpers. This was the user's call on 2026-11-09: chief = sessions, Implement = subagents.

Why

In a seatcommons chief thread, the user asked on Nov 2 for one session per ticket. The program record rewritten in #164 dropped that preference. On Nov 9 the chief started 5 subagents, was corrected, and stopped them. It then relaunched them as sessions, and those failed with branch_already_exists because the stopped subagents still held the worktrees.

Changes

• chief-of-staff/SKILL.md
  • Running a chief counts as a request for sessions. Each owner starts with t3_thread_launch, in a worktree the host binds.
  • A host that can't launch sessions falls back to a delegated owner in its own worktree.
  • A top-level owner watches its own PR and reports with t3_thread_send. The chief waits on each outstanding owner's run with t3_thread_wait. When a run fails, is interrupted, or goes idle without a report, the chief recovers it or marks the outcome blocked.
  • Replacing a stopped owner reuses its clean worktree through existing_worktree, or starts on a new branch.
• Owner kickoff: the top-level route is listed first, and helpers run "as your own subagents".
• Program state and chief-move: start mode now lists top-level first, and chief-move says "any delegated owner".
• implement/SKILL.md: the caller is "the user when they started you". Before, it was "the user in a top-level thread", which would have sent a session owner's report to the user instead of the chief.
• SOURCES.md: updated to match.

Verification

• python3 scripts/check.py: exit 0 at d435c21.
• Dry-run trials (gpt-6.1-sol, frozen copy, expectations written first):
  • T3 chief: launched 3 top-level owners. Matched.
  • Owner: started its helpers as subagents and reported to the chief. Matched.
  • Restart: reused the stopped owner's worktree. Matched.
  • Plain Codex: fell back to delegated owners, then held off because the host has no worktree isolation. The old text required the same.
• Review Fix Loop, 2 passes:
  • Pass 1: Primary found one P2, a chief with no wake-up when an owner dies before reporting. Gemini found nothing.
  • Pass 2: the repair is clean.

Not proven

• Live session launch and t3_thread_wait wake-up behavior have not been run in a real chief program.
• The trial noted that T3's "launch threads only when the user asks" rule could make a model hesitate. The skill frames running a chief as that request.

🤖 Generated with Claude Code