Move a channel to another host so work can continue on that machine
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 5/5
- Thời gian dự kiến
- Hơn một tuần
- Mức phù hợp với người mới
- 25/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- typescript
- Lĩnh vực
- backend, distributed-systems
Hướng nghiên cứu
Start from the existing channel backup mechanism and the Kill operation, which the design notes explicitly contrast with a handoff; also read issues #58 (tracking), #166 (single worker ownership) and #15 (project identity across hosts). Map what pi's durable state includes versus project/lane worktrees, then define a state machine where source execution stops before destination resumes. Done means a validated two-machine transfer preserving channel identity and lane files, with a recovery path on interrupted transfer.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
During a meeting, or while using the machine for other work, an agent can become distracting: applications open, computer use takes over the screen, and audio plays. The work should continue, but on another machine.
Add a way to move a channel's work to another host on the team's tailnet. The user should be able to choose a destination, hand off the channel, and keep following the same channel from the original machine while the agent uses the destination's screen, applications, and audio.
Desired workflow
- A channel is doing useful work on the machine the user now needs for a meeting.
- The user chooses Move to another host and an available destination.
- Ace checks the destination, pauses the channel's execution, transfers the necessary state and files, and resumes there.
- The original machine is free of that channel's execution activity. Its client can remain open for chat and progress; viewing the channel does not move execution back.
Acceptance
- Preserve the channel's identity, name, summary, chats and subagents, history and tool results, usage, owner, and collaborator-agent setting. Participants continue in the same channel.
- Preserve the lanes and work needed to continue, including branches, unpushed commits, dirty files, and untracked files. Handle different project and lane paths on the destination without requiring the user to commit or push first.
- Resume unfinished work where safe. Clearly surface tools, terminals, servers, or native app/browser state that must restart or be re-established; avoid blindly replaying actions with side effects.
- Complete one recoverable handoff: source execution ceases before destination execution resumes. A reconnect, crash, or restart must not leave two machines executing the same channel. Failed transfers preserve the source work and provide a clear recovery path.
- After the handoff, native UI activity, browser automation, audio playback, and channel-owned subprocesses run on the destination. Make the current execution host visible in the channel.
- Check destination readiness, including project files, tools and model access, and any needed desktop session, applications, devices, and macOS permissions. Explain missing requirements before claiming the channel has moved. Use the destination's configured credentials and OS grants.
- Keep the existing tailnet trust model and single collaborator-agent switch.
Design notes
A local channel needs its durable pi state and execution moved. For a hosted channel, its team-deployed cell can remain in place while its workspace changes. Resolve these paths under the same user-facing intent without making hosted infrastructure a prerequisite.
Existing channel backups are not a complete migration mechanism: they exclude project/lane worktrees and retain original paths. Preserve pi's durable state and resumability; Kill durably prevents continuation and is not the handoff operation. Define what can transfer, what must restart, and what requires user intervention, especially for already-open applications and devices.
Validate with real work across two machines, including an active run, uncommitted/untracked lane files, an interrupted transfer, and desktop/audio activity continuing on the destination while the original client remains attached.
Tracked by githubnext/ace#58. Related: githubnext/desktop-tools#11 (native UI), githubnext/ace#10 (two-machine validation), githubnext/ace#13 (hosted channels), githubnext/ace#15 (project identity across hosts), githubnext/ace#166 (single worker ownership of a channel, which a handoff relies on).
- Ngôn ngữ chính
- TypeScript
- Star
- 1
- Fork
- 0
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Không có hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của githubnext/ace2
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 94/100
githubnext/ace2#487 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 90/100
githubnext/ace2#486 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
githubnext/ace2#459 ·
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 88/100
githubnext/ace2#437 ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 35/100
githubnext/ace2#442 ·
Tất cả issue của githubnext/ace2
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 65/100
521xueweihan/HelloGitHub#4025 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
voidzero-dev/void#478 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 69/100
Small-tailqwq/dsh-deep-whale#207 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
The inspector never shows the instances field, so scaling out is unreachableCó thể đã có người làm @Mrkewl đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
xevrion/breakscale#96 ·
Maintainer thường phản hồi trong vòng 4 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
Flux159/mcp-server-kubernetes#384 ·