dsh-agent-teams-model-override

LIMITATIONS

Known limitations

These are known, tested limits—not guesses. 1. **Private runtime seams.** Nested teams depend on the installed Agent Teams/subagent internals (`roster.spawnAdmitted`, activation registry, delivery symbol, session controller). A future DSH that changes them makes the component fail closed with a reason in the Host log. It is not a promise of forward compatibility. 2. **No teammate deletion or renaming.** The official roster is append-only. A `failed` creation still consumes its name and slot. A Lead session has 16 teammate slots (the Lead is separate); `context: "fresh"` creates a new member, it does not reuse one. 3. **No true context clear.** `/compact` in the GUI summarizes history; it does not erase it. The only clean start is a new teammate with `context: "fresh"`. There is no `/clear` tool for teammates in 1.6.0. 4. **A nested worker replies to its manager,** not to the Lead. That is the consequence of a real `parentSession`. Use an explicit `send_message({ target: "lead" })` when the worker must answer the Lead. 5. **Pending model switches are in memory.** If the Host restarts between `switch_teammate_model` returning `via: "pending"` and the teammate's next start, repeat the switch. 6. **`context: "fork"` plus a changed route** can prevent the provider from reusing the inherited conversation prefix. This is the same trade-off as official subagent forking. 7. **Manager authority is zone-scoped, not global.** The manager can act only on actual descendants. It cannot claim another member's task, reassign across managers, or act on the Lead. `team_hierarchy_set` cannot physically reparent an existing session. 8. **Two 1.6.0 UI paths still need a live pass.** Manager interrupt and Team-panel nested transcript opening are tested against the installed roster and a fake session controller, but the final live UI check is pending (see Status above). ---