579 Commits

Author	SHA1	Message	Date
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>	2026-07-29 16:03:26 +08:00
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>	2026-07-29 15:54:51 +08:00
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>	2026-07-29 15:39:18 +08:00
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>	2026-07-29 15:20:13 +08:00
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>	2026-07-29 14:01:09 +08:00
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>	2026-07-29 13:22:12 +08:00
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>	2026-07-29 13:15:10 +08:00
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>	2026-07-29 12:47:14 +08:00
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>	2026-07-28 16:19:35 +08:00
Bohan Jiang	4d0475ce89	feat(usage): error/failure charts on the Usage page (MUL-5352) (#5991) ... * feat(usage): add error/failure visibility to the Usage dashboard The Usage page could only answer "how much did we spend"; nothing on it showed how often agents fail, what kind of failure it was, or which agent is responsible. Operators had to open failed tasks one at a time to spot a pattern. `agent_task_queue.failure_reason` already carries the refined 21-value taxonomy from server/pkg/taskfailure, so this is a read path over data that already exists. Backend — two rollups, both scoped by workspace/project/window like the existing dashboard endpoints: GET /api/dashboard/failures/daily per-(date, failure_reason) GET /api/dashboard/failures/by-agent per-(agent, failure_reason) They return every terminal task, not just failures: the `failure_reason: ""` row carries the succeeded count. That is what makes the error rate's denominator share filters with its numerator. The run-time rollups can't serve as that denominator — they require `started_at IS NOT NULL`, so a task that expired in the queue (the signature of a runtime outage) contributes nothing to their failed_count. A failed row with an empty reason column lands in an `unclassified` bucket rather than being mistaken for a success. Frontend: - "Errors" joins the trend toggle, daily and weekly, stacked by failure class with the bucket's error rate in the tooltip. - An Errors card breaks the window down by class and by agent, with the raw failure_reason strings behind a disclosure (unlocalised — an operator pastes them into a log search). Each agent row links to its Work tab, which lists the actual failed runs. - The 21 backend reasons fold into 7 display classes in @multica/core/dashboard. Unknown reasons — including ones from a backend newer than the client — land in "other" instead of being dropped, so the class totals always reconcile with the failure count. The Tasks KPI tile is deliberately left alone: its value counts started tasks only, so quoting the failure rollup's larger count there would put two denominators in one tile. The Errors card states its rate with the denominator spelled out instead. Migration 225 adds a partial index on agent_task_queue(completed_at) for terminal statuses. The table had no completed_at index at all, so the two pre-existing run-time rollups were already scanning it; these two new queries would have doubled that. Closes #4429 (MUL-5352) Co-authored-by: multica-agent <github@multica.ai> * fix(usage): correct the Errors drill-down, window and agent exposure Review findings on PR #5991. 1. The drill-down pointed at the wrong page. `?view=work` renders ActorIssuesPanel — the issues assigned to the agent — while its runs live in the Overview pane's ActivityTab. Link to Overview. That page also could not show why a run failed: `failureReasonLabel` was a `Record<TaskFailureReason, string>` indexed with a cast to the old 6-value coarse enum, so every refined reason the backend has written since MUL-1949 resolved to `undefined`. It is now a function over the full 21-value taxonomy plus the legacy coarse values, falling back to the raw wire string for anything newer than the client. Fixes the issue execution log too, which had the same cast. 2. The Errors card covered one more calendar day than the chart above it. `parseSinceParamInTZ` returns N+1 days of headroom on purpose and the dashboard trims the surplus client-side — but only a series carrying a date can be trimmed that way. Totals / classes / reasons now derive from the date-bucketed rollup after that trim, and the per-agent rollup (which has no date to trim on) closes its window server-side via a new `parseExactSinceParamInTZ`. At days=1 the card previously reported yesterday's failures beside a chart showing none. 3. The top-offenders list leaked agents the viewer cannot see. The failure rollups are workspace-scoped and deliberately skip per-agent visibility, but the agent list they are joined against does not — members only see a private agent when they own it or are owner/admin. `name ?? row.agentId` therefore rendered a bare UUID along with that agent's failure count, rate and dominant error class. Unresolvable agents now fold into one anonymous row, and the renderer never falls back to an id. Stricter than `bucketUnknownAgentRows` while the agent list loads: a transient flash of UUIDs is the leak, not a cosmetic glitch. Also from the review: the Errors tooltip echoed the raw Recharts dataKey ("rate_limit") instead of the translated label the legend already carries. Not changed — the schema's `failure_reason` default stays `""`. Defaulting a missing field to a failure bucket guards against a deflated rate, but the realistic drift is `omitempty` on the Go struct tag, which would strip the field from exactly the SUCCESS rows and read as a 100% error rate. Added TestDashboardFailureWireContractKeepsEmptyReason to pin that the server always emits the field, which is the assumption the default rests on. Co-authored-by: multica-agent <github@multica.ai> * fix(usage): renumber migration and fix the anonymous bucket's failure class Review findings on PR #5991, round 2. 1. Migration prefix 225 collided with `225_chat_message_channel_media_pending`, which landed on main while this branch was open — backend CI failed on TestMigrationNumericPrefixesStayUniqueAfterLegacySet. Merged main and renumbered to 231; main now carries 225 through 230, so 226 is taken too. 2. The anonymous "Other agents" bucket could announce the wrong failure class. It merged rows that had ALREADY collapsed to one dominant class per agent, then credited each agent's entire failure count to that class. An agent failing auth 6 / timeout 5 contributed 11 to auth and 0 to timeout, so a bucket whose real composition was timeout 15 / auth 6 rendered as Auth. Fixed by anonymizing the raw per-(agent, reason) rows instead: the sentinel becomes just another agent_id and `aggregateAgentFailures` computes its classes from real counts. That also deletes the parallel bucketing pass — one identity rewrite replaces it. `knownAgentIds` moves up to where both consumers can see it. Also from the review: - The wire-contract test decoded both payloads into one map. json.Unmarshal merges into a non-nil map rather than resetting it, so a residual failure_reason from the first case could have masked an omitempty regression in the second — exactly what the test is meant to catch. Now table-driven with a fresh map per case. - A test comment still described the drill-down as pointing at the Work tab. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-27 18:40:48 +08:00
beast	60048172a7	fix(lark): ingest inbound images and videos as chat attachments (MUL-4934) (#5580) ... * fix: ingest feishu media as chat attachments * fix: ingest feishu post embedded media * fix(lark): make inbound media retries safe * fix lark media resource limit * fix(lark): move inbound media off ack path * fix(channel): make inbound media runs durable * fix(channel): close enqueue-vs-append race on media deferral EnqueueChatTask read the session-wide media deadline in one statement and sealed the input batch in a later one. Under READ COMMITTED a media message committing between the two got sealed into a task the deadline read had already decided was 'queued', so the daemon could claim it before its attachment bound — the agent received the bare placeholder, and the later media-ready promotion was a no-op against a non-deferred task. After the seal, re-derive the deferral from the sealed batch itself in the same transaction (DeferChatTaskForSealedPendingMedia): if any sealed message still carries an unexpired media marker, flip the task to deferred with fire_at aligned to the latest marker. The existing post-commit promote fence already covers the opposite direction (marker cleared mid-transaction). Adds a deterministic regression test that injects the media append between the deadline read and the seal via a wrapped pgx.Tx. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): keep committed chat task out of enqueue error path The post-commit media-ready fence returned its error from EnqueueChatTask even though the deferred task was already durably committed. The router flush treats any enqueue error as "no task exists": it clears the typing indicator and logs an enqueue failure while the run still happens at its fire_at deadline. Log the fence failure instead — the claim-path deferred promoter re-queues the task regardless. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): cap global media resolution concurrency Media jobs were serialized per session but unbounded across sessions: a burst could open arbitrarily many concurrent 45s Lark downloads, and each unknown-length upload may buffer up to the 100 MiB resource cap in memory. Gate resolveAndBindMedia behind a global slot semaphore (default 8, RouterConfig.MediaConcurrency). Per-session ordering is unchanged; on shutdown a job cancelled while waiting for a slot proceeds straight to the bounded DB finalize so marker clearing stays prompt. Also document that the per-message media budget spans queue/slot waits (it must match the persisted fire_at) and why timed-out uploads cannot leak unbounded orphans. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(chat): keep channel-sealed user messages on task cancel Sealing the channel input batch stamps task_id onto channel user messages, which exposed them to the cancel draft-restore path: an empty-transcript cancel would DeleteUserChatMessageByTask the sealed Feishu/Slack messages and detach their attachments. Those messages are the durable record of what the platform sender wrote — the sender has no Multica composer to restore a draft into. Gate the restore-delete on ChatSessionHasChannelBinding in both the synchronous finalize and the deferred finalize (the latter covers markers left by an older replica during a rolling deploy); a bound session now settles as "Stopped." instead. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): skip the media pipeline for messages without media Every inbound message on a Media-enabled platform persisted a 45s media deadline and queued a resolution job, so a plain text message could wait behind the global media semaphore (its task deferred while other sessions download 100 MiB videos) and a crash between append and clear delayed a pure-text run to the full 45s fallback. Add MediaResolver.HasMedia — a pure in-memory probe the Router calls on the ACK path — and only persist the deadline / enqueue the job when the message actually references platform media. The Feishu resolver decodes the already-received payload and reports standalone image or video keys and post-embedded img/media spans. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(chat): gate cancel restore on immutable channel provenance The previous guard keyed the cancel restore-delete off ChatSessionHasChannelBinding, but a binding only proves routing exists right now: archiving a session and rebinding an installation both delete the binding while preserving chat history, so a still-cancellable sealed task could again restore-delete the original inbound messages. Persist provenance on the message instead: migration 203 adds chat_message.channel_ingested, stamped inside the channel append transaction and never mutated, and both cancel finalize paths now gate on TaskHasChannelIngestedMessages over the task's sealed batch. The binding-existence query is removed. Regression tests cover ingest -> archive/unbind -> cancel for a queued and a started task. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): reclaim media uploads that never gain an attachment row Deadline expiry dropped already-resolved refs and a BindMedia failure was log-only, leaving uploaded objects with no attachment row and no reclaim path — the dedup mark commits with the message before media runs, so a redelivery is dropped as a duplicate and never re-resolves (and thus never overwrites) those keys, and workspace/session deletion only enumerates the attachment table. Add MediaResolver.DiscardMedia — a best-effort delete by StorageKey — and call it from both failure paths in resolveAndBindMedia. The Feishu resolver forwards to the storage backend's Delete. Tests cover a partial upload discarded at the deadline, discard on bind failure, and key-level deletion in the resolver. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(server): refresh comments stale after detached media ingestion Channel tasks now seal a self-owned input batch, media ingestion is no longer out of scope for the flattener, and MediaRefs are filled by the detached resolver after append rather than by feishuChannel pre-engine. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(chat): stop keying channel empty-completion silence off chat_input_task_id Sealing gave channel tasks a self input-owner, which broke writeChatCompletionOutcome's discriminator: it treated any owned task as direct, so an empty channel completion wrote the no_response fallback row and the outbound patcher — which forwards any non-empty chat:done content verbatim — pushed the English fallback body to Feishu/Slack, violating the MUL-4351 contract. Silence is now decided by the immutable channel_ingested provenance of the task's input batch, looked up by the batch OWNER id (chat_input_task_id): auto-retry clones inherit the owner while their sealed messages stay tagged with the parent's id, so keying off the task's own id would misread a channel retry as direct. The cancel-path provenance gates switch to the same owner key via chatInputOwnerID. chat_input_task_id is back to meaning only "input batch owner". Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * chore(migrations): renumber to 203/204 after upstream took 202 Upstream main merged 202_runtime_profile_add_qwen while this branch held 202/203, tripping TestMigrationNumericPrefixesStayUniqueAfterLegacySet on the CI merge tree. channel_media_pending becomes 203 and channel_ingested becomes 204; no content changes. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channels): gate outbound delivery on channel provenance, not owner Merging main brought #5645 (keep direct chat replies in Multica), whose outbound gate assumed channel tasks leave chat_input_task_id NULL. Sealed channel tasks own an input batch too, so on the merge tree every channel reply and failure notice was classified as direct and silently dropped — agents stopped replying in Feishu/Slack. Both outbound gates now call engine.TaskInputIsChannelIngested: a NULL owner keeps #5645's deliver-by-default for pre-sealing tasks, an owned batch delivers only when it carries the immutable channel_ingested stamp (keyed by the owner id, so auto-retry clones inherit the verdict). Direct replies stay in Multica; sealed channel replies reach the platform. Tests cover both directions on both platforms. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): discard media orphans on a fresh context, after finalize DiscardMedia shared finalizeCtx with BindMedia, so a bind that failed because the finalize deadline expired handed the storage deletes an already-dead context — the compensation silently no-opped and the orphans leaked anyway. The deadline path also ran S3 deletes before the marker clear, eating the same 5s budget the user-facing bind/promotion needed. Collect the refs from both failure paths, run bind + promotion on the finalize budget first, then delete on a fresh discard context. The bind-failure test now pins that discard receives a live context. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): compensate result-uncertain media uploads and commits The compensation protocol treated "the call returned an error" as "the side effect did not happen", which is wrong in both directions across the result-uncertain windows: - An upload error can follow a server-side write (lost response, deadline mid-write). The attempted key never reached the router, so nothing could reclaim it and dedup guarantees no re-resolve. The resolver now idempotently deletes the deterministic key on a fresh budget right at the failure site. - A commit error is not a rollback guarantee: a lost ack can report failure after Postgres durably committed the attachment rows, and the router's discard would then delete objects those rows reference. BindMediaRefs now converges the ambiguity on a fresh budget — any of the batch's URLs present proves the atomic commit landed (bind reports success); none proves the rollback (discard stays safe); a failed verification returns ErrMediaBindResultUnknown and the router keeps the uploads, preferring a rare orphan over a broken attachment. Fault-injection coverage: an upload error deletes the attempted key; a lost-ack commit keeps the bound attachment and reports success; a verified rollback stays a discardable error; the router keeps uploads on the unknown-outcome sentinel. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * chore(migrations): renumber to 207/208 after upstream took 203-206 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * docs(channel): note DiscardMedia self-invocation and the unknown-outcome skip Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * chore(migrations): renumber to 212/213 after upstream took 207-211 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(channel): replace inline media compensation with an intent ledger and reconciler Inline best-effort compensation cannot answer "did my side effect happen?" at the moment it needs the answer — the DELETE/PUT reordering and the empty-read-vs-in-flight-COMMIT gaps were both instances of the same two-system atomicity problem. Persist the intent instead and let an asynchronous reconciler settle it: - channel_media_pending_object (migration 214; claim index 215 as its own single-statement CONCURRENTLY migration): a state machine row ('pending' -> 'deleting') with lease, attempt, and backoff columns. - The resolver upserts the row BEFORE each PUT, state-guarded so a key the reconciler owns is never resurrected (the resource is skipped). ObjectURL is a pure function of configuration, so the row carries the attachment URL pre-upload. - BindMediaRefs deletes the batch's rows INSIDE the attachment-insert transaction: commit landed <=> intents gone, atomically, so an ambiguous COMMIT never needs adjudication. A key already claimed to 'deleting' is skipped (placeholder stays). - Nothing is ever deleted inline. The reconciler — an independent worker so storage latency cannot starve other sweepers — claims due rows ('pending' past the settle delay, or expired leases) under a fresh lease, checks for a durable attachment reference only AFTER the claim (race-free: bind can no longer succeed on the key), deletes unreferenced objects outside any transaction, and backs off failed deletes with attempt-based retry. Crash windows converge for free. - The settle delay is a fixed constant carrying NO correctness weight; invariant tests pin it at >=10x every pipeline budget. Metrics cover deletes, referenced clears, delete failures, and ledger backlog. Removed: MediaResolver.DiscardMedia, ErrMediaBindResultUnknown, the post-commit verification, and both router discard branches. Tests: intent-before-upload ordering; upload error leaves the row and deletes nothing; bind-wins vs reconciler-wins on the same key; lost-ack and rolled-back commit injections (intent cleared iff the attachment landed); reconciler three-state settle; expired-lease reclaim; delete failure backoff and retry; settle invariants. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): never build or sweep the media reconciler without storage store is nil when S3 is unconfigured AND the local upload dir fails to initialize, but the reconciler was constructed unconditionally and main only gates the goroutine on the reconciler pointer — the first unreferenced ledger row (rows can pre-exist from a boot where storage worked) would nil-pointer panic a bare goroutine and take down the process. Construct the reconciler only when a storage backend exists, and guard RunOnce defensively: with no deleter it skips the sweep without claiming, so rows are not stranded in 'deleting' until lease expiry. Test covers the pre-existing-row + missing-storage boot. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * chore(migrations): renumber to 213-216 after upstream took 212 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(channel): remove the dead pre-resolved MediaRefs ingress path lark.InboundMessage.MediaRefs and the resolver's early-returns for pre-populated refs were vestiges of the pre-detached synchronous design — no producer fills them before the router anymore. Worse, the intent ledger made the path actively misleading: refs arriving without ledger rows would be silently skipped at bind (with a log blaming the reconciler), contradicting the field's "already persisted" contract. Delete the field, its channelMessageFromLark mapping, and both early-returns; channel.InboundMessage.MediaRefs is now documented as what it actually is — ResolveMedia's output channel, always empty on ingress, attachable only through a claimed ledger intent. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): enforce workspace tenancy on every ledger query The intent-ledger upsert's conflict branch guarded only on state, so a cross-workspace storage_key collision could rewrite the row's workspace/message/url ownership; release and delete keyed on (storage_key, lease_token) alone. The derived key embeds the workspace UUID so none of this is reachable today — but tenancy must be enforced by the workspace column in every query, never derived from the key string (MUL-3515 rule, restated in this PR's review). The upsert now updates only within the same workspace (a cross-tenant conflict updates nothing, returns no row, and the resolver skips the upload — the fail-safe direction), and release/delete take (workspace_id, storage_key, lease_token). Tests pin that a foreign workspace can neither steal, release, nor delete a row. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(migrations): build the ledger primary key via a concurrent index storage_key TEXT PRIMARY KEY created its unique index implicitly at CREATE TABLE, against the repo convention that every migration index — including a new table's unique index — is built CONCURRENTLY in its own single-statement migration (the exact three-step pattern client_usage_daily shipped in 207-209). The table now declares storage_key NOT NULL, 216 builds the unique index concurrently, and 217 attaches the primary key USING INDEX; the claim index moves to 218. ON CONFLICT (storage_key) still resolves against the constraint, and the full down/up round-trip is verified. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): bound each reconciler object delete with its own timeout DeleteObject ran on the worker-lifetime context and the SDK's default HTTP client has no overall request timeout, so one black-holed connection would wedge the sequential sweep loop — and with it every later batch and the backlog gauge — forever; a single-replica deployment has no other worker to reclaim the lease. Each delete now gets a 30s timeout (well under the 2min lease), and a timed-out delete takes the existing release/backoff path. Covered by a blocking-deleter test with an injectable timeout. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): anchor the media deadline to the DB clock and bound queue waits by it Two deadline gaps from review: - The persisted marker was an application-clock timestamp compared against SQL now() everywhere it is read, so a skewed app node could shrink the fallback window and hand the agent a placeholder before the resolver's local budget ended. The append transaction now anchors a relative budget (MediaPendingSeconds) with now() + make_interval, writer and readers sharing one clock; the local resolve budget stays monotonic app-side. A DB test pins that the remaining budget measured by the DB clock equals the requested one. - enqueueMedia's waits (per-session order, global slot) only watched shutdown, so in a burst an already-expired job kept its goroutine and payload until it reached the front. Both waits now also watch the message's deadline; on expiry the job skips the resolver entirely and runs only the empty finalize (marker clear + promotion), which also unblocks the session's later messages. Covered by a queued-expiry test that finalizes while the only slot is deterministically held. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * chore(migrations): renumber to 216-221 after upstream took 213-215 Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): start the local media budget before the append transaction The DB anchors the durable fallback at insert-time now(), but the local monotonic budget started only after AppendMessage returned — so the resolver outlived the fallback by the append/commit latency, a window where the deferred task is already claimable while the resolver still runs and the agent reads a placeholder that binds moments later. Capture the local deadline before calling AppendMessage, restoring the ordering local-gives-up <= durable-fallback-fires. A slow-append test pins that the resolver's context deadline is measured from the pre-append instant. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * chore(migrations): renumber to 224-229 after upstream took 216-223 Verified against the merged tree: the numeric-prefix uniqueness test passes and the full migration set applies cleanly from scratch. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): heartbeat the reconciler lease per row One claim covers up to 50 rows under a single 2-minute lease, but the batch is processed sequentially and each delete may run its full 30s timeout — a few stalled deletes could outlive the lease mid-batch, letting another replica reclaim the tail: duplicate concurrent deletes, inflated attempt/backoff on rows whose owner was alive, and skewed metrics. The lease is now renewed before EACH row's settle work, so it only ever needs to cover one row's worst case (invariant-tested: lease >= 2x the per-delete timeout). A renewal that matches no row means another worker reclaimed it after a genuine expiry — the row is skipped, leaving the new owner's state untouched. Test simulates a mid-batch reclaim and pins the skip. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): dedup post media resources and make local writes atomic A rich post may reference the same image_key/file_key in several spans. The object key derives from (message, type, key), so duplicates uploaded to the SAME key twice: LocalStorage.UploadStream truncated the destination up front and removed it outright on a copy error, so a second failing attempt destroyed the object the first success had produced — leaving an attachment row pointing at nothing. A second succeeding attempt instead produced two attachment rows for one object. Collapse duplicate spans by (fetch type, platform key) before the upload loop, and write local uploads through a temp file renamed into place so a failed write can only discard its own temp file. Tests cover a duplicated span uploading once and a failed re-upload leaving the previous object intact. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): fence late-materializing PUTs with a tombstone schedule A DELETE cannot be ordered against a PUT the client already abandoned: the store may materialize the object after the delete completes. The reconciler cleared the ledger row right after deleting, so such an object had no row and nothing to reclaim it — which made the settle delay the de-facto correctness barrier for the PUT/DELETE race, exactly what the design says it must not be. The row is now kept as a tombstone ('tombstoned' state, migration 226's CHECK) and re-deleted on a widening schedule (15m, 1h, 6h, 24h, the pass index carried in last_error), so a late materialization is reclaimed by a later pass; only after the schedule is exhausted is the row dropped. Claim, heartbeat, lease, and tenancy predicates are unchanged — a tombstone is claimed exactly like any other due row. A separate gauge reports tombstones so they cannot be mistaken for a backlog of objects awaiting reclaim, and the header comment now states precisely what state fences (bind/commit) versus what the schedule fences (late PUTs). Tests: the reviewer's interleaving — DELETE completes, the abandoned PUT materializes right after, and the object is gone by the end of the schedule — plus a full schedule walk asserting the object is counted once and the row clears at the end. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): tombstones must re-delete, not re-ask the reference question A tombstone revisit ran the same reference check as a first settle, so an attachment carrying the same URL — a re-ingested copy of the object — sent the row down the "referenced, keep it" branch: the object was kept and the row cleared, abandoning the re-delete schedule that fences the ORIGINAL object against an abandoned PUT. A tombstone has already been judged unreferenced and deleted; it exists only to re-delete whatever materializes later, so it now goes straight to the delete + schedule tail (extracted as settleDeletedObject, shared with the first settle). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(channel): keep the tombstone schedule position in its own column The re-delete pass index was encoded into last_error, which the failure path also writes: one failed re-delete erased the position and restarted the walk. A store failing intermittently could therefore keep a tombstone alive indefinitely — every recovery would resume at pass 1 and the row would never reach the end of the schedule to be dropped. tombstone_pass is now its own column (the table is introduced in this PR, so migration 226 carries it), advanced only by a successful delete, and the tombstone write clears the now-stale last_error. Test walks the schedule across a failed re-delete and asserts it resumes rather than restarts, and that the row still terminates. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(lark): derive media object keys per chat message The object key was derived from the platform message alone, so a second ingest of the same Feishu message reused the first ingest's ledger row. That row can be a tombstone (up to ~31h while the re-delete schedule runs), and the intent upsert refuses anything that has left 'pending', so the second ingest skipped the upload and silently produced a placeholder with no attachment. A re-ingest is reachable: the inbound dedup claim is reclaimable once 60s stale and the dedup row is only vacuumed after 24h. Keying on the chat message the object will attach to keeps the two ingests independent, and nothing leaks: each one's objects are covered by its own ledger row. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * refactor(storage): route both local upload paths through one atomic write UploadStream wrote through a temp file and renamed into place, but the buffered Upload path still truncated the destination up front — the destructive shape the stream path exists to avoid, one caller away from coming back. Both now share writeAtomic, which also restores the 0644 the direct write used (CreateTemp makes files 0600). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(channel): gofmt the media-pending append fields Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(storage): keep the local upload chmod best-effort The rename-into-place rewrite made a failed chmod fail the whole upload. CreateTemp's 0600 has to be widened to the 0644 the direct write used, but an upload dir on a mount that ignores chmod (SMB/NFS/FUSE) accepted the old direct write fine — turning those deployments' uploads into hard errors would be a regression for a cosmetic property. Log and continue. Tests pin 0644 on both upload paths, and that a failed buffered upload leaves no temp litter and no damage to a previous object. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(channel): never re-delete an object an attachment references The tombstone pass skipped the reference check and deleted unconditionally, so a durable attachment carrying that URL lost the only object it can read — the dangling attachment the intent ledger exists to prevent, and the opposite of the posture every other path here takes ("a reclaimable orphan beats a broken attachment"). The check now runs on every pass. A positive result on a tombstone is unreachable by design — keys are per (chat message, resource) and a bind cannot attach a key that has left 'pending' — so reaching it means an invariant broke: keep the object, clear the row, log it, and count it on a dedicated reconciler_tombstone_referenced_total counter. The test's contract is flipped to assert the referenced object survives. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(storage): make the local staging file reclaimable after a crash os.CreateTemp's random suffix meant a crash between the staging write and the rename left a file nothing could name: the ledger records only the final storage key, and DeleteObject removed only the object and its sidecar. Each leftover can approach the 100 MiB resource cap and they accumulate without bound. The staging path is now derived from the object key, so DeleteObject removes it alongside the object — which makes the media reconciler reclaim it too, since the intent row is written before the upload. Opening it 0644 directly also drops the chmod the previous commit had to make best-effort. Both read paths refuse the staging name (keys come from the request URL, and a half-written body should not be readable); a user-supplied ".tmp" extension is unaffected, since object keys are generated and never dot-prefixed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(channel): renumber the media migrations after merging main main took 224 (agent_task_session_rollout_missing), so the ledger group moves to 225-230 and the cross-references inside the table migration follow. main's CompleteTask also grew a sessionRolloutMissing parameter; the three call sites this PR added to chat_input_ownership_test.go pass false. Verified the way the numbering is meant to be verified: full migration set applied from scratch on the merged tree, and the whole server suite run against that database. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * fix(channel): let Postgres compute every reconciler deadline The reconciler built settle cutoffs, lease expiry, backoff and re-delete times from the process clock and compared them against the database's now(). A replica whose clock had drifted would therefore settle rows whose upload was still in flight (the object is deleted and the bind then refuses to attach — media silently lost), hand out leases that are born expired (rows churn between workers, attempt/backoff inflate), or compress the tombstone schedule that fences a late-materializing PUT. The four settle queries now take durations and derive their timestamps from now(), so every replica reads one clock. The parameter types are the guard: an app-side timestamp can no longer be passed. Test asserts the persisted lease, backoff and re-delete deadlines all track the database's now(). The generated code also picks up main's new agent_task_queue column in the two RETURNING task.* queries this PR adds. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * chore(lark): drop unrelated gofmt-only churn from this PR Six files carried whitespace/comment-reformatting with no functional change, unrelated to the inbound media pipeline. Reverting them to the base revision keeps the diff focused on the feature (75 -> 69 files): server/internal/service/empty_claim_cache.go server/internal/integrations/lark/markdown_detect.go server/internal/integrations/lark/ws_chunk_assembler.go server/internal/integrations/lark/ws_chunk_assembler_test.go server/internal/integrations/lark/ws_frame_test.go server/internal/integrations/lark/registration_test.go Verified: `git diff -w` against these files was already empty, so no behavior is affected. go vet clean; tests covering these files pass. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Claude Fable 5 <noreply@anthropic.com> Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-27 15:44:39 +08:00
Bohan Jiang	4581e9ee76	fix(server): surface real reason for failed quick-create (MUL-5268) (#5898) ... * fix(server): surface real reason for failed quick-create (MUL-5268, #5885) When an agent's quick-create run finishes without producing an issue, the completion path wrote a fixed "agent finished without creating an issue" inbox, discarding the real reason — most often the active-duplicate guard rejecting the create. Users saw no actionable detail. notifyQuickCreateCompleted now: - distinguishes pgx.ErrNoRows (a confirmed no-issue → real failure) from a genuine lookup fault (DB/timeout), so a transient error no longer mislabels a run that may actually have created the issue; - on the real-failure branch, surfaces the agent's final output as the failure reason. The quick-create prompt already requires the agent to exit with the CLI error as its only output, so this carries the concrete cause (e.g. the existing issue's identifier + status), unescaped, bounded, and redacted. Empty output falls back to the existing generic message. No API/CLI contract or migration change. Co-authored-by: multica-agent <github@multica.ai> * fix(server): never end quick-create with no notification on lookup fault Review follow-up. The previous commit returned silently when the completion lookup failed with a non-ErrNoRows error, to avoid misreporting a failure that was never observed. But the task is already completed and nothing retries this reconciliation, so a single transient DB fault permanently stranded the requester with no inbox result at all. The indeterminate branch now writes a neutral, terminal notification: it does not assert failure (the agent may have created the issue), does not reuse the agent output as if it were the confirmed reason, and points at the one safe next step — check recent issues before retrying, so a retry cannot silently produce the duplicate the guard exists to prevent. notifyQuickCreateFailed / notifyQuickCreateUnconfirmed are now thin wrappers over a shared writer so both outcomes keep the identical row shape and the frontend's 'Edit as advanced form' recovery affordance. Tests: - TestQuickCreateLookupFault_WritesUnconfirmedInbox: fails against the previous commit with 'no rows in result set' (the exact silent-drop), passes now. Uses a DBTX wrapper that faults only GetIssueByOrigin so the inbox write still reaches the real DB. - TestQuickCreateFailure_RedactsAgentOutput: locks in that the newly-surfaced agent output is scrubbed before storage. Co-authored-by: multica-agent <github@multica.ai> * fix(inbox): render unverified quick-create outcome as neutral, not failed Review round 2. Three fixes. 1. Rebased onto main and updated the three CompleteTask call sites for the new sessionRolloutMissing parameter; the branch no longer compiles-fails on the merge ref. 2. The unverified outcome reused the quick_create_failed inbox type, so every client framed it as a failure regardless of the neutral title/body: web list rendered 'Failed: {detail}', web detail showed 'Create with agent failed', mobile rendered 'Failed: ...', and getInboxDisplayTitle replaced the neutral title with the original prompt. Users saw 'Failed: Couldn't confirm...' — asserting a failure never observed. Added a distinct quick_create_unconfirmed type end to end: core type union, web list label (no failure framing), web detail pane, the original-prompt box and 'Edit as advanced form' recovery affordance, mobile label + display title, and en / zh-Hans / ja / ko strings. Older clients hit their existing default branch and render the already-neutral title. 3. The terminal notification reused the caller's context, so a lookup that failed with context.Canceled / DeadlineExceeded failed the write for the same reason and still dropped the notification. The write is now detached via context.WithoutCancel with a bounded timeout. Tests (each verified to fail without its fix): - TestQuickCreateLookupCancelled_StillWritesUnconfirmedInbox: cancels the ctx at the lookup; without the detach, 'no rows in result set'. - inbox-detail-label.test.tsx: resolves accessors against the real en locale; pointing the unconfirmed case back at failed_with_detail reproduces 'Failed: Couldn't confirm...'. - inbox-display.test.ts: both outcomes stay recoverable rows. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: J <j@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-27 15:35:09 +08:00
Multica Eve	2294f450e8	fix(kiro): recover from oversized-history-image session resume failures ... Merges MUL-5338 / fixes GH #5975.	2026-07-27 13:53:58 +08:00
Bohan Jiang	85a14cde37	fix(daemon): gate codex session pointer writes on rollout presence (MUL-5305) (#5960) ... * fix(daemon): gate codex session pointer writes on rollout presence (MUL-5305) Codex issue follow-ups on local_directory projects intermittently lost their session: the server sent a prior session whose rollout was not in the task CODEX_HOME, so the daemon dropped the resume and started a fresh thread (gateCodexResumeToRolloutPresence), losing the conversation. Root of the bad pointer: the daemon persists a Codex session id as the resumable pointer at two points -- the mid-flight pin and the terminal report -- before the rollout is guaranteed on disk. A task that exits early (crash / runtime offline / timeout) leaves a pinned/reported session id with no rollout; GetLastTaskSession (which accepts failed rows) then hands it to the next follow-up, which drops it. Enforce the invariant at write time: only record a Codex session as the resumable pointer once its rollout is present in the per-issue store, with a short bounded wait for flush. If it never lands, don't overwrite the last good pointer -- a blanked session_id becomes NULL server-side, so GetLastTaskSession falls back to the most recent session whose rollout is real. Non-Codex providers are unaffected; crash recovery is preserved because a present rollout still pins. - codexSessionResumable: shared write-time presence check (bounded wait) - runTask: gate the terminal session_id before reporting - executeAndDrain: gate the mid-flight pin (thread codexHome through) - tests: helper cases + behavioral pin test Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): address review — don't silently downgrade completed sessions (MUL-5305) Follow-up to review feedback on #5960: - Must-fix 1 (silent downgrade): limit the write-time session withholding to NON-completed terminal states. A missing rollout means no resumable conversation was persisted, so a withheld non-completed attempt loses nothing; a completed session is authoritative and, if its rollout is anomalously absent, is still recorded so the next run's resume gate discloses the loss (PriorSessionResumeUnavailable, MUL-4424) instead of silently falling back to an older session. Extracted resumableTerminalSessionID. - Non-blocking risk: pin the mid-flight resume pointer with a per-status presence check instead of one fixed 2s window, and set sessionPinned only once the rollout is confirmed, so a rollout that lands shortly after the first status is still pinned this run. - Must-fix 2 (regression coverage): pin skipped when rollout absent (no /session call); terminal helper (completed keeps / failed withholds); and a DB-backed GetLastTaskSession test proving the next claim falls back to the older recorded session when the latest was blanked. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): disclose Codex session continuity gaps end-to-end (MUL-5305) Addresses review feedback on #5960. Must-fix 1 — a completed turn whose rollout is missing is exactly the #5934 case (the reporter waits for each turn to finish), so it can no longer be excluded from withholding. Withhold the session for ANY terminal state, and pair the withhold with a persisted continuity-gap signal so the next claim still discloses the loss even while resuming an older good session: - new agent_task_queue.session_rollout_missing column (migration 224) - daemon sends session_rollout_missing on the terminal report; the handler clears the resume pointer (MarkTaskSessionRolloutMissing, overriding FailAgentTask's COALESCE) and flags the row - claim reads GetLatestTaskRolloutMissing and sets a new prior_session_resume_unavailable response field, which the daemon ORs into the brief's PriorSessionResumeUnavailable disclosure Must-fix 2 — Codex reveals the session id on a single task_started status, so a one-shot presence check missed a rollout that flushed later and lost in-flight crash recovery. Pin via a background waiter bounded by the run's context that pins the moment the rollout lands. Tests: - completed + rollout missing -> next claim withholds the bad session AND flags the continuity gap (cross-layer DB test) - session pinned once its rollout appears after the status (mid-run) - pin skipped while the rollout is absent Co-authored-by: multica-agent <github@multica.ai> * fix(server): make continuity-gap write atomic + disclose on all claim paths (MUL-5305) Addresses review round 3 of #5960. Must-fix 1 — the previous handler-level marker ran AFTER the terminal transaction committed, and FailTask creates + wakes the auto-retry inside that same transaction, so a retry could claim the rollout-missing session before the marker cleared it (and a marker failure was swallowed). Move session_rollout_missing INTO the terminal write: CompleteAgentTask and FailAgentTask now force session_id NULL (overriding Fail's COALESCE that would keep a stale mid-flight pin) and set the flag in the SAME UPDATE, so the withhold + gap flag commit atomically with the retry creation. The flag is threaded through TaskService.CompleteTask/FailTask; the swallowed best-effort MarkTaskSessionRolloutMissing query is removed. Must-fix 2 — the daemon withholds for all Codex tasks, but only the issue non-rerun claim consumed the disclosure. Now every fallback path sets prior_session_resume_unavailable: the manual-rerun branch reads the source task's session_rollout_missing, and the chat branch reads a new GetLatestChatTaskRolloutMissing. Tests (cross-layer DB): - completed + rollout missing via the real CompleteAgentTask terminal write -> session withheld AND gap flagged - failed + rollout missing forces session_id NULL over the COALESCE- preserved mid-flight pin in ONE statement Deploy order: migration + server first, daemon second (new fields are omitempty and ignored by an old peer). Co-authored-by: multica-agent <github@multica.ai> * fix(handler): return 5xx on FailTask error + cover claim-response gap paths (MUL-5305) Addresses review round 4 of #5960. Must-fix 1 — the FailTask handler returned 400 on a service/DB error, but the daemon's terminal callback treats 400 as permanent (postJSONWithRetry / isTransientError bails without retrying). Since the fail transaction is now the sole persistence point for the withheld session + continuity-gap flag + auto-retry, a rolled-back fail must be retried, so return 5xx (an invalid request body still returns 400), mirroring CompleteTask. Regression: client.FailTask retries on a transient 5xx and eventually succeeds. Must-fix 2 — add claim-response-level regressions that drive the two new disclosure branches through buildClaimedTaskResponse: - chat: the latest terminal task on the session withheld -> the next chat claim sets prior_session_resume_unavailable - manual rerun: the source task withheld -> the rerun claim discloses These handler DB tests run under CI's fully-migrated database (the local workspace DB cannot set up the handler fixture). Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-27 13:12:06 +08:00
Bohan Jiang	3d4c5c7da2	feat(cli): add 'multica agent copy' to fork an agent across runtimes (MUL-5279) (#5961) ... Add a CLI/headless equivalent of the web Duplicate action: copy an existing agent's portable config into a new agent, optionally on a different runtime, leaving the source untouched. The command composes existing endpoints (GET source, then POST create) — no new server API — passing the source's skill ids in skill_ids so bindings attach in the same create transaction the server already runs, keeping the mutation atomic. - Copied by default (each overridable): name (+" (copy)"), description, instructions, avatar, custom_args, max_concurrent_tasks, invocation permission, and assigned workspace skills. - Runtime-specific fields (model/thinking_level/service_tier) copy only on the same runtime; a different --runtime-id drops them and requires --model. - Secrets/machine-local (custom_env/mcp_config/runtime_config) are never copied; they are set only via explicit secret-safe flags. Docs: updated the multica-creating-agents built-in skill + source map. Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-27 02:38:26 +08:00
YYClaw	af1ff00e14	test(cli): use example domains in setup fixtures (#5944)	2026-07-27 01:10:46 +08:00
Bohan Jiang	ecce589867	MUL-5265: GitHub API-snapshot PR cards — CI status + mergeability (#5889) ... * feat(github): API-snapshot PR cards — CI status + mergeability (MUL-5265) Fetch each linked PR's CI checks and mergeability from the GitHub GraphQL API as the single source of truth (Plan C). Webhooks, page visits and a bounded TTL sweep are refresh triggers only; nothing is inferred from webhook payloads anymore. Backend (server/internal/integrations/ghsnapshot): - installation-token cache + GraphQL client (private key / tokens never logged) - one paginated pullRequest query -> normalized per-check snapshot - outbound queue: (installation,repo,PR) dedup + single in-flight per PR, bounded worker pool, Retry-After / rate-limit backoff, jitter - head-SHA-guarded atomic batch replace (a slow response for an old head can never overwrite a newer head's snapshot) - bounded chase window (30s->5m, stops on terminal/closed) + page-visit + TTL refresh; clean degradation when no App private key is configured Removes the old suite-level webhook aggregation display path (query + handlers + tests). check_suite / check_run / status are now pure triggers. Frontend: PR card shows two independent tri-state elements (CI status + mergeability). "Ready to merge" only when merge state is clean; no-checks and unknown-mergeable never assert a positive verdict; progress strip removed; four locales; stale marker. Docs: github-integration + environment-variables (four languages) — now required App private key, read-only Checks/Commit-statuses permissions, new event subscriptions, capability boundaries and troubleshooting. Co-authored-by: multica-agent <github@multica.ai> * fix(github): address PR snapshot review blockers Co-authored-by: multica-agent <github@multica.ai> * fix(github): bound snapshot refresh scheduling Co-authored-by: multica-agent <github@multica.ai> * fix(github): concurrent check-run index migration + singleflight token mint Address Elon's third-round review on the MUL-5265 PR snapshot pipeline. Must-fix — migration built a non-concurrent index. The github_pull_request_check_run table declared PRIMARY KEY (pr_id, ordinal) inside CREATE TABLE, which builds a unique index synchronously and violates the repo rule that every migration-created index (including on a new table) use CREATE UNIQUE INDEX CONCURRENTLY in its own single-statement file. Split: 222 now creates the table without a primary key; new 223 adds the (pr_id, ordinal) unique index CONCURRENTLY. The atomic delete-all/insert write path already guarantees ordinal uniqueness, so a plain unique index is sufficient; the index also serves the pr_id-prefix list aggregation and the workspace/PR cleanup deletes. Nit — token mint now singleflights per installation. installationToken released the lock before minting, so the N workers of one installation could mint N tokens on a cold cache or a simultaneous renew. Concurrent callers for the same installation are now collapsed via singleflight into one HTTP mint; added a -race concurrent-mint test asserting a single mint under 16 callers. Verified: fresh DB migrates through 223 (table has no PK, concurrent unique index present); ghsnapshot suite + new test pass under -race; migration lint and handler github/workspace-delete tests pass; sqlc produced no diff; go build / vet / gofmt / git diff --check clean. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-24 18:30:20 +08:00
Bohan Jiang	73b0015475	feat(vcs): make self-hosted Git providers self-host-only (MUL-3772, MUL-5138) (#5888) ... * feat(vcs): gate self-hosted Git providers to self-host deployments only (MUL-3772) The Forgejo/Gitea/GitLab integration is intended for self-hosted Multica, where Multica can reach a Git instance on the operator's own network. On the managed multi-tenant cloud it adds an SSRF surface (connect validates a user-supplied instance URL from the server) and would store third-party Git tokens for all tenants under one key, while only serving the small subset of users whose instance is publicly reachable. Product decision: offer it on self-host only. - Add an explicit deployment switch MULTICA_VCS_INTEGRATION_ENABLED (default off). Connect, rotate, and webhook now require BOTH the switch on AND a valid MULTICA_VCS_SECRET_KEY — the switch is the product boundary, not key presence alone. When off, connect/rotate return 404 and the webhook returns a bare 404 (no config leak), independent of the frontend. - /api/config exposes vcs_integration_available (mirrors the switch, omitted when false) so the Settings UI hides the whole "Git providers" section on cloud instead of surfacing an operator-only "missing key" hint. - docker-compose.selfhost.yml defaults the switch on; .env.example documents it. - Docs (en/zh) lead with a callout: available on self-hosted Multica only, not Multica Cloud, and clarify "self-hosted" means Multica itself, not just Git. #5006 / #5883 stay in place — the schema and backend capability are retained; this only gates availability. No cloud VCS connection can exist (connect always required the key, which the cloud never set), so nothing needs migrating. Verified: go build/vet + VCS/config handler tests on a fresh migrated DB (incl. a new disabled-deployment 404 test); pnpm typecheck (core + views) and the integrations-tab + core schema/config vitest suites pass. Co-authored-by: multica-agent <github@multica.ai> * fix(vcs): complete self-host integration gating (MUL-5138) Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-24 16:39:22 +08:00
dixonl90	581d9527ba	feat(vcs): self-hosted Git providers (Forgejo, Gitea, GitLab) alongside GitHub (MUL-3772) (#5006) ... Adds self-hosted Git provider support (Forgejo, Gitea, GitLab) alongside GitHub: per-workspace token connection, a provider-dispatched webhook, PR/MR and CI mirroring, and the shared issue auto-link / auto-close machinery. Off until MULTICA_VCS_SECRET_KEY is set, so existing deployments are unaffected. Co-authored-by: Bohan <bohan@devv.ai>	2026-07-24 15:01:27 +08:00
Multica Eve	423a5c59cb	MUL-5200: unify working-agent filters across issue views (#5819) ... * fix(issues): query workspace working agents independently Co-authored-by: multica-agent <github@multica.ai> * feat(agents): filter working agents by source type Co-authored-by: multica-agent <github@multica.ai> * feat(issues): scope working agents to My Issues Co-authored-by: multica-agent <github@multica.ai> * test(agents): cover My Issues squad relations Co-authored-by: multica-agent <github@multica.ai> * fix(issues): unify working-agent filters across views Co-authored-by: multica-agent <github@multica.ai> * fix(issues): preserve empty working-agent filters Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-23 16:54:41 +08:00
Multica Eve	40f9ecdd56	MUL-5202: unify Issue Query across List, Board, and Swimlane (#5820) ... * MUL-5202: migrate status issue surfaces to table query Co-authored-by: multica-agent <github@multica.ai> * MUL-5202: unify grouped issue surfaces Co-authored-by: multica-agent <github@multica.ai> * MUL-5202: cover move safety boundaries Co-authored-by: multica-agent <github@multica.ai> * MUL-5202: preserve server swimlane semantics Co-authored-by: multica-agent <github@multica.ai> * MUL-5202: keep grouped surface facets exact Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-23 15:58:25 +08:00
Multica Eve	6992c58de3	MUL-5185: add Codex Fast mode (#5821) ... * feat(agents): add Codex fast mode (MUL-5185) Co-authored-by: multica-agent <github@multica.ai> * fix(agents): make Codex Fast override authoritative Co-authored-by: multica-agent <github@multica.ai> * fix(agents): remove Codex Fast config conflicts Co-authored-by: multica-agent <github@multica.ai> * chore: refresh checks after conflict resolution Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-23 15:40:18 +08:00
Multica Eve	8065cead85	MUL-5198: Restore server-backed issue table grouping (MUL-5100) (#5817) ... * revert(issues): restore server-backed table grouping Co-authored-by: multica-agent <github@multica.ai> * test(skills): stabilize import completion coverage Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-23 12:03:27 +08:00
Bohan Jiang	168620fc15	MUL-5163 fix(agents): rebind the Agent Builder carrier when the runtime is switched (#5780) ... Switching the runtime mid-conversation in Build with AI only updated local React state, so the picker could show runtime B while every subsequent message still executed on the runtime frozen at session create time. - Add PATCH /api/agent-builder/sessions/{id}/runtime to rebind the hidden builder carrier (runtime_id/runtime_mode, model cleared since model ids are per-runtime). Creator-only, builder carriers only, target must be in-workspace, usable by the member, and online; a reply in flight returns 409. - Serialise rebind against send: both take LockChatSessionForRuntimeBind on the chat_session row and SendDirectChatMessage re-reads the agent inside that transaction, so a send blocked behind a rebind cannot resume and stamp its task with the runtime the switch moved away from. - Leave chat_session.runtime_id stale on purpose so the daemon starts a fresh provider session on the new runtime while Multica-side history and the draft survive. - Frontend updates the draft only after the server reports the bound runtime, blocks sending during a rebind, disables the Mine/All filter alongside the trigger, and explains why the picker is locked during a pending reply. Closes #5773	2026-07-23 10:56:53 +08:00
LinYushen	4dc47ef113	Revert "MUL-5100: Move issue table grouping to the server" (#5777) ... This reverts commit d43e500ff6.	2026-07-22 18:06:37 +08:00
Multica Eve	216aee5629	[MUL-5125] Add daily Desktop/Web usage and runtime reporting (#5763) ... * feat(analytics): add daily client usage reporting (MUL-5125) Co-authored-by: multica-agent <github@multica.ai> * fix(analytics): clarify daily usage semantics (MUL-5125) Co-authored-by: multica-agent <github@multica.ai> * fix(analytics): resolve usage review blockers (MUL-5125) Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-22 16:52:34 +08:00
Jiayuan Zhang	5d9295ac65	feat(agents): add per-agent runtime skill controls (#5686) ... * feat(agents): add per-agent runtime skill controls Co-authored-by: multica-agent <github@multica.ai> * fix(agents): renumber runtime-skill migration and broadcast agent:status on toggle Address the MUL-5101 review blockers on PR #5686: - Rebase onto main and renumber the runtime-skill-disable migration 202 -> 203. main added 202_runtime_profile_add_qwen, so the pair collided on prefix 202 and migrations_lint_test would reject the duplicate. 203 is the next free prefix. - Publish an "agent:status" event after persisting a disabled_runtime_skills override, mirroring the workspace-skill toggle in writeUpdatedAgentSkills. The realtime layer keys off this event to invalidate workspaceKeys.agents, so other open web/desktop/mobile clients now drop their stale toggle state instead of only the initiating tab refreshing. Reload junction-table skills before the broadcast so it doesn't signal cleared skills (#3459). - Add a handler regression test proving the broadcast fires on both disable and enable. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai> Co-authored-by: Walt <walt@multica.ai> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-22 15:38:38 +08:00
Jiayuan Zhang	d43e500ff6	MUL-5100: Move issue table grouping to the server ... Merge approved after review; CI checks are green.	2026-07-22 14:36:51 +08:00
Bohan Jiang	ed57707bb2	MUL-4923: bound daemon task preparation time (#5584) ... * fix(daemon): bound pre-start task preparation Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): isolate pre-start env preparation Run execution-environment Prepare and Reuse in a killable helper process so a timed-out attempt cannot keep writing after retry. Add FIFO lifecycle and squad Stage retry regression coverage. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): terminate Windows prepare process trees Assign the pre-start helper to a kill-on-close Job Object before releasing its request, wait for all job members to exit on cancellation, and add a Windows runtime regression job. Co-authored-by: multica-agent <github@multica.ai> * ci: target Windows prepare tree regression Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-20 15:30:18 +08:00
Multica Eve	68c2328838	MUL-4938: support configurable shutdown hold (#5586) ... * feat(server): support configurable shutdown hold Co-authored-by: multica-agent <github@multica.ai> * fix(server): address shutdown hold 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>	2026-07-20 12:03:07 +08:00
Jiayuan Zhang	002ea0d879	MUL-4797: add configurable issue table view (#5454) ... * feat(issues): add configurable table view Co-authored-by: multica-agent <github@multica.ai> * test(issues): cover table columns in page fixture Co-authored-by: multica-agent <github@multica.ai> * fix(issues): make table column picker interactive Co-authored-by: multica-agent <github@multica.ai> * fix(issues): repair quick create and virtualize table rows Co-authored-by: multica-agent <github@multica.ai> * fix(issues): keep pinned table cells opaque Co-authored-by: multica-agent <github@multica.ai> * fix(issues): anchor full-width table rows Co-authored-by: multica-agent <github@multica.ai> * fix(issues): consolidate table controls Co-authored-by: multica-agent <github@multica.ai> * fix(issues): harden table pagination and export Co-authored-by: multica-agent <github@multica.ai> * feat(issues): add table quick search Co-authored-by: multica-agent <github@multica.ai> * fix(issues): make table window filters, selection, and export authoritative Round-2 review fixes for the issues table (MUL-4797): - Send the agents-working filter as a server ids facet so matches on unfetched pages surface and total/pagination/export agree; a present- but-empty id list yields an empty window instead of an unfiltered one. - Reset surface selection when the membership window changes and act on selection ∩ visible rows in the batch toolbar, so batch actions, Export selected, and the count all share one authoritative set. - Materialize the full flat window while table grouping is active, and suspend hierarchy nesting / parent-based grouping until the window is complete so structure cannot reshuffle as pages arrive; suppress header facet-count badges while the table window is partial. - Resolve actor directories and the property catalog at export time and fail the export instead of writing Unknown* actors or dropping configured property columns on cold/errored lookups. - Append a unique id tie-break to the list/grouped ORDER BY and mirror it in compareIssuesForSort so offset pages are stable across same-timestamp ties. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): bound table structure window and align chip/transport/selection Round-3 review fixes for the issues table (MUL-4797): - Cap whole-window materialization at TABLE_STRUCTURE_MAX_WINDOW (1000): below it the remaining pages load automatically — hierarchy applies without scrolling to the last page — and above it grouping/hierarchy suspend with an explicit toolbar notice instead of triggering an unbounded workspace download from a persisted view option. - Give the agents-working chip the authoritative in-window running set (the ids-facet window query, shared key with the filter-on state) so its badge can no longer say 0 while the filter would find matches on unfetched pages; falls back to loaded-row scoping elsewhere. - Route ids-facet windows through a new POST /api/issues/query twin — hundreds of running-issue UUIDs overflow the ~8 KB GET request-line budget of common proxies. The body carries the same key/value pairs; the handler rebuilds the query string and delegates to ListIssues. - Reset surface selection during render (key-change pattern) instead of a post-commit effect, so no frame ever pairs new membership with the old selection. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): harden table auto-pagination against errors and stale totals Round-4 review fixes for the issues table (MUL-4797): - Stop the structure materialization loop (and the scroll sentinel) when the window query is in error state — a persistently failing page left hasNextPage true and isFetchingNextPage false after every attempt, so the ungated effect refired forever. Resuming is an explicit toolbar Retry. The advancement decision now lives in a pure, tested shouldAutoLoadNextStructurePage helper. - Make the structure ceiling a hard stop: the ceiling check reads the LATEST page's total (pagination already advances on it, so a stale small page-1 total could re-open unbounded materialization), and the loop additionally halts on loaded count >= ceiling regardless of any reported total. - Drive the working (ids-facet) window to completion — it is inherently bounded by the running set — and treat it as the chip's authoritative scope only when complete, so >100 running issues no longer under-count as a single page. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): make working-window pagination capped and unknown-aware Round-5 (final) review fixes for the issues table (MUL-4797): - The working (ids-facet) window now advances through the same shouldAutoLoadNextWindowPage gates as the structure loop — it shares the main table's cache key while the agents-working filter is on, so an uncapped chip-driven loop re-opened the very ceiling the table just enforced. An over-ceiling window stops after page one. - A cold-load failure of the flat window is an ERROR state, not an empty workspace: isEmpty only claims empty on a successful zero-result fetch, and the surface renders a dedicated failed-to-load state with a reachable Retry (the in-table Retry never mounted without data). - The chip scope is now tri-state honest: a COMPLETE window (or an empty running set) yields a precise count, keepPreviousData carries the last-known-complete set across re-keys, and everything else — cold resolving, failed, over the ceiling — presents as an explicit unknown ('Agents working: —') instead of a number derived from whichever incomplete window happened to be loaded. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): single pagination owner and placeholder-honest chip scope Round-6 review fixes for the issues table (MUL-4797): - Exclude placeholder data from the working-window completeness gate: on a re-key (running set or facet change) keepPreviousData leaves the OLD key's rows visible, and pairing them with the new task snapshot published a precise-looking number for a scope nobody fetched. The scope now reads unknown until the new key resolves. - Make the shared table query single-owner while the agents-working filter is on: the chip's background loop no longer answers the same render snapshot as TableView's structure loop, and every auto caller (structure loop, working loop, scroll sentinel, retry) now uses fetchNextPage({cancelRefetch: false}) so a concurrent responder no-ops instead of cancel/restarting a fetch whose HTTP request is not abortable — which had been duplicating every offset. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-17 19:21:27 +08:00
Multica Eve	90ee83e10a	MUL-4925: fix Linux Codex Git metadata writes (#5575) ... * fix(daemon): isolate Linux Codex git metadata (MUL-4925) Co-authored-by: multica-agent <github@multica.ai> * refactor(daemon): address isolated-checkout review nits (MUL-4925) - rename sameFilesystemPath -> sameResolvedPath (it compares resolved paths for equality, not same-device), with a clarifying doc comment - prune earlier tasks' agent/* branches when reusing an isolated checkout so a long-lived reused workdir stops accumulating one local branch per checkout; deleteLocalBranches now takes a keepBranch arg and the prune is non-fatal - cover the prune in TestCreateWorktreeReusesIsolatedGitMetadata * fix(repocache): preserve user branches on reuse (MUL-4925) Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-17 18:37:33 +08:00
YYClaw	465546b83b	feat(autopilots): redesign the autopilot schedule editor (#5457) ... Replace the free-form trigger-config form with a structured schedule editor built on an orthogonal cron model: separate frequency, time, and day-of-week/day-of-month dimensions map to and from cron expressions via a dedicated grammar and mapping layer, with validation and a human-readable describe() summary. The grammar suite drives the editor against a combinatorially generated corpus of 51,755 distinct cron expressions - every token form of every field, crossed - each judged against a reference robfig/cron v3 parser. Add a server-side /autopilot/cron-preview endpoint (plus schema and React Query hook) so the editor shows upcoming run times, and echo wildcard-carrying cron lists correctly instead of collapsing them. Supporting pieces: timezone-aware formatting helper, segmented-toggle and debounced-value utilities, a reworked time-input, and refreshed en/ja/ko/zh-Hans locale strings.	2026-07-17 16:44:31 +08:00
leroy-chen	e13eb6c216	feat(cli): persist daemon flags in config.json (#3824) ... Merge approved PR #5161.	2026-07-17 15:43:29 +08:00
Bohan Jiang	3ce25d16e7	fix(migrate): auto-backfill attribution before migration 198 to unblock self-host upgrade (MUL-4897) (#5558) ... Self-hosted upgrades to v0.4.3 failed closed on migration 198's VALIDATE of the strict attribution constraint, because the legacy rows migration 190 exempted were only backfilled out-of-band on cloud. Registers a pre-198 preMigrationHook that idempotently mirrors originator_user_id into accountable_user_id in batches before VALIDATE, with FOR UPDATE + repeated predicate to avoid clobbering concurrently-written rows, so a stuck-at-197 instance auto-heals on migrate up with no manual SQL. Originator-NULL rows are left untouched. Verified with unit + concurrency + end-to-end tests against real Postgres. Fixes #5544	2026-07-17 14:06:03 +08:00
Naiyuan Qing	1507997272	fix(agent): stop agents shipping local-path links, make Desktop 404 recoverable (MUL-4899) (#5557) ... Agents were writing runtime-local paths into deliverables as clickable links (`[screenshot](/Users/agent/work/shot.png)`). Two root causes, both fixed here. A. The brief never stated the delivery contract. Add an always-on delivery invariant (outside writeOutput's kind switch, so no task kind can inherit none) plus a per-surface file-delivery line for each of the five surfaces. Chat splits into two: `attachment upload` works only on web/mobile chat, never on an IM channel, so ChatChannelType is now threaded into TaskContextForEnv. The claim path only ever looked up Slack bindings, so a Feishu session reported as a web chat and got upload guidance for a channel that cannot carry attachments. Probe every channel type. The chat policy is two independent layers and stays that way: delivery keys off "is there a channel at all"; the `chat history` / `chat thread` commands stay Slack-only because both endpoints are hardwired to h.SlackHistory and there is no Feishu reader — ChatInThread only selects between those two commands, so it stays Slack-only too. Add a CLI hard-fail lint on `issue comment add` / `issue create` / `issue update` as the enforcement backstop. Scoped narrowly, since a false positive blocks a real deliverable: agent task context only (a human's PAT run is untouched), real CommonMark link/image/autolink destinations only via goldmark (a path in a code span or fence — how an agent quotes a path it is discussing — is structurally invisible), and three high-confidence signals only (`file://`, inside the workdir, or an existing local file). A bare `/foo` is a valid origin-relative URI and is deliberately allowed. `issue update` has no --attachment flag, so its hint redirects to `comment add` rather than naming an argument it rejects. B. Desktop presented the resulting router 404 as an unknown crash. 8 of 18 desktop_route_error reports were users clicking such a link and being told the app broke and to file a bug. Split the 404 into a first-class Not Found view: no crash framing, no Report error. Its recovery entry comes from the tab store's active workspace, never from the failed pathname — deriving a slug from `/Users/me/shot.png` yields "Users" and a button to `/Users/issues`, a second 404. Also add a will-navigate trusted-origin guard via the shared loadRenderer (main + issue windows). This is origin hardening only, NOT the mechanism for in-app links: client-side routing never fires will-navigate, so app paths never reach it. Issue windows need no 404 work — their router only accepts paths validated by parseIssueWindowPath and they do not listen for multica:navigate, so a bad path cannot reach them. Server-side completion observation is metric/log only and never blocks: it is lexical (`file://` + task work_dir prefix) because the server cannot stat the daemon's filesystem, and the metric label is a closed enum so no path or reply text reaches Prometheus. Verified: pnpm typecheck/lint/test (3582 tests), go vet, full Go suite including new claim-path integration tests. cmd/multica was verified outside the daemon workdir — inside one, 93 of its tests fail identically on origin/main because the suite walks up and finds the runtime's own task marker. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>	2026-07-17 13:40:23 +08:00
YYClaw	7d04b1d9a3	fix(cli): fail fast with actionable daemon startup errors ... * fix(cli): fail fast with login hint when starting daemon unauthenticated 'multica daemon start' (background mode) spawned the child first and only then polled its health port. When the user never ran 'multica login', the child died instantly on resolveAuth, but the parent kept polling for the full 45s readiness window and ended with a vague "check logs" warning and exit code 0 — looking like a silent hang. Check the stored config token before spawning (mirroring daemon.resolveAuth, which only accepts the config token) and exit immediately with an actionable "run 'multica login'" hint. 'daemon restart' gets the same guard BEFORE its stop phase: it used to stop the running daemon first and only then fail auth inside the start phase, leaving the user with no daemon at all. The foreground path already failed fast and is unchanged. * fix(cli): report early daemon child exit with an actionable reason Background 'daemon start' Release()d the child immediately and then polled the health port blind. Any preflight failure — server unreachable, stored token rejected with 401 — killed the child within a second, but the parent still sat through the full 45s readiness window and ended with a vague "check logs" warning and exit code 0. Keep a Wait() goroutine on the child and select on it inside the readiness poll. When the child dies before reporting ready, classify what this startup attempt appended to the log and fail with exit code 1 and a one-line reason plus next step: - token rejected / 401 -> run 'multica login' (profile-scoped) - connection refused / DNS / timeout -> server unreachable at <url> - anything else -> short log excerpt with DBG/INF noise dropped * fix(cli): probe token validity and server reachability before restart stops the daemon requireDaemonAuth only rejects an empty stored token, so a revoked or expired token — or an unreachable server — passed the restart guard, the running daemon was stopped, and the replacement child then died in preflight, leaving no daemon at all (#5165). daemon restart now runs a whoami round-trip (same /api/me call as 'multica auth status') against the server the daemon will talk to, using the stored token, before entering the stop phase — and only when a daemon is actually running, so plain 'daemon start' keeps its zero-round-trip happy path. On 401 it reports the re-login hint; on a transport error it reports the unreachable server; both state that the running daemon was left untouched. Regression tests cover a non-empty stored token against a fake 401 server and an unreachable server, asserting /shutdown is never requested on the fake running daemon.	2026-07-17 13:27:06 +08:00
Multica Eve	18d41151eb	feat(gc): batch issue reconciliation (#5534) ... Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-17 12:33:36 +08:00
milymarkovic	1e34dab672	fix(cli): set agent type when updating autopilot (#5543)	2026-07-17 11:36:08 +08:00
Jiayuan Zhang	ed9adc2bbe	feat: improve create issue field controls (#5532) ... Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-17 11:11:52 +08:00
Naiyuan Qing	6b2097ccbb	feat(inbox): archived notifications sub-view (MUL-3736) (#5518) ... Adds an "Archived" sub-view to the Inbox, reachable from an entry at the bottom of the main list, with per-row unarchive. Mirrors chat's archived sub-view so the two surfaces share one mental model. Backend: - GET /api/inbox/archived and POST /api/inbox/{id}/unarchive. Kept off the existing GET /api/inbox so installed clients keep their contract and the unbounded archive never rides along with the main list. - The archived query excludes any issue that still has an active row. Archiving is issue-level, so a new notification on an archived issue leaves old archived rows beside a fresh active one — without the guard the issue renders in BOTH lists. The exclusion lives in SQL so neither list depends on the other's cache. - Unarchive is issue-level (mirroring archive) and leaves `read` untouched, so a restored unread item raises the unread badge again. - v1 ships no pagination: LIMIT 200, newest-first, so truncation drops the oldest rows and never hides a group's newest one. - inbox:unarchived event, fanned out to the recipient like the other personal inbox events. - Two CONCURRENTLY-built indexes; inbox_item previously had none covering workspace/archived/created_at. Frontend: - Separate TanStack cache per list; every inbox event invalidates the workspace prefix, since any of them can move an item across the boundary. - View persisted as ?view=archived, so refresh, back/forward, and the mobile detail-back all return to the list the user was in. - Batch actions stay main-view only — they archive from the MAIN inbox, so offering them over the archived list would do the opposite of what it reads. - Mobile subscribes to inbox:unarchived (its list gains the restored row); its own archived view remains follow-up. Known debt: no pagination, so an archive past ~200 rows is truncated silently in the UI; the entry's count is the deduplicated count of the rows returned. Verified: pnpm typecheck/test/lint (0 errors), go build/vet, Go inbox suite against a real Postgres, migrations up+down, and EXPLAIN confirming both new indexes serve the query. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>	2026-07-16 14:58:42 +08:00
Jiayuan Zhang	ea8511340e	MUL-4820: support custom property icons (#5468) ... * feat(properties): add custom icons Co-authored-by: multica-agent <github@multica.ai> * fix(migrations): use unique property icon prefix Co-authored-by: multica-agent <github@multica.ai> * fix(properties): replace emoji icons with Lucide picker Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-15 22:37:57 +08:00
Jiayuan Zhang	19e52e007c	MUL-4798: make Inbox notification preference updates atomic (#5451) ... * fix(notifications): make preference updates atomic Co-authored-by: multica-agent <github@multica.ai> * fix(notifications): serialize preference mutations Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-15 17:52:10 +08:00
CAVIN	7f12380f05	feat(cli): add workspace create command (#5062) ... Adds `multica workspace create` (--name/--slug/--description/--context/--issue-prefix, JSON/table output). Creation does not switch the current workspace. Both --name and --slug are required to match the server contract, and the slug is immutable after creation. Docs (en/zh/ja/ko) and the CLI reference now show the executable command. Closes #5055	2026-07-15 13:49:56 +08:00
Jiayuan Zhang	b85bb71a58	feat: custom issue properties — typed workspace-defined fields with list-surface support (MUL-4463) (#5335) ... * feat(server): custom issue properties — definitions, typed values, CLI (MUL-4463) Workspace-level property definitions (issue_property table; 7 types: text/number/select/multi_select/date/checkbox/url) plus a typed value bag on each issue (issue.properties JSONB keyed by definition UUID, mirroring the metadata machinery: single-key atomic writes, 16KB cap, GIN index). - Definitions: owner/admin only; agent actors rejected (agents propose, humans confirm). 20 active per workspace, 50 options per select, reserved built-in names blocked, archive instead of delete. - Values: any member or agent; per-type validation with self-correcting error messages that enumerate legal option ids. - API: /api/properties CRUD + PUT/DELETE /api/issues/{id}/properties/{propertyId}; issue responses always emit the properties bag. - CLI: multica property list/get/create/update/archive/unarchive and multica issue property list/set/unset with name→id translation. - Events: property:created/updated, issue_properties:changed. Co-authored-by: multica-agent <github@multica.ai> * feat(web): custom properties settings tab + issue sidebar editors (MUL-4463) - Settings → Properties: definition management mirroring the Labels tab (list with type badges/option chips/usage counts, create/edit dialog with option editor, archive/restore, 20-cap indicator). Admin-gated; members see a read-only catalog. - Issue detail sidebar: custom properties join the built-in optional props' progressive disclosure — set values render as rows with type-appropriate editors (select/multi-select pickers, calendar, yes/no, inline input for text/number/url), unset ones live in the same '+ Add property' menu behind a separator. Archived definitions render read-only until cleared. - Core: property types, zod schemas (lenient type strings for forward compat), api client methods, React Query hooks with optimistic single-key value writes, ws-updaters + realtime wiring for property:created/updated and issue_properties:changed. - Locales: en/zh-Hans/ja/ko strings; Issue fixtures gain properties: {}. Co-authored-by: multica-agent <github@multica.ai> * fix(properties): address MUL-4463 review round 1 — mobile CI, option guard, mutation safety, schema tolerance - mobile: EMPTY_ISSUE_FALLBACK gains the required properties field (mobile typecheck was the red CI check). - server: PATCH /api/properties/{id} rejects config updates that remove select options still referenced by issues (409 with a per-option usage census via jsonb ?); renames keep ids and pass. Integration test included. - core: property value mutations are serialized per workspace via mutation scope, snapshot the bag from detail OR list caches (board surfaces have no detail cache — the old path overwrote whole bags with one key), roll back to the snapshot or invalidate on error, and the last settled mutation does an authoritative detail+catalog invalidate (usage counts reconcile). - schemas: unknown-shaped property values (future server types) are dropped per-entry in a preprocess step instead of failing the whole IssueSchema and blanking lists through parseWithFallback; test updated to lock the tolerant behavior. - realtime: reconnect invalidation covers the property catalog; every issue_properties:changed event also refreshes catalog usage counts. - ui: number editor accepts decimals (step=any); settings usage count pluralizes (issue/issues) with CJK-safe plural keys. Co-authored-by: multica-agent <github@multica.ai> * fix(migrations): renumber issue properties to 179 and build the GIN index concurrently main's migration sequence advanced twice under this PR (167 collision, then an upstream renumber wave that claimed 178), so issue properties now sits at 179 — verified against main's current tip by the prefix-uniqueness lint. The properties GIN index moves to its own single-statement migration (180) using CREATE INDEX CONCURRENTLY — a plain CREATE INDEX on the hot issue table would block writes for the duration of the build. Mirrors the 119_user_created_at_index pattern; full-chain dry-run on a fresh database passes through 180. Co-authored-by: multica-agent <github@multica.ai> * feat(web): custom-property list surfaces — filter, cards, sort, board grouping (MUL-4463 M2) Brings custom properties to the issue list surfaces on top of the M1 definitions/values core: - Filter: per-definition sections in the Filter dropdown (select / multi_select options with color dots and counts; checkbox as Yes/No pseudo-options). OR within a definition, AND across definitions; client-side in applyIssueFilters, mirrored into filterAssigneeGroups for the assignee-grouped board. Included in active-filter count and Clear all. - Cards: per-property Display toggles (cardPropertyIds) render value chips on board cards and list rows via CustomPropertyValueDisplay. - Sort: SortField gains property:<id> for number/date definitions. Server keeps position order (fixed sort enum); the surface controller re-sorts client-side, swimlane/gantt reuse the same comparator. Date-only strings compare lexically; missing values sort last. - Board grouping: IssueGrouping gains property:<id> for select definitions — one column per option (definition order) plus a trailing No-value column, option-colored headings. Drag-drop moves position via UpdateIssue and applies the value through useSetIssueProperty/useUnsetIssueProperty (properties are not part of UpdateIssueRequest). Stale persisted property groupings fall back to status columns. View-store: propertyFilters + cardPropertyIds persisted via the partialize allowlist; clearFilters resets property filters; new fields deep-merge cleanly into pre-existing persisted snapshots. Co-authored-by: multica-agent <github@multica.ai> * fix(properties): address MUL-4463 review round 2 — desc sort, option bucketing, archived-state reconciliation - sort: direction now applies to value comparison only; issues without a value sort last in BOTH directions (the whole-array reverse flipped them to the front on desc). Test covers the desc+missing case. - board: values referencing an option removed from the definition bucket into the No-value column instead of vanishing (unmatched column ids dropped the issue entirely). Defense-in-depth behind the new server-side in-use guard; drag-utils test locks both behaviors. - controller: persisted propertyFilters keyed by archived/deleted definitions are stripped before reaching the filter predicates, and a persisted property sort on a non-active definition degrades to manual order — previously both kept silently applying while the header claimed otherwise. The filter badge counts only active-definition filters. Co-authored-by: multica-agent <github@multica.ai> * feat(properties): server-side property filtering and sorting on list endpoints Property filter/sort now execute in the database, so results are correct across the full issue set — not just the loaded 50-per-status window (closes MUL-4493 item 1's filter/sort half; requested on MUL-4463). - New `properties` query param on ListIssues and ListGroupedIssues: JSON {definitionId: [values]} compiled to an AND-of-ORs containment check (double NOT EXISTS over jsonb_array_elements). One value expands to every storage shape it could match — string (select), array element (multi_select), boolean (checkbox) — so the handler stays type-agnostic. Guarded at 20 definitions / 50 values. - `sort=property:<definitionId>` resolves the definition and orders by a typed expression (numeric CASE cast for number, NULLIF text for date/text/url); missing values sort last in both directions. Malformed ids 400; unknown/archived definitions degrade to position order instead of breaking stale clients. - Frontend: the property filter and property sort ride the IssueSortParam window bag, so every surface (workspace + my-issues variants), query key, and per-status load-more page carries them automatically. The client-side re-sort layer is gone; applyIssueFilters keeps its property predicate as an optimistic-update backstop. - Regression test seeds 55 issues and proves a match at position 55 is returned by a filtered 50-row page, plus sort order/missing-last, AND-across-definitions, and the 400/fallback sort paths. Co-authored-by: multica-agent <github@multica.ai> * fix(properties): address review round 3 — cache reconcile, merged-scope order, GIN-indexable filter, pool loader - Cache reconciliation: property value writes (mutation settle + WS event) now invalidate every issue window whose server-side shape depends on property values — queries filtered by `properties` or sorted by `property:<id>` (detected via query-key predicate), covering flat lists, assignee groups, and my-issues variants. Windows without property params keep the cheap in-place patch. Fixes stale ordering/membership/counts under staleTime:Infinity. - My Issues "All" scope: merged assigned/created/involves results are re-sorted with a comparator mirroring the server ORDER BY semantics (including property sorts and missing-last, created_at DESC tiebreak) in both the flat and assignee-grouped merge paths — relation concatenation no longer overrides the user's sort. - Filter predicate rebuilt as plain bind-parameter containment ORs (AND across definitions): EXPLAIN now shows BitmapOr over idx_issue_properties_gin (the correlated jsonb_array_elements form defeated the index). Alternatives capped at 256 bind params. - Property-grouped board gains a pool loader strip: one sentinel per status that still has server rows, keeping every issue reachable until per-column pagination lands (MUL-4493). - Windowing regression test hardened: explicit positions + an assertion that the unfiltered first page excludes the target (the old fixture tied at position 0 and the created_at DESC tiebreak put the target on page one, proving nothing). - Rollback safety: /api/properties 404 (old server) degrades to an empty catalog instead of a query error, which also keeps property params from ever being sent to pre-property servers; migration 179's CHECK constraints switch to NOT VALID + VALIDATE so the exclusive lock is instantaneous. Co-authored-by: multica-agent <github@multica.ai> * fix(properties): harden concurrency and cache coordination from clean-room review Backend (MUL-4762 F1/F4/F5): - withPropertyLock: pg_advisory_xact_lock helper; definition create/update and value writes now serialize config-vs-value and cap-vs-insert races (workspace-level 'props:' lock + per-definition 'prop:' lock, ordered). - propertySortExpr degrades archived definitions to position sort. Frontend (F2/F3/F6): - onIssuePropertiesChanged invalidates plain assignee-group caches too. - Property value mutations cancel list refetches in onMutate and roll back only the touched key against the current bag (concurrent WS writes to other keys survive a failed write). - useUpdateIssue reconcile drops the stale properties bag from the server snapshot; the property pipeline owns that field. - Surface controller passes persisted property filters/sorts through until the catalog query settles (cold cache no longer strips them). Co-authored-by: multica-agent <github@multica.ai> * fix(properties): open_only branch honors the properties filter ListOpenIssues takes the parsed AND-of-ORs containment groups as a single jsonb properties_filter param and unrolls them with a static double NOT EXISTS; previously the open_only path parsed the properties param and silently dropped it (clean-room review F7a). Co-authored-by: multica-agent <github@multica.ai> * fix(properties): toast on failed board drag to a property column Property-column drags rolled the card back silently on failure; mirror the status/assignee drag path (use-issue-surface-actions) so the snap-back is explained (clean-room review F3, drag half). Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-15 12:00:28 +08:00
Bohan Jiang	4fac8d772f	feat(attribution): Human Attribution Phase 1 (MUL-4302) (#5150) ... * feat(attribution): Phase 1 foundation — provenance schema + resolver (MUL-4302) Human Attribution, Phase 1 (地基) first increment. Every agent run must be traceable to exactly one accountable human AND record at which waterfall level that human was resolved, so a NULL originator can be told apart from a genuine 'no human in the chain'. - migration 149: add originator_source (waterfall label) + delegation/retry/ rerun/rule-version lineage + kind-tagged trigger evidence to agent_task_queue. No FK, no cascade, no CHECK on the source enum (MUL-4302 §7); nullable ADD COLUMNs = fast metadata-only change on the hot queue table. - internal/attribution: the accountable-human vocabulary (Source, EvidenceKind, TriggerKind) + pure, unit-tested classification rules (ClassifyComment/ ClassifyDirect). No DB, no authorization — provenance labeling only. - service: attributionFor{IssueTask,TriggerComment} gather facts and delegate to the pure classifier; the legacy originator resolvers now delegate here so there is one source of truth. originator_user_id's VALUE is unchanged, so the Composio-overlay and canInvokeAgent A2A authorization boundaries are byte-for-byte preserved (MUL-4302 §1.3). - enqueueIssueTask / enqueueMentionTask stamp originator_source + evidence; CreateRetryTask carries the parent attribution forward and records retry_of_task_id so retry and manual rerun stay separable (MUL-4302 §5). Verified: go build ./..., go vet, gofmt clean; new attribution unit tests + enqueue stamping integration test green; existing resolve_originator tests unchanged. Co-authored-by: multica-agent <github@multica.ai> * feat(attribution): split accountable_user_id from originator, close enqueue bypasses (MUL-4302) Phase 1, per Bohan's decision on the MUL-4302 thread: audit and authorization answer different questions and get different columns. - Migration 151 adds agent_task_queue.accountable_user_id (no FK, no cascade). Authorization keeps reading ONLY originator_user_id (canInvokeAgent A2A gate, Composio overlay); audit/UI/usage read accountable_user_id + source + evidence. - Invariant (finalizeAttribution, single chokepoint + §11 tests): originator non-null ⟹ accountable equals it. The two diverge only when originator is null (autopilot / degraded fallback), which is the deferred rule_owner/owner_fallback increment; this lands the column + mirror-write so that split has a home. - Close the NULL-source enqueue bypasses Elon flagged: chat, quick-create, deferred-fallback and run_only-autopilot now stamp originator_source + evidence (+ accountable where a human exists). Autopilot stays unattributed until the rule-version snapshot table lands, but is no longer a silent NULL-source row. Retry inherits accountable_user_id like the rest of the attribution lineage. - Fix assign/promote attribution (§4): a member who assigns/promotes an existing issue is now the accountable human (and, by the invariant, originator) ahead of the issue creator. Threaded as an OPTIONAL actor override, so comment/rerun/ autopilot paths keep today's resolution and create-with-assignee (creator == actor) is unchanged. The squad leader gate already judged the same member. Also merges origin/main: renumbers the attribution migration 149→150 (main took 149 for issue_origin_agent_create) and folds agent_create into ClassifyDirect's origin inheritance. go build/vet/gofmt clean; attribution unit tests + service stamp/actor tests + handler suite pass on a fresh DB migrated through 151. Co-authored-by: multica-agent <github@multica.ai> * docs(attribution): fix accountable NULL semantics + close chat/quick-create evidence boundary (MUL-4302) Addresses Elon's 2nd-round review on PR #5150 (pre-merge doc/evidence items): - Migration 151 no longer overclaims NULL. accountable_user_id is NULL not only on pre-migration rows but on NEW rows whose audit source resolved no human yet (run_only autopilot writes originator_source='unattributed' with NULL accountable until rule_owner lands). Header + COMMENT ON COLUMN reworded so a schema reader does not misjudge the invariant. - Chat now uses the UNIFORM evidence pair (kind=chat, ref=chat_session_id), like autopilot_run/issue_assignment, instead of relying only on the dedicated chat_session_id column — new EvidenceChat kind. Added a service test asserting chat stamps direct_human + chat evidence. - Quick-create is documented as the ONE intentional no-antecedent-row path: no comment/issue/session/run exists at enqueue time (the run creates the issue), so trigger_evidence_kind/ref stay NULL while the human rides originator/accountable and source is direct_human — not a NULL-source bypass. No authorization behavior change. attribution + service + handler suites pass on a DB migrated through 151. Co-authored-by: multica-agent <github@multica.ai> * chore(attribution): renumber migrations 150/151 → 157/158 after merging main (MUL-4302) main's #5162 ("unblock release migrations") renumbered the chat migrations and took 150 (agent_task_coalesced_comments) and 151 (chat_read_cursor), colliding with this branch's attribution migrations. Renumber them above main's new highest (156) so TestMigrationNumericPrefixesStayUniqueAfterLegacySet passes: - 150_agent_task_attribution → 157_agent_task_attribution - 151_agent_task_accountable_user → 158_agent_task_accountable_user Fixed the internal "migration 150" references in 158's header to 157. Migrations apply cleanly through 158 on a fresh DB; migration lint green. Co-authored-by: multica-agent <github@multica.ai> * feat(attribution): autopilot rule_owner — accountable = rule version publisher (MUL-4302) Implements rule_owner (MUL-4302 §3.4), the first attribution source where the accountable human diverges from the (NULL) authorization originator. - Migration 159 adds the append-only autopilot_rule_version snapshot table (no FK, no cascade); migration 160 adds its CONCURRENTLY lookup index. - Write-on-publish: CreateAutopilot appends v1 (publisher = creator); UpdateAutopilot appends a new version when a SUBSTANTIVE autopilot-row field changes (assignee / status / execution_mode) — cosmetic edits (title/description/template) write none. Both run inside the existing handler tx (atomic with the autopilot write). - Dispatch resolution: both autopilot execution modes now resolve the active rule version and stamp originator_source='rule_owner', accountable_user_id=publisher, rule_version_id=<snapshot>, with originator_user_id left NULL (authorization unchanged). run_only stamps CreateAutopilotTask directly; create_issue resolves in attributionForIssueTask so both modes attribute identically. A missing version / non-member publisher degrades to unattributed — never fabricates a human. - finalizeAttribution now enforces the invariant ONE-WAY: it mirrors originator onto accountable only when originator is valid, leaving an explicitly-set accountable (rule_owner / future owner_fallback) intact when originator is NULL. Added rule_version_id to CreateAgentTask so the create_issue path persists it too. Also merges origin/main and renumbers this branch's attribution migrations 150/151 → 157/158 (main's #5162 took 150/151); rule_version table is 159/160. Tests: attribution unit RuleOwner + one-way invariant table; service integration tests proving an autopilot-origin issue stamps rule_owner + rule_version_id (and degrades to unattributed with no version). Full service/attribution/handler/ migration suites pass on a DB migrated through 160; build/vet/gofmt clean. Deferred (same PR): trigger-table republish (cron/webhook/event_filters) and system-pause/archive versioning; owner_fallback + fail-closed; manual rerun. Co-authored-by: multica-agent <github@multica.ai> * fix(attribution): manual autopilot trigger → direct_human to the triggering member (MUL-4302) Elon's blocking finding: a member manually triggering an autopilot was attributed rule_owner (accountable = rule publisher, originator NULL) like a schedule/webhook run, so member B triggering member A's autopilot landed accountable=A and carried no originator authorization context for the run. Per MUL-4302 §4 a manual "run now" is a direct human action and must attribute direct_human to the triggering member. - Thread the triggering member from TriggerAutopilot into dispatch: new DispatchAutopilotManual carries actorUserID (resolved via resolveActor + memberActorUserID, so only a member actor is a human; an A2A agent actor falls back to rule_owner). DispatchAutopilot / DispatchAutopilotForPlan keep their public signatures (pass an invalid actor); only the internal dispatchAutopilot / dispatchCreateIssue / dispatchRunOnly gained the param, so the many existing callers are untouched. - run_only: dispatchRunOnly stamps direct_human (originator == accountable == actor, no rule_version) for a manual actor, else rule_owner. CreateAutopilotTask gains an originator_user_id param for the manual case. - create_issue: dispatchCreateIssue enqueues a manual trigger via the actor-carrying *WithHandoff entry points; attributionForIssueTask's autopilot-origin rule_owner branch is now guarded on !actorUserID.Valid, so a valid actor falls through to the direct_human override. Both execution modes attribute identically. - schedule / webhook keep rule_owner (no actor). Trigger-table + system-pause/archive versioning remain the pre-merge follow-ups. Tests: the run_only row assertion Elon asked for (schedule → rule_owner row on CreateAutopilotTask), plus manual direct_human on BOTH modes (run_only and create_issue), including a manual actor distinct from the rule publisher. Full service/attribution/handler/migration/scheduler/cmd suites pass on a DB migrated through 160; build/vet/gofmt clean. Co-authored-by: multica-agent <github@multica.ai> * feat(attribution): owner_fallback + fail-closed policy, and manual-rerun direct_human (MUL-4302) Two of the three remaining Phase 1 items (trigger-table / system-pause versioning is deferred — see PR description). owner_fallback + fail-closed (§1/§3.5) — the never-null accountable guarantee: - attribution.OwnerFallback degrades an UNATTRIBUTED result to owner_fallback: accountable = agent owner, originator stays NULL (audit-only, authz untouched), Source.Precise()==false. finalizeAttribution's one-way invariant already allows accountable-set / originator-NULL divergence, so nothing else changes. - Migration 161 adds workspace.attribution_fail_closed (default FALSE) + a lean GetWorkspaceAttributionFailClosed read. (Also added the column to ListWorkspaces' explicit column list so its row type stays db.Workspace.) - applyAttributionFallback is applied at every enqueue boundary (issue, mention, chat, quick-create, deferred-fallback, autopilot run_only): unattributed → owner_fallback (agent owner) by default, or ErrAttributionFailClosed when the workspace is fail-closed, which the caller surfaces to refuse the enqueue (the run does not start). So no run is left without an accountable human, and a compliance workspace can block unattributable runs instead. manual rerun (§5) — a rerun is a NEW direct_human trigger to the rerunning member: - RerunIssue threads the acting member (resolved in the handler via resolveActor) down to enqueueRerunTask, and attributionForIssueTask is now actor-first so the actor wins over an INHERITED trigger comment (a rerun keeps the comment for the daemon's prompt context but must attribute to whoever clicked rerun, not the original comment's human). - rerun_of_task_id lineage is recorded via a targeted SetAgentTaskRerunOf update on the rerun path only (keeping the shared CreateAgentTask insert untouched), so system retry (retry_of_task_id) and human rerun stay separable in reporting. Tests: OwnerFallback unit test; owner_fallback + fail-closed-refusal + manual-rerun (direct_human + rerun_of_task_id) service tests; the prior "degrades to unattributed" test updated to owner_fallback. Full service/attribution/handler/migration/scheduler/ cmd suites pass on a DB migrated through 161; build/vet/gofmt clean. Co-authored-by: multica-agent <github@multica.ai> * fix(attribution): close fail-open holes + move rerun_of_task_id into creation snapshot (MUL-4302) Addresses Elon's two must-fixes on PR #5150. 1. accountable-never-null / fail-closed had fail-open holes. applyAttributionFallback now, for an UNATTRIBUTED run, refuses the enqueue (ErrAttributionFailClosed) in THREE cases instead of silently degrading to a runnable NULL-accountable task: - workspace policy read fails (or no workspace) → fail closed; we cannot confirm fallback is permitted, so we don't run an unattributable task on a DB hiccup. (Only the rare unattributed path pays this; precise runs never read the policy.) - workspace is fail-closed → refuse (unchanged). - owner_fallback has no valid agent owner → refuse rather than enqueue a task with a NULL accountable_user_id. ErrAttributionFailClosed's doc now covers all three "cannot guarantee an accountable human" refusals. Added missing-owner / policy-read-failure / precise-passthrough tests. 2. manual rerun rerun_of_task_id was a post-notify UPDATE (race: the queued event / daemon claim could see rerun_of_task_id = NULL, and a failed update degraded the run to a plain direct_human). It now rides the CreateAgentTask insert — threaded through enqueueIssueTask / enqueueMentionTask as a creation param (like retry_of_task_id) so it is written in the same statement before the daemon is notified. Removed the SetAgentTaskRerunOf follow-up query. Also merges origin/main (unrelated CLI fix #5167, no conflict). Full service / attribution / handler / migration / scheduler / cmd suites pass on a DB migrated through 161; build / vet / gofmt clean. Co-authored-by: multica-agent <github@multica.ai> * feat(attribution): rule_owner versioning on trigger edits + system-pause/archive (MUL-4302) The final remaining Phase 1 item: substantive publishes beyond the autopilot row now republish the rule version, so a run's rule_owner accountable follows whoever last changed what the rule does. - Extracted the config-summary + insert into service.RecordAutopilotRuleVersion so the handler and the (different-package) failure monitor share one writer; the handler's recordAutopilotRuleVersion is now a thin wrapper. - Trigger edits: UpdateAutopilotTrigger and DeleteAutopilotTrigger republish the rule version with the acting member as publisher, ATOMICALLY (tx-wrapped mutation + version write, mirroring CreateAutopilot/UpdateAutopilot). CreateAutopilotTrigger republishes best-effort — the webhook path mints its token with a retry loop that cannot share one tx, and a create is usually initial setup already covered by v1; a failed write there is benign (active version stays the current publisher, the new trigger fires under it, no immediate daemon claim rides it). - Archive (DeleteAutopilot) republishes (member, status=archived), tx-wrapped. - System auto-pause (failure monitor) republishes with a 'system' publisher, best-effort — a background sweep to a non-dispatching state (a paused autopilot never dispatches; a later member resume supersedes). - RotateWebhookToken / SetSigningSecret deliberately do NOT version: they rotate credentials, not the rule's behavior (not §3.4 substantive). Semantics: a system-published (no-member) active version degrades dispatch to unattributed → owner_fallback, never fabricating a human. Tests: republish-reattributes (member A → member B supersedes → dispatch resolves to B; system publisher → unattributed). Full service/attribution/handler/migration/ scheduler/cmd suites pass on a DB migrated through 161; build/vet/gofmt clean. Also merges origin/main (unrelated frontend feature #5074). Co-authored-by: multica-agent <github@multica.ai> * fix(attribution): make trigger-create rule-version republish atomic (MUL-4302) Addresses Elon's final Phase 1 blocking finding: CreateAutopilotTrigger recorded the rule-version republish best-effort AFTER the trigger insert. If member B added a schedule/webhook trigger to member A's autopilot and the version write failed, future schedule/webhook dispatches would keep attributing to A — violating the rule_owner invariant that the last member to substantively change the rule owns future runs ("no immediate daemon claim" doesn't save it, since the miss surfaces at the LATER trigger firing). Both create paths now write the version in the SAME tx as the trigger INSERT: - schedule create: wrap CreateAutopilotTrigger + recordAutopilotRuleVersion in one tx. - webhook create: each mint-with-retry attempt runs in its own tx (insert + version commit together; a token collision rolls that attempt back and retries with a fresh token; a version-write failure rolls the trigger back). Passes ap + the acting member id into the helper. - removed the best-effort recordTriggerRuleVersionBestEffort helper (and the now-unused slog import). Test: TestCreateTrigger_RepublishesRuleVersionAtomically drives both create paths through the handler and asserts a rule version is published by the acting member. Existing webhook/trigger/archive handler tests still pass. Also merges origin/main (unrelated avatar feature #5074). Full service/attribution/handler/migration/ scheduler/cmd suites pass on a DB migrated through 161; build/vet/gofmt clean. Co-authored-by: multica-agent <github@multica.ai> * feat(attribution): Phase 2.1 — surface run attribution on the task API (MUL-4302 §9) First Phase 2 (visibility) increment: the agent-task API now returns the resolved accountable-human provenance so the UI can render an "on behalf of" badge. - AgentTaskResponse gains an `attribution` object: source label (never blank — pre-migration NULL renders "unattributed") + `precise` flag (false for the degraded owner_fallback / backfill / unattributed sources), the initiator (accountable) and originator (authorization) user refs, the evidence {kind, ref_id} pointer, and the rule_version / delegated / retry / rerun lineage ids. - The label + evidence + raw ids are built in the PURE taskToResponse (no DB), so every task response carries them. Names are hydrated separately, only on the user-facing surfaces (ListAgentTasks, ListWorkspaceAgentTaskSnapshot, RerunIssue, CancelTaskByUser) — daemon-claim paths stay lean. - Hydration resolves initiator/originator from the GLOBAL user table (departed-member safe) via a new batch GetUsersByIDs query (no N+1); best-effort, so a lookup hiccup leaves the raw ids intact. Tests: pure taskAttributionBase (direct_human / rule_owner NULL-originator / owner_fallback degraded / pre-migration→unattributed) + DB hydration (fills known ref, leaves unknown id un-filled, skips nil). Full handler/service/attribution/ migration/scheduler/cmd suites pass on a DB migrated through 161; build/vet/gofmt clean. The field is additive — the frontend's parseWithFallback ignores unknown keys, so nothing breaks until the UI increment consumes it. Also merges origin/main (unrelated editor feature #5090). Remaining Phase 2 (next increments, same PR): frontend zod schema + "on behalf of" badge + evidence-chain jump; append-only correction events (write + display). Co-authored-by: multica-agent <github@multica.ai> * feat(attribution): Phase 2.2 — on-behalf-of badge in the execution log (MUL-4302 §9) Surface the accountable human on every agent run row: - AttributionBadge composes Badge + ActorAvatar, shows "on behalf of <member>" with the resolution source as a tooltip; degraded (non-precise) attribution gets a warning tone, and an unresolved initiator renders an explicit "no responsible member" chip. - Wire the badge into both active and past rows of the execution log. - Mirror the attribution shape into AgentTaskResponseSchema (defensive, .loose()) so the cancel-task path carries it through zod; add parse tests. - Export TaskAttribution/AttributionUser/TaskEvidence from @multica/core/types and add the attribution block to all four issues.json locales. Co-authored-by: multica-agent <github@multica.ai> * fix(attribution): hydrate initiator names on issue-facing task endpoints + bound the badge (MUL-4302 §9) Address Elon's PR #5150 review: - ListTasksByIssue (the execution-log data source), GetActiveTaskForIssue and the issue-scoped CancelTask now call hydrateTaskAttributions, so the "on behalf of <member>" badge shows the real member name on issue detail instead of falling back to "someone". Mirrors the existing ListAgentTasks / snapshot behavior. - AttributionBadge: cap width (max-w-40, min-w-0) and truncate the name span so a long name / narrow right column can't squeeze out trigger/status/actions; keep the avatar shrink-0. - Add a handler test asserting the issue task list returns a hydrated attribution.initiator.name. Co-authored-by: multica-agent <github@multica.ai> * fix(attribution): use semantic AvatarSize 'xs' for the badge avatar main refactored ActorAvatar.size from a raw pixel number to the semantic AvatarSize union (packages/ui/lib/avatar-size). Switch the on-behalf-of badge avatar from size={14} to size="xs" (16px) after merging main. Co-authored-by: multica-agent <github@multica.ai> * fix(attribution): stage-cascade falls back to parent-issue provenance, not agent owner (MUL-4302) When closing the last sub-issue in a Stage wakes the parent's assignee agent, the run was enqueued via a system-authored child-done comment with no actor, which the resolver classified as unattributed and then degraded to owner_fallback (the agent's own owner). That is the wrong accountable human: the woken run should be accountable to whoever caused the parent issue to exist. attributionForIssueTask now detects a system-authored trigger comment and falls through to the parent issue's own provenance — the same creator / agent_create-origin / autopilot-origin chain a direct enqueue resolves (so an agent-decomposed parent attributes via delegation to the human who drove it; a member-created parent to that member; an autopilot parent to the rule publisher). owner_fallback is now only the last resort when the parent provenance itself has no human. - Extract attributionFromComment so attributionForIssueTask can inspect author_type without a second GetComment; authorization resolution stays byte-identical. - Add a DB-backed test asserting a system child-done comment resolves to the parent issue's origin human (delegation), not owner_fallback. Co-authored-by: multica-agent <github@multica.ai> * feat(attribution): autopilot runs attribute to the firing trigger's creator (MUL-4302) Per Bohan: an autopilot schedule/webhook run should be accountable to the human who created the SPECIFIC trigger that fired it, not the rule publisher. (Manual triggers already attribute to the invoking member via direct_human — unchanged.) - Migration 162: add autopilot_trigger.created_by_type/created_by_id (nullable, no FK/cascade). Capture the creating member at both trigger-create sites (schedule + webhook). - New precise source trigger_owner: originator stays NULL (an autonomous fire carries no human authorization — same authz-safe divergence as rule_owner), accountable = the trigger's member creator. - triggerOwnerAttribution resolves run.trigger_id → creator; wired into run_only dispatch and the create_issue path (bridging issue → active run → trigger_id). Legacy triggers with no recorded creator, and agent-created triggers, degrade to rule_owner then owner_fallback — nothing regresses. - Frontend: trigger_owner source label in all four locales + badge switch case. - Tests: attribution TriggerOwner unit + Precise/invariant; DB-backed resolver tests (member creator → trigger_owner; creatorless → rule_owner fallback). Co-authored-by: multica-agent <github@multica.ai> * chore(attribution): re-trigger CI (dropped synchronize event on 249090260) Co-authored-by: multica-agent <github@multica.ai> * fix(attribution): mirror accountable_user_id on comment-coalescing merge (MUL-4302) The one-way invariant is 'originator_user_id IS NOT NULL ⟹ accountable_user_id = originator_user_id', enforced at finalizeAttribution for enqueues and preserved by the retry-clone (copies both columns). But MergeCommentIntoPendingTask (main #5192) re-stamps originator_user_id to the newly-coalesced comment's human WITHOUT touching accountable_user_id — so folding member B's comment into member A's queued task left originator=B / accountable=A, violating the invariant. Re-stamp accountable to mirror the new originator (same thing finalizeAttribution does). Add a DB-backed regression test. Co-authored-by: multica-agent <github@multica.ai> * fix(attribution): Elon's 3 must-fixes + DB cross-column invariant CHECK (MUL-4302) Bohan approved Elon's plan; this closes the three attribution boundaries he flagged and locks the one-way invariant at the DB. 1. Delegation now inherits the parent's ACCOUNTABLE, not just its originator. An autopilot-rooted chain (parent originator NULL, accountable = trigger creator) @mentioning an agent / creating a sub-issue used to drop to unattributed → owner_fallback and fail-closed workspaces wrongly rejected the fan-out. Added ParentAccountable/OriginAccountable to CommentFacts/DirectFacts; ClassifyComment/ ClassifyDirect copy accountable down (source=delegation, precise, originator NULL) so the chain root stays stable at any depth (§3.2). 2. The direct-chat send path (SendDirectChatMessage, MUL-4351) wrote only originator_user_id — no accountable/source/evidence, a NULL-source bypass. It now stamps the full direct_human attribution like EnqueueChatTask. 3. Comment-coalescing merge re-attribution is now ATOMIC: MergeCommentIntoPendingTask re-stamps the whole snapshot (person columns + source + delegation lineage + rule version + evidence) of the new comment, not just the two person fields, so a merged run never shows B accountable while pointing at A's stale source/evidence. 4. Migration 169: NOT VALID CHECK (originator_user_id IS NULL OR (accountable_user_id IS NOT NULL AND accountable_user_id = originator_user_id)). Enforces the invariant on every new write (the class of bug #5192 introduced); historical rows not blocked, VALIDATE after Phase 3 backfill. Updated test fixtures that seeded originator-only rows to also set accountable. Merged latest main (renumbered attribution migrations 163–168 after main took 161/162; merged the retry-clone chat_input_task_id + attribution columns). Verified: go build/ vet, attribution/service/handler/cmd-server tests on a migrated DB, frontend typecheck/lint/tests. Co-authored-by: multica-agent <github@multica.ai> * fix(attribution): trigger responsibility transfers to effective publisher; fail-closed comment merge Elon final-review must-fix 1 (MUL-4302): trigger_owner now resolves to the member CURRENTLY responsible for the firing trigger's effective config, not the fixed creator. Per-trigger published_by on autopilot_trigger, seeded to the creator and re-stamped to the editor on a substantive edit — a trigger-scoped edit bumps only that row (UpdateAutopilotTrigger), an autopilot-level edit bumps all its triggers (UpdateAutopilot). Editing one trigger never reassigns another. Adds real dispatchRunOnly transfer test + resolver-level isolation test. Must-fix 3: AttributionForMergedComment reuses applyAttributionFallback and returns ErrAttributionFailClosed; the merge caller refuses on fail-closed, keeping the queued task's original precise snapshot instead of degrading it to owner_fallback. Adds regression test. Renumbered attribution migrations to 166-172 after merging main. Co-authored-by: multica-agent <github@multica.ai> * fix(attribution): make migration 172 invariant CHECK upgrade-safe (Option A) Elon final-review must-fix 2 (MUL-4302), rollout chosen by Bohan. The NOT VALID CHECK still checks a pre-existing row on any later UPDATE (even one not touching attribution columns), so cross-deployment stale queued/running tasks (originator set, accountable NULL from before migration 167) would fail on their next claim/complete/cancel. Exempt exactly those legacy rows via 'originator_source IS NULL' — that column was added in 166 with no backfill, so it is NULL only on pre-migration rows and non-NULL on every attribution-aware write. New writes stay fully enforced; the #5192 bypass class (source always set) is unaffected. Phase 3 backfills legacy rows then drops+re-adds the strict form + VALIDATE. Adds TestAttributionInvariantCheck_ExemptsLegacyRows (legacy row survives a status UPDATE) and updates the reject-bypass test to the enforced regime. Co-authored-by: multica-agent <github@multica.ai> * fix(attribution): pin substantive/cosmetic edit boundary for trigger transfer Elon re-review must-fix 1: an autopilot-level edit only transfers trigger_owner responsibility when it changes what the automation instructs or who/whether it runs. autopilotRuleSubstantiveChange now includes description (the run Prompt) and issue_title_template; title and project_id stay cosmetic/routing. UpdateAutopilotTrigger no longer transfers on every PATCH — it compares the persisted before/after and transfers only on a real cron/timezone/enabled/ event_filters change, not a label-only or no-op PATCH. Adds real handler tests (prompt->all, title->none, cron->one+isolation, label->none, no-op->none). Must-fix 3: real merge-path regression (TestMergeCommentIntoPendingTask_ FailClosedKeepsOriginalSnapshot) drives mergeCommentIntoPendingTask and asserts a fail-closed workspace preserves the queued task's full snapshot; fail-open control completes the owner_fallback merge. Docs: migration 172 comment reworded to legacy-writer/unbackfilled-lineage semantics (source NULL is not strictly pre-migration); PR description synced. Migration renumber vs latest main (must-fix 2) deferred to pre-launch per Bohan. Co-authored-by: multica-agent <github@multica.ai> * chore(attribution): renumber migrations to 167-173 after syncing main Merged latest main (which took 166_project_dates) and shifted the attribution migration series off the 166 collision: 166->167 agent_task_attribution, 167->168 accountable_user, 168->169 rule_version, 169->170 rule_version_index, 170->171 fail_closed, 171->172 trigger_publisher, 172->173 invariant_check. Updated the internal cross-references in the migration comments accordingly. Fixes TestMigrationNumericPrefixesStayUniqueAfterLegacySet on the merge tree. Co-authored-by: multica-agent <github@multica.ai> * feat(admission): unify dispatch outcome + close rerun/chat/autopilot invoke holes (MUL-4525) P0 first increment toward a platform-wide execution-admission contract so a user who names an execution target always gets a definite result and never a silent no-op, and so blocked targets are reported without leaking private-agent details. Backend: - New shared contract (handler/admission.go): DispatchOutcome / DispatchStatus (queued/coalesced/deferred/blocked) + stable, enumeration-safe DispatchReasonCode set, plus writeDispatchBlocked() whose legacy `error` string never reveals target existence. - Rerun (task.go / task_lifecycle.go): re-validate the operator can invoke the RESOLVED target agent (historical agent for a task_id rerun) before any cancel/enqueue; blocked returns a structured 403 and mutates nothing (ErrRerunInvokeNotAllowed). - Chat send (chat.go): re-run canInvokeAgent on every send, not just the softer canAccessPrivateAgent view gate; a revoked permission blocks before the message/attachments/task persist. - Autopilot manual "run now" (service/autopilot.go): admission now keys on the current CLICKER, not the autopilot creator — clicker admission and clicker attribution no longer fork. Automation (schedule/webhook) still falls back to the creator gate. Added reason_code to the run response for the UI. Frontend: - triggerAutopilot response is schema-parsed; handleRunNow branches on run status and shows a localized, reason_code-based warning for skipped/failed instead of a false-success toast. - Chat send and rerun surface the structured 403 reason_code as localized toasts (dispatchReasonCode helper) instead of a generic failure. - Additive fields only; older clients keep working. i18n added to all 4 locales. Tests: rerun fail-before-mutation gate, autopilot clicker-vs-creator fork (service + handler), reason-code classification, and a malformed-response schema test. Backend handler+service suites and FE typecheck/lint green. Co-authored-by: multica-agent <github@multica.ai> * test(cmd/server): thread nil invoke gate through RerunIssue call sites (MUL-4525) Co-authored-by: multica-agent <github@multica.ai> * fix(admission): typed reason codes + run-now whitelist + real security tests (MUL-4525) Addresses Elon's review of the P0 first increment (must-fix 1–3). 1. Run now no longer has a false-success branch. handleRunNow now classifies on a whitelist via a pure runNowToastKind(): only issue_created/running → success; skipped → warning; failed and any unknown/future status → error. Add run-now-toast unit test over all five status classes plus reason-code → key mapping. 2. reason_code is a typed value decided at the admission source, not reverse-engineered from English failure text. New leaf package internal/dispatch holds the canonical ReasonCode enum (shared by handler + service so they can never drift). shouldSkipDispatch / errDispatchSkipped / the fail path now carry a typed code through DispatchAutopilotManual straight into the response; the substring classifier is deleted. Fixes the two missed branches: attribution fail-closed → attribution_blocked (typed errors.Is), "agent has no runtime bound" → runtime_offline. Regression tests for both. 3. Security acceptance tests exercise the REAL handlers, not injected callbacks: - Chat: create session while invokable → revoke invoke (flip to private, keep owner-view) → send returns 403 + reason_code with zero chat_message / task writes. - Rerun: private historical agent through RerunIssue + canInvokeAgent — a non-invoking workspace owner is refused 403 + reason_code and mutates nothing (fail-before-mutation); the agent owner is allowed 202. No migration; reason_code is a decision-time value only the manual "run now" response carries. Additive on the wire. Backend build/vet/handler+service suites and FE typecheck/lint/vitest green. (Migration-prefix collision with main remains the deferred pre-merge renumber.) Co-authored-by: multica-agent <github@multica.ai> * test(admission): make must-fix 3 acceptance tests prove the invariant (MUL-4525) Addresses Elon's round-3 narrow review — the two security tests were not yet falsifiable against the bugs they must catch. - Rerun: after enqueuing the historical task, reassign the issue to a SECOND agent that the denied user CAN invoke. Now the current assignee and the task_id agent differ, so a rerun that wrongly validated the current assignee would let the denied user through — the 403 proves the gate is keyed on the historical private agent. The allow case now asserts the reran task's agent_id is the historical agent, not the current assignee. - Chat: the blocked send now carries a valid, still-unbound attachment. After the 403 the test asserts the attachment's chat_session_id and chat_message_id are both still NULL, guarding against anyone moving attachment binding ahead of the invoke gate. Test-only. Full internal/handler Go suite green. Co-authored-by: multica-agent <github@multica.ai> * feat(comments): surface blocked @mention trigger_outcomes instead of silent no-op (MUL-4525 §2) A comment that @mentions an agent/squad the author cannot invoke used to save with zero feedback — the user assumed a bug. Now the explicit-mention path reports a per-target outcome on both preview and create/edit. Backend (server/internal/handler/comment.go): - resolveMentionedAgentCommentTriggers collects blocked outcomes instead of a silent `continue`. The invoke gate is evaluated BEFORE any archived/runtime state is read, so a caller who cannot invoke a private target only ever sees the generic invocation_not_allowed and can never enumerate its existence. - enqueueCommentAgentTriggers returns queued/coalesced/deferred/blocked per explicit mention; enqueue errors are typed (attribution_blocked via errors.Is), not swallowed. Implicit routing (assignee/thread/conversation) carries no outcome — the user never named those targets. - trigger-preview returns `blocked[]`; create/edit return additive `trigger_outcomes[]`. One blocked mention never fails the comment. Frontend: - Composer shows a warning chip for blocked mentions before sending; after sending, a "posted, but N not triggered" toast (blocked-only; coalesced/ deferred are success-shaped). Additive schema + defensive parse; i18n ×4. Tests: handler partial-success + enumeration-safety acceptance tests; core outcome-parse + preview-schema tests; hook/parity updated. Backend handler+service suites and FE typecheck/lint/vitest green. Co-authored-by: multica-agent <github@multica.ai> * i18n(admission): clearer, consistent blocked-trigger copy (MUL-4525) Reword the awkward "you are not allowed to run this autopilot's assignee" and polish all MUL-4525 blocked/partial copy across en/zh-Hans/ja/ko: - Unify on "you don't have permission to use this <agent|target>" (zh: 没有…的 使用权限) for autopilot Run now, comment mentions, rerun, and chat send — replacing the various "not allowed to run/trigger" phrasings. - Align zh to the glossary term 智能体 (was mixed "Agent"), matching the surrounding UI voice (e.g. agent_link_no_access). - Drop jargon: "blocked by an admission policy"/"被准入策略拦截" → "the run was blocked"/"本次运行已被拦截"; "attributed"/"归因" → plainer wording. - Comment copy counts "mentions" (was "targets") for consistency with the chip. Backend dispatchBlockedFallbackMessage (old-client English fallback) reworded to match; its enumeration-safety test assertion updated. Copy-only — no key/logic changes; parity + typecheck green. Co-authored-by: multica-agent <github@multica.ai> * fix(comments): one outcome per explicit mention + FE success whitelist (MUL-4525) Addresses Elon's round-2 review of the §2 comment trigger_outcomes. 1. Separate execution dedup from per-target outcomes. resolveMentionedAgent- CommentTriggers now returns triggers (deduped by executing agent) AND one commentMentionTarget per EXPLICIT mention. enqueueCommentAgentTriggers returns a per-executing-agent result map; commentTriggerOutcomes fans each agent's status to every target that resolved to it. So @Agent A + @Squad S(leader=A) coalesces to ONE task but yields TWO outcomes. The squad-leader self-suppress branch now returns a definite `deferred` outcome instead of no result. New CreateComment test asserts 1 task, 2 outcomes. 2. Frontend no longer treats an unknown status as success. unhandledComment- TriggerOutcomes whitelists queued/coalesced/deferred as handled; blocked and any unknown/future/empty status warn (mirrors the Run now whitelist). The preview schema's `blocked` now drops malformed entries INDIVIDUALLY instead of z.array(...).catch([]) discarding the whole set. Regression tests for the unknown status and the per-item drop. Backend handler suite + go vet, FE typecheck/lint/vitest green. Co-authored-by: multica-agent <github@multica.ai> * fix(comments): honest role + status in trigger_outcomes fan-out (MUL-4525) Addresses Elon's round-3 review of the §2 fan-out. 1. Execution merge preserves the squad-leader role instead of first-mention- wins. The dedup now UPGRADES an already-added plain @agent trigger to a @squad-leader trigger for the same agent, so @Agent A + @Squad S(leader=A) always runs as a leader task (is_leader_task + squad_id=S) regardless of mention order — the daemon still injects S's briefing. When two DIFFERENT squads share one leader, the single run carries one squad's context and the other squad is reported `coalesced` (folded), never a second `queued`. The enqueue result now records the executed squad so the fan-out can tell them apart. Tests assert the task role in both orders and the two-squad split. 2. Squad-leader self-suppression no longer fakes success. The self-trigger guard keys on the latest task ROLE with no status filter, so a long-completed task also suppresses; reporting `deferred/already_active` when nothing is active was a false success. The branch now reports `deferred` only when a real non-terminal task is active (its reconcile covers the comment), else a non-success `blocked` + new `already_handled` reason. Fixed the reversed helper-semantics comment. New handler test covers the completed-task branch. Backend handler+service suites and go vet green. Co-authored-by: multica-agent <github@multica.ai> * fix(comments): fail-closed active-task check, never fake deferred (MUL-4525) Elon round-4 must-fix: hasActiveTaskForIssueAndAgent swallowed DB errors by returning true, so both call sites could turn a query failure into a success-shaped `deferred/already_active` — a silent false success, exactly what this issue forbids for admission-query failures. - hasActiveTaskForIssueAndAgent now returns (bool, error). - Two pure decision helpers govern the branches, fail closed on error: - decidePostMergeMiss: on query error, do NOT enqueue a fresh task (duplicate concurrent-run risk) AND report non-success blocked/internal_error; a confirmed active task defers; a confirmed-none enqueues fresh. - decideSuppressedLeaderOutcome: on query error, blocked/internal_error; a confirmed active run defers; else self_trigger_suppressed. Never a fabricated deferred. - Renamed reason already_handled -> self_trigger_suppressed (Elon non-blocking note): the old name implied the new comment was already processed, but the real meaning is a suppressed self-trigger. Deterministic unit tests cover the query-failure branch at both call sites (no fresh enqueue, non-success outcome) — a real DB fault can't be forced through valid handler inputs, and the decision is what governs the behavior. Backend handler+service suites and go vet green. Co-authored-by: multica-agent <github@multica.ai> * fix(comments): honest merge outcome — refused merge is blocked, not fake coalesced (MUL-4525) A pending-task merge previously reported success (coalesced) even when it was refused or failed: attribution fail-closed and unknown DB errors both returned handled=true, so the caller recorded coalesced for a merge that never happened. mergeCommentIntoPendingTask now returns a distinguishable commentMergeResult; commentMergeTerminalOutcome maps a real merge to coalesced, a fail-closed refusal to blocked/attribution_blocked, and any other failure to blocked/internal_error. Only "no queued task to fold" falls through to the active-task decision. Adds pure coverage of the mapping plus a fail-closed regression asserting the non-success outcome and unchanged task count. Co-authored-by: multica-agent <github@multica.ai> * fix(comments): name blocked @mentions in preview + toast instead of a vague count (MUL-4525) The blocked-trigger preview showed a red "1 mention won't trigger" with no name, and the post-send toast said "but 1 mention wasn't triggered" — the user can't tell which target or why. Now each blocked mention renders its own chip named from the mention markup the user typed ("Go · No permission"), with an error indicator and a short reason; the toast names the single target too. The wire outcome still omits the target name (enumeration-safety) — the label comes from the user's own draft, so nothing new is disclosed. Shares a blocked-trigger-copy module (long + short reason labels) between the chip and the toast, and a pure mentionLabelsByTarget/parseMentions helper in core (fresh regex per call — a shared global leaked lastIndex). Adds core + chip tests; drops the now-unused trigger_blocked_count keys across locales. Co-authored-by: multica-agent <github@multica.ai> * feat(attribution): accountable-member avatar on agent task rows + transcript header (MUL-4302) Surface who each agent run is on behalf of where runs are actually browsed: - Agent detail activity tab: an avatar-only AttributionBadge on every task row's meta line (Now + Recent work), tooltip carries the name + resolution source. - Execution-record (transcript) dialog header: the full on-behalf-of badge next to the status pill. Adds a compact variant="avatar" mode to AttributionBadge, reusing its source-label mapping and degraded-attribution tone. Renders nothing when a run has no resolved accountable member. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: J <j@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-15 03:09:56 +08:00
YYClaw	9eddcaff10	fix(chat): defer cancellation-time finalization until the task transcript is stable (#5246) ... A quick Stop before the agent's first token no longer races a late reply. Started-but-empty cancellations defer the empty/non-empty judgment until the daemon acks its transcript flush (or a grace-period sweeper fires), then settle to a single outcome. Empty outcomes persist a durable, creator-authorized draft restore (fetched/consumed via a dedicated endpoint, reconnect-safe and at-most-once) instead of broadcasting the prompt over the workspace bus. Closes #5219	2026-07-15 00:52:27 +08:00
Marcelo Cecin	7985699df9	feat(help): surface the running server version in the Help popover (#4959) ... Surface the running server build version in the Help popover so self-hosted operators can confirm what's deployed and include it in bug reports. - Backend exposes it via /api/config's server_version (from main.version), omitempty so older/unstamped builds omit the field. - Unstamped "dev" builds are normalized to empty and the row stays hidden. - The row is suppressed on the managed cloud (frontend host multica.ai) and shown only on self-hosted deployments. - Frontend renders a muted footer row in the Help popover only when the value is non-empty; i18n added for en/ja/ko/zh-Hans.	2026-07-14 20:11:52 +08:00
Multica Eve	e07b5403ab	MUL-4502: make autopilot webhook admission durable (#5386) ... * fix(autopilots): make webhook admission durable Co-authored-by: multica-agent <github@multica.ai> * fix(autopilots): address webhook delivery review Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-14 16:20:33 +08:00
Multica Eve	a91a390d48	fix(cli): recover daemon executable path (MUL-4514) ... * fix(cli): recover daemon executable path Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): reuse executable fallback for restart Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-14 14:50:22 +08:00