# Reported issues for mlua-swarm Pod holds 17 of 22 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user. Back to [mlua-swarm](/mcp/mlua-swarm). ## Most discussed ### [Refactor] ID lifecycle audit — canonicalize run_id / task_id / worker_handle / sid / req_id / capability_token and fix six drift observations # [Refactor] ID lifecycle audit — canonicalize `run_id` / `task_id` / `worker_handle` / `sid` / `req_id` / `capability_token` and fix six drift observations ## Summary Several distinct identifiers flow through the swarm run pipeline — `run_id`, `TaskId`, `SessionId`, `WorkerId`, `worker_handle`, the operator session `sid`, `req_id`, and the embedded `capability_token`. A short `grep`-based audit surfaces six concrete drift observations, and the operator-facing mental model (task_id stable acro [Read the thread](https://github.com/ynishi/mlua-swarm/issues/11) · 2026-07-06 · closed · 3 comments ### [Enhancement] Bump agent-block to 0.33.0 — HTTPS MCP endpoints need the TLS-enabled mcp.connect_http (raises MSRV to 1.88) ## What Bump `agent-block-core` / `agent-block-types` from `0.31.0` to `0.33.0` in `[workspace.dependencies]`. ## Why `mse` reaches an MCP endpoint through agent-block's `mcp.connect_http`. Up to agent-block 0.31.0 that Streamable HTTP transport was built **without a TLS backend**, so any `https://` endpoint failed at connect with: ``` ConnectError("invalid URL, scheme is not http") ``` agent-block 0.32.0 fixed it: the `mcp-http` feature now enables rmcp's `reqwest-tls-no-provider` (rustls [Read the thread](https://github.com/ynishi/mlua-swarm/issues/99) · 2026-08-27 · closed · 1 comment ### LaunchAgent should not chdir into a source checkout ## Problem The bootstrapped LaunchAgent sets `WorkingDirectory` to a source checkout of this repository. That couples the daemon's ability to start to the presence of a developer checkout it does not otherwise need at runtime: the config lives under `~/.mse/`, and `blueprint_ref_base` is an absolute path pointing outside the checkout. Move, rename or delete that checkout and `mse serve` becomes permanently unstartable. ## What it looks like when it happens `mse serve` exits with **78 (`EX_CO [Read the thread](https://github.com/ynishi/mlua-swarm/issues/97) · 2026-08-13 · closed · 1 comment ### [Enhancement] Add `mse server` subcommand family for launchd lifecycle management (MCP recovery path completeness) # [Enhancement] Add `mse server` subcommand family for launchd lifecycle management (MCP recovery path completeness) ## Summary `mse` binary currently has no first-class subcommand for managing its own server lifecycle (install / bootstrap / bootout / restart under launchd). The install path lives in `scripts/launchd/install.sh`, and mse-mcp is a thin wrapper over binary subcommands, so operations that exist only in the shell script are not reachable through MCP tools. This creates a recovery [Read the thread](https://github.com/ynishi/mlua-swarm/issues/69) · 2026-07-19 · closed · 1 comment ### [Enhancement] bp_dsl authoring DX: scaffolding CLI/MCP (`mse bp new`) + lint auto-recovery with concrete fix hints # [Enhancement] bp_dsl authoring DX: scaffolding CLI/MCP (`mse bp new`) + lint auto-recovery with concrete fix hints ## Summary Sibling issues (`[Bug] halted_at missing` and `[Enhancement] worker_binding compile-lint`) surface a shared root: authors writing `.bp.lua` from scratch hit compile-lint failures whose fix is mechanical, but the current authoring loop has neither a preventive layer (start from a template that already sets the required fields) nor a curative layer (lint tells you the e [Read the thread](https://github.com/ynishi/mlua-swarm/issues/62) · 2026-07-17 · closed · 1 comment ### [Docs] flow-dsl: authoring guide + bundled .bp.lua samples # [Docs] flow-dsl: authoring guide + bundled .bp.lua samples Splits the documentation follow-ups out of #52. Deliberately sequenced **after** the authoring enablers and after first real-world DSL usage, so the guide documents proven workflows instead of untested ones. ## Summary The Lua authoring DSL (v0.10.0, #52) has no bundled documentation yet: the Blueprint authoring guide does not mention `.bp.lua` / `mse bp build`, and there are no `.bp.lua` samples exposed as MCP resources. First-time [Read the thread](https://github.com/ynishi/mlua-swarm/issues/55) · 2026-07-14 · closed · 1 comment ### [Enhancement] bp_explain_agents (batch): sweep all agents in a Blueprint in one call # [Enhancement] bp_explain_agents (batch): sweep all agents in a Blueprint in one call ## Summary Current `bp_explain_agent` is per-agent. Sweeping a Blueprint with 15+ agents (e.g. a Phase A coding orch) costs 15 calls / 15 HTTP round trips. Add a batch endpoint that returns a per-agent drift summary in one call. ## Proposal Server: ``` GET /v1/blueprints/:id/agents/explain ``` Returns: ```json { "blueprint": { "id", "version" }, "agents": [ { "name", "kind", "worker_binding", "d [Read the thread](https://github.com/ynishi/mlua-swarm/issues/47) · 2026-07-12 · closed · 1 comment ### [Enhancement] bp_doctor contract lint: verify referenced tool names against the live MCP registry + flag missing output-contract declarations # [Enhancement] bp_doctor contract lint: verify referenced tool names against the live MCP registry + flag missing output-contract declarations ## Summary `bp_doctor` (#28) currently performs a single class of static check: agent profile size (bytes/lines thresholds, OK/WARN/BLOCK with the BLOCK band disabled by default). In practice another failure class recurs that static inspection could catch at authoring time: **phantom specs** — agent definitions that reference tool names that do not exi [Read the thread](https://github.com/ynishi/mlua-swarm/issues/45) · 2026-07-11 · closed · 1 comment ## Most recent ### [Enhancement] Task resume — fix & re-execute a failed step (and its downstream) without replaying the whole flow # [Enhancement] Task resume — fix & re-execute a failed step (and its downstream) without replaying the whole flow ## Summary The core ask: when a Blueprint run stops (or one step returns a failing verdict) mid-flow, let the user **fix the Blueprint / agent definition and resume the task from that step**, without replaying every unchanged upstream step from scratch. Fix-then-resume is the normal iterate loop. Between the stop and the resume, the natural expectation is that the Blueprint itsel [Read the thread](https://github.com/ynishi/mlua-swarm/issues/71) · 2026-07-19 · open · 0 comments ### [Bug] swarm_status MCP tool returns stale 'running' for completed detach runs # [Bug] `swarm_status` MCP tool returns stale `running` for completed detach runs ## Summary After a `detach: true` run completes end-to-end (all spawn frames acknowledged, server writes final `result_ref` and marks the run `done` in the SQLite `RunStore`), calling `mcp__mse__swarm_status(run_id)` still returns `{status: "running"}`. Meanwhile a direct `GET /v1/runs/:id` against the same server returns `status: "done"` with a full `step_entries` list and `result_ref` populated. The MCP tool r [Read the thread](https://github.com/ynishi/mlua-swarm/issues/67) · 2026-07-18 · closed · 0 comments ### [Bug] mse bp new pipeline scaffold does not surface init_ctx seeding, causing silent launch failure # [Bug] `mse bp new pipeline` scaffold does not surface `init_ctx` seeding, causing silent launch failure ## Summary Blueprints generated by `mse bp new pipeline` pass `mse bp build` compile-lint successfully, but the first `swarm_run` against them fails at flow evaluation with `launch: flow eval: path not found: $.d.`. In detach mode, the run silently stays in `running` state, the joined operator's `pending_wait` never receives a spawn frame, and no obvious error surfaces to the [Read the thread](https://github.com/ynishi/mlua-swarm/issues/64) · 2026-07-18 · closed · 0 comments ### feat: file-path upload for worker_submit (@file: sentinel) ## Motivation Some workers produce large response bodies (multi-KB structured output) and submit them inline via `mcp__mse__mse_worker_submit`. Two problems appear: 1. **Duplicate emission cost**: LLM-driven workers frequently "rehearse" a large response body as an inline text stream before calling the submit tool, then submit the same body again as the tool argument. This effectively doubles output tokens for kilobyte-scale payloads. 2. **Reliability**: Inline body emission couples response q [Read the thread](https://github.com/ynishi/mlua-swarm/issues/42) · 2026-07-11 · closed · 0 comments ### [Enhancement] Detach the flow-eval driver from the sync launch request (async launch + explicit await) # [Enhancement] Detach the flow-eval driver from the sync launch request (async launch + explicit await) ## Summary Today, `POST /v1/tasks` (and the MCP `swarm_run` tool that proxies to it) is a synchronous launch: the HTTP handler drives the in-process flow eval **inline inside its own request future**, wrapped in `tokio::time::timeout(sync_timeout_secs, ...)`. This was an intentional v1 semantic (fail-loud sync launch, see the Guard 2 work): on ceiling expiry the timed-out future is dropped, [Read the thread](https://github.com/ynishi/mlua-swarm/issues/37) · 2026-07-10 · closed · 1 comment ### [Feature] Structured worker degradation reporting — persist tool failures / fallbacks on the Run record instead of losing them to silent workarounds # [Feature] Structured worker degradation reporting — persist tool failures / fallbacks on the Run record instead of losing them to silent workarounds ## Summary LLM workers that hit a tool failure mid-task tend to work around it silently: they fall back to an alternative tool or a weaker method and still submit a plausible-looking result. The engine currently has no channel for this — `mse_worker_submit` / `POST /v1/worker/submit` carries only the result body, so a degraded run and a clean ru [Read the thread](https://github.com/ynishi/mlua-swarm/issues/32) · 2026-07-09 · closed · 0 comments ### [Feature] Ship a Claude Code plugin bundle (plugins/mse): Blueprint-authoring DX agents + skills # [Feature] Ship a Claude Code plugin bundle (`plugins/mse`): Blueprint-authoring DX agents + skills ## Summary Blueprint authoring is the hardest part of adopting mlua-swarm: Flow IR node/expr ops, worker binding, projection placement, and context-supply tiers all have to line up before a Blueprint runs. The building blocks for guided authoring already exist — `mse://api/blueprint-schema`, bundled samples, the agent-md authoring guide (#28), and the `bp_doctor` MCP tool (v0.8.0) — but they ar [Read the thread](https://github.com/ynishi/mlua-swarm/issues/30) · 2026-07-09 · closed · 1 comment ### [Enhancement] Add doctor check for oversized agent.md (SubAgent system prompt) # [Enhancement] Add doctor check for oversized `agent.md` (SubAgent system prompt) ## Summary SubAgent `agent.md` files (the durable system prompt fetched into every SubAgent context) have no size discipline enforced anywhere in the toolchain. In practice, `agent.md` files drift toward embedding accident logs, restated CLAUDE.md content, tool schemas, and long narrative — reaching 500+ lines / ~77 KB in extreme cases. At that size, when the fetch-based delivery path pushes the `agent.md` body [Read the thread](https://github.com/ynishi/mlua-swarm/issues/28) · 2026-07-09 · closed · 1 comment ### [Enhancement] Adopt utoipa (or aide) to publish an OpenAPI 3.1 spec of the HTTP surface + wire it into the release-plz drift-detection loop # [Enhancement] Adopt utoipa (or aide) to publish an OpenAPI 3.1 spec of the HTTP surface + wire it into the release-plz drift-detection loop ## Summary The HTTP surface of `mse serve` (`crates/mlua-swarm-server`) has no schema artifact today — external callers must read `build_router` to learn the contract, and API drift between releases is only caught by `cargo-semver-checks` on the *Rust* API surface, not the *HTTP* one. Two recent events motivate closing that gap now, not later. ## Motiva [Read the thread](https://github.com/ynishi/mlua-swarm/issues/25) · 2026-07-08 · open · 1 comment The remaining reports are on [the project's issue tracker](https://github.com/ynishi/mlua-swarm/issues).