[2/7] feat: coordinate subagents with tasks, reviews and budgets

[BIackFIame]

Summary

Part 2/7 of the CanvasTTY agent-workflow series. Reusable task templates, dependencies, a shared board, reviewer results, task budgets and explicit retry make multi-agent work visible and controllable. Selected accounts propagate to children; first prompts wait for CLI readiness, and OpenCode waits return before the client deadline.

Review scope and dependencies

Depends on: #131.

This is a cumulative upstream PR: GitHub's Files changed tab includes earlier unmerged parts because all PRs target upstream main; cross-fork stacked bases are unsupported. Review this part in the predecessor-to-head diff. This comparison also contains the integration of upstream main 6faadcdc. The intended merge order follows the numbered series; do not merge a later part independently of its predecessors.

Accounts account-support changes are a companion.

Validation and limitations

Tested head: b09cfcae5793b97b642519fc090318eb664dde06. Local helpers, typecheck, build and secret audit passed; full suite: 1,931 passed, 6 skipped, zero failures. The six skips cover optional native sandbox, platform-specific and Ollama checks. GitHub CI is pending on this head.

Upstream main 6faadcdc is merged into this branch. The WorkspaceCanvas conflict is resolved with both orchestration and upstream material/terminal-link behavior retained. This remains a Draft while the requested review cycles and current-head CI complete.

Workflow launches require a nonblank user task. Automatic worker review now requires a clean separate worktree with an attributable launch baseline. Shared, initially dirty, unverifiable and submodule-containing trees return an explicit unavailable result, as does a competing managed launch in the same tree. Prepared reviewer account resources are cleaned up on launch failure or cancellation.

A prior real OpenCode/GLM run started three children without prompt resends and completed repeated bounded waits around a long-running child. All failure/retry variants and the full template/reviewer workflow remain separate live acceptance work. This update used real temporary Git repositories and fake provider processes; it did not rerun paid provider, real SSH or Ollama tests.

Series order

1. macOS clipboard
2. Orchestration, reviews and budgets — Draft
3. Worktrees and checkpoints — Draft
4. Timeline, usage and attention — Draft
5. Network policies and temporary secrets — Draft
6. Workspace context and navigation — Draft
7. Experimental routing, handoff and remote controls — Draft

Parts 2–7 are cumulative Draft PRs against upstream main, with an isolated layer diff in each description. Part 2 now includes upstream main 6faadcdc; parts 3–7 still need that integration and fresh checks before readiness. Part 7 also retains its independent experimental acceptance gate.

[BIackFIame]

@codex review

Please review this PR for correctness, regressions and security issues. Review only; post findings on GitHub without changing code.

This is part 2/7 of a cumulative series. Focus on changes introduced after predecessor 22620f37238d4693c064216a5ba61fbc5fe7251d through current head 72accd26e8451e187de4436b7d51a4b22a6a1eaf, including their interactions with the inherited code. The isolated layer diff is linked in the PR description. Known merge conflicts with newer main are already documented; look for substantive code defects in addition to those integration blockers.

[howdeploy]

@BIackFIame, we are rejecting this PR in its current form and closing it after this feedback. This is a product, design and integration decision following local Linux acceptance. The current implementation adds too much harness configuration to the normal CanvasTTY experience and does not meet our UI contract.

The related feedback on #137 is here: #137 (comment). That PR is also being rejected and closed. Please treat a future plugin implementation or an agreed advanced-settings proposal as a new, separately scoped contribution.

1. The design is broken in the Linux acceptance flow

During acceptance on the maintainer's Linux machine, parts of the added UI were unreadable or did not appear correctly, and parts remained in English with Russian selected. The workflow selector shown in the launch card is a concrete example. These observations concern the local combined DEV build; they do not establish that every Linux environment behaves identically.

There is a specific contrast problem in the source: the launch dialog uses var(--text-dark) on its sage surface, while .launch-flow-picker__row select sets a dark #30323f background and inherits the text color. That combination can make the selected value effectively unreadable. It also illustrates why adding independent control styling outside the existing component and token rules is fragile.

