Keep shared fixes out of private preferences; prefer visible host child threads #142

Outcome

Shared behavior lives in AgentsMD or the owning project, so every user gets it. Private preferences hold only what is genuinely personal. Delegation inside a host that offers visible child threads uses them.

Evidence (2026-09-27)

• A planner running in T3 Code needed an implementer on a specific model and effort. The in-session subagent tool cannot set effort. A personal setup note told agents to open separate terminal sessions for long work, so the implementer opened in a new terminal window. T3 Code's own spawn_thread tool names model and effort and shows the child in the parent thread's Agents panel; the planner did not consider it.
• The first fix was added to the user's private preferences. The user: "preferences are not a place to save things that should be fixed elsewhere, unless it's not possible to fix ... another user might not have it inside."
• AGENTS.md defines preferences only as "personal defaults" and lists what they cannot waive; nothing says what does not belong in them. reflection already says "edit the actual owner", but corrections made during ordinary work bypass it.
• orchestration.md: "Submit that packet through the routing tool when one is available; otherwise use a nested child". It does not mention host-native child threads or honoring the requested model and effort.

Proposed change

Generalized 2026-09-27 at the user's request: the first draft named one user's setup and one host's tool. Neither rule names a user setup or host tool. T3-specific tool guidance (such as spawn_thread) belongs in T3 Code itself, not AgentsMD.

• AGENTS.md, Canonical source and preferences: one sentence. When a correction or discovery reveals missing or wrong shared behavior or tool knowledge, fix it at the owner of that behavior (the shared instructions, the project, or the tool that provides it), not in preferences; keep a preference only for what cannot live at an owner, and remove it once the owner fix lands.
• orchestration.md: rewrite the existing routing and separate-host-task sentences. Before choosing, check every delegation tool the host provides, including deferred and MCP-supplied tools (the observed failure was a routing tool that was present but deferred and never inspected). Use the routing tool for work it accepts; when there is none, or it cannot honor a model or effort the user named, use a host child mechanism that honors them and shows the child to the user, else a nested child with no prior transcript; do not fork the parent transcript. A separate host task only for work that must outlive the parent or continue after it stops, or when the host offers no visible child. GLOSSARY.md Fresh context aligned.
• Contract tests pin both rules; the Rewrite delegation rules to the Prism/T3 layering (supersedes #130) #131 tool-neutrality guard stays unchanged.

Elon record

• Wanted result: agents route shared fixes to shared owners and pick the visible child mechanism, without relying on one user's private file.
• Cuts: a preferences linter or hook (no evidence yet that the sentence is ignored); a new document for preference placement (one sentence in the existing section suffices); host-specific delegation docs (one example in orchestration is enough).
• Smallest surviving solution: two sentences and their contract tests.

Contribution to the Objective

"After one-time installation and configuration, a fresh supported agent ... begin[s] useful work without manual workflow routing." Behavior that lives only in one user's private file fails that for everyone else.

Non-goals

• Changing what preferences may not waive.
• Auditing any particular user's preferences file.

Blockers

Touches AGENTS.md and version files alongside #138 (different sentences). Whichever PR merges second rebases and reruns versionctl.

Proof

Contract tests and the full suite pass.