mirror of
https://github.com/multica-ai/multica.git
synced 2026-08-05 09:30:05 +02:00
agent/lambda/b70477d6
4396 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Lambda
|
39a61c2ab7 |
feat(issues): description version history with inline diff and restore (MUL-5470)
Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
e45a8f6c12 |
fix(daemon): scan comment roots before bulk reads in agent catch-up (MUL-5372) (#6093)
* fix(daemon): scan comment roots before bulk reads in agent catch-up The mandatory step-3 catch-up in the issue runtime brief asked for `--recent 10`. `--recent N` caps THREADS, not comments: each returned thread carries its root plus every descendant with no depth bound, so on an issue with fewer than N root threads it returns the entire comment history. Because the step is mandatory and fires on every run, every reply turn re-read the whole issue -- and on comment-triggered turns it duplicated the bounded thread read the per-turn message had already pointed at, so the same bytes were fetched twice. Lead the step with `--roots-only --summary` instead: every top-level thread with reply_count and last_activity_at, contents clipped. That keeps the property the step exists for -- the agent still sees every thread that exists, so it cannot act on stale context -- and makes the drill-down into `--thread <id> --tail 30` explicit. `--recent 10` stays documented for when several complete threads really are needed, now with its saturation semantics spelled out. Measured on a live 2-thread issue: 21,249 -> 1,518 bytes for the mandatory read (-93%), and the duplicate 11,082-byte thread read is gone. The brief stays byte-identical across runs of a session (MUL-5377): the new text interpolates only the issue id, no per-run state. The three per-turn pointers that express the same rule move with it so the two layers cannot drift. MUL-5372 Co-authored-by: multica-agent <github@multica.ai> * refactor(daemon): keep comment-read flag semantics in one place The previous commit fixed the payload shape but restated the read surface in four places: the workflow step, both per-turn prompt fallbacks, and the cold-start hint each explained what `--recent 10` does. `## Available Commands` is already the brief's single discovery point for these flags, and `TestInjectRuntimeConfigStaticCatchUp` pins it as such -- so those restatements were duplicated reference text, and the per-turn ones were paid on every turn rather than once in the cached prefix. Move the `--recent N` saturation warning into the `comment list` line in Available Commands, next to the flags it qualifies, and add `--roots-only` and `--summary` to that signature so the bounding options are discoverable where an agent already looks. Workflow steps and per-turn hints now name only the reads they actually want run. Per-turn prompt sizes: assignment 1170 -> 749 bytes (-36%), cold-start comment turn 1550 -> 1355 (-13%). Step 3 is 1065 bytes and no longer carries a ready-to-paste bulk read. MUL-5372 Co-authored-by: multica-agent <github@multica.ai> * docs(daemon): address review nits on comment-catchup change Three cosmetic follow-ups from review: - `--recent N` saturation warning said it hands back "the entire history"; resolved threads are still folded by default on that read, so say so. - Rename two tests whose names still advertised `--recent` after their assertions stopped mentioning it, plus the one added in this branch whose name referenced a bulk read the step no longer contains: MentionsRecent -> ScansRootsFirst, ScansRootsBeforeBulkRead -> ScansRootsFirst. - Fix the stale doc comment that still described the mandatory read as bounded to "the recent active-thread window". No behavior change. MUL-5372 Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Multica Eve
|
c25a82eee0 |
perf(agents): fast model discovery on runtime switch (MUL-5444) (#6098)
* perf(agents): make runtime model discovery fast on runtime switch (MUL-5444) Switching runtime in the agent creation form left the model picker spinning for ~8-20s. Two costs stacked up: - the list-models request sat in the store until the daemon's next scheduled heartbeat (0-15s, avg 7.5s of pure dead wait), and - the daemon then enumerated the catalog locally (static for claude, but a CLI/ACP round trip up to ~15s for everyone else). Both are addressed with the two standard techniques for a slow, low-frequency, read-only operation: push instead of poll, and stale-while-revalidate. Push (removes the heartbeat wait): - new additive `daemon:pending_work` hint, runtime-scoped, delivered through the existing daemon WS hub and the Redis relay so the API node holding the socket does the delivery. - the daemon answers a hint with ONE immediate heartbeat and dispatches what it claimed. The hint deliberately carries no work, so nothing has to be un-claimed when delivery fails and a duplicate hint cannot duplicate work - PopPending stays the atomic claim. - per-runtime coalescing plus a 1s floor keeps a caller-triggered hint from becoming a heartbeat amplifier. Cache (removes the discovery wait on repeat opens): - server-side per-runtime catalog cache (in-memory single-node, Redis multi-node) written on every successful report. - a snapshot younger than 15min answers the POST immediately as an already-completed request; older than 60s it also enqueues a background refresh that only warms the cache. - only supported, non-empty catalogs are cached; a completed-but-empty report invalidates instead, while a failed report keeps serving the last known good list. Frontend: staleTime 60s -> 5min and gcTime 30min, so a runtime revisited in the same session renders from cache and revalidates in the background instead of showing the spinner again. Compatibility: every wire change is additive. Old daemons ignore the unknown hint type and keep using the scheduled heartbeat; new daemons against an old server simply never receive one. The cached response is shaped exactly like a completed live discovery apart from the optional `cached` / `cached_at` markers. Co-authored-by: multica-agent <github@multica.ai> * fix(agents): address review on model discovery SWR (MUL-5444) Sol-Boy's review on #6098 found the client cache could outlive the server's own staleness promise, and that the two changed endpoints were still cast rather than validated. Must-fix 1 — client freshness now derives from the served answer. `staleTime` was a flat 5min, so a 14-minute-old snapshot (which the server returns while queueing its own refresh) was held as fresh for another 5min: observable staleness became server window + client window, and the refreshed catalog never reached the tab that triggered the refresh. `staleTime` is now a function of the query data: a `cached` answer is stale on arrival (bound stays the server's window alone, and the next mount/focus picks up the refreshed snapshot), while a live discovery — which just measured the truth — is trusted for the full 5min so a cold runtime is never re-enumerated inside one form session. `gcTime` stays 30min, so a revisited runtime still renders from cache and revalidates in the background; the pickers gate their spinner on `isLoading`, which stays false throughout. Must-fix 2 — both model-discovery responses go through a zod schema. `POST /api/runtimes/{id}/models` and its poll companion were casting network JSON to `RuntimeModelListRequest`, which the root CLAUDE.md API-compatibility rules forbid. Added a lenient schema (`status` stays `z.string()`, `supported` defaults to true, `.loose()` keeps unknown fields) plus a fallback record whose `status` is `failed`: a malformed body now surfaces "discovery failed" with manual entry still usable instead of a fabricated empty catalog or an endless spinner. `resolveRuntimeModels` was tightened to match — only an explicit `completed` is a catalog, so an unrecognised status is an error rather than a silent empty list, and `supported` can no longer be `undefined`. Nit — the in-memory catalog cache now deep-copies each entry's `Thinking` (and its level slice) and `ServiceTiers`, so it delivers the independent value its comment promises and matches the Redis backend's JSON round-trip semantics. Tests: staleTime policy for cached/live/no-data; a QueryObserver test proving the refreshed catalog reaches the same client with no blank loading state; unknown-status and omitted-`supported` handling; schema tests for live, cached, old-backend and nine malformed shapes; client tests that both endpoints degrade to an explicit failure; nested-field mutation isolation for the cache. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
280fa28e0d |
fix(agent): deny CodeBuddy's interactive plan-mode tools in headless runs (MUL-5383) (#6104)
CodeBuddy exempts AskUserQuestion and ExitPlanMode from permission-mode finalization, so `--permission-mode bypassPermissions` never auto-approves them. Once the model entered plan mode the session mode is Plan, not BypassPermissions, so ExitPlanMode also missed the daemon's bypass fast-path and went to the SDK permission bridge — which waits with no timeout for a confirmation the headless runtime cannot render. The task sat in-flight until the 2h tool watchdog, and users killed it by hand. Deny EnterPlanMode/ExitPlanMode alongside the AskUserQuestion we already deny. Each tool is passed as its own argv value because CodeBuddy matches disallowedTools entries exactly and does not split on commas. Also send `allowed: true` on control_response: CodeBuddy's SdkPermissionClient reads `allowed`, not Claude Code's `behavior`, so the daemon's "auto-approve" was being read as a denial. Fixes #6012 Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
30318b79bc |
MUL-5426: fix(daemon): retire sessions whose history the provider refuses to replay (#6083)
* fix(daemon): retire sessions whose history the provider refuses to replay A run killed mid-reply (machine shutdown, force-quit, SIGKILL) can leave an empty assistant message in the agent CLI's transcript. Every later resume replays it, the provider rejects the request, and the (agent, issue) pair is bricked with no self-healing and no user-facing recovery. Multica already has the mechanism for this — poisoned-session classification — but its detector paired "400" with "invalid_request_error", which is the Anthropic wire shape. The same defect reported by any other provider carried neither token, so it classified as agent_error.unknown: resume-safe by omission. GetLastTaskSession kept handing back the dead session on every follow-up, manual Rerun resolved it through the same predicate, and the in-turn fresh-session retry never fired because ResumeRejected is false here (nothing rejected the resume — the transcript loaded and the provider refused to replay it). Add taskfailure.UnresumableHistory, which recognises the defect by what the provider says is wrong — some content is empty, and here is which message in the history — rather than by status code or provider name. Both signals are required, so a tool reporting "field must not be empty" does not match. Wire it into the four places that decide whether a session survives: - classifyPoisonedError, so the task is written as api_invalid_request - shouldRetryWithFreshSession, so the turn recovers on all 17 backends instead of the subset whose adapter learned to detect it; the tools == 0 gate is unchanged, so a run that already used a tool is never re-run - ResumeUnsafeFailure, covering the manual-Rerun path - both resume queries, as defense-in-depth for hosts whose daemon predates this (self-host daemons upgrade on their own cadence) Fixes #6066. Also covers the daemon half of #5760. Co-authored-by: multica-agent <github@multica.ai> * fix(session): close the Chat and fresh-retry paths that resurrect a poisoned session Review found the previous commit stopped short in two places, both of which put the dead transcript back in play. Chat never consulted the guarded query. The claim handler reads chat_session.session_id first and only falls back to GetLastChatTaskSession when it is empty, so a poisoned pointer there bypasses every filter that query applies. The fail path merely declined to OVERWRITE the pointer, leaving it in place. It now clears it in the same transaction, matched on session and runtime so a concurrent turn's newer pointer survives. The promote guard moves to ResumeUnsafeFailure as well — the reason-only check passed an un-upgraded daemon's agent_error.unknown row and re-pinned what the clear had just removed. GetLastChatTaskSession also kept the row-level filter the issue query dropped in GH #5975: it discarded the newest poisoned row and fell back to an older completed row carrying the same dead session. It now judges each session by its latest terminal state, matching GetLastTaskSession. A recovered turn could not retire anything. A terminal report carried one session_id, and an empty one meant both "nothing to report" and "forget the old session", so a fresh-session retry that SUCCEEDED left the id it retried away from selectable — through an older completed row on the issue, or through the chat pointer. agent_task_queue.retired_session_id records the abandonment itself, reported on every terminal path including completed, and both resume lookups exclude it. This is the contract gap the previous PR deferred; the fresh-retry path now runs on all backends, so deferring it is not safe. Also narrows what the cross-backend test claims: it pins the shared decision, not that all 17 adapters surface the error into Result.Error (#5760 is the counter-example), and says so. Co-authored-by: multica-agent <github@multica.ai> * test(session): require pgx.ErrNoRows in the resume-exclusion assertions The `if err == nil && prior.SessionID.Valid` form these tests shared is false-green: any real fault — undefined column, syntax error, dead connection — makes err non-nil, so the condition is false and the test passes. Run against a database missing this branch's new column, the exclusion tests reported PASS on a SQLSTATE 42703, meaning they could not have caught a broken query. requireSessionExcluded demands pgx.ErrNoRows specifically and fails loudly on anything else, so a green run now means the filter worked rather than the query never ran. Applied to all nine sites, not just the four this branch added: the other five guard the same GetLastTaskSession exclusion behaviour that this branch changes, so leaving them false-green would leave the change under-tested. All nine pass on a correctly migrated database. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
06a100d612 |
fix(editor): render proxy-mode inline images from an authenticated byte fetch (MUL-5445) (#6091)
Inline media re-sign is a two-step repair: detect that a URL is auth-gated (fixed in #6029), then swap in a URL a native <img> can load. The second step only worked where the server had a signed URL to give — CloudFront signing, or presign mode with a DownloadPresigner. In proxy mode GetAttachmentByID returns `/api/attachments/<id>/download` again, the renderer rejected it and kept the URL it already knew 401s, so the image stayed broken and the metadata request was pure overhead. Proxy is the default for self-hosted storage on an internal host: `auto` mode forces it for a dotless hostname (docker-compose MinIO at `http://minio:9000`), localhost, .local/.internal/.lan/.docker suffixes, and private/loopback IPs. Combined with a client that cannot ride the session cookie on a native resource fetch — Desktop's file:// renderer, the mobile webview, split-origin web (cookies are SameSite=Strict) — every inline image in such a deployment fails. When the refreshed metadata confirms there is no signed URL, pull the bytes through the authenticated API client and paint them from an object URL. The metadata request stops being wasted: it is the per-attachment probe that decides signed-URL vs bytes, so presign/CloudFront clients never double-fetch. - getAttachmentBlob goes through fetchRaw, inheriting auth headers, 401 recovery and the ApiError shape, mirroring getAttachmentTextContent. - The byte fetch is gated on the image branch; a file card only needs a link and must not pull a large archive into renderer memory. - The object URL is revoked on unmount, and the blob query is capped with a 5 minute gcTime so an image-heavy thread does not pin every screenshot. - Copy Link keeps handing out the durable URL — a blob: URL resolves only inside this renderer session. Co-authored-by: J <agent-j@multica.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
607209de7c |
fix(avatar): serve avatars through a signed endpoint on private buckets (MUL-5393) (#6088)
* fix(avatar): serve avatars through a signed endpoint on private buckets (MUL-5393) Avatar uploads persisted the raw storage object URL into `avatar_url`. On a deployment whose bucket is private and has no public CDN domain (S3 with Block Public Access, R2, MinIO) that URL is a guaranteed 403 in the browser: ATTACHMENT_DOWNLOAD_MODE only ever applied to the attachment download endpoint, so every user / agent / squad / workspace avatar rendered broken even though the upload itself succeeded. Resolve at read time instead of at upload time. What is persisted stays the durable object reference, so nothing with a TTL is ever written to the database and avatars saved by an older build are fixed without a backfill. What is served is `/api/avatars/<sig>/<key>`, a stable URL the server resolves per request through the deployment's existing storage download policy (presigned redirect, CloudFront-signed redirect, or proxied body). The endpoint is unauthenticated and the HMAC signature is the credential: the session cookie is SameSite=Strict, so an auth-gated URL cannot be a native <img src> from Desktop, a mobile webview, or a split-origin self-hosted web app. The signature covers the storage key and only image extensions resolve, so an avatar_url pointed at a private document cannot launder it into a publicly fetchable URL. Deployments that already work are untouched: a public CDN domain without per-request signing, and the local-disk backend whose /uploads/* route is public, both keep returning the raw URL. Fixes #6024 Co-authored-by: multica-agent <github@multica.ai> * fix(avatar): only publish avatar-class objects through the signed endpoint (MUL-5393) Review found that being able to name a storage object was treated as permission to publish it. `ownedStorageKey` proved only that a URL came from this deployment's storage, and every image-shaped key was then signed — while the avatar update endpoints accepted any raw storage URL. A caller who had seen a private image attachment's URL could submit it as their own avatar, and the unauthenticated endpoint would keep re-signing it indefinitely. A user avatar propagates to every workspace that user belongs to, so the leak crossed workspace boundaries. Add the missing authorization rule: an object is serveable as an avatar only when it is avatar-class — a standalone image upload not attached to an issue, comment, chat session, chat message, or task. The check resolves the backing attachment row from the id UploadFile embeds in the object filename, so it needs no lookup by URL and no new index. It is enforced on both sides. The write side rejects such a value with 403 before anything is stored; the read side re-checks per request, which is what makes the guarantee hold for rows written before this existed and revokes the URL if an object is later bound to a comment or chat. Scope is the `workspaces/` namespace — the only place that can hold content belonging to someone other than whoever is setting the avatar, covering both uploads and channel media ingest. Keys elsewhere (the per-user standalone namespace, or objects an operator placed in the bucket) stay usable, which keeps the documented "an explicit avatar_url is preserved" contract intact. Uploader identity is deliberately not part of the rule: duplicating an agent legitimately reuses the source agent's avatar object, which a different admin may have uploaded. Publishing someone else's unbound image would require knowing its URL, and unbound rows appear in no listing endpoint. Also clamp the 302's cache lifetime to half the signed URL's own TTL (0 -> no-store). ATTACHMENT_DOWNLOAD_URL_TTL takes any positive duration, so the fixed 60s could outlive the target it pointed at on a short-TTL deployment. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Jiayuan Zhang
|
9ff766d700 |
fix(ui): tabular figures on live task timers (MUL-5448) (#6094)
The 1Hz elapsed counters rendered with proportional figures, so the text width changed on 9s -> 10s and 1m 9s -> 1m 10s, nudging the neighbouring elements once a second for the whole run. Web/desktop take the `tabular-nums` utility. Mobile cannot: Tailwind compiles that class to `font-variant-numeric`, and react-native-css-interop's property allow-list only carries `font-variant-caps`, so the declaration is dropped and the class is a silent no-op on RN. Use RN's `fontVariant` style prop there instead. Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Jiayuan Zhang
|
e54296eabb |
fix(ui): raise light muted-foreground to clear WCAG AA (MUL-5447) (#6095)
In light mode `--muted-foreground` at oklch(0.552 0.016 285.938) missed the 4.5:1 AA floor on every light surface except pure white. The worst pair was 3.98:1 — nav labels on --sidebar-accent, i.e. the primary navigation in its hover state. One token backs ~2k `text-muted-foreground` call sites, so the blast radius is most of the product's secondary text. Drop lightness to 0.505 and leave hue and chroma alone so the neutral ramp keeps its cast. Worst case is now 4.88:1. Dark mode already passed at 5.2-7.2:1 and is untouched. The `.landing-light` block in apps/web re-declares the light palette so token-driven components stay light under next-themes' `.dark` class; it moves with the source or it silently drifts. The new test asserts on the token file rather than on components: the token is the contract every consumer inherits, and a component test could only prove a class name is present, not that the pixels are legible. Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Jiayuan Zhang
|
503b09c5de |
fix(web): give landing CJK headlines a real serif and CJK metrics (MUL-5446) (#6101)
The landing tree set `--font-serif` to Instrument Serif, which ships Latin only, so zh/ja/ko headlines fell out of the stack onto the browser default sans while the Latin next to them stayed in a high-contrast display serif. A `Noto_Serif_SC` next/font entry was loaded as `--font-serif-zh` but no rule ever referenced it, and it requested `subsets: ["latin"]`, so it downloaded no CJK glyphs either way — remove it. Compose `--font-serif` for the landing tree in static CSS instead, with a per-`<html lang>` CJK tail, mirroring the `--font-sans` chain in globals.css: Chinese before Korean by default, a Mincho-first chain promoted for `ja` so Kanji do not get Chinese glyph shapes. Platform Songti/Mincho/Myeongjo faces rather than a multi-megabyte CJK webfont. The 16 landing surfaces that inlined `font-[family-name:var(--font-serif)]` now share a `.landing-serif` hook, which gives the per-locale metric reset a precise target: CJK headings drop the Latin display tracking (down to -0.038em) and sub-1 leading (0.93) that crowded ideographs and collided the two lines of a `<br />`-split headline. Korean additionally gets `word-break: keep-all` so wrapped Hangul breaks at word boundaries. Scoped to h1/h2 so the Latin-only footer wordmark keeps its tuned tracking. The English landing hero renders pixel-identical to before. Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
bdae0d2a03 |
fix(attachments): serve proxy-mode downloads with a scoped capability URL (MUL-5292) (#6092)
Desktop users on self-hosted deployments saw a save dialog but never got a
file. Electron's native download is a browser-level request: it carries
neither the desktop client's Authorization header nor a session cookie, so
GET /api/attachments/{id}/download answered 401.
The authenticated GET /api/attachments/{id} already exists to hand native
loaders a URL they can fetch without our credentials, and it already does so
in two of three modes -- a CloudFront-signed URL, or an S3 presigned URL.
Proxy mode (local disk, private object host) had no equivalent and kept
returning the auth-gated API path, which is the whole of the bug: one
unfinished branch of an otherwise correct design.
Finish that branch. In proxy mode the already-authenticated metadata endpoint
now mints a capability -- an HMAC-SHA256 signature over (version, attachment
id, expiry) with a key domain-separated from the JWT secret, valid for 60
seconds and scoped to exactly one attachment -- and a separate public route
redeems it. Membership is checked when the capability is minted, never at
redemption; the signature is the proof that check happened.
Nothing moves out of middleware.Auth: the existing authenticated download
route is untouched, so clients that predate this keep working and there is no
second copy of the header/cookie/PAT/task-token resolution. The capability
route always proxy-streams, so it emits no cross-origin redirect and the
signed query cannot leak to a CDN in a Referer.
The capability is site-relative and minted only by GetAttachmentByID. Both
matter: an absolute URL would be picked up by the inline-media re-sign path
and pinned into an <img> far longer than the TTL, and a capability in a list
response would expire before anything used it.
Verification: go test ./internal/handler/ ./cmd/server/ and the
@multica/views editor tests pass; gofmt, go vet, tsc --noEmit clean.
Co-authored-by: Bohan-J <bohan@devv.ai>
Co-authored-by: multica-agent <github@multica.ai>
|
||
|
Naiyuan Qing
|
6c9a59cc14 |
refactor(uploads): widen handleUpload contract, fix interrupted doc drift (#6035)
Follow-up to #6025 (MUL-5391), addressing the two non-blocking cleanups raised in review. 1. `CoordinatedUploads.handleUpload` was still typed as a one-arg function while the real `ContentEditor` contract is `(file, uploadId)`. Runtime was already safe (the implementation accepts `uploadId?`), but the exported interface erased the second parameter at the boundary, so a mock or hand-rolled caller could silently drop the editor-minted id and mint a second one — breaking the one-id link between the document node and the draft record. Widened the type and documented why the id must be threaded through. 2. #6025 changed `normalizeStoredUploads` to DROP persisted `uploading` records instead of coercing them to `interrupted`, but eleven comments across core and views still described the old coercion. Corrected them to state what the code does. `interrupted` is now produced by no code path at all; it stays in the union and is still accepted, rendered and dismissable because builds before this change persisted such records. Marked it LEGACY at the type and in the test that pins the behaviour. No runtime behaviour change: comments, one type widening, one test comment. Verified: pnpm typecheck (6/6); packages/core Vitest 1133 tests; packages/views Vitest 3178 tests; git diff --check. Co-authored-by: multica-agent <github@multica.ai> |
||
|
Multica Eve
|
de3e0ae556 |
fix(agent): make cursor stream protocol drift loud instead of silent (MUL-5434) (#6089)
* fix(agent): make cursor stream protocol drift loud instead of silent (MUL-5434) #6071 reports Cursor tasks that demonstrably read files, ran commands and called the Multica CLI, yet showed a single blob of agent text with no reasoning and no tool rows. The run still reported success and tools=0. `switch evt.Type` in cursor.go had no `default` branch, so any top-level event type we do not handle was dropped with no counter and no warning. Renaming only the top-level types of a healthy stream (`thinking`->`reasoning`, `tool_call`->`tool_calls`), leaving every nested field untouched, reproduces the report exactly: status=completed, output = the result text alone, tool_use=0, thinking=0, zero diagnostics. The existing unknown-subtype warning cannot catch this — it only increments once the type has already matched — so "no unknown-subtype warning" does not rule out protocol drift. Two diagnostic gaps are closed: - Add the `default` branch with a bounded, content-free tally of unhandled top-level types, reported once per run as a warning and alongside tool_use_count in the protocol summary. Type names are normalized through observedCursorEventType and distinct names are capped at 16 plus an overflow bucket, so a hostile or noisy stream cannot grow the map or leak payload into logs. `user` (the CLI echoing our prompt, present in every recorded run) is explicitly benign so the warning does not fire always. - Count assistant text separately from the terminal result text. The result event writes into the same builder, so last_assistant_bytes equalled result_bytes even when the assistant streamed nothing — erasing the signal that says "only the final answer arrived". This also aligns cursor with claude, which already reports assistant bytes only. Unrecognized events are still never coerced into tool or reasoning messages; guessing at upstream additions is the failure mode MUL-5231 already fixed once. This is diagnosis only and does not itself restore the missing tool rows — identifying which upstream shape changed requires a captured 2026.07.23 stream, and this warning is what makes that identifiable from a single production log line. Co-authored-by: multica-agent <github@multica.ai> * fix(agent): report cursor unhandled events as evidence, not as a verdict Addresses the review's must-fix on MUL-5434. The diagnostic was described as deciding WHY a transcript is empty, which it cannot do: - "tools=0 with unhandled types" does not establish that a rename ate the tool rows. Cursor 2026.07.23 also emits transport/control frames, so an unhandled type only proves the stream carried events we do not parse. - "tools=0 with no unhandled types" does not establish the agent used no tools. The CLI may execute tools without handing the updates to its stream serializer at all — the main branch #6071 has NOT ruled out — a new shape may be nested inside an event type we already recognize, or events may be lost to invalid framing or a scanner boundary. Changes, no behaviour change to messages, status or output: - Reword the tally doc, the switch default, the warning and the shared observation struct to state what a non-zero and a zero count each do and do not establish, and point at the branches that stay open. - Rename unknown* to unhandled* (fields, log keys, warning text, the pre-existing subtype counter) so the diagnostic never implies the type is unrecognized upstream — only that this parser does not handle it. - Classify `connection` and `retry` explicitly. They join `user` in cursorNonTranscriptEventTypes, with per-entry provenance recorded: `user` is confirmed in the recorded 2026.07.20 stream, the control frames are reported on newer builds and listed defensively. A build that does not emit them makes the entry inert; one that does must not have a known control frame reported as an unhandled protocol event. Tests assert signal presence and that nothing is fabricated, not causality: the healthy-stream test now carries `connection` / `retry` and additionally asserts the real thinking/tool rows still arrive, so suppressing the warning cannot silently suppress the transcript. TestCursorNonTranscriptEventType also pins that no type the parser handles can enter the suppression list. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Naiyuan Qing
|
e70e71fea1 |
fix(issues): repair the issue Table's column interactions, loading states and scroll rendering (#6036)
* fix(ui): make table column resizing land where the pointer is (MUL-5166) Pressing the resize handle committed a width before any drag: it wrote the rendered width, which fixed table-layout had stretched past the configured one, so a stray click on a column edge silently rewrote and persisted that column and stopped it adapting to the window. Dragging then ran ahead of the pointer, because committing one width changes how much leftover space the layout has to share out and rescales every other column mid-gesture. And the gesture never ended if the pointer came up outside the window or the user switched apps — the column kept tracking the pointer on return, with the page stuck unselectable under a col-resize cursor. - Require 4px of travel before anything is committed, matching the column-reorder sensor's activation distance on the same header. - Pin every column to its rendered width on the frame the drag starts, so there is no leftover left to redistribute and the drag maps 1:1. - Capture the pointer and end on blur / pointercancel / lostpointercapture, the same four-part contract the sidebar rail already uses. - Own the cursor from a portaled full-viewport layer for the duration of the drag. document.body.style.cursor loses to any descendant that declares its own, which is why the cursor flickered over rows and text. Resizing also re-rendered every cell each frame, and each cell carries a popover, so a frame cost ~143ms. Widths now travel as custom properties published once on the <table>, and the body is swapped for a memoized copy while a drag is live — the browser applies each new width with no React work. Visually the table had no column rules at all, which left the pinned columns' trailing shadow as the only vertical line and made it read as a stray border on one column. Every column now carries a rule, the pinned shadow appears only once the surface is actually scrolled sideways, and the resize handle brightens its rule to brand rather than matching the faint resting colour. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(issues): drag a table column by its header, not by a hidden grip Reordering columns was advertised by a grip that only appeared once the pointer was already on the header, and dragging it moved a wrapper the height of its own line of text while the <th> around it clipped anything that travelled outside the cell — so the column being moved looked like it had vanished rather than slid. The header is now the handle. There is no grip: the cursor carries the affordance (grab, then grabbing), the whole cell responds, and only the sort/hide button opts out, since a press there is always the menu. The wrapper spans the cell's box at all times — the negative margins undo the <th>'s padding and put it back inside — so what travels is a header-sized block and going translucent is the entire drag state, matching how a desktop tab behaves. Overflow is lifted for the length of a reorder and the column in hand is raised over its neighbours. Columns are restricted to the horizontal axis, the same constraint the desktop tab bar puts on tab reordering, which is why packages/views now declares @dnd-kit/modifiers directly. Transforming the <th> itself would carry the header's height along for free, but `transform` on a table cell is a corner of the spec browsers take liberties with — Chromium lifts the cell out of the table's box model and its geometry stops matching the row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(issues): stop a dragged table column stretching into its neighbour's width Dragging a column header applied dnd-kit's full transform, which carries scaleX/scaleY alongside the translation. Those come from its layout animation: old rect over new rect, tweening an item into the shape of the slot it lands in. Between two tabs of equal width the ratio is 1 and never shows. Between two columns it is not — swapping a 174px column with a 96px one stretched the header to 1.8x on the way across. Only the horizontal translation is applied now; reordering changes no column's width, so there is no shape for a tween to describe. The travel and the settle stay animated through `transition`. The travelling wrapper was also fixed at h-8 while the header strip measures 39px once row borders are counted, leaving the block short at both edges and misaligned by 3px — which read as the same flattening. Its height is derived from the cell now. The reorder grip returns as the drag handle, appearing on hover as before and staying visible for the length of a drag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ui): mark the frozen column boundary while the table is scrolled sideways The edge where the frozen columns end had a shadow drawn inside the pinned cell with `--border`. That token is tuned for hairlines between adjacent surfaces — oklch .945 in light mode — and all but disappears once spread into a shadow, so the boundary read as unmarked while content slid underneath it. Darkening it in place only made the frozen column look outlined: an inset shadow can shade that cell's own edge and nothing else, while the depth being described belongs to the content passing beneath. Split into the two things MUI X's data grid separates, a permanent border for where the boundary is and a shadow for something crossing it right now: - the rule between the frozen columns and the rest stays put, as before; - a 12px gradient is cast past the frozen block, mounted outside the scroll container and shown only while scrolled sideways. Its position is measured off the DOM — the trailing frozen header carries a `data-pinned-edge` marker — rather than summed from column sizes. Fixed table-layout stretches columns past their configured widths whenever the container is wider than the table's min-width, so a sum lands the marker in the middle of visible content. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ui): size a table column to its content on double-click Double-clicking a column's resize handle called column.resetSize, which cleared the stored width and let TanStack fall back to its generic default of 150 — a number unrelated to any width this table was designed with. "Reset" therefore widened priority from 130, collapsed labels from 220, and clamped title to its 260 minimum. It restored nothing. It now sizes the column to its widest rendered cell, the convention Excel, Sheets, AG Grid and Notion all share for that gesture. Fixed table-layout ignores content and the cells truncate their own text, so nothing on screen reports the width the content wants. The measurement lifts both constraints across the column's cells, reads them, and restores everything within the same task, so the browser paints once — after the restore — and the intermediate layout is never seen. Only the rows inside the virtual window are measured. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ui): stop the table header flickering black during scroll The sticky header carried backdrop-blur over a translucent fill. A backdrop-filter on a sticky element with content scrolling beneath it is a known Chromium compositing fault — the blur layer recomputes its backdrop every frame, and virtualisation is adding and removing the very rows it reads from, so the strip flickers black under fast scrolling. Chromium's fix for the same symptom was reverted, so upgrading does not carry it (electron#12906, electron#45854, chromium#339841685). The fill is now the opaque colour that bg-muted/30 was compositing to, which is the mix the pinned header cells already use. A header the content scrolls behind has no reason to show it through. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(issues): give the table's title column back the width its hover actions held The sub-issue and rename buttons sat inline in the title cell at opacity 0. Hidden is not absent: their boxes reserved around 40px of the column at all times, in the one column with the least room to spare, for controls that only appear on hover. They are positioned over the cell's trailing edge now, the way SidebarMenuAction is, with a gradient fading the title running underneath rather than icons sitting on top of it — the sidebar needs no gradient because its labels are short, a title runs to the cell's edge. focus-within keeps them reachable from the keyboard, where hover never fires. Reordering a column also scrolled the table vertically. Modifiers constrain a drag's movement but not its auto-scrolling, which reads raw pointer coordinates, so a few pixels of vertical drift sent the rows moving under a gesture that cannot act on them. Auto-scroll's y threshold is zero now; x keeps it, since a table wider than its viewport needs it to reach a distant slot, but at 0.05 rather than the default 0.2, which arms it a fifth of the way in from either edge — most of a wide header. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(issues): show the table's own grid while its first page loads, and end its columns like every other surface Two loading-state gaps, both in how the table's non-issue rows are modelled. A cold load rendered a single "Loading…" line under a full header, which reads as an empty table rather than a loading one. The surface-level skeleton meant for it was unreachable: use-issue-surface-data hardcodes isLoading to false for table, so the `mode === "table"` branch never ran — and it would not have fitted, drawing rounded bars at p-2 where the table draws an edge-to-edge grid, so switching it on would have traded one wrong state for a layout jump. Placeholders are rows now, rendered through the ordinary cell renderer so they inherit the real column widths, pinning and borders. Everything the table knows before its data — header, toolbar, column layout — is up immediately, and the rows swap in without moving anything. The unreachable surface branch is gone. The end of a column was hand-rolled too, leaving the table the one surface where a failed page read as muted body text rather than an error, where the prompt sat left-aligned against three centred ones, and where reaching the end of a paginated branch said nothing at all. The row carries its state rather than a finished label and renders through ListLoadMoreFooter, the footer Board, List and Swimlane already share — which exists, per its own comment, so those states and their wording stay consistent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ui): measure table rows instead of assuming they are all one height Virtualisation sized every row at the same 41px estimate, but the table does not have one kind of row: group headers are 37px, an end-of-column footer shorter still, and placeholders different again. Each one put the estimate a few pixels out, and the error accumulates — with grouping on, the rendered window drifts off the rows it should be showing and the scrollbar overshoots the bottom. Rows report their own height through the virtualizer's measureElement now, and the estimate only covers rows that have never been mounted. Rows built by renderRow are cloned to carry data-index and the measuring ref, so callers keep returning a plain <tr> and still take part. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(issues): scope the title cell's actions to the title cell The sub-issue and rename buttons keyed off the row's hover state, so pointing anywhere along a row — a status chip, a date, empty space — put controls that act on the title under a pointer that was somewhere else. They follow the title cell's own hover now. The gradient behind them still tracks the row colour, since that is what the cell is painted with while they are showing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ui): let group rows report their height, and re-measure the frozen edge on resize Self-review of the branch turned up two places where a change did not reach as far as it was supposed to. Group rows never took part in the row measurement. DataTable clones the virtualizer's ref and data-index onto whatever renderRow returns, but IssueTableGroupRow declared only its own three props and absorbed them — and a group header, being shorter than a data row, is exactly the row the measurement was added for. The frozen-column shadow measured its boundary from the scroll handler alone. Resizing a frozen column while the surface is scrolled sideways moves that boundary with no scroll event to follow, leaving the shadow behind at the old position. Also drops a dependency left behind when the load-more rows stopped building their own labels. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Multica Eve
|
07a78d910d |
fix(daemon): discover agent CLIs installed after startup (MUL-5439) (#6086)
* fix(daemon): discover agent CLIs installed after startup (MUL-5439) The built-in agent availability set was built exactly once, in LoadConfig, and every later consumer read that static map. A CLI installed while the daemon was running was therefore invisible until the daemon process restarted. On Desktop that is worse than it sounds: the app defaults to autoStop=false and auto-start only compares CLI versions, so quitting and reopening the app does not restart the daemon. A user who installed a CLI, verified it in their shell, and relaunched the app was left with a runtime that never appeared — which is GH #6077, reported against Antigravity but not specific to it. - Extract discovery into probeAgentCLIs (pure availability, no version gate). - Add agentDiscoveryLoop: re-probe every 2 minutes and register providers that appeared, reusing applyRegisterResponseInPlace so nothing restarts and no in-flight task is interrupted. RecoverOrphans is deliberately not called here (MUL-3332): surviving runtimes may be executing tasks. - Additive only. A provider that stops resolving is kept, because a narrower PATH or a version manager mid-upgrade would otherwise tear down a working runtime. Removal stays with an explicit restart. - Hold the set in an atomic.Pointer copy-on-write: cfg.Agents was read unlocked from task-execution paths, so a mutable map would be a data race. - Cache the login-shell PATH fallback process-wide with a 30m TTL keyed on PATH/SHELL/HOME, so the 2-minute loop stays a pure LookPath sweep instead of forking the user's rc files every round. - Report skipped_agents on /health with the reason a discovered provider was dropped at registration, so "not installed" and "installed but rejected" stop looking identical (they were only distinguishable in the daemon log). - Fix the onboarding template in all four locales: it told users that restarting the desktop app was enough, which is exactly the false lead the reporter followed. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): retry discovery until registered, and never evict live runtimes Addresses both P1s from review. P1-1: a failed first attempt was never retried. refreshAgentAvailability published a newly discovered provider into the availability set and only acted on providers "gained" in that same round, so a version probe that timed out or a register call that failed left the provider permanently unregistered — the user was back to restarting the daemon, with skipped_agents able to explain the problem but not fix it. Registration is now driven by live state instead of by the round that discovered the provider. providersMissingRuntimes derives, from runtimeIndex, which discovered providers lack a built-in runtime in each tracked workspace; convergeRuntimeRegistrations registers only those, for only the workspaces that need them. Nothing records "already handled", so a version-probe failure, a register failure, or a partial failure across workspaces all retry on the next tick, and a provider rejected for being below the minimum version recovers on its own after an in-place upgrade. A permanently stuck provider is bounded by exponential backoff (one discovery interval up to 30m) on the expensive half only; discovery itself stays on its 2-minute cadence, and the steady state issues no version probes and no register calls at all. P1-2: the "additive only" refresh could evict existing custom runtimes. applyRegisterResponseInPlace treats the response as authoritative and drops prior runtime IDs it does not mention — correct for the convergence paths that re-derive a whole runtime set, wrong here. appendProfileRuntimes is best-effort, so one failed GetRuntimeProfiles call yields a builtins-only response, which would evict the workspace's custom profile runtimes from runtimeIndex and stop their heartbeats, possibly mid-task. Added mergeRegisterResponseInPlace: indexes and appends returned runtimes, never deletes an unmentioned one, and keeps profileSetSig when the fetch failed. Safe because the server's register endpoint is a pure per-entry upsert that prunes nothing, so omitted runtimes still exist server-side. ID rotation is still handled destructively for that one runtime, so a re-issued ID replaces its predecessor instead of leaving two heartbeat goroutines. New regression tests: first version probe fails then recovers; first register call fails then recovers; partial failure across two workspaces retries only the one that needs it and makes exactly one call; a failed profile fetch leaves the custom runtime indexed, watched, and its signature intact; below-minimum provider registers after an upgrade; steady state re-probes nothing; rotated runtime ID is swapped not duplicated; stuck provider is retried but bounded. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): keep CLI discovery out of custom-profile convergence (MUL-5439) Third-round review P1: discovery could mask a concurrent profile disable. The discovery path registered through registerRuntimesForWorkspaceBatch, which fetches the workspace's custom runtime profiles and returns their content signature, and the additive merge cached that signature. So if a user disabled a custom profile at the same moment a newly installed CLI was discovered, the merge correctly kept the disabled profile's runtime ID (it must not delete unmentioned runtimes) while recording the POST-disable signature. refreshWorkspaceRuntimeProfiles short-circuits on a matching signature, so the drift path then saw "already converged" and the disabled runtime stayed tracked and heartbeating forever. Discovery is now strictly built-ins only: - registerBuiltinRuntimesForWorkspace posts a builtins-only register request. It never calls appendProfileRuntimes, so discovery cannot observe the profile set at all and there is no signature to cache. - mergeRegisterResponseInPlace becomes mergeBuiltinRegisterResponse: it ignores any entry carrying a ProfileID (invariant guard — only the drift path may introduce a custom runtime), and neither reads nor writes profileSetSig. - Custom profile add/edit/disable remains owned exclusively by refreshWorkspaceRuntimeProfiles. Regression tests: a profile disabled concurrently with a new CLI install is still converged away by the drift path (this test reproduces the reviewer's exact failure — "disabled custom runtime rt-2 remained tracked" — when the old signature write is replayed); the merge ignores profile-bearing entries; the merge leaves profileSetSig untouched. The profile-fetch-failure test now also asserts the signature is unchanged rather than merely non-empty. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai> |
||
|
David Zhang
|
b3847b4172 |
MUL-5433: fix(agent/hermes): pin session id mid-flight for daemon resume (#6070)
* fix(agent/hermes): pin session id mid-flight for daemon resume Hermes was the only ACP-backed agent that created a session without emitting a running status carrying the session id. When the daemon restarted or a task was cancelled mid-flight, PinTaskSession had nothing to key on, so the resume pointer was lost and the task could not resume. Emit MessageStatus+SessionID immediately after session create, matching claude, codebuddy, codex, grok and qwen. The daemon already listens for this (daemon.go MessageStatus -> PinTaskSession), so this small pin is all Hermes needs. See #4969 for the companion daemon/SQL cancel-salvage work. Co-authored-by: multica-agent <github@multica.ai> * test(agent): cover Hermes mid-flight session pin Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai> Co-authored-by: Eve <eve@multica-ai.local> |
||
|
Multica Eve
|
d4dac0e77c |
perf(agents): index-backed latest-terminal lookup in task snapshot (MUL-5436) (#6085)
ListWorkspaceAgentTaskSnapshot took each agent's latest completed/failed
task with a workspace-wide DISTINCT ON, so every presence load read and
sorted the workspace's whole terminal history. Neither existing index
matches that shape: (agent_id, status) has no completed_at, and migration
231's (completed_at) partial index is completed_at-first for the Usage
rollups.
Replace the outcome half with a per-agent JOIN LATERAL Top-1 and add a
partial index on (agent_id, completed_at DESC NULLS LAST, created_at DESC,
id DESC) WHERE status IN ('completed','failed'). On a 40-agent workspace
with 200k terminal rows this goes from 6631 shared buffers / 48.3 ms to
162 buffers / 0.1 ms, with an identical row set.
The (created_at, id) tie-break also makes the pick deterministic when
completed_at ties or is NULL — completed_at DESC alone left the winner up
to the plan.
Report #6075 asked to delete the outcome half as dead code, but PR #2608
made the Squad hover card (AgentLivePeekCard) read those rows for its
"last activity" line, so removing them would be a product regression for
shipped desktop builds. The response contract is unchanged here; splitting
the outcome into a lazy endpoint stays follow-up work.
Also tighten pickLatestTerminal to completed/failed only, matching the
snapshot's filter — it accepted cancelled, which the endpoint never
returns and which would have masked an agent's last real outcome.
Co-authored-by: Eve <eve@multica-ai.local>
Co-authored-by: multica-agent <github@multica.ai>
|
||
|
苗大
|
6d98b5eeb3 |
fix(editor): re-sign cross-origin attachment URLs (#6029)
Treat absolute cross-origin attachment API URLs as requiring an authenticated metadata refresh, so draft image previews load on split-origin self-hosted deployments backed by presign-capable or CloudFront-signed storage. Same-origin URLs (relative or absolute) and external image URLs keep their existing no-refetch path. Fixes #6049 |
||
|
Bohan Jiang
|
cc5ee169f0 |
fix(agents): allow agent owners to manage their own agent's env (MUL-5438) (#6080)
* fix(agents): let agent owners manage their own agent's env (MUL-5438)
GET/PUT /api/agents/{id}/env admitted only workspace owner/admin, which
made env the one endpoint in the agent permission model that ignored
agent ownership: canManageAgent already lets the owner update/archive,
and canViewAgentSecrets already lets the owner read mcp_config. The
asymmetry was worst on create — POST /api/agents accepts custom_env from
any member and stores that member as owner_id — so a member could write
secrets into their own agent and then never read or rotate them, with
UpdateAgent rejecting custom_env outright and no workaround left.
authorizeAgentEnv now admits a workspace owner/admin OR the agent's own
human owner. The agent-actor rejection still runs first and unchanged:
an agent process is denied even when its backing human owns the target
agent. The owner comparison uses member.UserID rather than the raw
X-User-ID header because agent.owner_id is nullable and uuidToString
renders NULL as "", and canManageAgentEnv rejects an empty owner from
the other side too.
The web Environment tab is gated on the same rule via the existing
canEdit decision, so it stops offering a "Reveal & edit" action that is
a guaranteed 403. The server remains the boundary.
Closes #6076
Fixes: https://github.com/multica-ai/multica/issues/6076
Co-authored-by: multica-agent <github@multica.ai>
* docs(agents): correct stale "owner/admin only" env permission wording
Follow-up to the MUL-5438 permission change: several comments and the
published docs still described the env endpoints as workspace
owner/admin only, which now contradicts the code.
- router.go / agent.go / types/agent.ts: the three sites flagged in
review.
- agents-create.mdx (en/zh/ja/ko): the user-facing callout said reading
values requires a workspace owner or admin. It now names the agent's
own owner first, and spells out that the agent-actor denial holds even
for an agent the same human owns.
- daemon.go / middleware/auth.go: these called the env endpoints
"owner-only" as shorthand for "reject agent actors". That property is
unchanged, but "human-only" is what they actually mean now.
Comments and docs only — no behavior change.
Co-authored-by: multica-agent <github@multica.ai>
---------
Co-authored-by: Bohan-J <bohan@devv.ai>
Co-authored-by: multica-agent <github@multica.ai>
|
||
|
Naiyuan Qing
|
b5992c4454 |
fix(featureflags): publish the hang stack capture flag to clients (MUL-5345) (#6079)
#6026 shipped the desktop half of hang stack capture fail-closed: the renderer only enables it when `desktop_hang_stack_capture` arrives from `/api/config` as an explicit true. The server half was missing — the key was never added to `frontendPublicFlags`, so `/api/config` never published it and the client had nothing to receive. The effect in production is that capture has been inert since release. 0.4.13 recorded two real hard hangs in its first 14 hours and both came back with empty `stack_*` fields, which reads like "nobody turned the flag on" but is not fixable that way: with the key absent from the published set, enabling it in the flag service would not have reached any client. Publishing it changes no behaviour on its own — the default is off, and the desktop side still requires an explicit true — it only makes the switch reachable. Co-authored-by: multica-agent <github@multica.ai> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
XuSt
|
77907db1e3 |
MUL-5406: propagate non-ErrNoRows scope DB errors (#6057)
* fix(scope_authorizer): propagate non-ErrNoRows DB errors instead of swallowing them dbScopeAuthorizer.AuthorizeScope returned (false, nil) on every query error at all four lookup points (GetAgentTask, GetIssue, GetChatSession x2), masking transient DB failures as plain 'forbidden' denials. This made the 'lookup_failed' branch in realtime/hub.go handleSubscribe unreachable and hid database outages from users and operators. Now only pgx.ErrNoRows (a legitimate missing resource) yields (false, nil); any other error propagates as (false, err) so handleSubscribe reports 'lookup_failed'. Updated fakeScopeQuerier to return pgx.ErrNoRows for misses, and added tests pinning both the error-propagation and the not-found-is-plain-denial semantics. Closes #6037 * test(realtime): cover scope lookup failures Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Multica Eve
|
45e24e3565 |
fix(comment): @all no longer swallows an explicit @agent mention (MUL-5411) (#6048)
* fix(comment): @all no longer swallows an explicit @agent mention (MUL-5411) computeCommentAgentTriggers short-circuited on `util.HasMentionAll` before it looked for explicit mentions, so a comment carrying both `@all` and an `@agent` / `@squad` mention enqueued nothing at all — the named target never ran. Evaluate the explicit-mention branch first; `@all` now only suppresses the implicit routes (assignee / thread parent / conversation), which was its intent. `all` is neither "agent" nor "squad", so it is still skipped inside resolveMentionedAgentCommentTriggers and never enqueues a run of its own. Tests: preview + create coverage for @all + @agent (mentioned agent only, no assignee fallback), @all + @squad (leader wakes), @all + @member (still suppressed), plus an end-to-end subtest in the @all suppression integration test. Refreshed the builtin multica-mentioning skill and its source map, which documented the old short-circuit and a function name that no longer exists. Co-authored-by: multica-agent <github@multica.ai> * fix(comment): malformed mention id no longer panics the trigger resolver Review finding on PR #6048. MentionRe accepts any `[0-9a-fA-F-]+` id, so `mention://agent/-` parses as a real mention, and resolveMentionedAgentCommentTriggers handed it to parseUUID (util.MustParseUUID) — a panic on attacker-controlled comment text. Preview returned a 500; on the create path the comment row was already committed before the panic fired. Parse both the agent and the squad mention id with the error-returning util.ParseUUID (the convention routeFirstExplicitRootMentionOwner already follows) and record a blocked outcome instead: agent → invocation_not_allowed, squad → target_unavailable. Those are the same enumeration-safe codes a well-formed id that owns no entity already produces, so a malformed id reveals nothing new and never enqueues. The panic predated the @all reordering on plain explicit mentions; the reorder made it reachable for @all + malformed id too, so it is closed here. Tests: table-driven preview + create regression for a bare `-` agent id, a short hex agent id, a malformed squad id, and both @all combinations — asserting no panic, no trigger, and the exact blocked outcome. Verified the tests fail with the panic before the fix. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
2e9a3d0119 |
fix(dashboard): stop leaking private agents from the per-agent rollups (MUL-5409) (#6051)
* fix(dashboard): stop leaking private agents from the per-agent rollups (MUL-5409) Three per-agent dashboard endpoints authorized on workspace membership alone and returned a bare agent_id for every agent in the workspace: GET /api/dashboard/usage/by-agent GET /api/dashboard/agent-runtime GET /api/dashboard/failures/by-agent That told a plain member which private agents exist, how much they spend, how long they run and what they fail on. The client already collapsed those rows, but client-side filtering is decoration — one curl bypasses it. Server: rows for agents the caller may not view are now folded onto a `__restricted_agents__` sentinel before serialization, via one shared helper. Folded, not dropped: each of these responses is the per-agent half of a pair whose other half (usage/daily, runtime/daily, failures/daily) is workspace- scoped and unfiltered, so dropping rows would make the per-agent breakdown stop adding up to the KPIs rendered beside it. The bucket keeps its provider/model and failure_reason dimensions — both are derivable by subtraction from the workspace-level series anyway, and the client needs them to price the bucket and compute its failure rate. Owner/admin and agent actors short-circuit before any extra query, so the governance view is unchanged. Hard-deleted agents are deliberately excluded from the fold — they have no visibility left to protect and keep their own bucket. Client: fixes the mislabelling that shipped with this. A live private agent was folded into a row labelled "Deleted agents" with a bin icon, and counted into the card's "· N deleted" caption — telling the user N agents were deleted when they are alive and still running. The restricted bucket is now its own row with neutral copy, keeps its real Time / Tasks values, and counts as neither an agent nor a deletion in the caption. Tests: handler regression coverage proving a plain member's response contains no private agent UUID while every aggregate still sums to the privileged view's total, plus view coverage for the label and caption. Co-authored-by: multica-agent <github@multica.ai> * fix(dashboard): fold hidden system agent carriers into the restricted bucket (MUL-5409) Review follow-up. The first pass built the restricted set from ListAllAgents, which filters `kind = 'user'` — so it missed the hidden `kind = 'system'` execution carriers behind agent-builder sessions. Those carriers run real tasks and book real usage, and all three rollups aggregate over agent_task_queue / task_usage with no kind filter of their own. No list endpoint returns them either (ListAgents / ListAllAgents both filter on kind), so no client can resolve one to a name. Net effect: the exact two bugs this PR exists to fix, still live — a bare UUID exposing one member's builder session (with its spend and failure profile) to every other member, and, once the agent list loads, a running agent folded into the client's "Deleted agents" row and counted as a deletion. restrictedAgentIDs now reads a new ListAllAgentsAnyKind and restricts every non-user-kind agent for EVERYONE, workspace owner included — nobody can name one, so a bare UUID row is wrong for every viewer, not just plain members. User agents keep the per-viewer visibility rule. The invocation-target lookup is skipped for actors that rule can never restrict (agent actors, owner/admin), so the added cost is one indexed list query. Because the bucket now also carries carriers that are nobody's "restricted" agents, its copy drops to the neutral "Other agents" — the same wording the Errors card already uses for its equivalent row, in all four locales. Adds a regression test seeding a kind=system private carrier with tasks and usage: no endpoint may return its UUID to either the plain member OR the workspace owner who owns it, a bucket must be present to carry its rows, and every metric delta (tokens, seconds, tasks, failures, runs) must equal its exact contribution. Verified to fail on all three endpoints for both viewers with the kind-filtered query restored. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Multica Eve
|
cf4114cd5d |
MUL-5396: validate agent concurrency limits (#6034)
* fix(agent): validate concurrency limits Co-authored-by: multica-agent <github@multica.ai> * fix(agent): harden concurrency duplication Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Naiyuan Qing
|
ba17fcf46a |
fix(editor): open mention and slash pickers only for typed triggers (MUL-5429) (#6072)
* fix(editor): stop pasted @ text from hijacking Enter and Escape (MUL-5429) Pasting a line containing `@` into the create-issue composer left an empty mention picker open that swallowed Enter, and Escape then closed the whole dialog instead of just the picker. Two independent causes: 1. The Tiptap suggestion plugin re-runs findSuggestionMatch on EVERY transaction, including the one that commits a paste, so pasted text containing `@` opened the picker. With `allowSpaces` the match runs from the `@` to the end of the line, so the entire pasted tail became one query that matched nothing — and the empty popup deliberately captures Enter. Gate the mention picker with `shouldShow`: skip paste/drop transactions, and skip queries longer than any real mention target (60 chars). The empty-list Enter capture is intentional and is left alone; the fix stops the picker opening instead. 2. ProseMirror calls preventDefault() for a handled key but never stops propagation, and Base UI's dismiss layer listens for Escape on `document` in the bubble phase without consulting defaultPrevented. So the Escape that closed the picker also closed the host dialog. Stop propagation in the shared suggestion popup handler — the only layer that knows a picker is open — which fixes every host at once. The slash pickers get the same paste guard so a pasted path no longer opens the command menu; they were never affected by the Enter capture. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> * fix(editor): open mention and slash pickers only for typed triggers (MUL-5429) Pasting a line containing `@` opened an empty mention picker that swallowed Enter. The first attempt at this fix aimed at the wrong target and did not work in the product; this replaces it. The picker also opened with no paste involved at all: placing the caret at the end of a line that already contained `@` was enough. Tiptap's Suggestion plugin is state-derived, not event-driven — it re-runs findSuggestionMatch on EVERY transaction and asks whether the text before the cursor looks like a trigger, never whether the user just typed one. Pasted, dropped, undone and server-loaded text produce an identical document, so it cannot tell them apart. With allowSpaces the match then runs from the `@` to the end of the line, so the whole pasted tail became one query that matched nothing, and the empty popup deliberately captures Enter. That is upstream's known, unfixed design: ueberdosis/tiptap#4183 (open since 2023, labelled `complexity: hard`, reopened in January after `shouldShow` proved insufficient) and #7371. Upstream's position is that applications supply the missing provenance themselves. `shouldShow` alone cannot: it receives the transaction without `prev.active`, while `allow` receives `prev.active` without the transaction, so no transaction-inspecting predicate can express "only on the transaction that opened the picker". Add a trigger-arming plugin instead. `handleTextInput` is the one ProseMirror hook that fires for real keyboard and IME input only — paste goes through handlePaste/doPaste and drop through handleDrop, neither of which reaches it. Typing a trigger character arms its document position; the pickers' shouldShow opens only for a match anchored there; a deliberate caret move, or losing the trigger character, disarms it. This is the same signal Tiptap's own InputRules run on, which is why typing `- ` makes a list but pasting it does not. Suggestion is the one Tiptap feature that does not use it. Also stamp the paste metas markdownPaste was dropping. ProseMirror's doPaste returns early once a handlePaste prop claims the event, and markdownPaste is a catch-all that claims nearly every paste, so the transaction that commits a paste carried no `paste` / `uiEvent` mark. That is why the previous fix never fired in the product, and it independently broke issueIdentifierAutolink, which reads exactly that mark: pasting `See MUL-2 now` autolinked nothing, because the unmarked transaction sent it down the typing path that only inspects the token before the caret. Both features' paste tests passed throughout because they hand-built transactions carrying a meta the real paste path never produces. Every paste case now fires a real paste event, and typing is routed through handleTextInput the way readDOMChange does, so a test cannot be green while the product is broken. The Escape containment from the previous attempt is unrelated to all of this and is kept as is. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
0abee49005 |
docs(self-hosting): require COOKIE_DOMAIN for split-domain deployments (MUL-5413) (#6055)
The split-domain reverse-proxy recipe listed FRONTEND_ORIGIN, CORS_ALLOWED_ORIGINS and NEXT_PUBLIC_API_URL but never COOKIE_DOMAIN. Without it the session cookies are host-only on the API host, so the frontend cannot read multica_csrf, never sends X-CSRF-Token, and every non-GET request is rejected with 403 "CSRF validation failed" while reads keep working. Add COOKIE_DOMAIN to the recipe and explain the failure mode, including the stale-cookie cleanup needed after changing it. COOKIE_DOMAIN also scopes multica_auth, so the browser sends the session JWT to every host under that domain — HttpOnly stops page scripts from reading it, not sibling subdomains from receiving it. Require the narrowest parent domain covering both hosts, state that every host in scope must be operated by the same trusted party, and mark the same-origin layout as recommended since it keeps the cookie host-only. Also document the requirement and the scope caveat in the environment variable reference (en/zh/ko/ja). Refs #6046 (MUL-5413) |
||
|
Bohan Jiang
|
0066ab259e |
refactor(agent): drop unreachable inline system-prompt branches (MUL-5392) (#6050)
* refactor(agent): drop unreachable inline system-prompt branches (MUL-5392) The daemon only populates ExecOptions.SystemPrompt for openclaw, kimi and traecli (providerNeedsInlineSystemPrompt); every other backend receives the runtime brief as a per-task context file in the workdir. The inline branches in claude, codex, opencode and pi were therefore dead, and read as if they were the live delivery path. Probed each backend over its real launch path with a canary in the context file and no inline delivery — claude 2.1.220 (CLAUDE.md), codex 0.144.6 via the app-server, opencode 1.17.7, pi 0.67.2, hermes 0.18.2 via ACP — and all of them picked the brief up from disk, so the branches were removable with no behaviour change. An empty workdir returned no canary, confirming the probe could fail. opencode's branch was worse than dead: `opencode run` has no --prompt flag, so enabling inline delivery there would have made every opencode task exit 1 with a usage dump. The DevEco backend, forked from opencode, already documents this constraint; opencode itself never got the fix. Regression tests pin all three arg builders against re-adding the flag, and providerNeedsInlineSystemPrompt now documents what was verified and what is still unprobed (grok, qoder, codebuddy). Hermes and kiro are untouched: their exclusion is deliberate and already tested. Co-authored-by: multica-agent <github@multica.ai> * test(agent): pin codex developerInstructions contract, drop stale pi flag doc Review follow-up on MUL-5392. buildPiArgs' doc comment still advertised --append-system-prompt after the branch that emitted it was removed — exactly the stale-signal this PR set out to delete. The two codex sites fixed to a literal nil had no regression test, so restoring nilIfEmpty(opts.SystemPrompt) would still have gone green. Both thread/start and thread/resume now run with a canary SystemPrompt and assert developerInstructions comes through as an explicit null. Mutation-checked: reverting either site fails its test. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: J <agent@multica.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
962d376fda |
refactor(agent): share acpDeliverableTracker across ACP backends (MUL-5405) (#6044)
#6022 stopped qoder from delivering interim narration as Result.Output, but hermes / kimi / kiro / traecli / grok still accumulate every MessageText into one builder and hand the whole thing to Result.Output — the same leak (#6006), since Result.Output becomes the channel reply and the auto-generated issue comment. Extract the boundary rule into acpDeliverableTracker (observe / result) and share it across all six backends instead of copying qoder's block five times: Result.Output keeps only the text after the latest tool call, a turn that ends on a tool call falls back to the latest non-empty text block so the reply is never empty, and provider-error detection keeps reading the full text stream. Covered by tracker unit tests and a cross-backend regression test that pins both scenarios on all six backends, over both tool-use emission paths (emitted at the tool call and deferred to tool completion). Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
0254090853 |
docs(changelog): file the Claude Code cache fix under fixes and lead with it (MUL-5400) (#6047)
* docs(changelog): lead v0.4.13 with the prompt-cache saving (MUL-5400) Co-authored-by: multica-agent <github@multica.ai> * docs(changelog): scope the cache fix to Claude Code and move it to fixes (MUL-5400) Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>v0.4.13 |
||
|
Multica Eve
|
c0f397b8d2 |
fix(migrations): remove historical skill-bundle backfill (MUL-5400) (#6045)
* fix(migrations): skip historical skill bundle backfill (MUL-5400) Co-authored-by: multica-agent <github@multica.ai> * fix(migrations): drop unused skill bundle migration Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Multica Eve
|
79cc3abc8d |
docs(changelog): add v0.4.13 release entry (#6038)
Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Naiyuan Qing
|
831ef926e1 |
fix(editor): limit paste-as-file to chat (#6043)
#6019 opted four composers into converting an over-threshold plain-text paste into a `pasted-text.txt` attachment. Only chat should: a wall of text there is context handed to an agent for one turn, and the body is not what anyone reads. In an issue comment the paste IS prose a human reader is expected to see in the thread, so hiding it behind an attachment chip makes the thread worse, not better. So the three comment surfaces — new comment, reply, comment edit — stop passing `pasteAsFileThreshold`. Nothing else changes: the extension, the threshold constant and the failed-paste recovery all stay, because the prop was always opt-in per editor and chat still uses every part of it. The recovery test moves from comment-composers to use-coordinated-uploads. Comments can no longer produce a paste-as-file upload at all, so hosting the test there would pin a path that cannot happen; the hook is where the contract actually lives, since the upload outlives its mount and no editor can own the failure. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
YYClaw
|
54469766fd |
fix(qoder): deliver final answer only (MUL-5394) (#6022)
* fix(qoder): deliver final answer only * fix(qoder): preserve tool-terminated replies |
||
|
Naiyuan Qing
|
18adb20c14 |
MUL-5391: unify upload placeholder UI (#6025)
* fix(editor): an in-flight upload placeholder is never content, and is drawn once
Two defects with one cause: a placeholder for an upload in progress was both
serialised into the draft body and drawn a second time as a chip.
The document IS the persisted draft (getMarkdown -> setDraft), so serialising
an in-flight node turns it into text that outlives the upload:
- fileCard emitted `!file[x.pdf]()`. Its own tokenizer cannot parse an empty
href back, so the line survived reopen as dead literal text, sat next to
the real link the write-back appended, and shipped with the comment.
- image emitted its process-local `blob:` URL, which ContentEditor then
scrubbed back out with a regex on every serialise.
Both renderMarkdown implementations now emit nothing while `attrs.uploading`
is set (or no URL exists). A node becomes content the moment it holds a real
URL and never before, which is strictly stronger than scrubbing after the
fact — so BLOB_IMAGE_RE / stripBlobUrls are deleted rather than extended.
Separately, ComposerUploadChips rendered every non-`uploaded` entry, including
ones whose placeholder node is right there in the editor. Every upload started
from a live mount inserts a node first (uploadAndInsertFile is the uploader's
only caller), so those chips were the same upload drawn twice, in two visual
languages, shifting layout as they appeared and vanished. useCoordinatedUploads
now exposes `orphanUploads` — the entries inherited from the persisted draft,
whose originating mount is gone and whose node died with it. That is the case
the chip strip was introduced for, and now the only one it covers.
`getMarkdown()` deliberately stays untrimmed (see its safety-net test); only
its stripBlobUrls wrapper is gone.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(editor): keep a failed upload visible after the chip/node split
Self-review catch on the previous commit: suppressing the chip for every
upload this mount started also suppressed it for FAILED ones. The document
cannot stand in for those — uploadAndInsertFile removes the placeholder node
on failure — so the outcome was left to a toast that has already gone.
The rule is not "started here" but "the document is showing it", and the
document only ever shows a live placeholder: still `uploading` AND started by
this mount. `failed` / `interrupted` always get a chip, `uploaded` never does
(the editor and AttachmentList render those), which also makes an
`orphanUploads.length` gate mean what the call sites assume.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(editor): keep the chip when the user deletes a running upload's placeholder
Code-review catch: "started by this mount" is necessary but not sufficient for
"the document is showing it". Cmd+Z right after a paste removes the placeholder
node while the upload keeps running — and gate.isBlocked keeps blocking send on
the store entry regardless of the node — so the previous filter left a dead send
button with nothing on screen explaining it.
The filter now also consults editorGate.uploading, which is the document's own
answer to "am I showing a placeholder right now" (sourced from the uploading-node
scan via onUploadingChange). Started-here AND still shown is what suppresses a
chip; either half failing brings it back.
Also drops a stale stripBlobUrls reference from the use-upload-gate docstring —
that helper no longer exists.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(editor): a failed upload leaves nothing behind
The failure chip carried no information the toast had not already given at the
moment it happened, and it could not act on it: the bytes were never persisted,
so there is nothing to retry, and the file is still on disk to re-attach. Its
only affordance was a dismiss ✕.
It cost more than that. The entry lives in the persisted draft, so it survived
reload and reopen until dismissed by hand — and `isMeaningful` counts uploads,
so a single flaky request kept an otherwise-empty draft alive for the full
30-day TTL. Uploading again did not clear it either: a new upload is a new
clientUploadId.
Failures now remove their placeholder outright instead of marking it. Both
failure paths (size check, coordinator settle) collapse into that one rule,
which also folds the paste-as-file recovery into the shared branch rather than
duplicating it.
`interrupted` keeps its chip: it is discovered a session later, when the user
no longer remembers attaching anything. `orphanUploads` still handles `failed`
because an older client may have persisted one.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* refactor(editor): one upload, one node, from start to finish
The chip strip existed because the document could not answer for an upload it
was not showing. Give it that ability and the strip has no reason to exist.
Three changes make one model:
- ONE IDENTITY. The node's `uploadId` and the draft's `clientUploadId` were
two independently minted random values, because the node is inserted before
the handler that created the draft record runs. `uploadAndInsertFile` now
mints the id up front and hands it to the uploader, which adopts it. Asking
"is this upload in the document" becomes a lookup instead of an inference.
- REBUILD ON MOUNT. A placeholder is never serialised (it is not content), so
it dies with the document that drew it and a reopened composer showed no
trace of an upload still running. The draft record is enough to draw it
again. Once per id per mount: a placeholder the user deleted mid-upload
stays deleted (MUL-5181), and the guard is what stops the next store write
from undoing that. Skipped entirely while chat pins its document to another
draft — `uploads` follows the selected key, the document does not.
- SETTLE IN PLACE. The write-back replaces the placeholder where the user last
saw it instead of appending the link at the end. A card promotes to an image
when that is what arrived; the rebuild path only ever has a filename, so it
cannot know in advance.
With that, the chips are deleted outright, along with `orphanUploads` and the
three-condition rule that approximated all of the above. `interrupted` goes
too: nothing could act on it, no surface rendered it after this change, and
`isMeaningful` counted it — one dead record kept an empty draft alive for the
full TTL. The attachment's absence from the body is the signal to re-attach.
SubmitButton's `busy` now spins rather than only greying out, so an upload
with no other on-screen trace (a composer still rebuilding, a placeholder the
user deleted) does not read as a dead control.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(editor): whoever draws a placeholder registers it, not whoever finds it
Review catch on the rebuild effect. An upload started by the current mount had
its node drawn synchronously by uploadAndInsertFile, but its id only entered
`rebuiltUploadIdsRef` once the effect ran and happened to find that node. In
between, a delete (Cmd+Z right after a paste) left the effect looking at an
unmarked `uploading` record with no node — so it drew a second one, undoing a
removal MUL-5181 says must stick, and letting the settle land an attachment
the user had taken out.
The id is now registered where it is minted: an id handed into handleUpload
means the editor already drew the node. The window is sub-frame and needs a
keystroke inside one render pass, but "whoever draws it registers it" is a
rule, where "the effect will notice in time" was a race.
The composer mocks called `onUploadFile(file)` with no id, so they were not
exercising the one-id contract at all — every mount-started upload looked
inherited to the hook. They now mint and pass one like the real handle does,
which is what lets the new regression test see the difference.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
Multica Eve
|
81797b5a03 |
feat(agents): thinking level + Codex speed in the create flow (MUL-5390) (#6027)
* feat(agents): expose thinking level and Codex speed in the create flow (MUL-5390) Creating an agent could only set runtime + model, so a Codex agent that needed Fast had to be created and then fixed in settings — and duplicating one silently dropped both overrides. The create API and the TS contract already carried `thinking_level` / `service_tier`; only the creation surface did not. - AgentDraft carries thinkingLevel / serviceTier, rendered in the Execution section through the same ThinkingSettingField / ServiceTierSettingField the settings page uses. They stay fail-closed: a field appears only when the exact selected model's live catalog on an online runtime advertises the capability, so no value can be sent that the daemon would refuse. - Payload and duplicate-draft assembly move into pure functions (buildCreateAgentRequest / buildDuplicateDraft); empty overrides are omitted instead of sent as "". - Dependency cleanup: a runtime change clears model + thinking + speed, a model change clears the two per-model overrides. Applies to the plain form, the AI-builder setup screen, a committed builder runtime rebind, and a builder draft that moves the model. - Duplicate now follows the rule `multica agent copy` already enforces: same runtime copies model / thinking / speed, a forced fallback to another runtime clears all three (it previously kept a model the target runtime may not serve) and says so. custom_args and concurrency are runtime-independent and still copied. - Settings page: changing the model no longer leaves an orphan override. Only what the authoritative catalog says the new model does not support is cleared, and it travels with the model in one request. An unknown catalog (offline runtime, discovery in flight or failed), an empty "runtime default" model or a model missing from the catalog leaves the stored values untouched instead of deleting a value the daemon would have honoured. - Restores the 255-rune description limit plus counter that the studio lost relative to the old dialog, and gates create on it since a duplicate or builder draft can seed a longer value programmatically. - zh-Hans / en / ja / ko strings, including a fuller duplicate notice (MCP servers and machine-local runtime config are not copied either). Out of scope, tracked separately: max_concurrent_tasks bounds on the API, from-template parity (its UI is unreachable on main), and copying skill enabled state / runtime-skill overrides. Co-authored-by: multica-agent <github@multica.ai> * fix(agents): do not seed a duplicate draft before runtimes resolve (MUL-5390) On a cold start — a direct ?duplicate=<id> link or a refresh — the agent list can resolve while the runtime list is still pending. The one-shot seeding effect ran anyway, so buildDuplicateDraft judged the source runtime unavailable against an empty list and permanently cleared the model / thinking_level / service_tier a same-runtime copy must keep, plus showed the fallback notice. Re-running on every runtime change would instead overwrite edits the user already made, so the gate is on the query being decidable. Seeding now lives in useDuplicateDraftSeed and waits for the runtime query to resolve or fail; a failure still seeds, since an unconfirmable runtime makes the fallback correct. Verified the new test fails without the gate. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
1018c052e9 |
test(daemon): extend the byte-identity guarantee to chat and the other kinds (#6033)
The MUL-5377 regression guard only covered issue runs, but chat sessions resume too: handler/daemon.go:2172 hands the daemon a PriorSessionID from the chat_session row, with the same PriorWorkDir and PriorSessionResumeUnavailable plumbing as an issue task. A chat brief that varied per turn would lose the prompt cache the same way, and a long chat is exactly where that costs most. The three blocks that moved out of the brief (Task Initiator, Session Continuity Notice, Connected Apps) were removed for every kind, so chat is already stable — this locks that in rather than leaving it as an accident. The initiator variant matters most: in a Slack-backed session a different person can trigger each turn, which is precisely when the old brief's Task Initiator block changed. Autopilot and quick-create are single-shot today; the invariant is free to hold for them too and stops a future resume path from silently reintroducing the bug. Test-only change. Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Multica Eve
|
aa110aac9c |
MUL-5088: import repositories from GitHub App (#5896)
* feat(github): import repositories from app installations Co-authored-by: multica-agent <github@multica.ai> * fix(github): address repository import review nits Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Naiyuan Qing
|
420ffe7dbc |
feat(diagnostics): capture the JS stack of a hung renderer (MUL-5345) (#6026)
* feat(diagnostics): capture the JS stack of a hung renderer (MUL-5345) Route attribution shipped in 0.4.12 and did its job: hard hangs are no longer scattered, they cluster on one page (10 of 12 hangs, 8 distinct users, spread over 16 hours). It also hit its ceiling there. That page hosts three modes on a single route and the mode lives in component state, so the route field cannot say which of them froze — and a page name was never going to name the function either. Two rounds of code-reading produced two hypotheses and both were wrong, and one manual repro attempt covered a path the telemetry never pointed at. Naming the code requires reading it off the stuck thread. When the renderer hangs, the main process attaches the DevTools protocol and asks for the stack. The channel is warmed while the renderer is healthy because a command sent after the thread is stuck is never dispatched — measured on the pinned Electron 39.8.7, where a post-hang attach returned nothing in 5s while a pause on a warm channel returned the stack in 2ms with the blocking function on top. Holding the channel open all session showed no cost beyond run-to-run noise (A/B/A; the ordering drift between cold phases exceeded the effect). That channel is the reason this ships behind a fail-closed server flag rather than on by default. `desktop_hang_stack_capture` rides the existing `/api/config` feature flags; main starts off, only an explicit `true` enables it, and revoking it detaches the channels rather than merely skipping the next capture. Main cannot read config itself, so the renderer forwards the one bit — which means a config that never arrives also lands on off. Privacy is unchanged in kind from `$exception`: four scalar fields per frame, `scopeChain` and `this` dropped so no handle can be dereferenced into user data, script URLs reduced to their bundle-relative tail, and a four-verb CDP allowlist that a source-level test pins to a single callsite. Resume is unconditional — a capture must never turn a recoverable hang into a permanent one. Delivery is fixed alongside, because a stack that cannot be sent is not worth capturing: `freeze:get-last` no longer deletes on read, the report goes out with `send_instantly`, and the breadcrumb is retired only after a grace window, so a second hang inside that window leaves the file for the next boot instead of taking the report with it (the MUL-4115 failure mode). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> * fix(diagnostics): close the kill switch, egress and multi-window gaps (MUL-5345) Three review findings on #6026, all in failure paths the tests didn't reach. The kill switch didn't reliably revoke. `coolDebuggerChannel` only detached after `Debugger.disable` resolved, so a failed disable left the channel attached — the exact state the switch exists to exit. Disable is a courtesy to the renderer; detach is the contract, so it now runs in `finally`. Warming had the mirror bug: an attach we made and could not enable returned false while leaving the channel open, stranding a debugger on a renderer nothing tracks. That attach is rolled back now, and only that one — a channel someone else owns (DevTools) is left alone. Stack frames were sanitized at capture and then forwarded verbatim at egress. Between those two points they cross an on-disk breadcrumb that `readFreezeBreadcrumb` barely validates, by design: it only has to survive version skew. So "sanitized once" was not a property the flush side could rely on — an older build, a corrupt file or a future writer could put a `scopeChain` handle or an absolute install path in there and it would ship. Both ends now rebuild frames through one shared whitelist, which also makes them impossible to drift apart. The url reduction is idempotent so re-running it costs nothing. The control flag was global, and that does not survive multiple windows. Every renderer publishes `false` before its own config lands, so a window opened while capture was on either never warmed (the global value never changed, so nothing warmed the new webContents) or cooled every other window on its way up. State is per renderer now; they converge on the same value because they read the same config, but each on its own schedule. Regression tests for each: detach after a throwing disable and rollback after a throwing enable, a frame carrying `scopeChain` / `this` / an absolute path reaching the flush side, and a second window warming while the first is already on without revoking it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> |
||
|
Bohan Jiang
|
ce45b8d353 |
feat(usage): rank the Errors offender list by failures or rate (MUL-5389) (#6023)
* feat(usage): rank the Errors offender list by failures or rate (MUL-5389) The Top offenders list ranked agents by absolute failure count and sized its bars the same way, while the loudest number on each row was the failure rate. The three never agreed: the worst-rate agent could sit near the bottom of the list with one of the shortest bars, and the busiest agent was pinned to the top with a full bar regardless of how healthy it was. Adopt the leaderboard's contract — sort metric, bar length and the emphasised column move together: - A Failures / Rate segmented control above the list. Bars are scaled to whichever metric is active, so a bar can no longer imply a number it is not measuring. - Under Rate, agents with fewer than MIN_RATE_SAMPLE terminal runs sort after every agent with enough runs. One run that failed is a 100% rate and would otherwise win outright. Those rows still render, and say why their rate is muted on hover — dropping them would stop the list reconciling with the workspace failure count above it. - `4 / 10 · 40%` becomes labelled Failed / Runs / Rate columns. - The bar is stacked by failure class and the dominant-class badge is gone. Colour now means the whole composition rather than repeating the badge: an agent failing one way is a solid block, one failing five ways is visibly striped. The bar carries that split as its accessible name. - `By class` becomes `Failure mix · N`, so the section states its own denominator instead of sitting under a rate over a different one. The failure rollups are unchanged; per-agent per-class counts were already on the wire and were being discarded after picking a top class. Co-authored-by: multica-agent <github@multica.ai> * fix(usage): announce the segmented control's active option, refresh a stale comment Review follow-ups on #6023. `Segmented` expressed the active option only as a colour swap, so a screen reader could not tell which metric the leaderboard or the offender list was ranked by. Each option now carries `aria-pressed`, and the group carries a required `label` — a naked group of toggle buttons announces "Rate, pressed" without ever saying what it ranks. Toggle buttons rather than a radiogroup: a radiogroup owes the user arrow-key roving focus, and these are ordinary tab stops everywhere they appear. `anonymizeUnresolvedAgentRows`' comment still argued that merging aggregated rows would lose the class breakdown, which stopped being true once AgentFailureRow started carrying the full per-class split. The reason to rewrite raw rows is now that the bucket reaches `aggregateAgentFailures` as an ordinary agent_id, so its totals, rate, class split and rank all come from one code path instead of a hand-rolled second copy at the merge site. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
4eb80c8b77 |
fix(daemon): keep the runtime brief byte-stable across triggers (MUL-5377) (#6021)
* fix(daemon): keep the runtime brief byte-stable across triggers (MUL-5377) Claude Code loads the runtime brief (CLAUDE.md / AGENTS.md) into messages[0], ahead of the entire conversation. A cache breakpoint is all-or-nothing, so a single differing byte there invalidates the prompt cache for the whole history on every `--resume`. InjectRuntimeConfig rewrites that file on every run and interpolated nine per-run values into it, so in practice the cache was thrown away on the first comment that landed on any issue. Measured on one issue over three runs: run 1 (cold) spent 89.9k cache-write tokens building 105k of context; runs 2 and 3 each spent ~425k re-creating a prefix they should have read. 842k of 946.5k cache-write tokens (89%) went into re-creation, with only tools[]+system[] surviving each resume (a constant 18,085 tokens both times). Fix: the brief now carries only what is stable for the lifetime of a resumed session, and per-run state travels in the per-turn user message, which is appended after the cached prefix. - Merge kindCommentTriggered + kindAssignmentTriggered into kindIssue, and stop reading TriggerCommentID in classifyTask. The brief can no longer diverge by trigger type structurally, rather than by convention. - Replace writeWorkflowComment/writeWorkflowAssignment with one writeWorkflowIssue that routes on the per-turn message. The mode-specific status rules live inside their own mode block, so "own the status arc" and "do not touch the status" can never be read as unarbitrated peers. - Move Task Initiator, Session Continuity Notice and Connected Apps out of the brief into BuildPrompt via BuildTaskInitiatorBlock / SessionContinuityNotice / BuildConnectedAppsBlock. - Drop TriggerCommentID, TriggerThreadID, NewCommentsSince, NewCommentCount, PriorSessionResumed and CommentReplyTargets from the brief; BuildPrompt already emitted all six from the same helpers, so this is de-duplication. - Set PriorSessionResumeUnavailable on `task` as well as `taskCtx` in both local resume gates, or the notice would silently vanish on exactly the failure path it exists to disclose. Tests: TestInjectRuntimeConfigByteIdenticalAcrossTriggers renders the brief across nine per-run variants (trigger type, differing comment/thread ids, resume delta, resume-unavailable, cross-thread fan-out, member/agent initiator, connected apps) for two providers and requires bytes.Equal, with a non-vacuity guard so it cannot pass on a function that ignores its input. Daemon-side tests assert the moved sections still reach the agent through the per-turn prompt. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): route the issue workflow on an explicit turn-mode marker Review follow-up on the mode router. The brief said Reply mode applies when the per-turn message "opens with a [NEW COMMENT] block", but buildCommentPrompt writes two paragraphs before that block and only emits it when TriggerCommentContent is non-empty. Two ways to get it wrong: - The message never literally opens with the block, so the router's own wording did not match the prompt it describes. - A comment-triggered run with an empty comment body — or an older server that does not send one — emitted no block at all. An agent following the brief would fall through to Ownership mode and change the issue status on a turn whose rule is "do NOT change the issue status". BuildPrompt now emits an unconditional `**Turn mode: Reply.**` / `**Turn mode: Ownership.**` line from the same branches it uses to pick a code path, and the brief routes on that marker. Brief and prompt can no longer disagree about the mode, because the value that selects the path also states it. The router also names a safe fallback (treat an unlabelled turn as Reply mode and leave the status alone). Tests: TestTurnModeMarkerAlwaysPresent covers comment-triggered with and without comment content, plus both assignment shapes; TestTurnModeMarkerAbsentOnIssuelessKinds keeps the marker off chat / quick-create / autopilot; TestBriefModeRouterMatchesPromptMarkers fails if the brief ever describes a marker the prompt does not emit. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
a874dc8066 |
feat(usage): cap the leaderboard at the top 10 agents behind a Show all toggle (MUL-5388) (#6020)
The leaderboard flattened every agent in the workspace, so a workspace with dozens of them pushed the Errors card a full screen or more below the fold. Rank the top 10 by the selected metric and collapse the tail behind the same toggle the Errors card's top-offenders list already uses; bar widths still scale to the global max so nothing re-scales on expand. Rows become a real list so the truncated ranking exposes its item boundaries to screen readers. Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Naiyuan Qing
|
995ec8fcf2 |
feat(editor): 粘贴超长文本自动转为文本附件 (#6019)
* feat(editor): convert over-threshold pastes into a text attachment Pasting more than PASTE_AS_FILE_THRESHOLD (4000) characters into a turn-based composer now uploads a `pasted-text.txt` attachment instead of writing thousands of characters into the body. Opt-in per editor: chat, new comment, reply and comment edit pass the threshold; issue and project descriptions deliberately do not, because there a long paste IS the content. The synthesised File goes through the existing upload pipeline unchanged (nothing in it inspects a File's origin), so draft persistence, status chips and .txt preview all come for free. Recovery is the part that needed real design. A dropped file survives a failed upload on disk; this text exists nowhere else — it was never written into the document and its source tab may be closed. Since uploads outlive their mount (MUL-5181), the editor cannot own that recovery, so useCoordinatedUploads does: deliverPastedTextBack mirrors deliverFinishedUpload (live editor, else the persisted body) and is the single responder, so the live and dead cases can neither both fire nor both be skipped. The text is restored as markdown because markdown-paste is what would have handled it had it never been converted. A paste inside a code block stays inline — opening a fence is the request to show the thing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(editor): pin the paste handler order against the real extension array Both markdownPaste and fileUpload register catch-all handlePaste handlers, so which one ProseMirror consults first decides whether paste-as-file works at all. That ordering is not visible in either file: Tiptap reverses the extension array before collecting plugins (@tiptap/core `get plugins()`), and neither extension sets a priority, so the array position in createEditorExtensions is the whole contract. The existing tests mounted the fileUpload extension alone and could not see it. This one builds the production array via createEditorExtensions; swapping the two entries makes it fail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Jiayuan Zhang
|
2274f521dc |
feat(issues): agents-working chip on the sub-issues header (#5825) (#5834)
* feat(issues): aggregate agents-working chip on the sub-issues header (#5825) Add a live "N agents working" chip next to the sub-issues progress ring in issue detail. The per-row IssueAgentActivityIndicator shows which sub-issue is being worked; this chip shows how many agents are on the parent's children at a glance — and keeps that signal visible while the list is collapsed. Derives from the shared workspace agent-task snapshot narrowed by a new selectIssuesTasks select (structural sharing keeps unrelated snapshot churn from re-rendering the header). Counts unique agents to match the workspace chip, whose chip_agents_working / hover_header_queued strings it reuses — already translated in every locale. Hover opens the shared AgentActivityHoverContent task list. Fixes #5825 Co-authored-by: multica-agent <github@multica.ai> * refactor(issues): read the sub-issues chip from the working-agents projection (#5825) The chip landed deriving its own count from the workspace agent-task snapshot, which put a second definition of "an agent is working" in the client. It showed up immediately: the number came from the running tasks only while the hover body listed running plus queued, so a parent with 2 running and 3 queued agents read "2 agents working" over a five-row card. A header count is a claim about a scope, so let the server own both the scope and the arithmetic, exactly as the Issues list header already does. ListWorkspaceWorkingAgents grows an optional parent_issue_id narrowing and the chip reads /api/working-agents?type=issue&parent=<id>. The number, the avatars and the hover body are now one list rather than three derivations, so they cannot disagree. Row indicators keep reading the snapshot. One shared query sliced per row is the right shape for a per-row cue and a stale row decoration costs nothing; a header number is the opposite, it has to be authoritative. The new parameter is additive: omitted, the query and the response are byte-for-byte what they were, so an installed client that never sends it keeps the workspace-wide behaviour. A regression test pins that. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai> Co-authored-by: Naiyuan Qing <145280634+NevilleQingNY@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> |
||
|
Bohan Jiang
|
ba108978ac |
fix(channel): deliver the final answer only to Slack and Lark (MUL-5378) (#6016)
* fix(channel): deliver the final answer only to Slack and Lark (MUL-5378) Channel replies could carry the agent's interim narration alongside its answer (GH #6006). Two independent causes, both fixed at the layer that owns the deliverable. Prompt regression. #4776 told every channel-backed chat to reply with the answer only and not narrate. The MUL-4899 split (#5557) moved that rule into the Slack branch along with the `chat history` / `chat thread` commands its wording happened to mention, so Feishu/Lark silently lost it on 2026-07-17. The rule is a third axis — it keys off "is there a channel at all", like the attachment-upload axis — so it now sits outside the Slack gate, generalized from "these history reads" to any progress note. The old two-layer matrix could not catch the regression because it only asserted the rule on the Slack case; the new test pins all three states. Runtime contract. Result.Output is documented as "final user-facing output selected by the backend" (agent.go), but Codex concatenated every agent_message and Copilot joined every assistant turn with "\n\n", so a tool-using run handed the daemon narration + answer as one string. Codex now takes the message its app-server labels phase="final_answer", falling back to the most recent agent message on the legacy protocol; Copilot keeps the latest complete turn, with the streaming deltas retained as the process-died-mid-turn fallback. This narrows delivery only — every message still streams as MessageText, so the Multica transcript is unchanged. Claude Code, CodeBuddy and qwen already selected a terminal result and are untouched; opencode/deveco/openclaw share the accumulating shape and want the same audit (pi was already fixed this way in #4894). Verified: go build ./..., go vet, full ./pkg/agent and ./internal/daemon/... suites pass locally. Co-authored-by: multica-agent <github@multica.ai> * fix(channel): scope the no-narration rule to process, not results Review follow-ups on the channel delivery rule and the Copilot turn boundary. The prompt said a reply "must not say what you are about to do or just did", which literally forbids the deliverable itself: asked to create an issue, the correct reply IS "created issue X". Rewritten to ban planned and in-progress narration while explicitly protecting the completion confirmation. The test now pins both halves — a future edit that drops the carve-out, or restores the blanket past-tense ban, fails. The example also referenced "check the code", which is not a thing an agent does inside a Slack or Lark conversation. Replaced with a generic "let me look into that first". Copilot cleared pendingDelta only when the authoritative assistant.message carried content. A tool-only turn reports content:"" with the requests as the whole turn, so its streamed deltas stayed buffered and were stitched onto the next turn's partial text if the process then died mid-stream — verified: the new test yields "Checking the logs now.The retry loop" before the fix. The reset now happens on every assistant.message, since that event is the turn boundary regardless of whether it carries text. Verified: go build ./..., go vet, full ./pkg/agent and ./internal/daemon/... suites pass locally. Co-authored-by: multica-agent <github@multica.ai> * fix(channel): tighten the no-narration rule to one sentence Same contract, fewer tokens: the four-line rationale comment collapses to one, and the delivery rule drops the restatement, the second example and the completion examples. What survives is exactly the semantic boundary the tests pin — no planned/in-progress narration, completed actions still count as the outcome — plus the one narration example actually observed in the report. Verified: go build ./..., go vet, ./internal/daemon/... suite pass locally. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
50c89c7094 |
feat(autopilots): hide webhook URL token by default (MUL-5374) (#6015)
* feat(autopilots): hide webhook URL token by default (MUL-5374) The webhook URL is a bearer credential — anyone who reads it off a screen share or screenshot can fire the autopilot. GH #6004 reports exactly that leak during a live demo. The trigger row and the post-create panel now render the URL through a shared WebhookUrlField that masks the token segment by default. Clicking the value (or the eye toggle) reveals it; Copy keeps working while hidden, so the common case never needs a reveal. The plaintext token is not in the DOM until the user asks for it — this is a real display boundary, not a CSS blur. Co-authored-by: multica-agent <github@multica.ai> * fix(autopilots): scope webhook URL reveal to the URL it was granted for (MUL-5374) The reveal was a bare boolean, so a token rotation under a mounted trigger row swapped in the new URL while `revealed` was still true — exposing the new credential in the clear at the exact moment the user rotated to contain a leak. Track which URL the reveal was granted for and derive `revealed` during render. Deriving it (rather than resetting in an effect) means the new token never reaches the DOM, not even for the pre-effect frame. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Bohan Jiang
|
c271f80999 |
MUL-5370 fix: label stalled skill-bundle downloads, align failure-reason copy with the backend taxonomy (#6001)
* fix(daemon): label stalled skill-bundle downloads and make them retryable A skill bundle that could not be downloaded during task preparation surfaced as the bare string "resolve skill bundles: context deadline exceeded". taskfailure.Classify has no rule for a Go context deadline, so it landed in agent_error.unknown — a bucket that is NOT on the server's retry allowlist. A transient stall therefore became a terminal chat failure carrying a label nobody could act on, and the failure was invisible on the Usage page's Errors breakdown. (MUL-5370) - Add the platform-side reason skill_bundle_unavailable and put it on retryableReasons. Retrying is cheap and safe: the agent process never started, and bundles that did arrive are already cached on disk, so successive attempts converge. - Carry a sentinel error from the resolve loop so the reason is derived structurally rather than by matching the wrapped transport error's text, and name the skill, its declared size and the elapsed wait in the wrap — enough to tell "this bundle is too big for the link" from "the link is dead" without reading daemon logs. - Normalise the wire shape an OLD daemon produces (a non-empty catchall plus the previous "resolve skill bundles:" wrapper) on the server side. Installed daemons upgrade on their own cadence, and FailTask only classifies when the caller supplied nothing, so without this the fix would reach only hosts that happened to update — while the un-upgraded hosts most likely to be hitting the bug kept failing terminally. - Teach Classify about "deadline exceeded" and net/http's "Client.Timeout exceeded while awaiting" so any other Go-side deadline that reaches it as text stops falling into the unknown bucket too. - Backfill historical rows in both agent_task_queue and chat_message. Scoped to agent_error.unknown alone — the old wrapper string postdates the in-flight classifier by three weeks, so no row carrying it can hold the legacy coarse value — which keeps the down migration an exact inverse. Co-authored-by: multica-agent <github@multica.ai> * fix(chat): give chat its own failure copy for the refined reasons #5991 rebuilt the operator-facing failure labels around an open wire string with a raw-value fallback, but the chat bubble kept its own exact-key lookup against the six coarse values from migration 055. So all 14 agent_error.* values still missed and rendered the generic "Something went wrong and the agent couldn't finish replying" — the classification the backend had already computed was discarded at the last step, and that is the message the MUL-5370 reporter saw. - Add resolveFailureReasonKey in packages/core: exact match, else degrade an `agent_error.*` value to its family, else undefined. A reason newer than the shipped client now lands on the family line instead of the fallback. - Rekey the chat copy map by wire value and route it through the helper. Chat deliberately degrades to friendly copy rather than adopting the operator surfaces' raw-value fallback: it is read by the person who just sent a message, and the raw error is one click away under the collapsible. - Add refined chat copy (en / zh-Hans / ja / ko) only where it can say something the family line can't — a different next step: network, auth, quota, rate limit, context overflow, missing/outdated CLI, skill download. - Give skill_bundle_unavailable a label on the web and mobile surfaces and a class on the Usage page's Errors breakdown (runtime — the operator response is "check the daemon's link to Multica", the provider is not involved). - Mobile's two label maps were still coarse-only for the same reason; rekey them by wire value and fill in the refined taxonomy. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |
||
|
Naiyuan Qing
|
b5f19adbab |
feat(composer): post-send caret policy per surface (afterAccepted) (#6014)
* feat(composer): post-send caret policy per surface (afterAccepted)
Where the caret goes after a send was hand-rolled per composer: chat blurred,
quick-create hand-wrote its own requestAnimationFrame focus, and comment/reply
did nothing at all. The mechanics are identical everywhere and easy to get
wrong (must run after the clear, must survive a dialog focus trap, must not
steal focus the user moved elsewhere mid-flight), so they now live once in the
shared send contract.
`useComposerSubmit` gains `afterAccepted` ("refocus" | "blur" | "none",
default "none") plus an optional `containerRef` that bounds focus reclaim to
the composer that sent. The mode may be a function so a surface can decide at
accept time — chat only reclaims focus when the commit actually scrubbed the
shared editor, never when a fire-and-forget send left another session's draft
on screen.
Per-surface policy:
- Chat refocuses (one file, three mount points: chat page, floating window,
agent creation studio). Replaces the deliberate blur.
- Thread replies refocus — the user is mid-conversation.
- A top-level comment blurs, and IssueDetail reveals what was posted instead:
submitComment now returns the created id, and the page scrolls to that row
and flashes it with the same jumpToThread the inbox deep-link uses.
- Quick create's keep-open mode drops its hand-written rAF for the option.
- Inline comment edit and Create Issue keep "none": both close on save.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* refactor(composer): drop the scroll-to-posted-comment reveal
The top-level composer is sticky at the bottom of the timeline, so a comment
posted from it lands directly above the box and is almost always already on
screen — the scroll was a no-op and the flash re-announced something the user
had just deliberately done. The flash earns its keep for inbox deep-links,
where the user did not choose the landing spot.
`submitComment` goes back to returning a boolean; it only carried the created
id to feed the reveal. The composer still blurs after posting: the turn is
over, so the caret is dropped rather than kept.
The shared contract is untouched — `afterAccepted` never knew about comments,
which is why removing this costs nothing outside IssueDetail.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* docs(composer): drop stale references to the removed comment reveal
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
* fix(composer): bind the post-send caret policy to an actually-cleared editor
Review blocker: CommentInput passed a literal `afterAccepted: "blur"`, but its
stale-submit guard declines to clear when the user typed during the request.
Posting comment A on a slow connection while typing comment B therefore
dropped the caret out of B mid-sentence — the guard kept the text, and the
blur fired anyway.
Both issue composers now resolve the mode from a ref set only on the branch
that really wipes the editor, matching what ChatInput and quick-create already
do. ReplyInput gets the same treatment: refocusing a box the user is typing in
happens to be harmless, but leaving one surface on the unsafe shape invites the
next one to copy it.
The rule is now stated on the option itself: a surface whose `onAccepted` can
decline to clear must pass a function and resolve to "none" on those paths.
Both regressions are mutation-verified — reverting either binding fails the new
assertions.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
||
|
beast
|
077ac8acc9 |
refactor(channel): claim media ledger rows one at a time (MUL-5367) (#5993)
The reconciler claimed a batch of ledger rows under one lease and settled them serially, so a tail row could expire and be reclaimed before its own DELETE was ever tried — inflating attempt/backoff for work that never happened, and delaying the row's first real attempt. Rows are now claimed one at a time, immediately before the work each claim authorizes, so attempt counts attempts. The per-row lease heartbeat is gone: the lease only has to cover one row's settle (30s delete timeout << 2m lease) and every settle write is already lease-token guarded. Migration 232 adds an index on next_attempt_at: migration 230's index leads with state and cannot serve the claim's cross-state ordering, so under backlog every claim in a sweep paid a full seq scan plus an external merge sort. Shutdown that lands mid-settle now stays quiet — the row keeps its lease and is reclaimed after expiry, like any interrupted worker. |
||
|
Naiyuan Qing
|
77b309a5ac |
feat(drafts): unified draft lifecycle + upload ownership inversion (MUL-5181) (#5900)
* feat(drafts): unified draft lifecycle + upload ownership inversion (MUL-5181) Unify how every composer preserves unsent work, sends, and handles uploads. L1 foundation (packages/core/drafts): - createDraftStore factory + self-registering cleanup-registry replacing the hand-maintained WORKSPACE_SCOPED_KEYS list; register-all-drafts guarantees registration completeness. Fixes the confirmed cross-user draft leak (persistence + in-memory) on logout / workspace delete. L3 send paradigm: - useComposerSubmit: one await-then-render contract (lock/spin, keep-on-fail, clear-on-success, single-flight, submit-time upload-gate), adopted by comment/reply/edit, create-issue, quick-create, and chat. Per-surface: - Comment/Reply/Edit: attachments moved into the persisted draft. - Create Issue: draft split into shared/manual/agent/activeMode with non-destructive mode switching + migration for old flat drafts. - Chat: optimistic send converted to await-then-render (kept server-driven cancel restore_to_input); chat draft keys registered for cleanup. L2 upload coordinator (ownership inversion, Linear-validated shape): - upload-coordinator + DraftUpload placeholder: uploads owned by a module coordinator that outlives the component, state persisted in the draft; AbortController + abort-on-logout; interrupted-on-reload. Comment surface fully wired. Create-issue/chat upload wiring is a documented residual. Verified: core + views typecheck clean; core 1064 + views 2928 tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(drafts): close three review gaps in the unified draft lifecycle (MUL-5181) 1. Logout resurrection: reset in-memory draft stores BEFORE removing their persisted keys — each reset is a setState and persist writes it straight back under the still-active slug, so the old order re-created the deleted keys. The issue draft store's reset is now a full reset including lastAssignee, which clearDraft deliberately re-seeds and would otherwise hand the previous user's last-picked assignee to the next login. 2. Submit gate blind spot: the composer gate now also reads the draft's coordinator-owned upload placeholders (hasUploadingDraft). A composer reopened over a still-in-flight upload could previously send past the editor-only gate, clearing the draft out from under the settling upload. 3. Attachment binding returns to reference-filtering: a submit binds only uploads the body references, so deleting an inline image really unbinds it. An upload that settles after its mount died gets its markdown link written back into the body instead — via the reopened composer's live editor (new ContentEditorRef.insertMarkdownAtEnd) or appended to the persisted draft (new appendToDraftContent) — so close-surviving files stay visible, deletable, and honestly bound. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): harden upload write-back delivery after independent review Review of the previous commit (fresh-context reviewer + probe against real @tiptap/react) found the write-back could still lose a file: - insertMarkdownAtEnd now returns a boolean: the imperative handle exists from first commit but the Tiptap instance arrives in a passive effect, so an insert in that window (or after destroy) no-ops. Callers previously assumed it landed. - Write-back is now confirmed delivery (deliverFinishedUpload): insert into the live editor and, on success, persist the same body as insurance against the debounced emit being dropped by a quick unmount; append to the store only when NO composer is mounted (a mounted editor's first emit would erase a store-only append); retry while a mounted composer's instance is still warming up. Every attempt re-checks the generation guard and the body reference. - mountedRef flips in a layout effect: React nulls the child editor ref in the unmount commit, and a settle in the gap before passive cleanup saw "mounted" with no editor left to swap. - uploadAndInsertFile guards editor.isDestroyed after the await: now that uploads outlive mounts, the swap/remove paths could dispatch against a destroyed EditorView and escape as an unhandled rejection. - Tests: the reopened-composer test now asserts the editor actually received the insert (it previously passed with liveEditors disabled), plus a warming-up retry case; the mock editor mirrors isDestroyed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(drafts): roll coordinated uploads out to issue-create and chat (MUL-5181 L2) Completes the upload-ownership layer for every composer surface. The generic engine is extracted from the comment implementation into editor/use-coordinated-uploads (UploadDraftBinding adapter: store-backed accessors + registry key + body append), and use-comment-uploads becomes a thin binding over it — behavior unchanged, all comment tests green. Issue-create (manual + agent panels): - shared.attachments migrates Attachment[] -> DraftUpload[]; load normalizes legacy bare rows to `uploaded` and coerces stale `uploading` to `interrupted`. - Uploads are coordinator-owned: placeholder at pick time, survives dialog close, aborts on logout, chips for uploading/failed/interrupted, combined gate on Create and both mode-switch actions. - Write-back targets the body of the MODE that started the upload (manual description vs agent prompt); mount-time prune keeps placeholders and drops only unreferenced `uploaded` entries. Chat (tab + floating window): - inputDraftAttachments migrates to DraftUpload[] with load-time normalization; new store ops (add/settle/fail/remove upload, append-to- draft) mirror the comment store. - ChatInput adopts the engine; the upload target is snapshotted at pick time via resolveUploadTarget so a file dropped while the editor is pinned to a previous session's document files under THAT draft. - uploadMapRef is gone — the draft's uploads are the single binding source, reference-filtered at send. Hosts no longer own transport: onUploadFile prop becomes uploadEnabled, and the controller/window drop uploadWithToast. - commitDraft prunes only `uploaded` entries the body no longer references; placeholders survive keystrokes (chips are their only UI). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): harden L2 rollout after independent review - attachmentToDraftUpload now strips the response-scoped signed download_url before the row is persisted (draft uploads survive restarts; a stale signature 403s the preview on reopen). Covers comments, issue-create, and chat in one place; issue-create's settle reuses the helper, and the Signature assertion the rollout had dropped is restored. - chat's live-editor registry follows the LOADED draft key (reactive mirror of editorDraftKeyRef): a settle for draft B must not insert into an editor still pinned to draft A's document. - removeUpload aborts an in-flight request before dropping its placeholder. - issue-create hasDraft counts only uploaded/uploading entries so a failed remnant can't pin the sidebar draft dot forever. - Tests: mutation-proof coverage for the two placeholder-preservation rules (create-issue mount prune, chat commitDraft prune) — both previously survived rule inversion; direct core tests for the five new chat store upload ops incl. persistence and signed-URL stripping; quick-create test gets the editor i18n namespace; dead uploadWithToast scaffolding removed from both modal tests; chat-input mock aligned with the real append semantics. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): close third-round review gaps in the upload engine - The live-editor registry registers in a layout effect: chat's adopt swaps the editor's document and loaded key synchronously during commit, and a passive re-registration one task later left a settle window where the old key mapped to an editor already holding another draft's document. The registry key is also built only when a binding exists. - removeUpload aborts only a request THIS surface tracks as `uploading` (guarded before the abort), with the comment now honest about the path being defensive — no current chip exposes ✕ mid-upload. - Mutation-proof test for the loaded-key registry rule: a dead mount's settle for a pinned draft must insert into the editor HOLDING it, not the selected one (verified to fail with the registry keyed by selection). - hasDraft upload semantics pinned by tests (uploaded/uploading count; failed/interrupted remnants don't pin the sidebar dot). - Dead scaffolding dropped: identity use-file-upload mocks and a redundant assertion in the modal tests. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): stale-submit draft guard + registry layout timing (review BLOCKED items) Blocker 1 — a submit that outlives its composer may only consume the draft it submitted (MUL-5181 P0). Every accepted-submit clear is now guarded: - create-issue / quick-create snapshot the singleton draft's object identity at submit; a dead panel clears (and records last-assignee/mode) only if the draft is untouched, and never runs close/reset effects. A replaced draft B typed after close survives a late success of draft A. - comment / reply / edit snapshot the per-key draft entry; a dead composer clears only the exact entry it submitted. - chat snapshots the sent slot's value; a dead mount's commitInput clears only an unreplaced draft. Mutation-verified tests for the create panels and comments (guard inverted => tests fail), plus untouched-draft control cases. Blocker 2 — the live-editor registry is now genuinely registered in a layout effect. The prior commit claimed this fix but a test-time `git checkout --` discarded the unstaged engine edits before committing; re-applied: layout registration, binding-gated registry key, and the tracked-only abort in removeUpload. New registry timing test captures the registry from a parent layout effect across a key switch — verified to fail with passive registration. Also: `multica:chat:selectedProjectId` joins the workspace-scoped cleanup list (was leaking across logout; flagged as a pre-existing risk). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): mounted submits also clear only the draft they submitted The stale-submit snapshot guard previously protected only dead composers; a mounted one cleared unconditionally on success. But the editor stays interactive during a request (Tiptap cannot toggle editable post-mount), so text typed while draft A was in flight was wiped by A's success. The guard is now unconditional across every surface: success consumes exactly the submitted snapshot, and any later edit survives. - create-issue / quick-create: the editor's pending debounce is flushed into the store BEFORE snapshotting (a late flush of pre-submit typing must not read as a mid-flight edit); a touched draft skips clear AND close/reset — the dialog stays open on the newer work. Untouched behavior unchanged. - comment / reply / edit: same flush + snapshot; a touched entry keeps both the store draft and the editor content (edit mode stays open on it). - chat: commitInput's value compare now applies while mounted too, and the editor is scrubbed only for an untouched draft. - use-composer-submit docs no longer claim "editor locked": they state the real contract — send affordance locks, edits after submit survive. Regression tests: mounted mid-flight-edit cases for manual create (incl. "dialog must not close over draft B"), quick create, comment, and chat, plus mounted-untouched controls. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): idempotent draft writes so a tab switch cannot resurrect a posted comment Final-review blocker: the comment/reply visibilitychange/pagehide flush re-writes IDENTICAL content on every tab switch, and writeDraft minted a new entry object each call — the stale-submit guard's identity compare then read a mid-flight tab switch as "edited during the request", kept the posted comment's draft alive, and left Send enabled for a duplicate. - writeDraft is now a no-op when content and uploads are unchanged (also kills a spurious persist write per tab switch). Regression tests: entry identity preserved on identical setDraft (core), and the reproduced tab-switch-mid-send scenario clears the posted draft (views) — verified to fail with the idempotence removed. - onAccepted now flushes the editor's pending debounce before judging `untouched` on every surface, so typing still inside the debounce window counts as a mid-flight edit instead of being scrubbed. - create-issue records last-assignee/mode from the SUBMITTED values, outside the untouched gate — a created issue updates the preference even when the dialog stays open on newer edits. - Stale guard comments corrected in both create panels; the use-composer-submit docstring no longer claims project/feedback were migrated (they still hand-roll await-then-clear; registered debt). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com> |
||
|
Bohan Jiang
|
f1cb726d7c |
fix(usage): move the Errors card to the page bottom and rebalance its layout (#6003)
Two problems with the card as shipped, both visible on real data (283 failures across 28 agents): 1. It sat between the trend chart and the leaderboard. Spend is the headline of this page; failures are the follow-up question you ask after seeing who is spending. Moved below the leaderboard. 2. The two-column split put a 7-row list next to an unbounded one. In practice that was 7 rows of classes beside 28 rows of agents — roughly 400px of content next to 1500px, so the left half was mostly whitespace and the card was taller than the rest of the page combined. Rebalanced by stacking two full-width sections instead: - Class breakdown is now a single 100%-stacked bar plus a legend, replacing seven individual progress bars. The question is "what is the mix", and one bar answers it directly instead of making the reader compare seven lengths and total them mentally. ~340px becomes ~70px. - Offender rows fold onto one line, borrowing the leaderboard's grid shape (identity, bar, numbers) instead of stacking a full-width bar under each name. Halves the per-row height and lines the numbers into a scannable column. - The list caps at 8 with a "Show all N" toggle. It is ranked by absolute failure count, so the tail is agents that failed once or twice — real, but not what anyone opens this card to see. The toggle label carries the full count, so the cap is never silent. - The raw error-code list gets two columns on wide viewports now that the section has the full page width. Card height on the screenshot's data drops from ~1500px to ~420px. Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai> |