The refresh control uses the literal ↻ character instead of our vendored Lucide assets through UiIcon. The new picker has its own border, padding, colors and form grammar. This needs a redesign within the application's existing components, not another independently styled form inserted into the launch card.

Please follow docs/UI_CONTRACT.md: preserve the concise provider launch flow, existing control patterns, shared palette roles and UI scale, and keep advanced explanations out of the default launch surface. Cross-platform readability and complete localization are part of that requirement.

2. Workflow templates are exposed before users can understand them

The picker presents a template name and an expected subagent count. It does not explain the template's purpose, when to choose it, the work it will perform, or how it relates to the existing Agent/Orchestrator choice and permission profiles. Choosing a template also switches the launch role to Orchestrator and disables the Agent choice, which is a significant behavior change that needs explanation before selection.

The backend already provides a description for each template, but AgentLaunchDialog does not display it in this flow. Built-in names such as "Executor and reviewer" and "Three options and a judge" are supplied as English strings and rendered directly through flow.name. Built-in labels and descriptions need proper localization. User-authored template content can retain the author's chosen language, but it must be clearly distinguished from application-owned text.

There is repository documentation about .canvastty/flows/*.yaml; that does not make the feature discoverable or understandable in the application. Users should not have to inspect source files or guess the format to understand an option appearing in their launch card. A future implementation needs an accessible explanation, a concrete example, clear template provenance, and a preview of the resulting roles/tasks before anything starts.

3. Another menu makes the existing permission and environment choices harder to understand

CanvasTTY already has agent permission profiles, sandbox/environment choices, and understandable enable/disable controls. Contributions from other authors also improve those existing paths. The new workflow picker adds a further configuration axis to the same launch surface, while the surrounding series adds more policy, goal, review and budget controls.

Technically, a workflow template describes task choreography; it does not itself change the caller's permissions. That distinction should be visible to the user. The current composition makes users work out the relationship between a workflow, an orchestrator role, a permission mode, an environment and the later execution-policy controls. A new dropdown without a clear hierarchy increases uncertainty about which option actually governs execution and safety.

We are preserving the application's minimal default workflow. More configuration is justified only by a clear user need, with a coherent place in the existing UI and explicit opt-in. Successful helper tests or a mergeable branch do not establish product acceptance or a usable Linux interface.

4. Acceptable direction for future work

Please take this harness/orchestration configuration into a separately installed CanvasTTY plugin. The plugin can own its templates, task board, review configuration, budgets and related UI, using the existing supervised services, launch contributions, environment and session APIs described in docs/ARCHITECTURE.md.

If an operation cannot be implemented through those capabilities, propose a small plugin-system extension first. Explain the concrete missing operation, its contract, permissions, ownership, cancellation and behavior when the plugin is disabled or unavailable. Core must continue to validate privileged operations and enforce its trust boundaries; a plugin should not acquire authority through a template or recommendation.

An alternative we can discuss is integration into the existing settings as an explicitly enabled Advanced mode. That would require an agreed design before implementation: reuse existing controls, consolidate related configuration, preserve simple defaults, explain precedence, and provide a clear way to return to normal behavior. The warning must describe actual consequences, such as starting additional agents, consuming additional tokens or changing task execution. It must not imply that enabling advanced mode grants permission to bypass host validation or weaken safety silently.

For either direction, the acceptance criteria are:

• Existing launch and safety controls retain a clear, consistent meaning without the optional feature.
• Built-in labels, descriptions and actionable states are localized; controls are readable on Linux in the existing palettes and UI scales.
• Templates have discoverable explanations and a concrete preview of what will run.
• Advanced harness configuration is deliberately enabled and lives in a coherent optional surface.
• Any required core API changes are separated from the plugin's policy and UI implementation.

The current series is cumulative. Closing #132 and #137 does not approve their code through another PR that includes them. Please split or rebase the remaining proposals so independently useful changes can be reviewed without bringing the rejected harness configuration back indirectly.

This PR is rejected in its current scope. Please use the direction above for a future proposal rather than continuing to expand this core launch/configuration interface.