Roadmap: run your org locally: the server's agent hierarchy as a swarm alongside you (opt-in)
Maintainer thường phản hồi trong vòng 1 ngày
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
- 5/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Cần làm rõ
- Mức độ hoạt động
- Sôi nổi
- Công nghệ
- electron, ollama, typescript
- Lĩnh vực
- ai-infra-agents
Hướng nghiên cứu
This is an unscheduled roadmap, so there is no fixed task. The payload points at the local governance store, wake queue, coordinator and scheduler in Projects, and at the server's heartbeat and lease model. Starting here means agreeing the mode (A, B or C) and the lease design with maintainers before any code. Done means a written design and an approved scope, not a patch.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Roadmap. Not scheduled yet.
Today Muster polls a snapshot of a Muster Server (Paperclip) org, and a person can check out one task to work on locally. The org's own architecture stays on the server: its roles, chain of command, wakes, delegation, review stages, budgets and routines. Users should be able to run their org locally with that same architecture, as a swarm of role agents working alongside them while they chat. Without that, working locally loses much of its point.
How the server orchestrates (from the Paperclip source)
- Heartbeats, not long-running agents. Every trigger goes through
heartbeat.wakeup(agentId, {source, reason, payload, idempotencyKey}). The sources are timer, assignment, on-demand and automation. Wakes also come from comments, resolved blockers, approvals and decisions (issue-*-wakeup.ts,decision-wakeup.ts). Wakes are coalesced and suppressed inheartbeat/queue.ts. - Each run:
- Read identity and
chainOfCommand(thereportsTowalk). - Pick from the inbox in this order: in progress, then in review if woken by a comment, then to do.
- Check out atomically (
checkoutRunId/executionRunId). A 409 means never retry. - Do the work, then leave an explicit disposition: done, blocked (with a routable wait) or in review.
- Compare-and-clear the locks. Recovery reclaims stale locks.
- Read identity and
- Delegation creates child issues and blockers. A parent wakes when its blockers resolve. Hiring goes through
can_create_agents, optionally with an approval. The "CEO" is simply the agent with noreportsTo. - Review and approval stages live in
executionPolicy.stages[]. Each participant's PATCH advances the stage or requests changes. Thread interactions are suggest_tasks, ask_user_questions, request_confirmation, checkbox, item verdicts and connection intent. Each carries a resolver and continuation policy. - Budgets are scoped by company, agent or project, in billed cents per month or lifetime, with incidents and daily run and cost caps. Routines cover cron, webhook and API triggers, with concurrency and catch-up policies.
What Muster already has locally
Projects already re-implements much of this. It has the governance store (wakes and runs, holds, execution-policy state, watchdogs, monitors, breakers), the wake queue, coordinator, review, watchdog and hire blocks with reportsTo, interactions, the scheduler (leases, concurrency, budgets), project governance timers and the mailbox.
What's missing
- A live two-way sync of roster,
reportsTo, execution policy and budgets. Import is one-shot today. - A mapping from server agents to local role agents: instruction bundle, adapter and model, permissions.
- Server-equivalent budget policies (agent and company scope, billed cents, incidents, daily caps).
- Routines as a local scheduler.
- Server review and approval stages mapped onto the local review flow, with write-back to the server.
- Chain-of-command context for role agents, and server-style routing of comments and mentions.
Stays on the server: the authoritative assignee and lock, the audit trail, approvals bound to real board users, secret grants, company-wide budget enforcement. Local agents act only through the existing API with the person's token.
Modes
- A. One task locally. This is today's mode. It is safe because a human-assigned task never wakes a server agent.
- B. Hybrid. Check out a subtree or a role. Local agents work that slice and the server keeps the rest. Needs a subtree lease.
- C. Mirror the org. Local role agents act as the org's roles in a Project, with write-through sync to the server. Server agents for mirrored roles are paused, or the roles are explicitly taken over.
Opt-in, never automatic: a setting in Settings, or Muster asks the first time you work in an org or project how you want to use it (A, B or C) and why.
Risks
- Double execution with server wakes: take roles over explicitly and verify the lease before every local start.
- Leases: a lease per role, with expiry and renewal, and compare-and-clear like the server's.
- Cost: report cost events up and enforce a local cap before each wake.
- Secrets: references only, never values.
- Sync conflicts: every write checks that the server still looks as expected.
- Fan-out loops: keep the circuit breakers, concurrency cap and holds, and add a per-org daily run cap.
UI: a swarm with you, without clutter
Keep the current look and add no new top-level surfaces.
- One chat. The person's conversation stays a single chat. Role agents appear as small chips (name and title) on task rows.
- Agent-to-agent traffic collapses to one activity line per task ("CTO delegated 3 tasks · QA reviewing"). It expands to the mailbox thread.
- Org strip. A collapsed strip shows live state dots (idle, running, waiting on you, blocked) and the reporting tree on hover. It is hosted in the existing Roster.
- Needs-you items (questions, approvals, secret requests) go to the existing Inbox, not inline.
- Status pill. A small pill ("Org local · 4 running · budget 62%") opens the strip and has Pause all.
- No streaming by default. Events are grouped by wake reason and task. An agent's tokens stream only when you open its run.
The UI needs its own design pass with before and after screenshots before any build.
Related: #434 (full task context locally), #134 (local org onboarding), #168 (Huddle), #143 (remaining parity), #150 (circuit breaker), #151 (limit-aware scheduler).
- Ngôn ngữ chính
- TypeScript
- Star
- 3
- Fork
- 0
- Merge trung bình
- 17 giờ 33 phút
- Pull request đã merge (30 ngày)
- 163
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọ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 musterhq/muster-code
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 62/100
musterhq/muster-code#866 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
p2 type:feature
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 35/100
musterhq/muster-code#843 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
p1 type:feature
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 25/100
musterhq/muster-code#840 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
p1 type:feature
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 30/100
musterhq/muster-code#829 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
type:bug
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 70/100
musterhq/muster-code#815 ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của musterhq/muster-code
Issue tương tự
-
[analytics-core] getQueryParams does not decode `+` as space and truncates values containing `=`Đang mởbug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
amplitude/Amplitude-TypeScript#2179 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày
-
ci good first issue severity: low
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 68/100
TMHSDigital/GH-Arcade#111 ·
-
AsnIntegerConverter.toASN coerces strings with +value, rounding integers outside safe-integer rangeĐang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
PeculiarVentures/asn1-schema#189 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
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 82/100