50 Commits

Include renames

Author	SHA1	Message	Date
Claude	5ca20d1123	feat(projects): return the newest reply excerpt in thread summaries ... Before: GET /api/issues/thread-summaries told a client how many replies an issue had and when the last one landed, but not what it said, so a compact list had to open the thread to show it. After: each summary row carries last_reply_excerpt, the newest counted (non-deleted, non-system) comment flattened to one line of at most 80 runes with mentions collapsed to @Label; null when the issue has no counted comment. How: ListIssueThreadSummaries joins a lateral lookup of the newest counted comment (body capped at 2000 characters in SQL) onto the existing rollup, so the batch is still one query; the handler flattens it with commentExcerpt. A DB-backed handler test covers newest-wins, deleted and system exclusion, mention flattening and truncation (not run here, no PostgreSQL). Co-Authored-By: Claude Fable 5.1 <[email protected]> Claude-Session: https://claude.ai/code/session_017deksZDSzZBA4QSqZZoBip	2026-10-21 07:44:08 +00:00
Claude	dc60823c7c	feat(issues): show PRs and deliverables on the feed's output strip ... Before: a feed card's thread bar only said how many replies an issue had. To see whether an agent had opened a PR, whether CI was green, or whether a report had been uploaded, the reader had to open the issue. After: GET /api/issues/thread-summaries also returns, per issue, up to 3 linked PRs (newest first, with state, diff size and a passed/failed/pending/ none CI verdict), the number of distinct deliverable files and when the newest was uploaded. The thread bar ends with one chip per PR (state icon and CI icon, opens the PR in a new tab) and one deliverables chip (count and age, opens the issue). The peek shows the same strip under its header when the issue has any output. Issues with a PR or file but no comment now get a row. How: three batched, workspace-scoped queries over all requested ids (GitHub PRs, self-hosted VCS PRs, deliverables); PRs are ranked per issue in SQL and merged in Go. checks_state reuses rollupToConclusion and aggregateChecksConclusion, so it agrees with the PR list. Deliverables are files on live comments, grouped by media type and filename like collectDeliverableFiles. The response schema defaults the new fields for older servers and maps unknown checks_state values to none. The summary cache is refetched on pull_request events and on comments that carry files. DB-backed handler tests were written but not run (no Postgres here). Co-Authored-By: Claude Fable 5.1 <[email protected]> Claude-Session: https://claude.ai/code/session_017deksZDSzZBA4QSqZZoBip	2026-10-21 06:27:43 +00:00
Claude	13af0e9e3e	feat(issues): show the agent's latest progress checklist in the feed ... Before: The feed gave no sense of how far an agent had got. Agents could not post a progress report that the feed understands: `comment add` had no way to set a comment type, and the run brief told agents not to post progress at all. After: Each feed message shows a compact checklist under its thread bar (done/total, a small bar, the first 5 items, "+N more"), and the issue peek shows the same block under its title. Finished issues (done or closed category) fold to a single "done/total" line with a chevron to expand. A progress report is a `progress_update` comment by an agent whose body is a Markdown task list; the newest one per issue wins. How: The thread-summaries endpoint gains `latest_progress` ({comment_id, content, created_at} | null) from one batched DISTINCT ON query, so there is no new endpoint. Core adds the type, a tolerant zod schema, `parseProgressChecklist`, and a realtime patch for new reports. Views add `FeedProgressCard`, mounted from the thread bar and the peek, with strings in all five locales. `multica issue comment add --type progress_update` lets agents post a report, and the run brief documents it as the one exception to the single-comment rule. Co-Authored-By: Claude Fable 5.1 <[email protected]> Claude-Session: https://claude.ai/code/session_017deksZDSzZBA4QSqZZoBip	2026-10-21 06:10:12 +00:00
Claude	5802a4469a	feat(issues): surface agent questions waiting on the reader in the feed ... Before: a feed card showed reply counts and an unread dot, but an agent asking the reader to decide something looked like any other reply. After: GET /api/issues/thread-summaries returns awaiting_me per issue (up to 3, newest first): unresolved threads whose latest comment is agent-authored and mentions the caller. FeedView renders one decision card between the message card and the thread bar with the agent avatar, the newest excerpt, a "+N" count and a button that opens the peek on that comment. How: new sqlc query ListAgentQuestionsForIssues picks the latest non-deleted, non-system comment of each unresolved thread (recursive walk from the root, like ListCommentRepliesForRoots) and matches mention://member/<caller> only on that row. The handler flattens mention markup to @Label and cuts the excerpt to 140 runes. Peek actions gain an optional { commentId } that reaches IssueDetail as highlightCommentId. comment:created keeps the server-owned list, clears it for the caller's own member comment and refetches when the comment may change it. Co-Authored-By: Claude Fable 5.1 <[email protected]> Claude-Session: https://claude.ai/code/session_017deksZDSzZBA4QSqZZoBip	2026-10-21 05:40:58 +00:00
Claude	642d75483a	Merge remote-tracking branch 'origin/main' into claude/project-thread-nhut62	2026-10-21 03:34:01 +00:00
Claude	c4b6140334	perf(issues): page the comment timeline by root comment ... Before: GET /issues/{id}/timeline read every comment and activity of the issue (up to the hard cap) in one response, and the paging params only changed the response wrapper. The issue page fetched, parsed and held the whole timeline no matter how long the conversation was. After: `roots` (1..200) pages by root comment, newest first, with a (created_at, id) cursor in `next_before` / `next_before_id`. Each page carries every reply of its roots, so a thread is never split, plus the activities of the page's time window; `has_more_before` is exact. `around=<commentId>` lands on the page that starts at the comment's thread root. Requests without `roots` (including the legacy limit/before/after/around) behave exactly as before, so installed clients still receive the whole timeline. The issue page loads the newest 50 roots, fetches an older page when the list scrolls to its top without moving the viewport, and walks older pages for deep links and in-page find. How: three new sqlc queries (roots before a cursor, replies of a set of roots via a recursive walk, activities in a time window) feed the new listTimelinePage path. The web cache becomes an infinite query whose newest page is pages[0]; older pages are its next pages. Realtime and optimistic patches go through updateTimelinePages in core, which applies a flat-list edit across pages. Replies per page are capped at the comment hard cap: trailing threads move to the next page, and only a single oversized thread is cut and reported through X-Timeline-Truncated. Co-Authored-By: Claude Fable 5.1 <[email protected]> Claude-Session: https://claude.ai/code/session_017deksZDSzZBA4QSqZZoBip	2026-10-21 03:24:28 +00:00
Claude	cdc9a5a417	feat(issues): batched thread summaries endpoint for the project feed ... Before, a feed card needed a full comment list per issue to show reply counts, open threads and who has been talking. Now GET /api/issues/thread-summaries?ids=a,b,c (max 100) returns one rollup per issue in the caller's workspace: counted comments, last comment time, open (unresolved root) thread count and the three most recent participants. Deleted and platform-authored (system) comments are not counted. Issues with no counted comments, or from another workspace, simply have no row. Co-Authored-By: Claude Fable 5.1 <[email protected]> Claude-Session: https://claude.ai/code/session_017deksZDSzZBA4QSqZZoBip	2026-10-21 01:57:09 +00:00
Riley Rogersandsoulmate	2f247cc92f	fix: respect explicit comment-trigger cancellation during reconciliation (#9300) ... Co-authored-by: soulmate <[email protected]>	2026-10-19 03:15:40 -04:00
3 people	e2f4a22030	feat: steer a running agent from the normal composer, per recipient (MUL-7631) (#8760) ... * feat(server): steer running turns from ordinary comments (MUL-7631) A comment can now name recipients whose running turn should receive it (`steer_agent_ids` on POST /issues/:id/comments). Each named recipient with a running, steer-capable turn gets the comment bound to that turn instead of a follow-up run; any other recipient keeps its normal queued / coalesced / deferred trigger, so losing a race never drops input. - One comment can steer several turns: receipts are keyed by (comment_id, task_id) and returned as `supplements` on comments and timeline entries. The single supplement_* fields mirror the first receipt for older clients. - Completion reconciliation skips a steered comment only for the agent it steered, so the same comment still reaches recipients that were addressed without steering. - Delivery claims match the (comment, run) pair. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(issues): choose per recipient how a message reaches a running agent (MUL-7631) Steering moves from a separate "Add message" box on the run row into the normal reply and comment composers. Recipients keep the existing trigger rules; each recipient's current run on the issue decides what the message can do: - running (and steer-capable): add to the current run (default in that run's own thread), start after this run, stop and start over, or skip - queued: include when it starts, or skip - idle: start on send, or skip Receipts follow the message ("Waiting for Lambda to read it" → "Read by Lambda · after step N"), a failed delivery offers retry or sending it as a new run, and the run's step list marks where it read the message. A draft whose recipient finished meanwhile stays in place and says it will start a new run; a message with files is handled after the run. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(server): steer only the chosen turn, and make a retried steer idempotent (MUL-7631) - Steering names the exact running turns the author chose (`steer_task_ids`). A chosen turn that ended before the send arrives is never swapped for a later turn of the same agent; that recipient keeps its normal trigger. - A steering send carries `client_request_id`. A retry after a lost response returns the original comment (200) instead of creating a second comment and a second delivery; a concurrent twin binding the same request is treated as already steered. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(issues): guard steering sends against stale previews and broad resends (MUL-7631) - "Stop and start over" never stops a run while the trigger preview is still catching up with an edited @mention: the stop is dropped unless the preview answers the submitted text. - Steering sends the chosen turns' task ids and one request id per draft text, reused on retries of the same text. - "Send as a new run" on a failed receipt reaches only that receipt's agent: every other current recipient is suppressed. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(issues): keep the reply box placeholder neutral (MUL-7631) The empty reply box cannot know who a reply goes to: the author may @ someone else or only talk to a teammate. The recipient chip already says what Send will do once there is text. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * test(issues): give steering composer tests room for the preview debounce (MUL-7631) Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(issues): choose the default reply to a running agent (MUL-7631) Preferences > Comments gains "When replying to a running agent": "Add to current run" (default) or "Start after this run". It only changes what a reply does without a per-message choice; the recipient chip still offers both, and replies that never steered by default (another thread, an idle or queued agent) are unaffected. Saved on this device next to the sticky comment bar. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(server): save one comment per send and honor "don't start" on replay (MUL-7631) Idempotency now lives on the comment, not the delivery receipt. A send's client_request_id is stored on the comment behind a partial unique index (migrations 550/551), so a retry, or a concurrent twin, returns the saved comment (200) whether the send steered a running turn or fell back to a normal trigger. Before, a twin could save a second comment, and a send whose turn had ended kept no receipt to find. The agents an author chose not to start are stored on the comment too, and completion replay skips them. "Send as a new run" for one missed recipient, and "Won't start this time", no longer wake the other agent once its current run completes. An edit re-records the choice. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(issues): repeat the original steering request on retry (MUL-7631) Until a send is settled, retrying the same text sends its first steering request unchanged, even after the chosen turn ended. The server then returns the comment the first attempt saved instead of posting it again as new input. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(migrations): fail fast on locks in 549 and 550 (MUL-7631) Both take an ACCESS EXCLUSIVE lock on a table the product touches continuously: comment for every read and write, task_supplement for every daemon claim. Bound lock acquisition and execution, as 483 does for issue, so a long transaction makes the migration fail and retry on the next run instead of queueing all traffic behind it. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(server): steer at most one turn per comment during rollout (MUL-7631) Steering is live, and servers from before per-run receipts claim every receipt of a comment at once. While they still serve daemons during a rollout, a comment bound to two turns could have the second copy marked in flight and never delivered. Until every server claims per (comment, run), a comment steers the first chosen turn only; later recipients keep their normal trigger. A follow-up lifts the limit after this ships. Also covers a steer_task_ids entry that names another issue's turn. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(server): finish a saved send on retry; keep an edit's choices with its text (MUL-7631) A send's comment was saved before its agents were started or steered, and deduplication treated the saved comment as the whole send. A dropped connection cancelled the request between the two, and the retry only returned the comment, so no agent ever received it. - Attempts of one logical send now run one at a time under a transaction advisory lock, held on its own connection: a twin waits for the attempt in progress (up to 30s, then 409) instead of racing it, and a process that dies releases it. - After the comment is saved, dispatch runs on a non-cancelable context, and comment.client_request_dispatched_at (migration 552) records that it finished. A retry that finds a saved but undispatched comment finishes the dispatch with the comment's recorded choices. An edit's "don't start" choices were written by a separate statement after the text, so interleaved edits could leave an older edit's choice. They are now part of UpdateComment, under the same revision check as the text. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(issues): offer one steered recipient per message during rollout (MUL-7631) The server steers at most one turn per comment until #8800, but the composer showed "Add to current run" for every running recipient and the server quietly queued the rest. Now only one recipient steers: the one the author picked, otherwise the first that would by default. The others show "Start after this run", and picking "Add to current run" on one of them moves the steer there. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(server): claim a send before dispatching it; drop the request lock (MUL-7631) The previous recovery marked a send dispatched only after reaching its agents, so a failure after dispatch made a retry reach them all again. It also held a pooled connection per send for an advisory lock while the send needed more from the same pool, which could wait on itself until timeout. A send's comment now holds a dispatch claim instead (comment.client_request_dispatched_at, one conditional update): only the attempt whose claim takes effect publishes the comment and reaches its agents. A failed claim writes nothing else and returns 500 for the client to retry; a retry that finds an unclaimed comment claims and dispatches it; a claimed one is only returned. Concurrent attempts no longer wait on each other, and post-save dispatch keeps a 30s bound of its own. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(server): let one comment steer several running turns (MUL-7631) Lifts the rollout limit from #8760. Every server now claims receipts per (comment, run), so a comment can be bound to each running turn its author chose, and each recipient receives it in its own run. Merge only after #8760 is deployed everywhere. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(issues): steer every running recipient a message addresses (MUL-7631) The client side of lifting the rollout limit: each running recipient can take the message in its current turn again, instead of only one per message. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * refactor(issues): drop send-retry idempotency and two display extras (MUL-7631) A steering send now behaves like any other comment when its response is lost: a retry posts it again. The machinery that tried to make that retry return the saved comment grew with every edge it met, and ordinary comments never had it: - Remove comment.client_request_id, its unique index, and the dispatch claim (migrations 551/552, and 550 reduced to suppressed_agent_ids). - Remove the replay/resume path in CreateComment, the post-save non-cancelable dispatch context, and the client's sticky request id. Steering sends only `steer_task_ids`; each binding uses the comment id as its receipt request id. Two display extras go too, since the UI already shows the same thing: - The "run ended while you were writing" notice: the recipient chip already switches from "Add to current run" to its new action. - "after step N" on a read receipt: the run trace already places the message at the step where it was read. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(issues): space agent names in Chinese copy; neutral recipients header (MUL-7631) - The steer badge joined names with Intl.ListFormat, which gives "Lambda和Orion" in Chinese. Latin names are now spaced from the Chinese joiner ("Lambda 和 Orion"), per the zh copy conventions; the enumeration comma stays unspaced. - The multi-recipient popover was still titled "Will start when sent" and its tooltip said "choose who runs", though each row now picks how that agent handles the message. Title it "Recipients" and reword the tooltip. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(issues): translate the recipient source labels in Chinese (MUL-7631) "assignee" and "@mention" were left in English in zh-Hans; the recipient menu header shows them. Use 负责人 (per the zh conventions) and @提及. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-09-25 04:42:26 +08:00
4 people	93ae552ba9	feat: add messages to active Claude Code and Codex runs (MUL-7565) (#8682) ... * feat: add live run supplements (MUL-7565) Co-authored-by: multica-agent <[email protected]> * fix: address MUL-7565 review feedback Co-authored-by: multica-agent <[email protected]> * fix: resolve MUL-7565 supplement panel and receipt review Co-authored-by: multica-agent <[email protected]> * refactor: remove MUL-7565 supplement ordinals Co-authored-by: multica-agent <[email protected]> * fix: close supplement composer after run remount * fix: exclude task supplements from completion reconciliation * fix: build a persistent binary for local daemon launches * feat: support Claude task supplements through SDK hooks * refactor: simplify task supplement delivery * test: remove redundant task supplement coverage * fix: remove redundant supplement delivery notices * refactor: extract local daemon launcher fix to its own PR * fix: preserve ordinary comment size compatibility * fix: accept empty task start acknowledgements * fix: bound task start response decoding and retries --------- Co-authored-by: Forge-Boy <[email protected]> Co-authored-by: multica-agent <[email protected]> Co-authored-by: yushen <[email protected]>	2026-09-23 16:10:07 +08:00
Bohan Jiang	a9e82c7973	MUL-7282: fix(comments): delete only the selected comment and keep its replies (#8323) ... Deleting a comment removed every reply under it, through the parent_id ON DELETE CASCADE. Now delete removes only that comment: one with replies becomes a tombstone (deleted_at set, body/attachments/reactions/resolution cleared) so the replies keep their parent, and one without replies is removed along with any tombstone ancestor left empty. Tombstones are read-only and are never agent input. Every write to a comment's children takes its owners first (issue -> comment -> child), and a comment commits together with the attachments it was posted with. Clients only promise that replies are kept when the server declares comment_delete_keep_replies_supported, and then delete through DELETE /api/comments/{id}/keep-replies, which older servers do not route.	2026-09-13 19:13:43 +08:00
importcpp	1500abe357	MUL-7272: fix(comments): preserve deferred worker reply handoffs (#8288) ... A worker's plain reply that arrived after the squad leader's run was claimed, but before it started, was never delivered. Creation deferred it to completion reconcile, and reconcile only replays explicit agent mentions, so the leader never received another run for it. Record such replies in the claimed run's planned inputs. On completion, replay the assigned-squad-leader route only when the reply was recorded there, after rechecking current routing and permissions. Timestamp-only agent replies, self-replies, notes and suppressed replies still earn no follow-up. RegisterPlannedCommentForActiveTask now also rechecks status on the UPDATE target, so a registration that waited on a completing row misses and enqueues a successor instead of attaching an obligation to a completed run.	2026-09-11 14:09:28 +08:00
Jiayuan Zhang	028f3b4437	feat(issues): show agent execution inline in comment threads (#8131) ... * feat(issues): show agent runs inline with comment replies * fix(issues): unify run comment projection and preserve disclosure focus * refactor(issues): replace nested run cards with inline status rows * fix(issues): align thread roots with reply content * style(issues): remove thread toggle background * style(issues): group reaction picker with comment actions * feat(issues): show readable issue references in run summaries * style(issues): move completed run logs into comment headers * style(issues): balance comment block vertical spacing * style(issues): shimmer live agent progress text * style(issues): unify comment action hover feedback * style(issues): reveal comment actions on block hover * fix(issues): move published reply activity into the header * fix(issues): settle comment UI as soon as replies are published * fix(issues): reveal comment log buttons on hover * fix(issues): defer run placement until trigger comments arrive * fix(issues): isolate agent comment queues by thread * fix(issues): display pending runs in execution order * fix(ci): align integration tests with thread-scoped queues * fix(issues): fit run actions to narrow comment columns	2026-09-08 12:58:16 +08:00
4 people	f1ce9d4542	MUL-6883 perf(server): stop rescanning settled delegated-failure recoveries (#7820) ... * feat(server): retire settled delegated-failure recoveries from the outbox scan ListPendingDelegatedFailureRecoveries had no indexable notion of a finished recovery. Its partial index (343) selected every recovery comment ever written, so each sweeper tick re-proved through four joins and two NOT EXISTS subqueries that history was already handled. LIMIT bounds the rows RETURNED, never the rows CHECKED, so a tick that found nothing still grew more expensive as history accumulated. Add comment.recovery_settled_at and a partial index that holds only unsettled recovery comments, and write the marker inside the transaction that makes a task terminal. Every other exclusion the scan applies is reversible — an issue can leave 'done', a cancelled retry can be superseded — so none of them can be frozen into an index predicate. A delivery receipt on a terminal task cannot be taken back, which is what makes it safe to record as durable state. The marker is deliberately written only once the task is terminal. SetTaskDeliveredCommentIDs replaces rather than appends a receipt while a task is still dispatched, so a reclaim by a differently-capable daemon can drop an id it will not deliver; settling at receipt-write time would freeze that legitimate transient window into a permanently lost recovery. Exhaustion is the one terminal outcome whose receipt lands on a row that may still be running, so it retires the comment directly in the same transaction. An unmarked row is the safe direction: it is scanned exactly as it was before this column existed. That is what makes the rolling-deploy window harmless — an older replica that writes a receipt without the marker only leaves work for the backfill. Co-authored-by: multica-agent <[email protected]> * feat(server): backfill delegated-failure recoveries settled before the marker The marker only covers tasks that reach a terminal status after the writing code ships. History written before that keeps matching the unsettled index predicate and keeps being re-checked on every sweeper tick, which is the cost this change set exists to remove. The walk retires a candidate only when a terminal task already recorded it in delivered_comment_ids — the same monotonic condition the runtime path uses. Its keyset watermark advances over every candidate EXAMINED rather than every candidate marked: a recovery that is genuinely still pending must be left alone, and keying on updated rows would hand back the same watermark forever and never terminate. Separate from migrations and startup, in the shape the other backfill commands already use, so a large comment table cannot block a deploy. Running it is a performance recovery step, not a correctness step — until it finishes the scan behaves exactly as it does today. Co-authored-by: multica-agent <[email protected]> * fix(server): close the review gaps in the settled-recovery backfill and paths Three fixes from review. 1. The backfill reproduced the bug it was written to fix. Its keyset ordered by id while idx_comment_delegated_failure_unsettled is (created_at, id), so the candidate scan read every unsettled row and sorted it to return LIMIT of them; and the receipt test ran a per-candidate EXISTS over agent_task_queue, the largest table in the database. The keyset now matches the index, and the receipt lookup is inverted into one agent_task_queue read per BATCH that hash-joins delivered ids back against the candidates. Measured on 500k comments / 200k tasks / 50k unsettled recoveries: 17,393ms and 816,963 temp blocks before, 235ms and no temp spill after. The candidate scan goes from reading 50,000 rows to reading the 1,000 it needs. Total walk time is flat across batch size (50x228ms, 10x1016ms, 5x2199ms — all ~11s), so batch size only trades how long one statement holds row locks. 1000 stays, now for a measured reason rather than a guessed one. 2. Bulk cancellation paths could strand a delivered receipt permanently unsettled, which lets the new index regrow the history it exists to remove. Manual rerun's pending-slot clear and agent archive were the two named in review; auditing the rest found comment-edit cancellation, both chat-session cancellations, workspace revoke and runtime teardown in the same position. All now settle — inside the caller's transaction where one exists, and through CaptureCancelledTasks for bulk paths that finalize outside one. The invariant is stated on the exported helper so the next such path has somewhere to read it. 3. --max-batches could not actually resume. The watermark lived only in the process, so a bounded rerun restarted at the front of the index — which is precisely where the rows this walk never settles live, so repeated bounded runs would rescan the same prefix and never reach the settleable history behind it. Adds --checkpoint-file (atomic replace, read on start) and explicit --after-created-at/--after-id, and logs the resume cursor on every exit path including SIGTERM. Co-authored-by: multica-agent <[email protected]> * fix(server): make delegated-failure settlement terminal-checked and atomic Two fixes from review. 1. The settlement SQL trusted its caller. "A delivery receipt is only immutable once the task is terminal" is the safety premise of the whole design, but the exported helper enforced nothing: passing a dispatched or running task would settle a receipt a reclaiming daemon can still replace, and the marker is monotonic, so nothing could undo it. The predicate now lives in the SQL, so a non-terminal task updates no rows instead of destroying the obligation. 2. Bulk settlement was post-commit best-effort, and the comment claiming the sweeper would replay a failed one was simply wrong: the covering task is terminal and already holds the receipt, so ListPendingDelegatedFailureRecoveries excludes the comment. It would neither replay nor settle — it would sit in the partial index forever, restoring the unbounded scan this change set removes. Every terminal write now commits with its settlement. CancelTasksForIssue / ForAgent / ByTriggerComment and the rerun pending-slot clear run in a transaction; CancelQueuedChatTasks settles inside the one it already had; the sweeper and daemon-recovery bulk fails move behind TaskService wrappers that own the transaction; agent archive gets CancelTasksForArchivedAgent, which cancels and settles atomically while still skipping the per-task broadcast the archive event makes redundant. BroadcastCancelledTasks, CaptureCancelledTasks and HandleFailedTasks run after their caller committed, so they no longer settle at all — a failure there could be neither rolled back nor repaired. The best-effort helper is deleted rather than left available; every remaining call site passes a qtx. Tests: a dispatched/running task with a receipt is not settled (fails without the SQL predicate), a bulk cancel whose settlement fails rolls the cancel back, and the archive path settles through its atomic entry point. Co-authored-by: multica-agent <[email protected]> * docs(server): correct settlement invariant comment and drop leaked test function The SettleDeliveredDelegatedFailureRecoveries doc still described the pre-fix contract — settlement reachable through CaptureCancelledTasks or a post-commit best-effort call — which is exactly the shape the atomicity fix removed. Restate the rule as it now stands (same qtx as the terminal write, never from a post-commit helper) so the stale text cannot guide a future change back into stranding rows in the partial index. TestBulkCancelRollsBackWhenSettlementFails dropped its trigger but left reject_recovery_settlement() behind in the shared test database; drop the function too. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]> Co-authored-by: Eve <[email protected]>	2026-09-01 12:11:50 +08:00
YYClaw	8c563b49be	MUL-6555 feat(issues): preserve source context for sub-issues (#7461) ... * feat(issues): preserve source context for sub-issues * fix(issues): address source context review findings * fix(migrations): guard source context rollback preflight	2026-08-25 12:00:49 +08:00
3 people	b4bfe083be	MUL-6407: mint UUIDv7 primary keys for append-heavy tables (#7230) ... * perf(db): mint UUIDv7 primary keys for the append-heavy tables Random v4 primary keys scatter every insert across the whole primary-key B-tree, so each row dirties a different page. On the tables that grow continuously — the task queue, messages, comments, activity and audit rows — that is pure write amplification. UUIDv7 puts a big-endian millisecond timestamp in the leading 48 bits, so consecutive inserts share a page. The 12 tables converted here are the append-only hot paths: agent_task_queue, activity_log, inbox_item, comment, issue, chat_session, chat_message, autopilot_run, webhook_delivery, task_token, channel_inbound_audit, sys_cron_executions Ids come from the new pkg/dbid, which returns a pgtype.UUID ready to assign to a sqlc params struct. Upsert-dominated tables (task_usage, agent_runtime, ...) are deliberately left alone: v7 only buys locality for rows that are actually inserted. Lease and claim tokens keep gen_random_uuid() — they must stay unpredictable and carry no timestamp. No migration, and no backfill. Every converted INSERT binds its id as COALESCE(sqlc.narg('id')::uuid, gen_random_uuid()), so the column default stays reachable: a caller that passes no id inserts exactly as it does today. Tables will hold a mix of v4 and v7 ids permanently, which the uuid type and every parser in the repo already accept. Verification: - pkg/dbid: version/variant, uniqueness, and a non-decreasing timestamp prefix; a shape test asserting every converted query keeps the COALESCE fallback; and a source scan asserting every production params literal mints an id, so a call site added later cannot silently fall back to v4. - internal/handler: round-trips issue, comment, activity_log, inbox_item, chat_session, chat_message, agent_task_queue, task_token and channel_inbound_audit against Postgres and asserts the stored id is v7, plus one case proving an unset id still inserts (as v4). - internal/scheduler: covers the one hand-written INSERT, asserting the execution id is v7 while lease_token stays v4. Co-authored-by: multica-agent <[email protected]> * fix(db): address UUIDv7 review feedback Co-authored-by: multica-agent <[email protected]> * fix(db): cover Telegram audit UUIDv7 Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Sol-Boy <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-20 13:42:44 +08:00
3 people	5d5fe64672	MUL-6343: Add semantic issue activity timestamps (#7193) ... * feat: add semantic issue activity timestamps Co-authored-by: multica-agent <[email protected]> * fix(migrations): register issue activity index cleanup Co-authored-by: multica-agent <[email protected]> * fix(issues): address last activity review Co-authored-by: multica-agent <[email protected]> * fix(issues): close last activity review gaps Co-authored-by: multica-agent <[email protected]> * fix(issues): harden activity rollout safeguards Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Sol-Boy <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-19 16:08:40 +08:00
YYClaw	4b8873df3a	feat(issues): add revision-aware concurrency guards (#7038) ... * feat(issues): add revision-aware concurrency guards * fix(concurrency): decouple text edits from aggregate revisions	2026-08-19 14:06:59 +08:00
3 people	97195885fa	MUL-6350: rebuild the plugin system (2/4) — Action API + Surface + SDK (#7157) ... * MUL-6350 feat(plugins): Action API and via-plugin attribution (2/4, part 1) The server half of PR 2. A surface can now read and write through Multica, but nothing renders one yet — the iframe host, SDK and example plugin follow. Every Action API call passes three checks in order: 1. the installation exists and is enabled — a surface left open in a stale tab stops working the moment an admin disables the plugin, rather than merely disappearing from the settings page; 2. the installation holds the scope the endpoint needs, and the refusal names the missing scope so an admin can act on it; 3. the SIGNED-IN USER may touch the resource. Three is what makes the model safe, and it is deliberately not implemented here: the workspace comes from the installation row rather than a client header, membership is checked against that workspace, and the issue lookup is scoped to it. A plugin therefore inherits exactly the reach of the person using it, with no second copy of the permission rules to drift. There is no plugin credential anywhere in this path. The iframe holds no token; it posts a message to the host page, and the host re-issues the call on the user's own session with a header naming which installation is speaking. comment.via_plugin_id is the other half of that identity story: permission-wise a plugin-mediated write is the user's, so author_type/author_id are unchanged, but audit-wise it stays attributable to the plugin that produced it. Modeled on comment.quick_action_id — no request field sets it, so it cannot be forged by a member posting normally. Two deliberate narrowings, both additive to widen later: - PATCH issues covers title and description only. Status, priority, assignee, parent, project and stage carry dispatch, catalog or hierarchy semantics that would need a second, drifting copy of those rules here. - A plugin-posted comment does not run @mention trigger dispatch. A plugin able to post a mention could start agent runs, and spend the workspace's budget, from a surface the user only meant to click a button in. issue_panel and sidebar_panel flip on in HostCapabilities so an install stops failing on a surface the host is about to be able to render. Co-authored-by: multica-agent <[email protected]> * MUL-6350 feat(plugins): surface host, bridge and SDK (2/4, part 2) The half a user can see. An installed plugin's issue_panel now renders on the issue page and can read, write and store through the Action API landed in the previous commit. Isolation reuses the convention already in this repo for untrusted HTML (packages/views/editor/code-block-iframe.tsx): sandbox="allow-scripts" and NOT allow-same-origin, which the HTML spec calls out as the pairing that defeats the sandbox. The frame gets an opaque origin — no cookies, no localStorage, no access to the embedder, and no storage shared between two plugins. That is why no separate plugin origin domain is needed. The host generates the document rather than pointing the frame at the author's HTML. That is what makes the net: scopes real: CSP is decided by whoever emits the document, so an author-emitted page would carry its own server's policy and the scope the admin approved would be a claim nobody checks. Here connect-src is derived from the granted scopes, and a plugin with no net: scope gets connect-src 'none' — it cannot phone home at all. Identity on the bridge is bound by a MessagePort, not by event.origin: every sandboxed frame reports the opaque origin "null", so comparing origins would authenticate nothing. The host creates one channel per iframe, transfers one end in, and only listens on the other. Also here: @multica/plugin-sdk (zero runtime deps, no @multica/core or @multica/ui import, since it ships to third parties), the hello-panel reference plugin, and the bridge's own refusals — a path outside the Action API never becomes a request, and a resize is clamped. A local: install cannot render a surface: its files live on the server's filesystem with no URL a browser could fetch, and the panel says so rather than showing an empty frame. Tests cover what a reviewer cannot see by reading the components: the CSP derived from scopes, entry resolution refusing local and plaintext sources, attribute escaping, the sandbox attribute never gaining allow-same-origin, the bridge's path allowlist and status pass-through, and disabled installations not mounting. Co-authored-by: multica-agent <[email protected]> * MUL-6350 fix(plugins): give the SDK package a vitest config and protocol tests A new workspace package inherits the repo's `test` script, so `vitest run` ran with no config and no test files and exited non-zero — frontend-test went red on a package that had nothing wrong with it. Rather than only adding `passWithNoTests`, the guards now have the coverage they warrant: they are the only thing between a hostile message and the bridge handlers on both sides, so anything that is not exactly the agreed shape has to fall through instead of being coerced into something close enough. Includes the response/event mix-up, which would otherwise resolve a pending call with a theme payload or apply a response as design tokens. Co-authored-by: multica-agent <[email protected]> * MUL-6350 fix(plugins): make the surface flow actually work end to end Running a real plugin against a live stack found five defects that every test in this PR passed straight through. Each one produced the same symptom — a blank panel — and none was visible from reading the code. 1. The handshake raced in both directions. The host connected on the iframe's load event, which for a srcdoc frame can fire before React attaches the handler; and a guest that announced once could announce before the host was listening. The surface now announces until it is answered, and the host matches event.source against the frame it created. Origin cannot be used for this — every sandboxed frame reports "null". 2. The bridge was reused across a document change. close() is terminal, and the theme effect changed srcDoc, so the second connect() returned immediately on a permanently closed bridge. One bridge per rendered document. 3. The theme was read on first render, when the ref is still null, so every surface was built with no tokens at all. 4. X-Multica-Plugin-Installation was missing from corsAllowedHeaders, so the preflight failed and every Action API call from a browser client died as "Failed to fetch". The comment above that list warns about exactly this. 5. activity_log kept a via_plugin_id column in generated code from an earlier draft of migration 348 that no longer creates it — every issue timeline returned 500. Regenerated. Also from seeing it rendered: frame-ancestors is dropped from the meta CSP (ignored there, and the browser warns), and string config fields can declare multiline so a value that is a list of lines gets a textarea instead of a single-line input the user cannot read. MULTICA_PLUGIN_DEV_ORIGINS lets an operator name an origin a manifest may be served from while a plugin is being built, and a surface entry may resolve over plain HTTP from loopback — what browsers already treat as a secure context. Without both, a surface cannot be developed at all: there is no way to serve one over public HTTPS from a laptop. examples/plugins/release-checklist is the plugin this was verified with: a per-issue definition-of-done checklist with workspace-configured items, per-issue state in plugin storage, strict-mode gating, and a sign-off comment that lands as the user with via_plugin_id set. Co-authored-by: multica-agent <[email protected]> * MUL-6350 fix(plugins): close the bridge hijack, fix the capability gate, sync the comment path Review fixes for #7157. The security one first: the SDK accepted a bridge-init from any window and let a later init replace the port. Sibling surfaces are mutually opaque, but `parent.frames[i]` is an allowed cross-origin access — so another plugin on the same issue page could deliver its own MessagePort, become a surface's "host", feed it fabricated data and read everything it wrote, including whatever it put in storage:user. The host already made exactly this check on the readiness signal; the guest half was missing. Both examples carried the same hole, and examples get copied. The capability gate had flipped to enabling sidebar_panel with no mount point anywhere — a plugin declaring one would install cleanly and then never appear, which is the silent failure the gate exists to prevent. Turned back off, and a test now asserts the shipped set matches what the host actually mounts, so the next flip has to come with its renderer. The two red tests were red for a real reason but were also written to break on any capability flip. Rewritten to test the thing rather than today's set: the message is asserted against an explicit empty Capabilities{}, and the live gate against a kind that genuinely is not shipped (a hook). Added the other half — a shipped surface must install against the real HostCapabilities. A plugin-posted comment now publishes comment:created and re-opens a resolved thread, like every other comment path. Skipping mention dispatch was deliberate; skipping these two was not, and it is why the demo needed a page reload to see the comment appear. Corrected an overclaim rather than pretending to fix it: "no net: scope means it physically cannot send data out" was wrong, because script-src necessarily allows the author's own origin. net: bounds THIRD-PARTY destinations. img-src and font-src are narrowed to inline data, which removes the two side channels that need no scripting at all; the rest cannot close without re-hosting third-party code, which this design rules out. Smaller ones from the same review: the surface-error listener now checks window identity too (any frame could light every panel's failure banner), the bridge takes a method allowlist instead of any string, surfaces[].platforms is enforced rather than decorative, and the iframe is keyed on the issue so a bridge created for a new issue is not left waiting on a guest that already stopped announcing. Co-authored-by: multica-agent <[email protected]> * MUL-6350 fix(plugins): drop the SDK's jsdom dev dependency and stub the window `pnpm add -D jsdom` wrote a partial lockfile update: it resolved against a warm local store, so `--frozen-lockfile` passed here and failed in CI on a vitest peer key that was never written. Rather than re-resolve, the dependency is gone. The SDK touches exactly `window.addEventListener` and `window.parent`, so the handshake tests run on a hand-built EventTarget in the node environment. A package that ships to third parties is better off carrying no test-only dependency at all, and the tests still fail without either guard they cover. Co-authored-by: multica-agent <[email protected]> * MUL-6350 fix(plugins): keep a test runner out of the SDK package A new importer that pulls vitest through the catalog resolved to a peer key CI could not satisfy on a clean install, so every frontend job died in `pnpm install --frozen-lockfile` before running anything. Two attempts to re-resolve it locally produced a lockfile that looked correct here and stayed broken there — my store is warm, CI's is not. So the SDK stops carrying a test runner at all. It ships as TypeScript source to third parties and now declares only typescript plus the two workspace configs; its handshake and protocol tests move to packages/views, its only consumer in this repo, where the toolchain already exists. The lockfile delta for this whole PR is now four workspace links and a typescript pin — nothing that can resolve differently on a cold install. The tests themselves are unchanged and still fail without the guards they cover. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Lambda <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-19 01:06:25 +08:00
4 people	afd05ca221	MUL-6063: recover terminal delegated task failures (#6844) ... * fix: recover terminal delegated task failures Co-authored-by: multica-agent <[email protected]> * fix(tasks): make delegated failure recovery durable Co-authored-by: multica-agent <[email protected]> * fix(tasks): bound delegated failure recovery Co-authored-by: multica-agent <[email protected]> * fix(tasks): address delegated recovery review nits Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]> Co-authored-by: Sol-Boy <[email protected]>	2026-08-18 15:36:10 +08:00
3 people	c3f5df8bf4	MUL-5492: fix timeline cap dropping newest entries + stop double-broadcasting descriptions (#6175) ... * fix(timeline): cap the issue timeline at the newest end and report the clamp The per-issue timeline cap was applied with ORDER BY created_at ASC LIMIT 2000, so once an issue accumulated more than 2000 comments or activities the cap discarded the NEWEST rows. The timeline appeared to stop at some point in the past and every later event was invisible, with nothing in the response indicating anything was missing. Activity is machine-paced — description autosave, every agent run, status and assignee changes all write rows — so this was reachable in normal use, not only on pathological issues. Take the window with the keyset ordering (created_at DESC, id DESC) in a subquery and re-sort ascending in the outer query. This keeps the chronological contract for every existing caller, including the comment list endpoint that shares ListCommentsForIssue, and is served as an index-only scan by the idx_*_keyset indexes already added in migration 068 — no new migration, no call-site changes. Two things beyond the ordering flip: - Clamp both lists to a shared window floor. The two caps are applied independently, so each list has its own floor. Merging windows with different floors produces a timeline that looks continuous but, below the higher floor, contains only one of the two kinds — e.g. comments with no interleaved activity. That is worse than a timeline that visibly stops, because nothing about it looks wrong. Both lists are now clamped to the newest floor, so the result is a contiguous, correctly interleaved slice. - Stop truncating silently. The unpaginated response is a bare JSON array with nowhere to put a flag, so the clamp is reported via X-Timeline-Truncated and X-Timeline-Window-From, added to ExposedHeaders because a custom response header is otherwise unreadable from browser JS. The legacy wrapped shape's has_more_before is now truthful instead of hardcoded false. Queries read one row past the cap so "hit the cap" is distinguishable from "holds exactly 2000 rows", which would otherwise report a complete timeline as truncated and drag the other list's window down with it. Regression tests cover all four properties and were confirmed to fail against both the original query and a floor-less DESC flip. Co-authored-by: multica-agent <[email protected]> * perf(realtime): stop broadcasting two full descriptions on issue:updated issue:updated carried prev_description alongside the new description in the issue object, and the WS forwarder reuses the producer's payload map verbatim. Every debounced description autosave therefore pushed two full copies of the description to every connection in the workspace, including users who did not have the issue open. The DB write is O(1); the fanout was O(connections x description size), and it repeats on every pause in an editing session. prev_description and prev_title exist only for in-process listeners — subscriber_listeners adds newly @mentioned users, notification_listeners builds mention notifications, activity_listeners records the title change. No client reads them: IssueUpdatedPayload in packages/core/types/events.ts does not declare either field. Project the payload on the way out. The bus dispatches bus.Subscribe handlers before the SubscribeAll forwarder, so the in-process consumers are unaffected, and projecting at the forwarder covers both the single- node Hub and the Redis relays since that is where the frame is serialized. The producer's map is copied rather than mutated. The removed keys are listed in a table rather than an if on one event type. The bug was structural, not a typo: the next large field added to a published payload inherits the same cost silently, and a declarative list puts the internal/external payload boundary in one reviewable place. issue.description itself is deliberately kept — clients apply it to their cache, so stripping it would trade fanout bytes for N refetches. Cutting the remaining fanout needs the per-issue scope routing already scaffolded server-side for MUL-1138, which is blocked on the client sending subscribe frames. Tests assert both halves: the keys are absent from the serialized frame, and the in-process listener still receives them. Co-authored-by: multica-agent <[email protected]> * fix(timeline): keep comment threads whole under the newest-N cap Review found that the newest-N window can orphan a reply, and an orphaned reply is invisible rather than merely mis-nested: the timeline builds its top level from "activities + comments with no parent_id" and renders replies by looking them up under their parent, so an orphan sits in the map with no card to render it. MUL-1847 / #2263 was exactly this shape — 1 root + 29 replies, root dropped, all 29 vanished from the UI while the API returned them. Root cause of the regression: capping with the OLDEST n could never orphan anything, because a reply is always newer than its parent, so a prefix of the timeline is closed under "parent of". A newest-n window is a suffix and has no such property. Flipping which end the cap bites silently invalidated a structural property the comment tree relies on. Two changes. Drop the cross-kind clamp. The previous revision trimmed both lists to a shared floor so the window was provably contiguous. That was the wrong trade and it was also the dominant source of orphans. Comments are human-paced (p99 ~30, max ever observed ~1.1k) and essentially never reach the cap, while activity is machine-paced and reaches it routinely — so the shared floor was almost always the activity floor deleting comments that had been fetched successfully and would have rendered fine. On an issue with thirty comments it was pure loss. Each list now reports its own truncation and X-Timeline-Truncated names which kinds were affected. Not clamping costs only activity density in the older part of the range, which is metadata rather than content, and it is reported rather than hidden. Complete parent chains for the case that remains — comments themselves exceeding the cap. ListMissingAncestorComments walks parent_id upward via a recursive CTE and returns the ancestors not already held; the handler merges them and restores the ascending order. This only ever ADDS rows, so unlike clamping it cannot hide anything the caller would have seen, and it is bounded by the number of distinct missing ancestors. Whole- thread windowing was considered and rejected: a single thread can exceed any row budget, so its degradation is not definable. Applied to the shared query's default list path too, not just the timeline. foldResolvedThreads documents a COMPLETE-thread set as its precondition and comment.go asserts the default list mode satisfies it; a half thread made that assertion false and a resolved thread whose root was cut stopped folding correctly. Also drops X-Timeline-Window-From. It was second-precision RFC3339 while the real ordering key is (created_at, id) at full precision, so it could not resume a read without skipping or repeating rows inside a shared second. A resumable cursor should be opaque and carry both halves; worth designing when there is a consumer rather than shipping as a lossy approximation. Tests: the reviewer's exact scenario, plus a no-orphaned-replies invariant on both endpoints, the fold-still-works case, and a guard that activity truncation does not delete comments. Each was confirmed to fail with the fix disabled. TestListTimeline_JointWindowHasNoOneSidedRegion was rewritten rather than deleted — it pinned the clamp behaviour being abandoned here, so leaving it would lock in the wrong contract and deleting it would drop the coverage. Co-authored-by: multica-agent <[email protected]> * fix(comments): bound parent-chain completion and stop folding partial threads Second review round on MUL-5492. Four must-fixes, all stemming from one conflation: parent-chain closure, a newest-N window, and a complete thread are three different things. Closure makes a reply renderable; it does not license thread-level derivations. Do not fold a truncated read. fetchCommentsForList closes parent chains, but older siblings and descendants of a retained reply stay outside the window, so the set holds partial threads. Folding them produced wrong answers rather than incomplete ones: a resolution reply outside the window made a resolved thread look unresolved, and folded_count reported a total derived only from retained replies. The previous revision claimed closure restored foldResolvedThreads' COMPLETE-thread precondition; it did not, and that claim is removed. --recent and untailed --thread still return whole threads and still fold. Bound the walk. The recursive CTE climbed to the root with no depth limit, so a deep chain could drag its entire ancestry back and defeat the row cap it was meant to preserve. Depth is genuinely unbounded in stored data: the general write path stores the exact comment being replied to (only the agent path collapses to the thread root), so chains can run far deeper than the two levels the UI renders. Replaced with a layered walk under explicit budgets — 2000 extra rows, 64 levels — making a response provably bounded by 4000 comments, or 6000 timeline entries with activities. Scope every level to the tenant. The CTE's recursive branch matched on parent_id alone. parent_id carries a foreign key to comment(id) but not to a matching issue, so a stray cross-issue parent reference is representable, and the walk would have followed it into another issue's comments. The replacement filters issue_id and workspace_id on every level. A negative test confirms the leak: with the filter removed it reports "a comment from another issue leaked into this issue's response". Degrade by pruning, not by orphaning. When a budget is exhausted, a parent row is missing, or a parent is out of scope, keepRootConnected drops the affected comments instead of returning replies the UI cannot render. Dropping a node also drops its descendants, since their chains run through it. Returning fewer new replies is conservative and already signalled as a truncated read; leaking another tenant's data, returning an unbounded response, or emitting invisible orphans are all worse. Also: probe read on the comment list so exactly-2000 is not misreported as truncated, which would needlessly suppress the fold; CommentsTruncated is carried on fetchCommentsResult rather than inferred from the result length, which is meaningless once completion adds rows. The new query returns db.Comment directly instead of a hand-copied row, which is how quick_action_id came to be dropped after the rebase — a backfilled quick-action root would have rendered as a raw prompt. Corrected three inaccurate comments: the "index-only scan" claim (the index avoids the sort but does not cover SELECT *), the "write path collapses replies to root" claim, and a test header still describing the abandoned contiguous-window behaviour. Tests cover exactly-at-cap still folding, truncated reads not folding (both reply-resolved and root-resolved), depth beyond budget pruned not orphaned, shared ancestors fetched once, cross-issue parents never crossing the boundary, and quick_action_id surviving backfill. Each was confirmed to fail with its specific fix disabled; the reply-resolved fold test was reshaped after the first version passed for the wrong reason. Co-authored-by: multica-agent <[email protected]> * fix(timeline): preserve complete threads under comment cap Co-authored-by: multica-agent <[email protected]> * fix(comments): preserve newest bounded views Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-31 14:40:16 +08:00
3 people	5e3b7a8c37	feat(issues): Issue Quick Actions — preset agent + prompt, one-click from the sidebar (MUL-5465) (#6132) ... * feat(issues): Issue Quick Actions — preset agent + prompt, one-click from the sidebar (MUL-5465) Preset "who to call and what to say" once in Settings, then trigger it from any issue's sidebar with a single click. Running one is NOT a new dispatch path. The server renders the prompt, posts a `quick_action` comment carrying the target's mention markup, and hands off to the existing comment -> mention -> task trigger. Permission (canInvokeAgent), attribution, squad-leader routing, the execution log, and pending-task coalescing are inherited rather than reimplemented — the MUL-3375 lesson about four drifting copies of one trigger decision. Three things the UI has to be honest about, because the backend already decided them: - One pending task per (issue, agent) is a DB invariant (idx_one_pending_task_per_issue_agent). A second click against a busy agent starts no new run; the comment merges into the pending task. The toast says "Added to Lambda's current run", not "Lambda started working". - An offline target defers rather than fails; the run reuses the existing dispatch.ReasonCode vocabulary instead of inventing one. - Private agents are deny-by-default with no admin bypass. The sidebar filters by the caller's own invoke verdict, so a dead button is never rendered, and a direct API call still 403s with `invocation_not_allowed`. Visibility is DERIVED from the bound agent's permission_mode on every request, never stored — so it cannot drift after someone flips an agent between private and public_to. Binding a workspace action to a private agent is allowed (the alternative pressures people into making agents public just to satisfy a config constraint) but the settings form says so at bind time, and the catalog badges it. The target's name is withheld from callers who cannot see it, so the response never discloses a private agent's existence. Prompt templating is flat substitution over a closed whitelist. No conditionals, loops, or filters — the agent already reads the whole issue, so natural language is the control flow. One optional runtime input ({{input}}) keeps a single action from splitting into five near-identical variants; both directions of the input/{{input}} agreement are rejected at write time so a typo can never land silently. Surfaces: sidebar (top 5, rest behind More), the `/` menu in the comment composer (inserts the server-rendered body to edit before sending), and Alt-click for the same hand-off from the sidebar. Migrations 234-236: quick_action table, its listing index (CONCURRENTLY, own file), and comment.type + comment.quick_action_id. Co-authored-by: multica-agent <[email protected]> * refactor(issues): simplify quick action permissions to a stored public/private intent (MUL-5465) Replaces the derived four-value visibility model with a two-value choice made at creation, and collapses permission handling to a single check. The old model computed visibility per request from the bound agent's permission_mode and used it to filter the sidebar. That filtering was the problem: two people on one issue saw different sidebars with nothing to explain the difference, which is harder to debug than a button that tells you why it refused. It also required the list endpoint to run an invocation-target query per action per request. Now: - `visibility` is stored INTENT — 'public' or 'private' — chosen up front. - A public action must bind a target every workspace member can invoke (public_to carrying a workspace target), enforced at write time. So a public action is runnable by construction and dead buttons are eliminated at the source rather than filtered out later. - A private action allows any target and is returned only to its creator. That scoping is what the field MEANS, not a permission check. - Permission is checked in exactly one place: RunQuickAction. A refusal is a structured 403 the client renders as one dialog. The dialog does not distinguish "no permission" from "the binding drifted" — the person reading it takes the same next step either way, and the person who can fix it looks at settings. Removed: can_run, position + manual ordering (settings sorted by usage while the sidebar sorted by position — one list, two orders), the derived visibility_broken flag, the runnable_only projection and its second cache entry, target_name redaction, the alt-click composer hand-off (the `/` menu covers insert-then-edit and is discoverable), and the sidebar_limit response field (now a shared constant). Ordering is use_count DESC everywhere. Settings shows the target's current reachability as plain metadata ("Nova · private"), so a public action pointing at a now-private agent reads as visibly wrong without a bespoke error state. The tradeoff — no active signal when that drift happens — was accepted deliberately: drift is rare and the failure is loud at click time. Migration 234 is edited in place rather than layered, since the PR is unmerged and the table has never been deployed. Co-authored-by: multica-agent <[email protected]> * refactor(issues): drop quick action variables and runtime input (MUL-5465) V1 ships a preset prompt sent verbatim, triggered from the sidebar or the `/` slash command. Two features are removed and one guard is kept. Runtime input goes because `/` already covers it. Typing `/code review` drops the rendered body into the composer, where any part of it can be edited before sending — strictly more flexible than one fixed field, and the field was specified before `/` was in V1. Two UIs for one need. Variables go because none of them passed their own test. The rule was that a variable earns its place only if it changes what the agent ATTENDS TO, not what it KNOWS. Checked one by one — {{issue.title}}, {{issue.identifier}}, {{issue.url}}, {{user.name}}, {{date}} — the agent already has every one from the issue context and from the fact that the comment is authored by the person who triggered it. They were inherited from autopilot's title template rather than justified. The REJECTION survives the feature: any `{{...}}` is refused at write time, naming the offending token. Someone carrying the habit over would otherwise have `{{issue.title}}` rendered literally into an agent's instructions and never notice — the exact silent-typo failure the whitelist existed to prevent. The check is a fraction of the interpolation engine it replaces and keeps the door open to enabling variables later without touching stored data. Removed: 4 columns (input_enabled/label/placeholder/required), renderQuickActionPrompt + the variable whitelist + quickActionIssueURL, the two-way {{input}} agreement logic, the run/render `input` parameter, the variable insert chips, the entire "Ask for input on click" block, and the sidebar's Popover branch — every row is now a plain button. The settings dialog drops from six field groups to four. Migration 234 is edited in place rather than layered, since the PR is unmerged and the table has never been deployed. Co-authored-by: multica-agent <[email protected]> * refactor(settings): align Quick Actions with the Labels/Properties list, then fix what the UI review found (MUL-5465) The tab used a bespoke card list while its two siblings — Labels and Properties — share one table layout. These three are the workspace's catalog of small named things and should read as one surface, so Quick Actions now uses the same structure: search + primary action row, bordered card, responsive column grid that collapses to stacked rows under `md`, and an overflow menu instead of a row of icon buttons. Columns are Name / Runs as / Who / Used / Updated. The tab joins the max-w-5xl group for the same reason. A UI review pass over the result found five things, four of which are fixed here: - The visibility chooser communicated selection through border and background only, so a screen reader announced both options identically. Added aria-pressed. - The editor dialog was max-w-xl while both siblings use sm:max-w-lg, and the unprefixed cap applied at every breakpoint. - The empty-state hint diverged from the Properties tab it was copied from (text-sm and no max width vs mx-auto max-w-sm text-xs). - Two hardcoded `text-amber-600 dark:text-amber-400` usages replaced with the `text-warning` semantic token, per the repo's design-token rule. Also fixed a signal-quality bug the review surfaced: the usage column highlighted anything with use_count 0, so an action was flagged the instant it was created. Staleness now means "has had time to be used and wasn't" — 90 days since last use, or 90 days since creation for one never used. Not fixed here: the overflow trigger is size-7 (28px), under the 44px touch floor. Labels and Properties use the identical size, so changing only this tab would break the consistency this commit exists to create; it needs one pass across all three. Co-authored-by: multica-agent <[email protected]> * fix(issues): drop the quick_action comment type, widen the mention guard, harden the slash race (MUL-5465) Second review round on PR #6132. All four remaining findings. **Comment type removed entirely (#2 blocker + #3).** Adding a `quick_action` type meant dropping and re-adding comment_type_check, and re-adding a CHECK holds ACCESS EXCLUSIVE on `comment` for a full table scan — a read/write stall on one of the hottest tables in the product, every deploy. It was also forgeable: `type` is client-supplied on POST /comments, so any member could post type='quick_action' and have an ordinary comment render as an action audit record with its body collapsed out of view. Both go away by not having the type. A quick action now posts an ORDINARY comment marked with `quick_action_id`, and the collapsed card keys off that id. There is no request field for it, so the marker cannot be forged, and the migration is a bare nullable ADD COLUMN — metadata-only and instant. Verified against a fresh database: comment_type_check is untouched. The generic comment endpoint now also validates `type` instead of letting the DB CHECK reject it. An unknown type surfaced as a 500 on a constraint violation, which reads as a server fault for plainly bad input; it is a 400 now. `status_change` and `system` are excluded from what a client may author — claiming those would be forging system narration. **Member mentions rejected too (#1).** The first pass allowed `mention://member/...` in prompts on the reasoning that it "only renders a link". That was wrong: notification_listeners.go adds member mentions to the recipient set and creates an inbox item, so a saved prompt pinged that person on every single click. Only `mention://issue/...` reaches nobody and stays allowed. **Slash race, properly this time (#4).** The previous fix checked only that the range still started with "/". Rewriting `/review` into `/fix` while the request was open passed that check, and the stale response overwrote the new command. The exact original text is now captured and compared; if the command was edited, moved, or removed, the pick is abandoned rather than inserted somewhere wrong. Adds the three regression tests the review asked for: delayed resolve, rejection, and edit-during-flight. Co-authored-by: multica-agent <[email protected]> * fix(issues): stop the quick action card repeating its own prompt, and insert the `/` body as markdown (MUL-5465) Two fixes, one reported and one found while verifying it. **The card printed the prompt twice.** The collapsed header previewed the prompt's first line, and expanding showed the mention line plus that same prompt again. The header now identifies WHICH action ran — "Code Review via Lambda" — which is both non-redundant and something the body never told you: the prompt text alone does not say which action produced it. This is what the original design called for; previewing the prompt was the implementation drifting from it. When the action cannot be resolved — deleted, or another member's private one and so absent from this viewer's catalog — the header falls back to the prompt's opening line, which is the previous behaviour. **The `/` menu inserted its body as literal text.** insertContentAt was called with a plain string, so Tiptap treated the server-rendered markdown as text rather than parsing it. The mention never became a node; it serialised back out with escaped brackets (`\[@Lambda\](mention://agent/…)`) and rendered as raw markup in the thread. Passing `contentType: "markdown"` — the same option the description editor already uses — parses it properly. Found by reading the comment rows while checking the first fix: one had escaped brackets and no quick_action_id, which is what a slash-inserted comment looked like. The existing async test now asserts the contentType, so the option cannot be dropped again without failing. Co-authored-by: multica-agent <[email protected]> * docs(issues): correct the stale quick actions sidebar comment (MUL-5465) The comment still claimed the section renders nothing when no action is runnable by the member. Permission filtering was removed several rounds ago -- the list is deliberately unfiltered and a refusal is explained at run time -- so the comment described behavior that no longer exists. Co-authored-by: multica-agent <[email protected]> * refactor(settings): cut the quick action dialog's helper copy in half (MUL-5465) The dialog had five blocks of explanatory prose around four fields, and three of them wrapped to two lines, so the form read as a paragraph with inputs in it. Each helper now earns its line or loses it: - The header explained the implementation ("keeps the same history, permissions, and execution log as an @mention") -- an architecture note the person creating an action does not need. Reduced to the one fact they do: it posts a comment. - "Who can use it" is a question, so the hints answer it as noun phrases ("Everyone in the workspace" / "Only you") instead of restating the verb. Both now fit one line, which also makes the two cards the same height -- the shorter one used to sit in dead space. - The target and prompt hints front-load the constraint rather than burying it mid-sentence. 70 words to 32 across the dialog, with no fact dropped. Field spacing goes 4 -> 5 so the gap between groups beats the gap inside one. Co-authored-by: multica-agent <[email protected]> * refactor(issues): render a quick action comment as an ordinary comment (MUL-5465) The card had a collapsed one-line header that expanded to reveal the prompt, on the theory that repeated runs of the same action would bury the discussion. That was solving a problem the feature does not have: prompts are a sentence or two, the header restated what the body already said, and the disclosure only put a click between the reader and the text. A quick action posts a real comment through the real mention path, so the honest rendering is the one every other comment gets. Drops QuickActionCommentBody, its query for the action catalog, and the now-orphaned quick_action_ran_via string in all four locales. quick_action_id stays on the comment: it is provenance, and it was never the reason the card looked different -- keying the special rendering off it is what is going away, not the record itself. Co-authored-by: multica-agent <[email protected]> * fix(settings): use the faint tone token for the empty-state icon (MUL-5465) main added apps/web/app/text-contrast.test.ts, a guard that rejects transparency standing in for a text tone. The empty-state Zap used text-muted-foreground/60, which is exactly the pattern it forbids: an alpha-dimmed tone lands at a different contrast on every surface it is composited over, so it cannot be reasoned about the way a token can. text-faint-foreground is the token the guard names for icons and glyphs. The rule arrived on main after this branch's last merge, so local runs never saw it -- CI tests the merge commit, which is why only CI caught it. Merged main first so the branch is checked against the same rules. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Lambda <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-30 21:01:48 +08:00
3 people	9961db15ed	feat(issues): bump issue updated_at when a comment is added (MUL-5009) (#5667) ... * feat(issues): bump issue updated_at when a comment is added (MUL-5009) A new comment now counts as activity on its issue and advances updated_at, so the "Updated date" Kanban/list sort surfaces recently-discussed cards — not only cards whose status changed. Applies to all three comment-creation paths (user/agent HTTP, agent task delivery, and the child-done system comment) via a best-effort TouchIssue query. The bump never fails an already- persisted comment; it self-heals on the next activity if it errors. Co-authored-by: multica-agent <[email protected]> * fix(issues): make comment updated_at bump atomic (MUL-5009 review) Address Elon's review. Move the updated_at bump into CreateComment as a leading data-modifying CTE so the comment insert and the timestamp bump commit or roll back together — closing the non-atomic window where a comment could persist while updated_at stayed stale. That window also skewed the daemon GC TTL, which reads issue.updated_at to reclaim done/cancelled workdirs. Centralizing the bump in the query drops the three per-caller TouchIssue calls and guarantees any future comment entrypoint inherits it. Also refresh the now-stale gc.go / gc_test.go comments that asserted 'CreateComment does not bump issue.updated_at'. Co-authored-by: multica-agent <[email protected]> * fix(issues): make comment/issue workspace match a query-level guarantee (MUL-5009 nit2) The touch CTE now RETURNING id, workspace_id and the INSERT SELECTs from it, so the comment insert depends on the issue actually existing in the passed workspace. A mismatched (issue, workspace) pair matches 0 rows in the CTE, the dependent INSERT selects nothing, and the :one query returns pgx.ErrNoRows — no mis-attributed comment is written and the issue is not touched. CreateComment is now the single carrier of the 'a comment belongs to an issue in the same workspace and always bumps it' invariant, so no future caller can break it by passing the wrong workspace. Signature unchanged; no migration or foreign key. Add TestCreateComment_WorkspaceMismatchPersistsNothing (error returned, no comment persisted, updated_at unchanged). Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Bohan-J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-20 15:38:31 +08:00
3 people	69744241e8	fix(comment): restore autopilot @mention delegation authority (MUL-4857) (#5512) ... * fix(comment): restore autopilot @mention delegation authority (MUL-4857) A schedule/webhook autopilot run is unattributed by design (no top-of-chain human originator, MUL-4302). Since MUL-3963 the A2A invoke gate (canInvokeAgent) keys on that originator, so a mid-run @agent/@squad delegation on an autopilot-created issue fails closed for the DEFAULT private agent (and member-scoped public_to agents): the mention renders but no run is enqueued. The SAME autopilot's first dispatch is admitted via the autopilot creator (autopilotAdmitInvoke -> canCreatorInvokeAgent), so first-dispatch and mid-run delegation disagreed. Align them: when an unattributed agent/system-authored comment on an autopilot-origin issue reaches computeCommentAgentTriggers with no originator, fall back to the autopilot creator as the effective invoking user for the gate. The gate still runs (no unrestricted agent-to-agent bypass); it is authorization only -- the enqueued task's originator/attribution stays unattributed. Scoped to autopilot-origin issues so other unattributed chains stay fail-closed. Adds a DB-backed regression test covering: creator-owns-target admits, a non-autopilot unattributed run stays denied, and a creator without invoke rights stays denied. Co-authored-by: multica-agent <[email protected]> * fix(comment): bind autopilot @mention authority to verified task lineage (MUL-4857) Address the review's confused-deputy finding on the P0 fix. The first cut keyed the invoke-gate fallback on issue provenance + an empty originator alone (invokeAuthorityForAutopilotIssue took only the issue), so any unattributed run could borrow a stranger autopilot creator's rights merely by commenting on that autopilot's issue — and the fallback also leaked past explicit @mention into the plain-comment squad-leader path and system actors. Rework it so the autopilot-creator authority is granted ONLY when the SPEAKING task's lineage is verified against this issue: - resolve the authority separately (new AutopilotDelegationAuthorityUserID on commentTriggerComputeOptions), never by overwriting OriginatorUserID; the gate reads it through opts.effectiveInvoker() only when no human originator resolved, so attribution stays untouched; - resolve from a server-trusted speaking task — X-Task-ID on create/preview, comment.source_task_id on edit/reconcile — via autopilotDelegationAuthority, which admits only when author == task agent AND task.issue_id == this issue AND the issue is autopilot-origin, then keys on the member autopilot creator; - do NOT key on autopilot_run_id: in create_issue mode (the reported case) the leader task is enqueued through the ordinary issue-assignment path and has no autopilot_run_id — the task.issue_id == issue binding is what proves the run is part of this autopilot's work while rejecting foreign-issue runs. Tests: replace the provenance-only regression with lineage-bound coverage — verified-lineage-admits, creator-without-rights-denied, non-autopilot-denied, missing-source-task-denied, cross-issue-source-task-denied, author!=task-agent- denied — plus an end-to-end CreateComment path asserting the private worker is enqueued and the delegated run stays unattributed. Verified the fallback is load-bearing (positive + e2e fail with it disabled) and the full internal/handler package passes. Skill docs (multica-mentioning) updated to the lineage-bound contract and new helper names. Co-authored-by: multica-agent <[email protected]> * fix(comment): make autopilot @mention authority consistent across defer/edit (MUL-4857) Second review round (Elon) surfaced two must-fixes on top of the lineage binding. 1. Busy-target completion reconcile lost the authority. A delegation to a target that is already running is deferred to that target's completion reconcile (reconcileCommentsOnCompletion). That path recomputed triggers with only the (empty) originator, so an unattributed autopilot delegation's follow-up was gate-denied again and silently dropped. It now restores the delegation authority from comment.source_task_id, so the follow-up fires once the target frees up — still unattributed. 2. Edit could borrow the old authoring run's authority, and preview != save. The edit preview keyed authority on the current request task while save keyed it on the comment's original source_task_id, so an agent editing its old autopilot comment from a task on an UNRELATED issue would fail-closed in preview but reuse the old autopilot creator's authority on save (cross-issue confused-deputy, and a preview/side-effect divergence). Fix: treat source_task_id as the persisted per-action authority lineage and re-stamp it on edit to the CURRENT editing task, issue-scoped exactly like CreateComment. A cross-issue edit re-stamps it to NULL, so preview, save, AND the deferred reconcile all fail closed identically. UpdateComment query gains a source_task_id param (sqlc regen). Also locks the review-accepted behavior that effectiveInvoker() carries the autopilot-creator authority into the plain assigned-squad-leader wake (a worker's result comment on the autopilot issue can still wake the private leader). Tests: reconcile-restores-authority (owns -> one unattributed follow-up; no rights -> none); edit re-stamp (same-issue keeps authority and triggers; cross-issue clears source_task_id and fails closed); worker-result wakes private squad leader. Verified both fixes are load-bearing (each negative control reproduces the exact regression Elon described), full internal/handler + internal/service packages pass, gofmt/vet clean. Skill docs (multica-mentioning) updated. Co-authored-by: multica-agent <[email protected]> * fix(comment): clear stale task lineage on non-author comment edits (MUL-4857) An admin editing an autopilot Agent's comment previously preserved the comment's original source_task_id. The immediate save is judged on the admin's member identity and correctly fails closed, but the deferred completion-reconcile routes the comment under its original agent author and resolved the delegation authority from the stale source_task_id, resurrecting the autopilot creator's invoke authority once the busy target freed up — an admin (manage rights) could thereby trigger another owner's private agent (invoke rights). Now a content edit re-derives lineage from the edit action: only the agent author editing its own comment re-stamps source_task_id to the current editing task; every other editor (member/admin, or any non-author) clears it, so preview, save, and reconcile all fail closed. Adds a regression covering the admin-edit + busy-target path and syncs the multica-mentioning skill docs. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Bohan-J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-16 15:23:56 +08:00
3 people	bf161f2f9c	fix(tasks): preserve merged comment delivery (#5192) ... Track actual claim-time delivery, support legacy daemons, and repair comment batches across claim, retry, edit, and delete races. MUL-4348 Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-10 14:10:10 +08:00
3 people	4db1abe11d	fix(comment): compensate dropped agent→agent @mentions in completion reconcile (MUL-4304) (#5148) ... * fix(comment): compensate dropped agent→agent @mentions in completion reconcile (MUL-4304) When agent A explicitly @mentions agent B while B already has a dispatched/running task, the create-time enqueue path can only fold the comment into a QUEUED task; on a merge miss it defers to completion reconcile. But reconcileCommentsOnCompletion listed only member comments (ListMemberCommentsForIssueSince, author_type='member'), so A's agent-authored mention was never replayed and B was silently never woken — the intermittent 'agent @ agent fails to trigger' bug. Broaden the reconcile query to member+agent comments and route each under its own author_type. For an agent author, computeCommentAgentTriggers only produces triggers for explicit @agent/@squad mentions (plus the narrow assigned-squad-leader fallback), and reconcile still keeps only triggers routing to the agent that just ran — so plain agent replies never qualify and no unrelated agent is re-woken. Agent originator is resolved from the comment's source task so canInvokeAgent authorizes A2A correctly. Adds two covering tests: an agent-authored @B mention earns exactly one B follow-up; a plain agent reply (no mention) earns none. Co-authored-by: multica-agent <[email protected]> * fix(comment): address MUL-4304 review — exercise real dispatched drop + explicit-mention-only reconcile Review must-fix 1: the regression test used a 'running' task, which does not reproduce the drop (running-only is not AlreadyPending, so it takes the normal fresh-enqueue path). Rewrite it to drive the ACTUAL failure: B has a DISPATCHED task, agent A's explicit @B mention goes through the real trigger path (triggerTasksForComment), assert it is dropped at creation (0 queued follow-up), then complete B's task and assert reconcile recovers exactly 1 follow-up. Correct the 'dispatched/running' wording in daemon.go and comment.sql to 'dispatched'. Review must-fix 2: agent-authored comments on a squad-assigned issue can route to the squad leader via routeAssignedSquadLeaderFallback (a non-mention route), so 'plain reply yields nothing' was not unconditionally true. Scope reconcile's agent-comment compensation to EXPLICIT @agent/@squad mentions only (keepExplicitMentionTriggers, Source in {mention_agent, mention_squad_leader}); the squad-leader/assignee fallback and all other conversational routing are intentionally not replayed. Add a squad-assigned plain-worker-reply test proving the leader gets no completion-driven follow-up (verified failing without the filter). Update doc comments accordingly. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-09 15:02:58 +08:00
3 people	75695a2e40	fix(comments): guarantee at-least-once processing of user comments (MUL-4195) (#5068) ... * fix(comments): guarantee at-least-once processing of user comments (MUL-4195) Consecutive comments on an issue were silently dropped: a new comment that arrived while the agent already had a queued/dispatched task was discarded by the HasPendingTaskForIssueAndAgent dedup, losing the user's follow-up instruction with no visible trace. Comments — unlike chat — are deliberate, addressed, persisted input and must never vanish. This makes comment handling at-least-once while keeping concurrency bounded to one run per (issue, agent): - Merge, don't drop (PR1): a comment landing while a not-yet-started task exists is folded into that task — the prior trigger becomes a coalesced comment and the new one becomes the trigger, so a single run still covers every deliberate comment. Falls back to a fresh enqueue if the pending task was claimed mid-flight, so nothing is lost in the race. - Completion reconciliation (PR2): on task completion, a member comment newer than the run's started_at schedules exactly one follow-up via the normal trigger pipeline. Loop-safe: member-authored only, capped by the existing per-(issue,agent) dedup, and terminating. - Visibility (PR3): coalesced_comment_ids is surfaced on the task API and in the run prompt so the covered comments are explicit. Migration 145 adds agent_task_queue.coalesced_comment_ids UUID[]. Tests: merge-not-drop preserves all three of a rapid burst and repoints the trigger to the newest; reconciliation query gates on member/since; e2e CompleteTask enqueues a follow-up for a mid-run member comment and does not for none. Co-authored-by: multica-agent <[email protected]> * fix(comments): address review — originator gate, agent-scoped reconcile, cross-thread coalesced prompt (MUL-4195) Resolves GPT-Boy's Request-changes review on PR #5068. Must-fix #1 — merge no longer inherits a stale originator/runtime context. MergeCommentIntoPendingTask now only folds a comment into a pending task whose originator_user_id IS NOT DISTINCT FROM the new comment's originator. runtime_mcp_overlay / runtime_connected_apps are a pure function of (originator, agent) and the agent is fixed, so a matching originator keeps the stored overlay/attribution valid; a differing originator (e.g. user B commenting on a task originated by user A) matches no row and the caller enqueues a fresh follow-up with B's own context instead of reusing A's. trigger_summary is refreshed to the new trigger comment. Must-fix #2 — completion reconcile no longer re-wakes unrelated agents. reconcileCommentsOnCompletion computes the latest member comment's triggers and keeps ONLY the agent that just completed, instead of fanning the comment out through the full pipeline. An @-mention of agent B during agent A's run is triggered once at creation time and is no longer replayed (double-run) when A completes. Should-fix #3 — coalesced-comment prompt no longer assumes a single thread. The claim response now carries each folded comment's thread id / author / created_at / content (CoalescedCommentData); the prompt embeds them directly so the agent addresses cross-thread folded comments without the wrong "they are in the triggering thread" hint. Old servers that ship only ids fall back to an issue-wide fetch, still without the same-thread assumption. Tests: TestMergeCommentIntoPendingTask_OriginatorGate (query gate), TestCompleteTask_DoesNotReTriggerOtherAgentMentionedDuringRun (reconcile scoping), TestBuildCommentPromptCoalescedCrossThread / IDsOnlyFallback (prompt). Existing MUL-4195 suites still pass. Co-authored-by: multica-agent <[email protected]> * fix(comments): close unique-index drop + dispatched-window race in comment coalescing (MUL-4195) Second-round review follow-up on PR #5068. Must-fix #1 — originator-mismatch no longer drops the comment. The previous originator gate returned ErrNoRows on a different originator and the caller fell through to a fresh enqueue, which collided with the idx_one_pending_task_per_issue_agent unique index (one queued/dispatched task per (issue, agent)) — silently dropping the second user's comment. Replaced the gate with recompute-on-merge: MergeCommentIntoPendingTask now re-stamps originator_user_id, runtime_mcp_overlay, runtime_connected_apps and trigger_summary to the new comment's originator. A different member's comment folds into the single coalescing run carrying the latest instruction's own identity/overlay (no cross-user capability bleed, no drop, no collision). Must-fix #2 — comment arriving in the claim→StartTask window is no longer lost. Merge now targets only PRE-CLAIM states ('queued','deferred'); a dispatched/running task is never a merge target, so a post-claim comment is never falsely stamped into coalesced_comment_ids as "delivered". Completion reconcile is re-anchored on dispatched_at (the moment the claim response is built) instead of started_at, and sweeps ALL undelivered member comments since that anchor — replaying each through the normal enqueue path so they coalesce into one bounded, agent-scoped follow-up run. This covers the dispatch→start window a started_at anchor missed. Enqueue path: on a merge miss the caller no longer blindly fresh-enqueues (which could collide with a dispatched sibling); it defers to the active task's completion reconcile via HasActiveTaskForIssueAndAgent, and only fresh-enqueues when no active task exists. Tests: rewrote the query test to TestMergeCommentIntoPendingTask_RecomputesOriginatorAndSkipsDispatched; added TestConsecutiveCommentsDifferentOriginatorsFullEnqueuePath (full handler enqueue path, two distinct originators) and TestCompleteTask_ReconcilesDispatchedWindowComment (claim→start window). All existing MUL-4195 handler/cmd-server/daemon/service suites still pass. Co-authored-by: multica-agent <[email protected]> * fix(comments): catch pre-dispatch merge-race comment in completion reconcile (MUL-4195) Third-round review follow-up on PR #5068. Race: a member comment is created while the task is still queued, but its merge loses the race to the daemon claiming the task (queued→dispatched). The merge then finds no pre-claim row (ErrNoRows), the enqueue path defers to reconcile — but the comment's created_at is BEFORE dispatched_at, so the dispatched_at-anchored reconcile skipped it and the comment vanished with no task coverage. Fix: anchor completion reconcile on the task's created_at (which always precedes dispatch) instead of a dispatch/start timestamp, and exclude the run's DELIVERED SET — trigger_comment_id ∪ coalesced_comment_ids. Because merges only ever touch pre-claim rows, that set is exactly what the claim response carried, so any member comment created since the task was made that is NOT in it was genuinely undelivered and earns a bounded follow-up. This catches the pre-dispatch merge-race comment and the dispatch→start comment, while never re-firing a comment that was delivered as a pre-claim coalesced entry. Test: TestCompleteTask_ReconcilesPreDispatchMergeRaceComment reproduces the race (comment created pre-dispatch, task dispatched before merge, plus a delivered coalesced comment) and asserts exactly one follow-up, triggered by the race comment, with the delivered coalesced comment excluded. Existing reconcile fixtures updated to set a realistic created_at (the production invariant that created_at is the earliest task timestamp). Co-authored-by: multica-agent <[email protected]> * fix(comments): merge only into the queued task, never a deferred fallback (MUL-4195) Fourth-round review follow-up on PR #5068. MergeCommentIntoPendingTask targeted status IN ('queued','deferred') ordered by created_at DESC. When a (issue, agent) pair had both an older queued task (the run about to be claimed) and a newer deferred assignee-fallback task, a new comment merged into the deferred row instead of the queued one — so the comment missed the imminent run and the deferred fallback could later promote into a duplicate/conflicting run. This merge is only ever reached when HasPendingTaskForIssueAndAgent matched a queued/dispatched task (it never inspects deferred), so the coalescing target must be the queued row. Restricted the merge target to status = 'queued' (the unique index guarantees at most one). Deferred fallbacks keep their own fire_at/promotion escalation lifecycle and are never a merge target. Test: TestMergeCommentIntoPendingTask_TargetsQueuedNotDeferred seeds an older queued task + a newer deferred fallback for the same (issue, agent), merges a new comment, and asserts it lands on the queued task (trigger repointed, old trigger coalesced) while the deferred fallback is left untouched. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-09 12:48:57 +08:00
3 people	63b9b10df5	MUL-3328: add retry button for failed agent comments (#4217) ... * MUL-3328: add retry button for failed agent comments Co-authored-by: multica-agent <[email protected]> * MUL-3328: cover child-done system comments Co-authored-by: multica-agent <[email protected]> * MUL-3328: restrict retry affordance to failures Co-authored-by: multica-agent <[email protected]> * MUL-3328: clean migration whitespace Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Lambda <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-06-17 15:18:44 +02:00
3 people	34c68e1e4c	fix(comments): enforce single resolution per thread (#3984) ... A thread could hold multiple resolved comments at once: ResolveComment was a plain per-row setter that never cleared the prior resolution, and "replacing" one was a display-only illusion (deriveThreadResolution picks the max resolved_at). The stale rows stayed resolved in the DB and the optimistic update flashed the new resolution, then reverted. Make single-resolution-per-thread a write invariant: - ClearOtherThreadResolutions: thread-scoped clear via a RECURSIVE CTE (root + descendants of the target, id <> target), returns each cleared row. - ResolveComment handler runs the clear + set in one tx so the replace is atomic. It emits comment:unresolved per cleared sibling (granular realtime consumers patch a single comment in place and would otherwise keep showing the stale resolution). Target keeps its COALESCE idempotency and the re-resolve event suppression. - Frontend optimistic update mirrors the invariant: resolving clears every other resolution in the same thread, so the cache never shows two at once. Unresolve still only clears its own row. Co-authored-by: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-06-10 14:20:39 +08:00
Naiyuan Qingandmultica-agent	4ae4722ef0	fix(comments): preserve direct parent on replies (#3579) ... Co-authored-by: multica-agent <[email protected]>	2026-06-01 08:28:15 +08:00
3 people	973a43923f	fix(comments): revert since-delta to issue-wide, steer to parent thread first (#3535) ... #3509/#3523 scoped the comment-trigger since-delta count to the triggering thread, so an agent resuming a busy issue only saw "+N in this thread" and lost visibility of new comments in other threads. Revert the count to issue-wide (every thread), keeping the trigger-comment + agent-own exclusions, and reshape the warm-path hint to: - report the issue-wide new-comment volume, - steer the agent to read the triggering (parent) thread FIRST (`--thread <trigger> --since`, or `--tail 30` for full context), - demote the issue-wide `--since` catch-up to an only-if-needed fallback ("don't read them all blindly"). Also fixes the now-stale "scoped to the triggering thread" wording in the resumed-session no-delta hint (it's issue-wide zero now). Co-authored-by: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-05-29 20:13:23 +08:00
3 people	9616d78e47	MUL-2785: optimize resumed comment reads (#3509) ... * feat(comments): skip default thread read on resumed comment sessions Co-authored-by: multica-agent <[email protected]> * fix(comments): scope since delta to trigger thread Co-authored-by: multica-agent <[email protected]> * chore(comments): address thread delta review nits Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-05-29 14:57:14 +08:00
3 people	75b5be3f8e	feat(comments): roots-only thread stats + summary projection for comment list (MUL-2809) (#3505) ... * feat(comments): roots-only thread stats + summary projection for comment list Enrich the roots_only read so each root carries reply_count (recursive descendant count) and last_activity_at (MAX created_at over the subtree), letting an agent triage which thread to open without fetching any replies. Add an orthogonal summary=true projection (--summary) that clips each returned comment's content to a fixed budget and sets content_truncated, so an agent can scan a list cheaply before pulling a full body. It composes with every read mode (default, since, thread, recent, roots_only). New response fields are optional (omitempty) and only populated for the agent-facing query params, so the default response shape is unchanged for the desktop/web and existing CLI callers. Co-authored-by: multica-agent <[email protected]> * test(comments): cover roots_only + summary composition end-to-end The summary projection composing with roots_only is the spec's headline "table of contents" read, but it was only exercised at the CLI param- forwarding level — no handler test asserted that a roots_only response both clips content AND keeps reply_count / last_activity_at. A refactor moving the clip into a per-mode branch would silently break that composition with no failing test. Add TestListComments_RootsOnlySummaryComposes: a long root + a reply, read via roots_only=true&summary=true, asserting the root is clipped (content_truncated=true) while its subtree stats still surface. Co-authored-by: multica-agent <[email protected]> * refactor(comments): address review nits on roots stats + summary - ListRootComments[Since]ForIssue: scope the recursive membership walk to a selected_roots CTE (the @row_limit page, with the @since cut applied up front) so stats are only computed over the subtrees of the roots actually returned, instead of every thread in the issue. - summarizeContent: scan by rune and stop at the budget+1th rune instead of allocating a full []rune for the whole body, so a pathologically long comment costs only the budget under summary mode. Add a multi-byte (CJK) test to lock rune-boundary clipping. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-05-29 12:59:53 +08:00
Fangfei	c730e906b9	feat(cli): add roots-only issue comment listing (MUL-2805) (#3288)	2026-05-29 12:03:38 +08:00
Naiyuan QingandClaude Opus 4.8	3187bbf90c	feat(comments): re-add since-delta + cold-start thread read + parent-root write normalization (#3494) ... * feat(comments): since-delta new-comment hint + default-on comment session resume (#3432) * feat(db): add unresolved comment count + list filter queries Add CountUnresolvedComments (excludes the agent's own comments) and ListUnresolvedCommentsForIssue. Both are additive — existing callers stay on the unfiltered queries — so old clients are unaffected. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * feat(handler): support unresolved-only comment listing Wire an additive `unresolved` query param into ListComments. Defaults off so an old CLI that never sends it gets unchanged behavior; only true/1 enable it. Rejects combining unresolved with thread/recent (whole-issue filter vs navigation models). Includes filter + count query tests. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * feat(handler): plumb unresolved count + thread root into claim, gate comment resume Populate trigger_parent_id (thread root of the trigger comment) and unresolved_count (excludes the agent's own comments) on comment-triggered claim responses. Both fields are omitempty so old daemons ignore them. Gate comment-triggered session resume behind MULTICA_RESUME_COMMENT_SESSION (default off): resumed comment turns can inherit the prior turn's "Done." final message, so this stays an explicit rollout switch. The runtime-match and poisoned-session guards still apply regardless of the flag. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * feat(daemon): inject unresolved-comments hint + resolve step into agent brief Add a shared BuildUnresolvedCommentsHint helper rendered on both the per-turn prompt and the CLAUDE.md workflow (kept in sync per PR #2816). It ships only the count and the relevant CLI call — never comment bodies — so the server stays cheap. Thread case points at --thread <root>; issue case points at --unresolved. Suppressed when the count is 0. Also add a workflow step telling the agent to `multica comment resolve <thread-root>` once a thread is fully handled, so the unresolved set converges. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * feat(cli): add comment list --unresolved and comment resolve command Add an --unresolved filter to `issue comment list` (wired to the server's unresolved param, rejected when combined with --thread/--recent) and a top-level `comment resolve <id>` command that POSTs to the existing /api/comments/{id}/resolve endpoint, letting an agent close threads it has fully handled. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * refactor(comments): since-delta new-comment hint + default-on comment resume Simplifies the comment-triggered agent flow down to what's actually needed: - New-comment awareness is now a pure time delta: the claim response carries new_comment_count + new_comments_since (anchored on the prior run's started_at, never completed_at so a long run can't miss comments). The per-turn prompt and CLAUDE.md workflow render one line — "N new comment(s) since your last run, --since <ts>" — via a shared BuildNewCommentsHint so the two surfaces can't drift. Cold start (no prior run) falls back to a plain read. - Comment-triggered tasks resume the prior session by default (same runtime), dropping the MULTICA_RESUME_COMMENT_SESSION rollout gate. The "Focus on THIS comment" prompt guard defends against inheriting the prior turn's "Done." marker; GetLastTaskSession still excludes poisoned sessions. - Drops the resolved-based machinery from the first draft: CountUnresolvedComments / ListUnresolvedCommentsForIssue queries, the `comment list --unresolved` flag, the `multica comment resolve` command, and the resolve workflow step. - Removes the verbose cursor-pagination paragraph from the comment prompt; the --thread/--recent/--since flags stay in the CLI/API, just no longer explained inline every turn. Compatibility: new claim fields are omitempty (old daemons ignore them). Comment resume is default-on and affects even old daemons, which already consume prior_session_id. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]> * feat(comments): collapse reply parent_id to thread root on write Comment threads are a 2-level model (root + flat replies, like Linear/Slack), enforced today only by the UI and the agent path — the CreateComment handler stored whatever parent_id it was handed, and the agent-side flatten walked just one level, so a reply-to-a-reply could land at depth 3+. Add GetThreadRoot (a recursive walk to the parent_id=NULL root) and run both write paths (handler.CreateComment, service.createAgentComment) through it, so every stored reply's parent_id IS its thread root. Readers can now treat parent_id as the thread root without re-walking. The agent-drift guard still compares the raw parent_id to the trigger comment before normalization. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> * feat(comments): cold-start reads triggering thread, warm keeps --thread pointer The since-delta rework dropped the thread-first read on the COLD path: a first-time agent fell back to the flat `comment list` dump (oldest-first, cap 2000), burying the trigger's context in ancient chatter. Point cold start at the triggering conversation instead via a shared BuildColdCommentsHint (`--thread <trigger> --tail 30` + a --recent pointer for cross-thread background). On the WARM path, --since is a pure time delta and can miss the triggering thread's pre-anchor history, so BuildNewCommentsHint now also emits a --thread pointer. Both surfaces (per-turn prompt + CLAUDE.md workflow) render via the shared helpers so they cannot drift (PR #2816 rule). Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>	2026-05-29 10:38:37 +08:00
Naiyuan Qing	d90732750f	Revert "feat(comments): since-delta new-comment hint + default-on comment ses…" (#3455) ... This reverts commit 5e78e5100a.	2026-05-28 17:52:59 +08:00
Naiyuan QingandClaude Opus 4.7	5e78e5100a	feat(comments): since-delta new-comment hint + default-on comment session resume (#3432) ... * feat(db): add unresolved comment count + list filter queries Add CountUnresolvedComments (excludes the agent's own comments) and ListUnresolvedCommentsForIssue. Both are additive — existing callers stay on the unfiltered queries — so old clients are unaffected. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * feat(handler): support unresolved-only comment listing Wire an additive `unresolved` query param into ListComments. Defaults off so an old CLI that never sends it gets unchanged behavior; only true/1 enable it. Rejects combining unresolved with thread/recent (whole-issue filter vs navigation models). Includes filter + count query tests. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * feat(handler): plumb unresolved count + thread root into claim, gate comment resume Populate trigger_parent_id (thread root of the trigger comment) and unresolved_count (excludes the agent's own comments) on comment-triggered claim responses. Both fields are omitempty so old daemons ignore them. Gate comment-triggered session resume behind MULTICA_RESUME_COMMENT_SESSION (default off): resumed comment turns can inherit the prior turn's "Done." final message, so this stays an explicit rollout switch. The runtime-match and poisoned-session guards still apply regardless of the flag. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * feat(daemon): inject unresolved-comments hint + resolve step into agent brief Add a shared BuildUnresolvedCommentsHint helper rendered on both the per-turn prompt and the CLAUDE.md workflow (kept in sync per PR #2816). It ships only the count and the relevant CLI call — never comment bodies — so the server stays cheap. Thread case points at --thread <root>; issue case points at --unresolved. Suppressed when the count is 0. Also add a workflow step telling the agent to `multica comment resolve <thread-root>` once a thread is fully handled, so the unresolved set converges. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * feat(cli): add comment list --unresolved and comment resolve command Add an --unresolved filter to `issue comment list` (wired to the server's unresolved param, rejected when combined with --thread/--recent) and a top-level `comment resolve <id>` command that POSTs to the existing /api/comments/{id}/resolve endpoint, letting an agent close threads it has fully handled. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * refactor(comments): since-delta new-comment hint + default-on comment resume Simplifies the comment-triggered agent flow down to what's actually needed: - New-comment awareness is now a pure time delta: the claim response carries new_comment_count + new_comments_since (anchored on the prior run's started_at, never completed_at so a long run can't miss comments). The per-turn prompt and CLAUDE.md workflow render one line — "N new comment(s) since your last run, --since <ts>" — via a shared BuildNewCommentsHint so the two surfaces can't drift. Cold start (no prior run) falls back to a plain read. - Comment-triggered tasks resume the prior session by default (same runtime), dropping the MULTICA_RESUME_COMMENT_SESSION rollout gate. The "Focus on THIS comment" prompt guard defends against inheriting the prior turn's "Done." marker; GetLastTaskSession still excludes poisoned sessions. - Drops the resolved-based machinery from the first draft: CountUnresolvedComments / ListUnresolvedCommentsForIssue queries, the `comment list --unresolved` flag, the `multica comment resolve` command, and the resolve workflow step. - Removes the verbose cursor-pagination paragraph from the comment prompt; the --thread/--recent/--since flags stay in the CLI/API, just no longer explained inline every turn. Compatibility: new claim fields are omitempty (old daemons ignore them). Comment resume is default-on and affects even old daemons, which already consume prior_session_id. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>	2026-05-28 15:58:42 +08:00
3 people	1c91c2a3b2	security(db): scope DELETE/UpdateIssueStatus by workspace_id (defense-in-depth) (#3027) ... * fix(security): scope DELETE/UpdateIssueStatus by workspace_id Add workspace_id to the WHERE clause of DeleteIssue, DeleteComment, DeleteProject, DeleteSkill, DeleteChatSession, and UpdateIssueStatus as SQL-layer defense-in-depth. Handler loaders (loadIssueForUser / loadSkillForUser / etc.) already enforce workspace membership today, so this is not patching a known live vuln. But the tenant invariant is currently a handler-layer guarantee — a future loader bypass or a new caller skipping the loader would be silently catastrophic. Making workspace_id part of the SQL identity collapses the trust surface to the schema itself: forging a sibling-workspace UUID becomes ErrNoRows instead of a cross-tenant write. Reference: incident #1661 (util.ParseUUID silent zero UUID returning 204 on a DELETE that matched zero rows) — same class of failure, prevented at a different layer. Scope: - 5 DELETE queries: issue, comment, project, skill, chat_session - 1 simple UPDATE: UpdateIssueStatus (2 narg, no SET ordering risk) - All callers updated (handlers, service, runtime sweeper fallback) Multi-narg UPDATE queries (UpdateIssue, UpdateProject, UpdateSkill, UpdateComment, UpdateChatSession*) are deferred to a follow-up to keep this change reviewable: each needs its narg pinning shifted and per-caller verification. sqlc was regenerated by hand (no local sqlc toolchain); CI's backend job is the authoritative compile check. * test(security): add workspace_scope_guard regression test Locks in the SQL-layer tenant guard added in this PR. For each of the 6 scoped queries (DeleteIssue, DeleteComment, DeleteProject, DeleteSkill, DeleteChatSession, UpdateIssueStatus), creates the resource in workspace A, invokes the query with a foreign workspace UUID, and asserts the row is untouched (0 rows affected with no error for :exec; pgx.ErrNoRows for :one). A future refactor that drops the workspace_id arg from any of these queries will now fail loudly instead of silently regressing. Includes a sanity sub-test that the in-workspace path still mutates, so a buggy guard that returns no-op for every call would not pass. Co-Authored-By: Claude Opus 4 <[email protected]> --------- Co-authored-by: Tom Qiao <[email protected]> Co-authored-by: Claude Opus 4 <[email protected]>	2026-05-22 14:39:47 +08:00
LinYushenandmultica-agent	5bacfd9742	MUL-2526 feat: add member(user_id, workspace_id) index + upgrade sqlc to v1.31.1 (#3046) ... - Add migration 106: CREATE INDEX CONCURRENTLY on member(user_id, workspace_id) - Rewrite ListWorkspaces to drive from member table with explicit fields - Regenerate all sqlc code with v1.31.1 (intentional version upgrade) Co-authored-by: multica-agent <[email protected]>	2026-05-22 12:26:56 +08:00
Bohan Jiangandmultica-agent	7f9e4e829d	feat(comments): thread-internal --tail pagination + reply cursor (MUL-2421) (#2846) ... * feat(comments): thread-internal pagination via --tail + reply cursor (MUL-2421) Long threads inside a single issue still forced agents to read every reply once they used --thread, even after MUL-2387 fixed cross-thread noise. This adds reply-level paging so a 200-reply thread can be navigated tail-first without dragging the whole conversation into prompt context. - New SQL query ListThreadCommentsForIssuePaged: same recursive root walk as the legacy thread query, but caps reply count and supports an (created_at, id) composite cursor. Root is unconditional — even tail=0 emits it so the reader keeps the "what is this thread about" context. - Handler ListComments: parses `tail` (non-negative, ThreadTailSet flag preserves the tail=0 intent), threads it through to the paged query, and re-uses X-Multica-Next-Before / X-Multica-Next-Before-Id for the reply cursor. Cursor's meaning is now context-dependent: thread cursor under --recent, reply cursor under --thread + --tail. - CLI: new --tail flag (only valid with --thread; mutually exclusive with --recent), reply-cursor semantics for --before / --before-id when paired with --thread + --tail, stderr label flips to "Next reply cursor" so an operator copy-pasting the cursor knows which scope it scrolls. - Tests cover the new contract: tail=N keeps newest N + root, tail=0 is root-only, anchor on a nested reply still walks up, reply cursor scrolls older replies page-by-page, since combined with tail filters after the cut, and the negative-flag-combination matrix. Out of scope: prompt template update to hint at `--thread <id> --tail 30` on long threads — separate follow-up per the issue. Co-authored-by: multica-agent <[email protected]> * fix(comments): only emit reply cursor when older reply exists (MUL-2421) The thread-tail path emitted `X-Multica-Next-Before` whenever the page filled to exactly the requested reply count, even when there was nothing older to scroll to. So `--thread <root> --tail 3` on a thread with exactly 3 replies sent a cursor that, when followed, returned just the root — a wasted round-trip that surfaced as a phantom "older replies" affordance in the agent prompt. Switch to a `reply_limit + 1` probe: ask the SQL for one extra row, trim the oldest overflow before responding, and only emit the cursor when an older reply actually existed. The exact-boundary case (replyCount == tail with no overflow) now returns no cursor. Also documents `--thread/--tail/--recent/--before` and the cursor semantics in CLI_AND_DAEMON.md, which was the second must-fix in the MUL-2421 review. Co-authored-by: multica-agent <[email protected]> * fix(comments): suppress reply cursor when --since covers older replies (MUL-2421) In the thread + tail + since path the server still emitted a reply cursor whenever there was an older reply on disk, regardless of `since`. If the oldest retained reply on the page was already `<= since`, every older reply was guaranteed to be filtered out too, so the next page only ever returned the root — wasting round-trips until the agent walked the whole pre-`since` history. Mirror the recent + since suppression: when `replies[0].CreatedAt <= since`, drop the cursor. Test covers the exact case from Elon's review: tail=2 overflow, body keeps a fresher reply, but the cursor target (oldest retained reply) is already past `since` — header must be empty. Co-authored-by: multica-agent <[email protected]> * feat(prompt): default comment-trigger reads to --thread --tail 30 (MUL-2421) Comment-triggered agents previously defaulted the trigger-thread read to the unbounded `--thread <id> --output json`, which dumps the full thread into the prompt — exactly the kind of context bloat MUL-2387 fixed at the cross-thread layer but never bounded inside a single thread. Use the new `--tail` flag landed earlier in this PR (server + CLI) as the default for both the per-turn prompt and the runtime-config Workflow: - `--thread <trigger-id> --tail 30 --output json` is the new default. Root is always included so "what is this about" context survives. - If 30 replies aren't enough, the prompt now spells out the reply cursor: re-feed the stderr `Next reply cursor: --before <ts> --before-id <reply-id>` pair back to walk older replies. - `--recent 20` stays as the cross-thread background fallback, with an explicit callout that the same `--before` / `--before-id` flags walk *threads* (not replies) in that mode. - Available Commands core line now surfaces `--tail N` and both stderr cursor labels so non-workflow callers also discover the flag. - `--since` callouts reflect the post-MUL-2421 combinable mode names (`--thread --tail` / `--recent`). Tests (`prompt_test.go`, `execenv_test.go`) pin the new defaults and add a regression guard against the unbounded `--thread` recipe sneaking back in. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]>	2026-05-21 13:43:15 +08:00
Bohan Jiangandmultica-agent	6f5fbb7813	feat(comments): thread-aware list with composite cursor (MUL-2340) (#2787) ... * feat(comments): thread-aware list with composite cursor (MUL-2340) Adds three optional query params to GET /api/issues/{id}/comments and the matching `multica issue comment list` flags: - `thread=<comment-uuid>` resolves the anchor to the thread root via a recursive CTE (defends against any future nested replies) and returns root + all descendants chronologically. Anchor can be any comment in the thread, root or reply. - `recent=<N>` returns the newest N comments for the issue, ordered chronologically in the response. - `before=<RFC3339>` + `before-id=<uuid>` form a composite cursor for stable pagination of `recent`. Both must be set together; a timestamp-only cursor is rejected because ties on `created_at` would let the existing `(created_at ASC, id ASC)` total order skip or duplicate rows across pages. Flag combination rules: `thread` is exclusive with `recent` and the cursor; both may combine with `since`. Server and CLI enforce the same matrix; the CLI fails fast locally so callers don't pay for a 400 round-trip. Default behaviour (no params) is unchanged — full chronological dump capped at commentHardCap — so the desktop UI and existing `--since` polling are untouched. Agent prompt updates land in a follow-up PR so the new CLI capabilities ship and bake first. Co-authored-by: multica-agent <[email protected]> * fix(comments): reject cursor without recent and align CLI/server on invalid --recent (MUL-2340) Elon's PR #2787 second review flagged two gaps in the flag combination matrix: - server: GET /comments?before=...&before_id=... without `recent` was silently dropped by fetchCommentsForList (RecentN=0 fell through to the default / since path), so callers got the full timeline instead of the documented "before X" semantics. Now returns 400. - CLI: --recent 0 / --recent -3 were collapsed with "flag not passed" by `recent > 0`, so an explicit invalid value silently fell back to the default list. Switched to Flags().Changed("recent") so explicit non-positive values fail loudly. Also enforces that --before / --before-id only appear with explicit --recent (mirrors the new server-side rule). Tests: - server flag matrix gains `before + before_id without recent → 400`. - CLI gains TestRunIssueCommentListFlagGuards covering `--recent 0`, `--recent -3`, cursor-without-recent, and the thread/recent exclusivity path under the new Changed()-based check. The mock server fatals if a request reaches /comments, proving the guards fire before any HTTP round-trip. Co-authored-by: multica-agent <[email protected]> * feat(comments): make `recent` thread-grouped with a thread cursor (MUL-2340) Bohan pushed back on the row-based `recent=N` shape: comments form a tree, not a list, and the newest N rows can come from N unrelated threads, giving the agent N disjoint conversational tails. Replace the row-based query with a thread-grouped one before #2787 merges so we never ship the wrong shape: - `recent=N` now returns the N most recently active threads (root + every descendant per thread). A thread's recency is MAX(created_at) across its whole subtree, so a stale-but-recently-replied thread outranks an old quiet one — exactly the property row-recent loses. - The cursor is now a *thread* cursor: `before` = a thread's last_activity_at, `before_id` = its root comment id. The pair walks threads strictly less recent than the page's oldest-active thread. The cursor surfaces via `X-Multica-Next-Before` / `X-Multica-Next-Before-Id` response headers (empty when there are no older threads); the CLI forwards the same pair to stderr after listing. - Row-based `recent` is gone — there is no internal caller and the prompt update has not shipped yet, so there is no compat surface to preserve. - Response body shape unchanged (flat JSON array, chronological). Default and `--since` paths untouched. Desktop UI keeps working. Tests: - recent=1 returns the freshest-active thread fully; recent=2 returns both with the older-active thread first (oldest-active → freshest tail). - Stale-but-fresh: a thread whose root is older but has a fresh reply outranks a thread whose root is newer but quiet. - Cursor headers emitted only on full pages; empty on the final page. - Pagination walks threads root2 → root1 → empty, no skips/duplicates. - Tie-break: three threads sharing last_activity_at paginate one-at-a-time using (last_activity_at, root_id) ordering — verifies the timestamp-only cursor failure mode is fixed for the thread case too. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]>	2026-05-18 19:28:26 +08:00
Bohan Jiangandmultica-agent	3f20999597	refactor(timeline): drop server-side comment + timeline pagination (#2322) ... * refactor(timeline): drop server-side comment + timeline pagination (MUL-1929) The cursor-paginated /timeline and /comments endpoints were sized for a problem the data shape doesn't have: prod p99 is ~30 comments per issue and the all-time max is ~1.1k. Time-based pagination also splits reply threads across page boundaries (orphan replies), which the frontend was papering over with an "orphan rescue" that promoted disconnected replies to top-level — confusing UX with no real benefit. Replace both endpoints with a single full-issue fetch, capped server-side at 2000 rows as a defensive safety net (never hit in practice). Server - /api/issues/:id/timeline now returns a flat ASC TimelineEntry[] (matches the legacy desktop contract — older Multica.app builds keep working because the wrapped TimelineResponse + cursors are gone, and the raw array shape was always what they consumed). - /api/issues/:id/comments drops limit/offset; only ?since is honoured for the CLI agent-polling flow. - Drop ListCommentsBefore/After/Latest, ListActivitiesBefore/After/Latest and the timelineCursor encoding. - Replace with ListCommentsForIssue / ListCommentsSinceForIssue / ListActivitiesForIssue (capped by argument). CLI - multica issue comment list drops --limit / --offset and the X-Total-Count reporting; --since is preserved for incremental polling. Frontend - Replace useInfiniteQuery with useQuery in useIssueTimeline; drop fetchOlder/Newer, jumpToLatest, isAtLatest, newEntriesBelowCount. - Remove timeline-cache helpers (mapAllEntries / filterAllEntries / prependToLatestPage) and the TimelinePage / TimelinePageParam types. - WS event handlers update the single flat-array cache directly. - Drop the orphan-reply rescue in issue-detail — every reply's parent is now guaranteed to be in the same array. - Strip the "show older / show newer / jump to latest" buttons and their i18n strings. Co-authored-by: multica-agent <[email protected]> * fix(timeline): address review feedback on pagination removal Three issues caught in PR #2322 review: 1. /timeline broke for stale clients between #2128 and this PR. They send ?limit/?before/?after/?around and parse with the wrapped TimelinePageSchema; the new flat-array response was failing schema validation and falling back to an empty timeline. Restore the wrapped shape on those query params (DESC entries, null cursors, has_more_*=false), keeping the flat ASC array for bare requests. Around-mode now also fills target_index from the merged slice so legacy clients can still scroll-to-anchor without a follow-up. 2. The agent prompts in runtime_config.go and prompt.go still told agents that `multica issue comment list` accepts --limit/--offset and to use `--limit 30` on truncated output. With those flags removed in this PR, new agent runs would hit "unknown flag" or skip context. Update the prompt copy to "returns all comments, capped at 2000; --since for incremental polling". 3. useCreateComment's onSuccess was a bare append to the timeline cache with no id-dedupe, so a fast comment:created WS event firing before onSuccess produced a transient duplicate. Restore the id guard the old prependToLatestPage helper used to provide. Adds two new boundary tests: - TestListTimeline_LegacyWrappedShape_OnPaginationParams - TestListTimeline_LegacyWrappedShape_AroundFillsTargetIndex Co-authored-by: multica-agent <[email protected]> * test(handler): fix timeline test assertions for handler-package isolation The TestListTimeline_* assertions assumed CreateIssue would seed an "issue_created" activity_log row, but the activity listener that publishes those rows is registered in cmd/server/main.go — handler-package tests don't wire it up. CI saw 5 entries (3 comments + 2 activities) where the test expected ≥6. Drop the auto-activity assumption: assert exactly 5 entries in TestListTimeline_MergesCommentsAndActivities, and tighten TestListTimeline_EmptyIssue to assert a fully-empty timeline. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]>	2026-05-09 16:11:58 +08:00
Jiayuan Zhangandmultica-agent	3b3be9d7bd	feat(comments): resolve threads with collapsible bar (MUL-1895) (#2300) ... * feat(comments): resolve threads with collapsible bar (MUL-1895) Adds a Linear-style resolve action on comment thread roots. Resolved threads collapse to a single "N resolved comments from X" bar in the activity feed; clicking expands the thread inline (per-session, not persisted). Replying inside a resolved thread auto-unresolves it. Backend - migration 069: resolved_at, resolved_by_type, resolved_by_id on comment - sqlc ResolveComment / UnresolveComment queries (idempotent via COALESCE) - POST/DELETE /api/comments/{id}/resolve handlers, root-only validation - CreateComment auto-clears resolved_at when a reply lands in a resolved thread, publishing comment:unresolved - comment:resolved / comment:unresolved events; CommentResponse and TimelineEntry both surface the new fields Frontend - Comment + TimelineEntry types extended; payloads typed; WS sync wired - useResolveComment optimistic mutation with rollback - ResolvedThreadBar component for the collapsed view - Resolve / Unresolve menu items on root comments; Collapse strip on the expanded resolved card - en + zh-Hans locale strings Co-authored-by: multica-agent <[email protected]> * fix(comments): cover agent reply path, expand-state hygiene, nested counts (MUL-1895) Addresses three review issues from Emacs on PR #2300: 1. TaskService.createAgentComment bypasses Handler.CreateComment, so the auto-unresolve wired into the handler did not fire when an agent replied in a resolved thread (task / mention / on_comment paths). Extracted the logic to TaskService.AutoUnresolveThreadOnReply so both reply paths share it; rewired Handler.CreateComment to call the new method. 2. Resolving an already-expanded thread no longer collapses it back to the bar because expandedResolved still contained the id. Added clearResolvedExpand + handleResolveToggle wrapper so resolve / unresolve always wipe the session expand entry. 3. ResolvedThreadBar received only direct children, while CommentCard's expanded view recurses through descendants. Extracted the recursive walk into thread-utils.collectThreadReplies and called from both — counts and author lists now match. Co-authored-by: multica-agent <[email protected]> * test(comments): mock useResolveComment + add zh-Hans plural key Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]>	2026-05-09 05:49:33 +02:00
Naiyuan QingandClaude Opus 4.7	ba147708a6	fix(timeline): cursor-paginated timeline to stop long-issue freeze (#1968) (#2128) ... * fix(timeline): cursor-paginated timeline to stop long-issue freeze (#1968) Opening an issue from Inbox with thousands of timeline entries used to hard-freeze the browser tab on a synchronous render of every comment + activity. The whole pipeline was unbounded: the API returned every row, TanStack Query cached the full array, and IssueDetail mounted N CommentCards (each running a full react-markdown + lowlight pipeline) in one frame. This swaps the timeline endpoint to keyset cursor pagination and rewires the frontend to useInfiniteQuery so a long issue costs the same as a short one on first paint. API: - GET /issues/:id/timeline now accepts ?before / ?after / ?around (mutex) + ?limit (default 50, max 100); response wraps entries with next/prev cursors and has_more flags. Cursors are opaque base64 (created_at, id). - ?around=<entry_id> anchors a window on the target so Inbox notifications pointing at an old comment never trigger the freeze. - New composite indexes on (issue_id, created_at DESC, id DESC) replace the redundant single-column ones so keyset queries are index-only scans. - /issues/:id/comments default branch now caps at 50 instead of returning every row unbounded; the unbounded ListComments / ListActivities sqlc queries are deleted. Frontend: - useIssueTimeline switches to useInfiniteQuery, exposes fetchOlder/fetchNewer/jumpToLatest + isAtLatest + newEntriesBelowCount. - WS handlers respect the at-latest invariant: comment/activity:created prepends to pages[0] only when the user is reading the live tail; otherwise it just bumps a counter so the UI offers a "Jump to latest" affordance without yanking scroll. - Optimistic mutations adapted to the InfiniteData shape via shared helpers (mapAllEntries / filterAllEntries / prependToLatestPage in core/issues/timeline-cache.ts) and use setQueriesData so all open windows of the same issue stay in sync. - IssueDetail Activity section gets a TimelineSkeleton placeholder during the brief load window plus subtle text-link load-more buttons matching the existing Subscribe affordance (no Button chrome). Top uses a divider for boundary clarity; bottom shows "Jump to latest · N new" weighted slightly heavier when there's unread state. - highlightCommentId now flows into the hook's around parameter so Inbox jumps fetch the surrounding 50 entries directly. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> * chore(agent): default comment list to 50 + prompt hint about long issues The CLI's "multica issue comment list" used to default to --limit 0 (meaning "fetch every comment"), which lets an agent on a long issue fill its context window with thousands of rows. The default is now 50; agents that need older history can pass --limit or --since explicitly. The local-coding-agent prompt also gains a single-line note about this in both the comment-triggered and on-assign flows so the agent knows to scope its fetches when issue size is unknown. Autopilot run-only mode is intentionally unchanged — it has no issue context to query. Co-Authored-By: Claude Opus 4.7 (1M context) <[email protected]> --------- Co-authored-by: Claude Opus 4.7 (1M context) <[email protected]>	2026-05-06 16:27:06 +08:00
Bohan Jiang	bf71802451	fix(server): trigger agent on reply in thread where agent already participated (#981) ... When a member replies in a member-started thread without @mentioning the assigned agent, the on_comment trigger was suppressed — even if the agent had already replied in that thread. This meant the common flow of "member posts → agent replies → member follows up" would not re-trigger the agent on the follow-up. Add HasAgentRepliedInThread SQL query and check it in isReplyToMemberThread so that agent participation in a thread is treated as an ongoing conversation.	2026-04-14 18:00:29 +08:00
Jiayuan ZhangandClaude Opus 4.6	b3f98ef95d	fix(server): skip auto-comment when agent already posted during task (#712) ... * fix(server): skip auto-comment when agent already posted during task In CompleteTask(), check if the agent already posted a comment on the issue since the task started. If so, skip the automatic output comment to avoid duplicates. This preserves the fallback for agents that don't post comments via CLI. Closes MUL-609 Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> * fix(server): use StartedAt instead of CreatedAt for duplicate check CreatedAt is the enqueue time, not execution start. If a previous task posted a comment between enqueue and start of the next task, it would incorrectly suppress the auto-comment for the later task. Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]> --------- Co-authored-by: Claude Opus 4.6 (1M context) <[email protected]>	2026-04-11 21:27:02 +08:00
Jiayuan	0bbc6bc1c5	feat(comments): add pagination support to comment list API and CLI ... Add --limit, --offset, and --since flags to `multica issue comment list` to prevent context window overflow when issues have many comments. The API endpoint now accepts limit, offset, and since (RFC3339) query parameters. When paginating, the response includes an X-Total-Count header with the total number of comments.	2026-04-03 23:53:00 +08:00
Naiyuan QingandClaude Opus 4.6	9ede795c5b	feat(api): strict workspace isolation + agent parity fixes ... Enforce workspace isolation at every layer: - Router: move RequireWorkspaceMember middleware to group level so ALL workspace-scoped routes (issues, agents, skills, runtimes, inbox, comments) require workspace context - SQL: add GetXxxInWorkspace queries that filter by workspace_id, eliminating cross-workspace data access at the query level - Handlers: loadXForUser functions use workspace-scoped queries, no fallback to unscoped queries - Migration 025: add workspace_id column to comment table with backfill - ListComments: add workspace_id filter for defense-in-depth Fix daemon workspace mapping: - Server returns workspace_id in task claim response (from issue) - Daemon uses task.WorkspaceID directly instead of unreliable workspaceIDForRuntime() local map lookup - Remove workspaceIDForRuntime function Fix agent/human parity: - Comment update/delete: use resolveActor for isAuthor check so agents can edit/delete their own comments - Event attribution: replace hardcoded "member" with resolveActor in agent, skill, and subscriber publish calls Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>	2026-03-30 16:49:13 +08:00
Naiyuan QingandClaude Opus 4.6	e7fe6ea79b	feat(activity): unified activity timeline with comment reply support ... Replace the comment-only list with a Linear-style unified timeline that interleaves field changes and comments chronologically. Backend: - activity_listeners.go: records field changes (status, assignee, description, task completed/failed) to activity_log table on domain events - Timeline API: GET /api/issues/{id}/timeline merges activity_log + comments sorted by created_at - Comment reply: parent_id column + handler support for threading Frontend: - Unified timeline replaces comment list: activity entries as compact muted lines, comments as Card components with reply threading - Filter toggle (All / Comments / Activity) - Reply UI: inline editor under comments with Cancel/Reply buttons - Real-time sync for activity:created + comment events - 10 new Go tests, all passing Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>	2026-03-28 21:53:08 +08:00
Jiayuan ZhangandClaude Opus 4.6	1e61c1974c	feat(server): implement full REST API with JWT auth and real-time WebSocket ... - Add HTTP handlers for issues, comments, agents, workspaces, inbox, members, and activity - Implement JWT authentication middleware with Bearer token validation - Add sqlc queries for all entities (CRUD operations) - Extract router into reusable NewRouter() for testability - Expand SDK with full API client methods (CRUD for all resources) - Add updateWorkspace to SDK, add Member type to shared types Co-Authored-By: Claude Opus 4.6 <[email protected]>	2026-03-22 11:50:03 +08:00