Problem
Codewhale exposes the same multi-agent roster through competing public nouns and command shapes. Users encounter fleet, pod, saved rosters, durable runs, and current-session sub-agents without a stable boundary. That makes the TUI harder to learn and makes docs, setup, CLI help, and model-visible tool descriptions disagree.
Proposed solution
Make Pod the canonical customer-facing noun while preserving Fleet only where compatibility or durable protocol/storage requires it.
Acceptance criteria:
codewhale pod is canonical; codewhale fleet remains a compatibility alias./pod pods is the saved-Pod picker; /pod fleets remains a compatibility alias./setup pod is canonical; prior Fleet spellings continue to parse./pod status reports durable ledger state, while /pod workers reports only current-session sub-agents.- Public and model-visible copy uses Pod consistently across TUI, CLI, setup, docs, and web.
/docs/pod is canonical and /docs/fleet permanently redirects.- Fleet remains unchanged in wire/storage/schema/config/migration contracts such as
.codewhale/fleet.jsonl, serialized fleet, [fleet], and /v1/fleet.
- All 15 complete TUI locale packs preserve key and placeholder parity.
- Rust command/dispatch tests and web public-surface/localization tests cover the canonical and compatibility spellings.
Use case
A user can assemble and save a Pod, inspect its durable runs, and separately inspect workers active in the current session without learning legacy implementation vocabulary or guessing which command surface owns which state.
Alternatives considered
Keeping Fleet public preserves historical terminology but perpetuates the ambiguous split. Renaming protocol/storage keys in the same release would create unnecessary migration and compatibility risk, so those identities should remain Fleet internally.
Impact
This is a high-frequency naming and navigation improvement across every multi-agent workflow. It reduces command discovery errors, makes Pod composition easier to teach, and gives later managed-computer and cloud-sandbox surfaces one stable roster concept.
Additional context
The change is intentionally bounded to public language and aliases. It does not claim a storage migration, a new scheduler, provider qualification, cloud deployment, or release readiness by itself.
Problem
Codewhale exposes the same multi-agent roster through competing public nouns and command shapes. Users encounter
fleet,pod, saved rosters, durable runs, and current-session sub-agents without a stable boundary. That makes the TUI harder to learn and makes docs, setup, CLI help, and model-visible tool descriptions disagree.Proposed solution
Make Pod the canonical customer-facing noun while preserving Fleet only where compatibility or durable protocol/storage requires it.
Acceptance criteria:
codewhale podis canonical;codewhale fleetremains a compatibility alias./pod podsis the saved-Pod picker;/pod fleetsremains a compatibility alias./setup podis canonical; prior Fleet spellings continue to parse./pod statusreports durable ledger state, while/pod workersreports only current-session sub-agents./docs/podis canonical and/docs/fleetpermanently redirects..codewhale/fleet.jsonl, serializedfleet,[fleet], and/v1/fleet.Use case
A user can assemble and save a Pod, inspect its durable runs, and separately inspect workers active in the current session without learning legacy implementation vocabulary or guessing which command surface owns which state.
Alternatives considered
Keeping Fleet public preserves historical terminology but perpetuates the ambiguous split. Renaming protocol/storage keys in the same release would create unnecessary migration and compatibility risk, so those identities should remain Fleet internally.
Impact
This is a high-frequency naming and navigation improvement across every multi-agent workflow. It reduces command discovery errors, makes Pod composition easier to teach, and gives later managed-computer and cloud-sandbox surfaces one stable roster concept.
Additional context
The change is intentionally bounded to public language and aliases. It does not claim a storage migration, a new scheduler, provider qualification, cloud deployment, or release readiness by itself.