Repository navigation
Replies: 1 comment
|
Thanks for trying #159 and #160 in a DEV build and for opening this discussion. I agree with the main point: the amount of machinery has grown beyond what people need right now. Below is how I see the principles, the scenarios, and what I'm ready to accept, revise, split or defer. Principles (proposed)
Scenarios
By mechanism
Auto-sort (#163) is unrelated to this discussion: it is independent and the review comments are addressed. Where the complexity goesRouting (choosing a model and subscription), command review, quotas and account pools are plugins, not core. From core they only need narrow, read-only or person-approved APIs: language and scale for plugin pages, the list of CLIs, quotas and usage for services, visibility of the chosen model when a subagent starts. That is a separate topic (#150); I'm not proposing it here, only showing that the "complex" part doesn't go into core. Plugins that already cover part of these questionsMuch of what this discussion asks about already exists as optional plugins on the existing plugin API — you can install and try them, and core doesn't change:
All of them are off by default and add nothing to default surfaces. That's why I'd keep only reliability and protection in core, and leave choice policy and convenience to plugins. For fuller operation they lack a few narrow APIs (quotas and usage for services, visibility of the chosen model at launch) — that's #150, not this discussion. I mostly test this in an automated way: I build a separate build from my fork together with plugin updates and run live runs on my own subscriptions (a hidden app, real CLIs and models, a spend cap, checks on where requests go and what reaches the agents). If you'd like to see how it works in practice, the build is on the How I'd split it
Each PR description will have: the before/after scenario, what changes for existing workflows, why this implementation and whether a smaller one would do, and how it was validated (a test that fails before the fix plus a live run). If this order works for you, I'll close #159–#162 and open the first PRs from items 1–2 instead. And separately: which of the "restrictions" in #160 do you consider unnecessary first? |
Uh oh!
There was an error while loading. Please reload this page.
I'd like to open a broader discussion about the direction of orchestration and security in CanvasTTY before deciding which changes to bring into the project.
I tried #159 and #160 in a local DEV build and asked @teo-nex to help me understand the proposals and their practical implications. We both have mixed feedback. There are useful reliability improvements here, alongside questions about flexibility, complexity, and the everyday experience of people using the canvas.
The engineering appears thorough. My concern is that the overall system may be becoming more elaborate than users need at this stage. I want that engineering effort to produce clear controls, predictable behavior, and a convenient workflow. I'd like to involve the PR authors and other contributors in deciding how to get there.
Related proposals
These proposals cover different problems. Listing them together is an invitation to agree on the direction, rather than a single assessment of every change in them.
Where we see value
These solve understandable problems. The question is how much machinery and how many restrictions are necessary to solve them reliably.
What I would like us to agree on
1. Defaults and explicit choices for subagents
Inheriting the parent's account or model can be a useful default. We also need a clear path for intentionally using different accounts, models, reasoning levels, or CLIs for different tasks. For example, a stronger coordinator and a cheaper worker are a reasonable workflow.
To be precise, #160 does not universally lock every subagent to one account, model, and reasoning level. It inherits plugin launch options, permits explicit choices under the plugin's delegation rules, and refuses certain conflicting or incompatible combinations. What should the user-facing contract be, and which restrictions are actually necessary? Can we distinguish an intentional model/account choice from an escalation of permissions?
2. Protection that users can understand
Which protections must always apply, which decisions belong to the user, and which belong to a plugin or orchestrator? When a launch or action is refused, can the person understand why and resolve it through a clear supported workflow? The practical behavior should match what the interface promises.
3. The right amount of complexity for the current project
Which mechanisms address problems already encountered in real use? Which can wait? How do we keep the common workflow simple while still handling advanced orchestration and protecting private data? I'd appreciate simpler alternatives where they can preserve the required guarantees.
4. Changes we can review and accept independently
Could we separate reliability fixes, changes to security or delegation policy, UI fixes, and larger workflow features into smaller units? A useful fix for lost prompts should be possible to assess independently from a decision about account inheritance or worktree ownership.
A practical outcome
@BIackFIame and @mrcertis, I'd appreciate your perspective on these tradeoffs. @teo-nex, please feel free to expand on the workflows and concerns we discussed. Other contributors and users are welcome to join.
For each proposed mechanism or restriction, it would help to describe:
I'd like us to leave this discussion with a short set of shared principles, a few representative user scenarios, and a list of changes we can accept, revise, split, or defer. That would give future PRs a clearer target and help us develop orchestration and security around how people actually use CanvasTTY.
All reactions