[RFC]: FlowMesh 2026 Q2 Roadmap

[timzsu]

Motivation

RFC #1 has concluded, as our first release has been published. This RFC outlines the development roadmap for FlowMesh in Q2 2026. It includes undone items from #1, and we are gathering ideas and feedback.

Proposed change

Architecture

• Pydantic schema simplification — Use Pydantic schema across the repo so dict resolving is guarded by schema (e.g., the result schema for executors). refactor: introduce typed executor result schema #52
• Refactor SSH session and connection naming.
• Refactor omni executors to use the mixins. refactor: adopt mixin chain + emit per-phase spans #49
• Refactor all executors to avoid silently capping data to a valid range. Discussed in fix: unblock PPO multi-GPU training #18.
• Refactor data interface & graph template — refactor src/worker/executors/mixins/data.py and src/worker/executors/utils/graph_templates.py to simplify the convoluted logic.
• Make SSH container only see the allocated hardware resources. Discussed in feat: cap SSH session container resources by spec and worker config #50.
• Consider making env parsing stricter. Discussed in feat: cap SSH session container resources by spec and worker config #50.

Operations

• Worker scratch auto-remove policy — Auto remove old data on RESULTS_DIR and scratch so long-lived workers don't fill disks.
• Task error logs — Now, error logs for task execution are not included in the task logs, making it difficult for the users to debug when something goes wrong during task execution, especially when the submitted workflow is malformed. fix: include task execution errors in task logs #60

Bugfix

• Fix SSH resource access — Currently, SSH containers can access all CPU and memory resources of the machine on which the target worker is running. We should limit the accessible resources based on the requested task spec/max accessible resources set by the worker’s config. feat: cap SSH session container resources by spec and worker config #50
• Misleading CLI error message. flowmesh stack up worker gpu -t 1 raises "No such option: -t" while flowmesh stack up worker gpu leads to "Got unexpected extra arguments (worker gpu)". We should consider swapping the priority of the error reporting logic.

Alternatives considered

No response

Migration / compatibility

No response

Feedback period

No response

CC list

@kaiitunnz @J1shen @tjluyao

Before submitting

• I have searched existing issues and confirmed this is not a duplicate.

[J1shen]

LGTM. I will help in some refactor jobs.