Summary
Allow automation workflow edges (and related dependency expressions) to span projects, so a task in one project can gate a task in another.
Problem
Automation workflows are project-scoped and edges cannot cross projects. Teams that split backend and frontend (or other domains) into separate projects cannot express “backend task must finish before frontend task can start” without merging everything into a single project.
Proposed Direction
- Support cross-project edges in the workflow model (with clear permission and visibility rules).
- Alternatively (or as a first step), document a supported pattern (e.g. shared parent project, webhook/status bridge, or explicit “wait for external task” node) that achieves the same outcome without a full model change.
Scope
- Product behavior
- Repository structure
- Architecture
- Developer experience
- Documentation
- Other
Additional Context
- Current project-scoped design is clean for isolation; cross-project edges add coupling and permission complexity.
- A documented pattern may be enough for many teams; a native edge is cleaner for the common backend/frontend split.
- Related naming note: distinguishing a “task run / work session” from a free-form “chat” in the model and UI would make dependency and progress surfaces land more naturally.
Summary
Allow automation workflow edges (and related dependency expressions) to span projects, so a task in one project can gate a task in another.
Problem
Automation workflows are project-scoped and edges cannot cross projects. Teams that split backend and frontend (or other domains) into separate projects cannot express “backend task must finish before frontend task can start” without merging everything into a single project.
Proposed Direction
Scope
Additional Context