60 Commits

Include renames

Author	SHA1	Message	Date
5 people	da1671ca20	MUL-7420: Project workflows — columns and handoffs on the workflow (#8814) ... * feat(workflows): workspace workflows with step handoffs (MUL-7420) A workflow is a named, workspace-level selection of statuses from the shared status catalog, in board order, with an optional handoff on each step. Projects opt in through project.workflow_id; a project without one keeps the whole catalog (the implicit Default workflow), so existing workspaces see no change. - issue_workflow table + project.workflow_id, CRUD API under /api/issue-workflows, POST /api/projects/{id}/workflow with a dry-run status mapping plan. Only issues on statuses the target workflow does not list are remapped, and remapping never hands issues off. - Issue writes keep the status inside the project's workflow. Entering a step with a handler through a status change assigns the issue to that handler and starts its run with the step's brief as the handoff note; an explicit assignee in the same write wins. Creating an issue starts at the workflow's starting step. - Task claims carry the issue's project workflow, and the brief renders a Project Workflow section so agents move along this project's statuses instead of the built-in ones. - Statuses a workflow lists cannot be archived. - Adoption is gated by the project_workflows_v1 flag; existing workflows keep working and projects can always switch back to Default. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(workflows): workflow settings, project picker and workflow-aware boards (MUL-7420) - Settings → Workflows (behind project_workflows_v1): the Default workflow plus named workflows, each shown as its step chain with handlers and the projects using it; an editor to pick statuses from the library, order them, mark the starting step, and set each step's handoff, instructions and next/back statuses. - Project Workflow property: switching dry-runs first and asks where issues on unlisted statuses go; nothing else moves and nothing is handed off. - A project board's columns are its workflow's steps, and each column head names who entering it hands the issue to. - Status pickers offer only the issue's workflow steps and say who each hands off to; boards refuse drops onto statuses the dragged card's workflow does not list. - New issues in a workflow project start on its starting step, with a hint naming who they will be handed to. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(workflows): name built-in steps once in the brief; roomier picker hints (MUL-7420) Built-in statuses have no stored name, so the handoff brief printed `todo` todo. Print the key alone when the name adds nothing. The status picker widens for workflow projects and shows the handoff as an arrow and name, so step names no longer truncate to one letter. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(workflows): handoff previews and a single timeline entry per handoff (MUL-7420) - GET /api/issues/{id}/workflow-handoff?status= says what moving an issue would do: who it goes to, which runs of its current agent are still active, and the brief the handler receives. Backs the confirmation. - POST /api/issue-workflows/preview-brief renders a step's brief from an unsaved workflow, for the editor's preview. - Mapping plans list the statuses that stay, so the switch dialog can say which issues are untouched. - A handoff is recorded on the status_changed activity (workflow, handler, whether a run started, the brief) instead of a separate assignee row. - The brief now reads like the one shown in the design: the workflow, the current step, its instructions, the statuses, and the commands to hand off. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(workflows): rebuild the workflow UI to the reviewed design (MUL-7420) The first cut used generic controls where the design had purpose-built ones. This brings every surface up to the mockup: - Settings → Workflows is one page: the workflows (step chain with handler avatars, handoff count, projects using it; Default first) and, below, the shared status library with each status's workflow usage. - The workflow editor is a full page instead of a dialog: draggable step cards summarising each handoff, and a panel for the selected step — swap its status, pick the handler with a segmented control and a searchable target, handoff instructions, next/back statuses, a preview of the brief the handler receives, duplicate and delete. - The project Workflow picker lists each workflow's statuses, handoffs and projects, links to settings, and always confirms the switch with what moves and what stays. - Moving an issue into a handoff step (status picker, table, board drop) asks first: who it goes from and to, a default-on option to stop the previous agent's run, and the brief. - Status pickers name the workflow and project, show each step's handler with an avatar or that the assignee stays, and explain themselves. - Boards: the handler chip in project column heads, hatched columns a dragged card cannot enter with the reason, and a drop hint naming who the card will go to. - The timeline records a handoff under its status change, with the brief the run received; the issue sidebar shows the workflow it follows. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(workflows): word a queued previous run as queued in the handoff confirm The confirm dialog said the previous agent was "still running (for N minutes)" even when its task had only been queued. Queued runs now read as queued, and the checkbox cancels them instead of stopping them. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(workflows): refuse a run's status change once the issue left its step A run decides where the issue goes next from the step it was queued for. When someone else moved the issue while the run worked, applying that decision undid their move: in the live Grok run, a PM parked NW-1 as blocked and the still-running agent moved it straight back to code review. Tasks now record the issue's status when they are queued (agent_task_queue.workflow_step, written by the task INSERTs; automatic retries keep their parent's step), and a run's own status changes move it along. In a workflow project, an agent status change from a run whose step no longer matches the issue is refused with 409 workflow_step_moved, naming where the issue is now and who moved it, so the agent stops instead of retrying. A handoff away from a squad now also stops the runs made on the squad's behalf, and stopped runs record who stopped them. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(workflows): keep every status entry point inside the issue's workflow The issue context menu listed every catalog status and applied handoff steps without the confirmation the status picker and board show, so a right-click could pick a status the workflow refuses or start an agent unasked. It now offers the workflow's steps and opens the handoff confirmation through a shared modal. One-click status actions no longer assume built-in statuses a workflow may not list: "mark done" lands on the workflow's done step (hidden when it has none), un-marking a duplicate returns to the workflow's start, and "mark duplicate" is offered only when the workflow lists cancelled. The batch toolbar offers a single project's workflow statuses when the selection sits in one project. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(workflows): keep issue wakeups consistent with workflow steps Three places where project workflows and issue wakeups met: - A wakeup run is queued when it fires, so it took the issue's status at that moment as its workflow step. A wakeup an agent registered then bypassed the stale-step refusal: parked by a PM, the issue could be moved on by the agent's "check CI, then hand to review" wakeup. It now keeps the registering run's step; a member's wakeup still starts from the issue's status. - Retries carried handoff_note only for wakeup runs, so a retried workflow handoff lost its brief. Rows with a workflow step keep it. - Switching or editing a workflow remaps statuses in bulk without the close rule, so an issue remapped into a done status kept its wakeups and pending wakeup runs. The remap now ends them like any status write. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(wakeups): don't also wake the agent a write hands the issue to A workflow handoff or an assignment already starts the receiving agent's run. If that agent also subscribed an event wakeup to the issue's status or assignee, the same write queued a second run for one fact, and workflows made such writes frequent. The write now names the agent it hands the issue to in the transaction-local multica.handed_to_agent (the new agent assignee, a squad's leader, or a step's handler even when it already owned the issue), and wakeup capture skips that agent's subscriptions for the write's issue.* events. Other agents' wakeups, and task, comment and reaction events, are captured as before. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(workflows): tell agents not to watch workflow issues with wakeups The handoff brief and the runtime's project workflow section now say that each step's handler gets a run when the issue enters the step, so wakeups on a workflow issue are for waiting on time or on something outside it, not on its status, assignee or runs. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(workflows): refresh project usage after project changes Co-authored-by: multica-agent <[email protected]> * feat(workflows): MUL-7420 split columns from per-project handoffs Workflows now only define a board's columns between a fixed head (backlog, todo) and tail (blocked, done, cancelled). Handoffs move to project.workflow_handoffs, so projects can share columns and still hand off to different people. Default becomes a real, editable row that every project without a named workflow follows. Adds project handoff, add-column (project fork or shared) and project brief preview endpoints; same-agent adjacent columns re-run the agent. Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(core): MUL-7420 project handoffs and Default workflow client model Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(views): MUL-7420 column-header handoffs and project workflow menu Board column headers set the project's handoff for that column; the project toolbar gets a workflow menu (full flow, switch, templates) and an add-column action. Views outside a project show Default's columns, with other statuses reachable through a status filter. Adds the issue flow card, create-project workflow choice, a columns-only workflow editor and a lighter status picker. Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(views): MUL-7420 wrap create-project workflow label in a menu group Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(workflows): MUL-7420 keep workflow structure in settings; no squad handoffs Projects no longer add columns or create workflows: the add-column endpoint is removed and creating a workflow is admin-only. Handoffs go to one agent, a member or the project lead; squads route work themselves, so a handoff to one is rejected, as is the issue-creator handler. Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * refactor(core): MUL-7420 drop the project add-column client Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(views): MUL-7420 simpler handoff picker and workflow editor form The handoff form is one searchable "Hand to" picker (no handoff, the project lead, an agent or a member); the next status defaults to the next column and next/back overrides sit under "More options". The workflow editor gets labelled name and description fields and shows the fixed statuses as one start and one end row. Templates move from the project menu to Settings → Workflows → New, and the project board loses its add-column action. Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * refactor(server): MUL-7420 keep handoffs on the workflow, make backlog and blocked optional Handoffs move back onto workflow steps: a workflow is the whole pipeline, and a project only picks one. The project lead stays a relative handler, so projects can still share a workflow. Handoff edits are admin-only, through the workflow write or PUT /api/issue-workflows/{id}/handoffs/{status}; the brief preview moves to the workflow too. Drops the unreleased project.workflow_handoffs migration. Todo, done and cancelled are required; backlog and blocked are optional and keep their fixed places. Without blocked, the brief points agents at the step's back status. Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> Co-authored-by: Cursor <[email protected]> * feat(views): MUL-7420 edit handoffs on the workflow, optional backlog and blocked The workflow editor sets each column's handoff in its side panel, and Backlog and Blocked switch on and off. The board's column popover and the flow panel edit the workflow's handoff, say how many projects it reaches, and are read-only for non-admins. Drops the per-project handoff client code. Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(wakeups): MUL-7420 keep platform rules on writes that hand off nobody Migration 579 skips an issue.* event for the agent a write hands the issue to. Its filter compared agent_id with the transaction's handed_to_agent setting using IS DISTINCT FROM, which is false when both are NULL. Main's platform rules (child_done) have no agent_id, so every issue.* event that handed the issue to nobody was dropped for them: a parent leaving backlog never woke its agent for sub-issues that closed meanwhile (TestChildDoneHeldWhileParentInBacklog). Rules without an agent are never the handoff target, so they always capture. Extends TestHandoffDoesNotAlsoWakeTheHandler with a platform rule on a handoff and on a plain status change; the latter fails on the old filter. Co-Authored-By: Claude Opus 5.5 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(views): MUL-7420 three-way handoff choice; quieter move confirm The handoff form picks one of three directions, as in the mockup: no handoff, hand to an agent (starts a run), or hand to a member, project lead included (assignee only). What the step does, where it goes next and the back status only reach an agent's brief, so they show and save for agent handoffs alone. The board's move confirmation keeps the agent's brief collapsed. Create project shows the workflow picker even when Default is the only workflow, with a note on where to make more. The hidden-columns panel says a board's columns come from its workflow, with a link to manage workflows for admins. Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(workflows): confirm handoff on project move, per-project handoff copy, two-pane editor (MUL-7420) - A single issue moved into a workflow project from issue detail confirms the handoff of the column it lands on; the write opts in with enter_workflow_step. Batch, API and CLI moves stay administrative. - The handoff preview takes project_id to preview such a move. - Saving a shared workflow's handoff from a board can keep the change to that project: the server copies the workflow for it and switches the project in one transaction (copy_for_project_id). - The column popover says which workflow it edits and who else uses it. - The workflow editor is a step list with a detail panel for the selected step. Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * style: gofmt workflow tests Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(views): MUL-7420 show next/back always; edit workflow name and description in place Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(views): MUL-7420 trim copy on the workflows settings page Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix: MUL-7420 keep pre-workflow behavior for workspaces that never adopt workflows The run step guard now applies only to workflows that hand off, and the standalone Statuses settings page keeps its original header. Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(views): MUL-7420 use a solid placeholder tone on the workflow header Co-authored-by: Cursor <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(workflows): keep the runtime brief cache-stable; fix project board and batch status gaps (MUL-7420) - Move the project workflow out of the runtime brief into the per-turn prompt so CLAUDE.md stays byte-identical across steps and issues. - An explicit status filter overrides the project workflow's columns; the hidden-columns panel lists statuses outside the workflow. - Batch status offers only statuses every selected workflow allows; a partial batch rolls back, refetches and warns. - setProjectWorkflow returns void instead of an unparsed body. Co-authored-by: Cursor <[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]> Co-authored-by: Lambda <[email protected]> Co-authored-by: Cursor <[email protected]>	2026-10-16 16:49:49 +08:00
xjh	a820c9a0ef	fix(task): preserve autopilot attribution after run completion (#9158)	2026-10-10 18:24:05 -07:00
3 people	f39debf8d1	MUL-7344: skip the issue read and the comment scan when the server already answered them (#8377) ... * feat(daemon): read the comment delta with one --since, not a roots scan (MUL-7344) A resumed follow-up turn whose claim carried a server-computed issue-wide comment delta was still told to run the workflow's two-step scan: a `--roots-only --summary` pass to discover which threads moved, then a `--thread ... --since ...` expansion per thread. That rediscovers, in two or more calls, an answer the server already has. `--since <anchor>` without `--thread` IS that answer. ListCommentsSinceForIssue returns every comment on the issue created after the anchor, in every thread and at every nesting level, with no folding, on the same `created_at > since` predicate CountNewCommentsSince counted with. It is a strict superset of what the roots scan could surface: roots-only `last_activity_at` is MAX(created_at) over a thread, so any comment able to move a thread's activity is already in the `--since` result. So BuildNewCommentsHint now hands over exactly one wide read and says it answers step 2's scan — the same rule BuildResumedCommentsHint already applies to a server-computed EMPTY delta. The optional second command stays a THREAD read on `--tail 30` for the reply itself; it is never the wide read, and it never combines `--thread` with `--since`, which drops the thread root. Brief step 2 and the multica-platform skill's bounded-reads rule both gain the matching static sentence, so an agent is not left choosing between the hint and two surfaces that contradict it. Cold start, dropped resume and unknown-delta paths are untouched, byte for byte: only an affirmative server report may stand in for the scan. Co-authored-by: multica-agent <[email protected]> * feat(claim): compare the issue against the last run so a resumed turn can skip the read (MUL-7344) A follow-up turn that resumes its provider session already holds the issue it read minutes ago, and was still told, unconditionally, to run `multica issue get` before doing anything. On an issue that did not move, that read returns bytes the session already has. The claim now answers the question instead. Each claim records the comparable state of the issue it built its payload from — status, assignee, priority, and sha256 of title and description — in a new `agent_task_queue.issue_snapshot` JSONB column, and compares against the snapshot the SAME agent's previous run on the SAME issue recorded. The response carries `issue_state_delta_known`, `issue_changed_fields`, and the current `issue_status` / assignee. Why a per-claim snapshot and not a `content_revision` on `issue`: a revision column has to be bumped by every writer that touches one of those five fields, and the first one missed reports "unchanged" forever with no symptom. A snapshot taken at claim time has exactly one writer. It also rides the anchor the comment delta already uses (agent_id, issue_id, started_at DESC), so both deltas on a claim mean "since your last run" in the same sense. The daemon renders one of three things, gated on a REAL resume: - unchanged → reported as workflow step 1's answer; the read survives only as "if resumed memory is not enough". - changed → the changed field NAMES plus the read, so the agent knows what to look for instead of diffing blind. - otherwise → the pre-existing instruction, byte for byte. `issue_state_delta_known` carries the same contract as `new_comments_delta_known` (MUL-6984), and for the same reason: a cold start, a missing prior snapshot, a read error, a foreign shape version and an old server all produce an empty changed-field list, identical to a genuine "nothing changed". Only the flag separates them, and only the affirmative one may stand in for the read. The compared set is named in full in the prompt rather than summarised as "the issue": labels, parent, due date, stage, project and metadata are NOT compared, and an agent told "unchanged" has to be able to see that. The snapshot write is NOT gated on the task being comment-backed — an assignment run that recorded nothing would leave the next run with no baseline. It shares the receipt's CAS, so a stale handler cannot write over a newer reclaim or after execution starts, and a snapshot that fails to encode is simply not recorded: the next run reports "not compared" and reads the issue. Co-authored-by: multica-agent <[email protected]> * fix(claim): renumber the migration past main and fold in review nits (MUL-7344) CI caught a real collision: main landed 471_comment_deleted_at through 474 while this branch was open, so 471_agent_task_issue_snapshot shared a numeric prefix and TestMigrationNumericPrefixesAreUnique failed. Renumbered to 475 after merging main; no other migration references it. Review nits from the PR review, all non-blocking, all cheap to take now: 1. Brief step 2's closing sentence told the agent that a resumed run's scan surfaces moved threads via `last_activity_at`. That is now true only on the path where the delta is UNKNOWN — when the server hands over a `--since` delta there is no scan to read it from. Rewritten to attach the `last_activity_at` guidance to the scan itself, wherever the scan happens. Done in this PR rather than deferred because this PR already moves brief bytes, so it costs no extra prompt-cache invalidation. 2. The two per-claim anchor reads are now one. GetLastTaskStartedAtForIssueAndAgent and GetLastTaskIssueSnapshotForIssueAndAgent selected the same row with the same WHERE and ORDER, differing only in projection; they are replaced by GetLastRunAnchorForIssueAndAgent returning started_at and issue_snapshot together. A comment-triggered claim is back to ONE anchor read, as before this branch. The saved round trip is the smaller half. The real gain is that "since your last run" is now a single resolved fact on a claim instead of two independently-resolved ones that could disagree. The shared read also shares a failure mode, and both consumers already degrade the same safe way: comment scan required, issue comparison unknown. 3. The hint's `%d new comment(s)` excludes the injected trigger and the agent's own comments; the `--since` read it hands over has no such filter, so the row count is legitimately higher. Narrowing the read to match would mean a second count-shaped query for no gain, so the text now states the mismatch and its direction outright instead of leaving the agent to reconcile two numbers. New test pins the merge: one claim, one prior run, both deltas resolved from that single anchor row. Co-authored-by: multica-agent <[email protected]> * fix(migrations): renumber the issue-snapshot migration to 478 (MUL-7344) main landed 475_issue_status_key_not_reserved through 477 while the previous renumber was in flight, so 475_agent_task_issue_snapshot collided in turn. Merged main again and moved to 478. TestMigrationNumericPrefixesAreUnique passes, and the full ledger applies cleanly from scratch through 478. Co-authored-by: multica-agent <[email protected]> * fix(claim): measure both deltas from the run whose session is resumed (MUL-7344) Review found a real correctness bug, not a performance one: the claim could tell a resumed agent "the issue is unchanged" while the session it handed back predated the change. Both deltas were anchored on the most recently STARTED run for (agent, issue). The session the daemon resumes is chosen by a different rule, and the two are not the same row: - GetLastTaskSession skips poisoned and retired sessions, so a newer run that died on an unprocessable conversation is passed over for an OLDER healthy one. - A manual rerun resumes the exact source task the operator clicked. So: an old session remembers description A, the user edits it to B, a newer run records B and then dies unresumable. The next follow-up resumes the OLD session but compares B against B, reports "unchanged", and the agent keeps working from a context that still says A. PriorSessionResumeUnavailable does not catch this — it flags a missing Codex rollout, which is only one of the ways the resumed session can be older than the newest run. The fix binds both deltas to the run actually being resumed. GetLastTaskSession now returns that row's started_at and issue_snapshot alongside its session, the rerun path takes them from its source task, and the delta computation moves after resume resolution so it can only ever read the adopted row. Where no session is adopted — no prior session, a session on another runtime, a forced-fresh retry, a rerun whose source failure poisoned the conversation — no delta is reported and the daemon performs the reads it always has. That makes the standalone anchor query unnecessary: the anchor is now a projection on a row the claim already fetched, so a claim reads no extra row at all (GetLastRunAnchorForIssueAndAgent is removed). The precondition is now visible in the fixtures: a prior run has to be resumable for a delta to exist, so the comment-delta tests seed a session_id. The regression test covers both paths and was verified to fail against the previous anchor — both sub-cases report an empty changed-field list, which is exactly the wrong "unchanged". Also renumbers the migration 478 → 491; main landed 478_issue_status_category_expand through 490 while the branch was open. Co-authored-by: multica-agent <[email protected]> * fix(claim): a never-started anchor row may date neither delta (MUL-7344) Final review found the last corner of the resumed-run bug. Binding the anchor to the resumed SESSION was necessary but not sufficient: GetLastTaskSession returns that session's latest TERMINAL row, and that row is not always a run that ran. A retry child can inherit the session, be claimed — which writes its snapshot — and then fail before the agent ever starts: runtime offline during prepare, cancelled while dispatched. Its snapshot describes the issue as of ITS claim, while the session's memory stops at the last run that actually executed. If the description was edited in between, the current issue matches that snapshot and the claim reports "unchanged" to an agent whose context predates the edit. The started_at gate now covers both deltas rather than only the comment one. The comment delta was already immune because it read StartedAt directly; the issue delta read only the snapshot, so it had no such guard. Hoisting the check makes the row's requirement explicit — a row that never ran dates nothing — and the inner duplicate is dropped so no reader has to wonder what each guards. Regression test reproduces the exact fixture and was verified to fail without the gate: known=true with an empty changed-field list, i.e. the false "unchanged". Also from review: - Adopt the no-adopted-session table (missing session, session on another runtime, force-fresh retry, poisoned rerun source). Each seeds a usable snapshot AND an unread comment, so a regression has something to report and the assertion cannot pass on an empty fixture. - The resumed-run regression test asserted a comment anchor that never executed: both sub-cases created only the trigger comment, which the count excludes, so NewCommentsSince was empty and the branch was dead. A comment between the two runs now makes it run and pins known/count/since. - Rewrite the migration header, which still described the old "(agent_id, issue_id, started_at DESC)" anchor and an index rationale for a column that is never a lookup key. Co-authored-by: multica-agent <[email protected]> * refactor(claim): compare title, description and status only (MUL-7344) The snapshot compared five fields. The comparison answers exactly one question — must the agent run `issue get` again? — so a field earns a place only if changing it alters what the agent does AND its current value is not already in the per-turn message. Assignee fails the second test: the claim ships the current assignee outright, and "is this mine now" is answered by that value, not by whether it moved. Priority fails the first: it is reachable only by reading the issue, but it does not change what the agent does. Both are dropped. Status stays even though it is also shipped as a current value, so comparing it is strictly redundant for "what is it now". It earns its place as a signal rather than a value: "changed: status" is the clearest evidence that somebody intervened between the runs — a push back from in_review to todo means the delivery was rejected — and it costs nothing to carry. Narrowing the set means a narrower claim, so the prompt now says "compared title, description and status". An issue whose only change is assignee or priority is reported as unchanged, which is correct and now pinned by a test that also asserts the current assignee still ships — without that second assertion the fixture's UPDATE could silently not apply and the test would pass on nothing. Snapshot version goes to 2, because the rule is that the version tracks the compared SET. No deployment has written a v1 row, but the gate is what makes narrowing safe in general: a v1 row read by v2 code is "not compared", which degrades to the unconditional read. Test fixtures now build snapshots at issueSnapshotVersion rather than a literal 1, so a future bump cannot quietly turn them into not-compared tests while they keep passing. The foreign-version case stays explicit at +1. Also renumbers the migration 491 -> 495; main landed 491 through 494 while the branch was open. Fifth renumber. Co-authored-by: multica-agent <[email protected]> * refactor(claim): keep the snapshot at v1 (MUL-7344) The previous commit bumped issueSnapshotVersion to 2 when it narrowed the compared set. That was the version rule applied past its purpose. The rule — "bump when the compared SET changes" — exists to stop a stored snapshot from being compared against a differently-shaped one. It protects DEPLOYED rows. This column is introduced by this same unmerged PR: the migration exists only on this branch, main has neither the column nor the writer, and no environment has ever stored a row with the wider set. There is nothing for the bump to protect, and shipping v2 as the first version the column has ever held would leave a reader hunting for a v1 that never existed. Back to 1. The `v` field and its unknown-version gate stay exactly as they were — those are what make a real narrowing safe later. The comment now says which version this is and why the review-time narrowing did not earn a bump, so the rule still has a stated precedent without a burned number. No behaviour change: the compared set is still title, description and status, and fixtures build at issueSnapshotVersion rather than a literal, so they followed the constant back down. Co-authored-by: multica-agent <[email protected]> * fix(claim): only a completed run may date a delta (MUL-7344) Final review found a window one step later than the never-started case. A snapshot is written at CLAIM time. The daemon then writes started_at (TaskService.StartTask) and only afterwards launches the provider. So a run can carry both a snapshot and a started_at while its prompt never reached the session: the daemon exits during prepare, the runtime drops, orphan recovery marks the row failed. Anchoring there compares the current issue against a snapshot describing an edit that session never saw — reporting "unchanged" across a real change, and dating the comment delta late enough to hide every comment older than that row's start. Reproduced on the real CreateRetryTask -> claim -> StartTask -> RecoverOrphanedTasksForRuntime -> follow-up claim path. Nothing on the row separates "failed after the provider ran" from "failed before it ran". session_id is inherited by CreateRetryTask at insert, so it does not mean the session was fed; started_at precedes the launch, so it does not mean the turn began. The only terminal status that PROVES delivery is 'completed' — a run cannot finish a turn it never started. So failed and cancelled sources now date neither delta. Their SESSION is still resumed exactly as before, and GetLastTaskSession still accepts them on purpose; those runs simply perform the context reads they always did. That is the cheap side of the trade: a follow-up after a failure or a stop is already recovering from something, while the case the optimization exists for — an ordinary follow-up after a healthy run — is untouched. Both conditions now live in newResumedRunAnchor rather than at the use site, so "which run may date a delta" is answered once, and GetLastTaskSession carries the status needed to answer it. Regression test is the reviewer's repro, verified to fail without the rule: known=true with an empty changed list AND a computed zero comment count, i.e. both a false "unchanged" and a false "no new comments". Also: - Renumber the migration 495 -> 499; main landed 495 through 498. Sixth renumber. - The migration's content_revision rationale named the old five-field set while arguing about hypothetical issue-row writers; it now refers to "any compared field", which is what the argument actually depends on. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-09-16 16:11:16 +08:00
3 people	5132ac99eb	MUL-7235: show cancellation actor in run history (#8249) ... * MUL-7235: show cancellation actor in run history Co-authored-by: multica-agent <[email protected]> * fix(issues): simplify failed run recovery UI Co-authored-by: multica-agent <[email protected]> * Revert "fix(issues): simplify failed run recovery UI" This reverts commit 1b337bbe46. Co-authored-by: multica-agent <[email protected]> * fix(tasks): keep cancellation attribution consistent Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Lambda <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-09-10 21:24:35 +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
3 people	765321f053	MUL-6951 fix(autopilot): carry the trigger creator's authorization on scheduled runs (#7918) ... * fix(autopilot): carry the trigger owner's authorization on scheduled runs A schedule/webhook autopilot run left originator_user_id NULL, so canInvokeAgent saw no human and fail-closed against private agents. Arming a trigger is the same authorizing act as clicking "run now" — deferred, not absent — so withholding the originator did not remove that authority. It only forced every capability the automation legitimately needed to arrive as a separately-bounded borrow path: MUL-4857 for child creation, MUL-6691 for the run's own issues, #7902 for the accountable member's issues, with sub-issue dispatch queued up as the fourth. Each carries a hand-written scope that no operator can see in the UI. attribution.TriggerOwner / RuleOwner now populate UserID (the originator) instead of only the accountable side. finalizeAttribution mirrors it, so the originator == accountable invariant that migrations 190/197 enforce holds without a schema change or backfill. Both autopilot execution modes resolve through triggerOwnerAttribution, so run_only and create_issue are covered by the same two lines. This grants exactly the trigger owner's own rights — canInvokeAgent is untouched, only the principal handed to it changes — and originator_source still distinguishes a scheduled fire from a manual one in the audit trail. The borrowed-authority machinery in handler/agent_access.go is now dead for newly enqueued runs but is deliberately left in place: tasks enqueued by the previous backend are still running during a rolling deploy and carry originator NULL, and they must keep the path they were admitted under. Deleting it is a follow-up once this is deployed. Composio connected-app credentials also key on originator_user_id, so scheduled runs now receive the trigger owner's connected apps. Decoupling that from authorization was considered and explicitly deferred. Verification (real PostgreSQL 17): - internal/attribution, internal/service, internal/handler: PASS - the five attribution_stamp tests that pinned "originator stays NULL" were updated to assert the new principal, and fail against the old constructors - pre-existing, unrelated failures in internal/daemon/execenv (4 Hermes store-path tests) reproduce identically on a clean tree Co-authored-by: multica-agent <[email protected]> * refactor(autopilot): delete the borrowed-authority machinery With a scheduled run carrying its trigger owner as originator, every autopilot-shaped authority path in agent_access.go is unreachable: the invoke gate resolves a real human from the speaking task and judges it exactly as it judges that human acting directly. Removed: - autopilotTaskAssignAuthority + autopilotAssignAuthorityFromRequest (MUL-6691) - issueBoundToAutopilotTask, taskRunsAutopilotInWorkspace - autopilotDelegationAuthority and its FromRequest / FromComment resolvers (MUL-4857) - effectiveInvocationAuthorityFromRequest - assignAuthorityScope, assignScopeKind and the four scope constructors - commentTriggerComputeOptions.AutopilotDelegationAuthorityUserID + effectiveInvoker() validateAssigneePair and triggerTasksForComment lose their now-meaningless scope / delegation-authority parameters; every caller passes the run's originator instead. This also retires the fourth borrow scope #7902 proposed. CreateIssue still loads the parent issue when assigning, even though the gate no longer needs the row: it is what turns a cross-workspace or missing parent into 400 "parent issue not found" instead of a 403. Covered by a test. Two behaviour notes, both accepted: - Authority now propagates down a delegation chain, because the parent run finally has an originator to copy. Under the old design each hop had to re-borrow. This matches what a manual "run now" already did. - The old borrow path required task.Status == "running"; the originator path does not, and never did for any non-autopilot run. Task tokens are revoked at the terminal transition (TaskService, MUL-2600), so the primary guard remains; this only drops a second layer that existed solely for autopilot runs. Tests: the two suites that pinned the borrow bounds (autopilot-created-issue binding, authored-by-this-task binding) described a mechanism that no longer exists, so they collapse into one file asserting the rule that replaced them — rights / no rights / no human at all, across create-top-level, create-child, update and batch. The mention-authority suite keeps its shape; its fixture now gives the run a human, as a live run has. Verification (real PostgreSQL 17): internal/attribution, internal/service and internal/handler all PASS. Pre-existing unrelated failures in cmd/multica, internal/cli, internal/daemon and internal/daemon/execenv reproduce identically on a clean tree. Co-authored-by: multica-agent <[email protected]> * fix(autopilot): resolve one principal per dispatch and expire it with the run Addresses Elon's review of #7918. Three findings, all confirmed against the code before fixing. P1-1 — admission and the run's identity could be two different people. Automatic dispatch admitted the assignee agent as the AUTOPILOT CREATOR (canCreatorInvokeAgent) while the task took its originator from the trigger. With A owning both the autopilot and a private agent, and B owning the trigger, a dispatch was admitted as A and then executed as B — rights neither holds alone. The old suite could not see it because it called dispatchRunOnly directly, skipping admission. - autopilot_trigger gains an IMMUTABLE created_by (migration 449, best-effort backfill from published_by). published_by keeps its audit meaning and still transfers on a substantive edit; it is no longer an authorization input, because letting an editor move it silently re-authorizes the automation as that editor. Per Bohan's ruling the run always acts as the trigger CREATOR. - ResolveAutopilotTriggerPrincipal is now the single answer to "who does this run act as". Admission, the task stamp and every delegated run read it, so the fork is unrepresentable. It also binds the trigger to its autopilot (GetAutopilotTriggerForAutopilot — the old lookup was WHERE id = $1, which would let a foreign trigger select the principal) and re-checks workspace membership on every dispatch, so removing a member revokes their triggers. - canCreatorInvokeAgent is now unreachable and deleted. - RuleOwner reverts to accountable-only. It is a guess at who owns a rule; promoting it would hand a legacy trigger somebody's rights without that person arming anything. Such runs carry no originator and fail closed. P1-2 — a terminal task could still spend its human's rights. invokeOriginatorFromRequest now refuses completed / failed / cancelled tasks. Token revocation at the terminal transition stays the primary guard, but it is best-effort, explicitly non-fatal on failure, with a 24h expiry behind it. The check sits at the authorization boundary rather than the auth boundary, so a finishing run can still post its final comment but cannot start new work. P1-3 — the PR and code comments described Composio backwards. BuildTaskOverlay ignores the originator entirely and builds from the AGENT OWNER's connections and allow-list (MUL-3963). Naming the originator hands out no third-party credentials. Comments corrected; no decoupling was ever needed. Operational note: a trigger with neither created_by nor published_by (predating migration 186) resolves no principal, so its autopilot stops dispatching until the trigger is re-saved. That is the intended fail-closed behaviour. Tests: full dispatch through admission for both fork directions; principal fails closed on legacy / cross-autopilot / removed-member; terminal task refused on all three statuses; the edit-transfer tests now assert the principal STAYS with the creator while published_by moves. Verified the fork test fails when admission is reverted to canCreatorInvokeAgent. Verification (real PostgreSQL 17, pristine database): internal/attribution, internal/service, internal/handler and cmd/server all PASS. Migration 449 up/down round-trips. Pre-existing unrelated failures in cmd/multica, internal/cli, internal/daemon and internal/daemon/execenv are unchanged. Co-authored-by: multica-agent <[email protected]> * fix(autopilot): bind the trigger principal to its workspace, correct stale docs Second round of Elon's review on #7918. 1. The trigger lookup only enforced half of what its comment claimed. GetAutopilotTriggerForAutopilot matched on (trigger id, autopilot id); the workspace was used only for the creator's membership check afterwards. That check proves the resolved human belongs to the workspace PASSED IN, not that the autopilot does — a member of two workspaces satisfies it while the trigger came from the other tenant. The query now joins autopilot and filters on workspace_id, and the resolver passes it through. Regression test seeds two workspaces sharing one member and asserts the foreign workspace resolves nobody; verified it fails against the pre-fix query. 2. Several permission-boundary comments still described the pre-MUL-6951 model — that a run's authority and its accountable human transfer to whoever last edited the trigger. That is now the opposite of the code, and these are the comments a future reader would use to reason about the authorization model, so they are corrected at all four sites: the trigger create site, the SetAutopilotTriggerPublisher query, triggerOwnerAttribution, and the dispatchRunOnly attribution block. published_by is described as what it now is: a config-audit column with no bearing on a run. 3. The migration comment now states the backfill's imprecision plainly: for an already-edited trigger it freezes the last recoverable EDITOR as the immutable creator, not the historical creator, which the schema never recorded. It also records that a NULL/NULL trigger has no recovery path by decision (Bohan: leave them empty) — re-saving re-stamps published_by, not created_by — so its runs stay refused with a recorded failure_reason. Not done, per Bohan's ruling: no re-save takeover path for legacy triggers and no migration-period alerting. Verification (real PostgreSQL 17, pristine database): internal/attribution, internal/service, internal/handler and cmd/server PASS; full suite shows only the four pre-existing unrelated failures (cmd/multica, internal/cli, internal/daemon, internal/daemon/execenv). go vet ./internal/... and git diff --check clean. Co-authored-by: multica-agent <[email protected]> * docs(autopilot): carry the creator-principal semantics into every description Third round of Elon's review on #7918. Two must-fixes, no behaviour change. 1. The final semantics had not reached every surface that describes them. Migration 189 wrote COMMENT ON COLUMN text for autopilot_trigger.published_by_* saying it decides the accountable human of the runs a trigger fires. That is now false, and because sqlc generates column comments into models.go, the stalest description of the authorization model sat in generated code every reader passes through. 189 is released and untouched; migration 449 overrides both comments and documents created_by_* for the first time, and sqlc is regenerated. 449's down restores 189's original text verbatim so a rollback does not leave MUL-6951 wording describing a model the database no longer runs. The same stale semantics remained in prose at six code sites — the plain and manual dispatch entry points, the scheduled-plan path, the create_issue enqueue comment, the autopilot-level republish path, and the webhook trigger create site. All said a run's authority or accountable human follows the last editor, or that automation resolves rule_owner. These sit on the authorization path, so they are corrected rather than left to drift. published_by is now described as what it is: config audit, with no bearing on a run. Also corrects the backfill comment's migration reference: trigger publishers arrived in 189, not 186. 2. The test file this PR added open-coded INSERT ... RETURNING id with matching t.Cleanup(DELETE ...), which CLAUDE.md prohibits. Rewritten onto testutil.Fixture: a small principalFixture embeds it and every row — members, runtimes, private agents, autopilots, triggers, the second workspace — is built and cleaned up by dbfx. The only remaining DELETE is the mid-test member removal that IS the behaviour under test. Re-verified after the rewrite that both regressions still fail against the old code: reverting admission to the autopilot-creator check reddens the fork test, and dropping the workspace join reddens the cross-workspace test. Verification (real PostgreSQL 17, pristine database): full suite shows only the four pre-existing unrelated failures (cmd/multica, internal/cli, internal/daemon, internal/daemon/execenv). Migration 449 up/down round-trips and the down restores 189's comments. go vet ./internal/... and git diff --check clean. Co-authored-by: multica-agent <[email protected]> * docs(autopilot): state the backfill widening plainly, drop raw-SQL test seeding Fourth round of Elon's review on #7918. Both items are leftovers from the previous round; no behaviour change. 1. Migration 449's backfill comment carried two factual errors. It said published_by_* arrived in migration 186; it was 189. The previous round intended to fix this but the string replacement did not match the wrapped line and silently did nothing, so the wrong number shipped. It also claimed the backfill "is no wider than the authority those runs carry today", which is false: before MUL-6951 an automatic run had no originator at all, only narrowly-scoped borrow paths, so promoting a backfilled editor to the run's full originator IS a widening. The product decision to accept it stands; the comment now says so directly as a compatibility tradeoff instead of denying the widening. A migration comment that understates what it grants is worse than no comment. 2. The new test file still reached raw SQL transitively. It called seedAttributionFixture, which hand-writes INSERT and cleanup for its user / workspace / member / runtime / agent — so the file's own claim that "every row goes through testutil.Fixture" was untrue and the repository's fixture rule was still unmet. It now bootstraps the base identity with Fixture.User / Workspace / Member on an unbound fixture and adopts it, which also drops the agent and issue that helper builds and these tests never use. The comment explains why the helper is deliberately not reused. Re-verified after the fixture change that both regressions still fail against the old code: reverting admission to the autopilot-creator check reddens the fork test, and dropping the workspace join reddens the cross-workspace test. Verification (real PostgreSQL 17, pristine database): full suite shows only the four pre-existing unrelated failures (cmd/multica, internal/cli, internal/daemon, internal/daemon/execenv). go vet ./internal/..., gofmt and git diff --check clean. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-09-02 18:29:11 +08:00
3 people	6cbb50378f	MUL-6680: fix autopilot list subscribers + make CLI triggers discoverable (#7552) ... * fix(autopilot): populate subscribers in the list projection (MUL-6680) GET /api/autopilots passed a nil subscriber slice to avoid an N+1, but AutopilotResponse.Subscribers has no omitempty and autopilotToResponse builds the slice with make(), so a nil input serialized as "subscribers": [] rather than being omitted. Every listed autopilot therefore claimed to have no subscribers while GET /api/autopilots/{id} reported the real ones for the same row at the same moment. A silently wrong value is harder to work around than a missing one: the key is present and reads as authoritative — the field's own doc comment promises exactly that — so callers cannot tell "none configured" from "not fetched". It was reported after costing a real misdiagnosis ("subscribers keep being cleared"). The N+1 premise was wrong: autopilot_subscriber's primary key leads with autopilot_id, so one ANY($1) batch is index-supported and needs no new index. The batch query mirrors the single-autopilot query's member join and ordering exactly, so list and detail cannot drift apart on who counts as a subscriber. Reported at https://github.com/multica-ai/multica/issues/7549 Co-authored-by: multica-agent <[email protected]> * feat(cli): make autopilot triggers discoverable (MUL-6680) trigger-update, trigger-delete and trigger-rotate-url all take a <trigger-id>, but no command listed them. The ids were reachable — the detail payload returns "triggers" as a top-level sibling of "autopilot", and the prefix resolver already reads it — yet that requires knowing the envelope shape, so in practice the reported workaround was the web UI. The prefix resolver's own miss message already told users to "run the list command", which did not exist. Add `autopilot trigger-list <autopilot-id>`, reusing the detail payload and the same webhook-credential redaction `get` applies, so ids, kind, enabled state and schedule are readable without --output json | jq. Also add NEXT_RUN to the `autopilot list` table. next_run_at has been in the list payload all along, but the table dropped it, which made a correctly scheduled autopilot indistinguishable from one with no trigger at all — the second misdiagnosis in the same report. Times render relative ("in 2h", "3d ago", "—") to stay narrow and to make "never scheduled" a visibly distinct value rather than an empty cell; LAST_RUN moves to the same format for consistency within that table. The `get` table keeps absolute timestamps — it is a single-row detail view where precision matters more than width. Reported at https://github.com/multica-ai/multica/issues/7549 Co-authored-by: multica-agent <[email protected]> * docs(cli): correct autopilot trigger documentation (MUL-6680) The trigger section claimed webhook and api kinds were "not surfaced here" because "there is no server endpoint that fires them yet". Webhook triggers have both an endpoint and CLI support (`trigger-add --kind webhook`, `trigger-rotate-url`); only the api kind is unsurfaced. Also state that `triggers` is a top-level key alongside `autopilot` rather than nested inside it — reading `.autopilot` and finding no triggers is what the report described — and document trigger-list. Co-authored-by: multica-agent <[email protected]> * fix(autopilot): fail closed when the subscriber read fails (MUL-6680) Both subscriber projections swallowed a query error and continued with an empty slice. Because subscribers has no omitempty and is documented as authoritative, that degradation serialized as "subscribers": [] on a 200 — recreating the exact defect this branch set out to remove: the caller cannot distinguish "none configured" from "read failed", and a client that round-trips the response into a full-replace PATCH would silently wipe a real subscriber list. An empty array is a claim, not an absence. Return 500 on both the list and detail paths so the failure is visible and retryable. The detail path carried this degradation before this branch; it is fixed here rather than deferred because the list/detail agreement asserted by TestListAutopilots_SubscribersMatchDetail would otherwise still break under a failed read — leaving the field untrustworthy in exactly the condition the fix is about. Addresses review feedback on #7552. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-26 01:28:35 +08:00
3 people	2aa45853d9	MUL-6640: fix stale Autopilot subscribers after member removal (#7501) ... * fix(autopilot): prune departed subscribers Co-authored-by: multica-agent <[email protected]> * fix(autopilot): serialize subscriber saves with revocation Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Sol-Boy <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-24 18:49:54 +08:00
3 people	1cc46b2697	MUL-6516 fix(channels): enforce durable context boundaries for /new (#7362) ... * fix(channels): enforce new context boundaries * fix(channels): address context boundary review findings * fix(channels): enforce causal new context boundaries * fix(channels): scope outbound provenance to target --------- Co-authored-by: Sol-Boy <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-22 11:27:39 +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
Wu Changming	7fdc854c26	fix(issues): copy durable local path for worktree tasks (MUL-6378) (#7176) ... A worktree-mode local_directory task runs in a disposable git worktree that Finalize removes on every exit path, so the task's `work_dir` pointed at a directory that no longer existed. "Copy local workdir path" handed the user a path they could not `cd` into. The daemon now reports a `durable_work_dir` handoff instead of having clients infer one: - `removeLocalWorktreeDir` returns an error and confirms removal with `Lstat`, so a broken symlink cannot be mistaken for an absent directory. Finalize fails when removal cannot be confirmed. - `durable_work_dir` is written only after Finalize succeeds and the worktree is verifiably gone. A preserved worktree, an in-place run, a running task, a squad-leader task, and any older daemon all leave it unset, keeping the real `work_dir` authoritative. - The field travels on the complete, fail, and cancel-ack callbacks and is persisted on the task row (migration 362, additive nullable column). Writes use COALESCE for replay idempotency; the cancel-ack path CASes on `status = 'cancelled'` so a late ack cannot touch a completed or failed row. - The server derives `relative_durable_work_dir` through the same home-stripping helper as `relative_work_dir`; the absolute value is reserved for explicit clipboard actions and is never rendered. - Clients select the durable path only for a terminal task that carries the field. The issue actions menu and the transcript dialog share one resolver, and the label and toast say the task worktree was reclaimed, naming the delivery branch when one exists. The stored path is a point-in-time delivery snapshot: later renames or detachments of the project resource do not rewrite historical tasks.	2026-08-20 01:30:58 +08:00
3 people	3460f9aeaf	MUL-6342: enforce entitlement-backed autopilot quotas (#7194) ... * feat(autopilot): enforce entitlement run quotas Co-authored-by: multica-agent <[email protected]> * chore(deploy): expose entitlement policy config (#7195) Co-authored-by: Sol-Boy <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(autopilot): address quota review findings Co-authored-by: multica-agent <[email protected]> * fix(autopilot): finish quota review nits Co-authored-by: multica-agent <[email protected]> * refactor(autopilot): simplify quota schema Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Sol-Boy <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-19 15:51:26 +08:00
3 people	6a17c00144	MUL-6350: rebuild the plugin system (1/4) — cleanup and foundations (#7144) ... * MUL-6350 refactor(plugins): reset the plugin system to Action / Hook / Resource foundations The V1 plugin system shipped 14 tables, an append-only revision log per relationship, a capability-snapshot compiler, a per-task execution manifest pinned by an INSERT trigger on agent_task_queue, release signing, trust tiers, and a bundled catalog — and never left its feature flag. It holds no production data, so this removes it outright instead of migrating it forward. What replaces it, per the design in MUL-6338: - A plugin relates to Multica in exactly three ways. Action (plugin calls Multica), Hook (Multica calls plugin), Resource (a static contribution with no call at all). "Who triggers" and "what capability is called" are orthogonal: a hook is declared once and lists which triggers may invoke it. - We never execute third-party code. A plugin runs only in a sandboxed iframe in the user's browser or on the author's own server. - Distribution is "install by URL, admin reads the scopes". No signature, no trust tier, no publisher verification — the scope list IS the trust decision. This change is the foundation, with no user-visible surface yet: - Decouples remote MCP first. RemoteMCPConnection/RemoteMCPTool/DigestBytes move into pkg/remotemcp, where they belonged; the protocol layer and daemon broker survive intact and dormant, ready to be rewired for the agent trigger. - Drops all 14 plugin_* tables, their triggers, the manifest-composition function, and agent_task_queue.plugin_execution_manifest_id. Adds three: plugin_installation (one row per workspace+plugin, holding the manifest snapshot the admin consented to), plugin_storage, plugin_secret. - Defines the manifest schema in full, once — surfaces, hooks with their triggers and events, resources, and a closed scope list. Parsing stays strict (DisallowUnknownFields, no trailing JSON). Contribution kinds this build does not ship yet fail installation loudly rather than installing half-working. - Two-step install: preview parses and returns the scopes without writing, then install requires consent matching the manifest exactly. Manifest fetches reuse the remote MCP SSRF guard; MULTICA_PLUGIN_DIR adds a local source for self-hosting and plugin authors. - Storage quotas are enforced on write and never by eviction. Secrets live in a separate encrypted table with no read path that returns a value. Co-authored-by: multica-agent <[email protected]> * MUL-6350 fix(migrate): register the plugin index builds for invalid-index cleanup Every migration that builds an index CONCURRENTLY must be registered in concurrentIndexCleanups, or an interrupted build leaves a permanently INVALID index that the `IF NOT EXISTS` retry records as success. TestEveryConcurrentUp\ BuildHasCleanup caught all three new plugin index migrations. Co-authored-by: multica-agent <[email protected]> * MUL-6350 fix(plugins): address review — byte quotas, version bound, secret pruning, script entry From the review on #7144, plus one contract change the surface design forced. - Storage quotas were accounted in characters and enforced in bytes. The usage query and the size_bytes it reports now use octet_length, and so do the plugin_storage column checks. A UTF-8 value could otherwise spend up to a quarter of the budget it appeared to. - manifest version had no length bound while plugin_installation.version caps at 64, so a legal-but-long semver failed at INSERT as an opaque install error instead of a parse error naming the field. - Upgrading pruned config values the new manifest dropped but left the matching plugin_secret rows. Ciphertext nothing can reach is exactly the residue pruneConfig exists to prevent; upgrade now prunes both in one transaction. - SetConfig wrote secrets and config across two tables with no transaction, so a failed config write could leave a saved form half-applied. - A duplicate first install mapped a unique-index violation to 502; it is 409. - net: is now an exact host match. It was a suffix match in the hook transport check while the same scope becomes an exact-host CSP connect-src in the surface runtime — one scope string cannot mean two things across the two places the consent screen claims to describe. - surfaces[].entry must be a .js/.mjs script, not an HTML document. The host generates the surface's document so it can attach the CSP derived from net:; a plugin-authored document would carry its own server's policy and net: would be a claim rather than a control. Tests: the three storage limits get a canonical unit matrix plus DB-backed coverage of the byte counting and the exclude-the-candidate-key replacement semantics; upgrade-time secret pruning is pinned end to end (verified failing without the fix); and the admin-only routes now have a real middleware-level 403 check, which every direct-handler test bypassed. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Lambda <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-18 19:15:56 +08:00
3 people	c9727e6b2b	feat(daemon): worktree mode for local_directory resources (MUL-5707) (#6759) ... * feat(daemon): worktree mode for local_directory resources (MUL-5707) Local directory resources serialise every task on a per-path mutex, so two tasks on one folder queue behind each other. This adds an opt-in worktree mode: each task gets its own git worktree of the user's repo inside the daemon's env root, so tasks run concurrently and deliver their work as a branch instead of editing the user's working copy. Opt in per resource with execution_mode=worktree (default stays in_place, so existing resources are unchanged). Requires a git repo with at least one commit; a non-git directory fails with an actionable message rather than silently falling back to serial execution. Design points that make the mode safe to use: - The agent starts from what the user sees, not HEAD. Tracked edits are captured with `git stash create` (which writes a commit object without touching the index, working tree, or stash list) and replayed into the worktree; untracked non-ignored files are copied, bounded at 2000 files / 200MB with the skipped count logged at warn level. - That replayed state is committed as a baseline, so "did this task change anything?" has an exact answer and `git diff <baseline>..<branch>` is precisely the agent's work. - Nothing is silently discarded: leftovers are committed to the branch before the worktree is removed, including when the task fails partway. - A task that changes nothing leaves no branch behind. - Sidecars stay out of the branch by running the existing CleanupRuntimeConfig + CleanupSidecars pass over the worktree before finalizing. The .git/info/exclude approach repocache uses is not usable here: a linked worktree resolves info/exclude to the user's own common git dir, so it would change what `git status` hides in their checkout. - Worktree-mode env roots do not get the local_directory GC exemption, so they age out normally instead of accumulating one env root per task. - `git worktree prune` on create self-heals registrations orphaned by a crashed daemon. Adds --execution-mode to `project resource add/update`, and updates the docs and the projects-and-resources built-in skill. Co-authored-by: multica-agent <[email protected]> * fix(daemon): close data-loss and isolation gaps in worktree mode (MUL-5707) Review follow-up on #6759. Six issues, all on failure or skew paths. 1. Preserve work when the final commit fails. Finalize logged a warning and then ran `git worktree remove --force`, destroying the agent's changes. commit.gpgSign with no key available to the daemon triggers this, and --no-verify does not disable signing. Finalize now returns an error and deliberately keeps the worktree — it stays registered, so `git worktree list` points at the work — and the daemon fails the task instead of reporting success with a branch that is missing the changes. 2. Fail closed on an unsupported execution_mode. Treating an unknown mode as in_place was wrong: execution_mode is how a user asks for ISOLATION, so the "safe" fallback would edit the working copy they asked us to stay out of. An unrecognised mode now fails the task naming the version skew. 3. Keep Codex conversations alive across turns. The per-issue session store was keyed on LocalWorkDir != "", so worktree tasks — which also never reuse an env root — got a fresh empty CODEX_HOME per turn and silently lost the thread. Covered by a two-turn regression test that fails without the fix. 4. Fail closed on an incomplete snapshot. A failed stash create/apply, a failed untracked copy, or hitting the copy bounds all degraded to "agent sees HEAD" with only a daemon log line. A half-replayed tree looks like a working checkout, so nothing downstream questions it while the agent reads different code than the user has. All of these now abort the prepare and tear the partial worktree back down. 5. Do not snapshot a directory mid-mutation. The same real path can be attached to another project as an in_place resource; snapshotting under a running in_place task captured a half-written tree plus that task's in-flight .agent_context/.multica sidecars, which then reached the branch and could feed the agent another issue's brief. Worktree prepare now takes the per-path mutex for the snapshot alone (released before the run, so tasks still overlap), and the untracked replay skips Multica's own sidecars. 6. Stop the test helper from masking regressions. gitRun skipped on any git failure, including post-finalize assertions, so a lost branch could report as a skip. Git availability is now checked once at repo setup; every later git failure is fatal. Also rebased onto main, keeping both MulticaConfigRoot and LocalWorktree in the Environment initialiser. Co-authored-by: multica-agent <[email protected]> * fix(daemon): close sidecar-commit and wait-visibility gaps in worktree mode; gate worktree saves on daemon version (MUL-5707) - runTask: register the sidecar-cleanup defer immediately after the Finalize defer. Previously two early returns (temp-dir setup, StartTask failure) sat between them, and on those paths Finalize auto-committed the sidecars Prepare had just written — delivering a branch whose only content is Multica's own runtime files (in_place: leaving them in the user's tree). - runTask: give the worktree snapshot wait the same plumbing as the in-place acquire — waiting_local_directory status, resourceWaitTasks accounting, and a cancellation poller. The holder can be an hours-long in_place task; the wait was invisible and a user cancel went unnoticed until the 5-minute prepare timeout. - isMulticaSidecarPath: match sidecar dirs as whole path segments at any depth, not only at the repo root. An in_place resource pointed at a SUBDIRECTORY leaves its sidecars below that subdirectory; replaying them committed another issue's brief into the delivered branch. - handler: refuse saving execution_mode=worktree while the owning daemon's registered cli_version is below MinLocalWorktreeCLIVersion (422, daemon_version_unsupported). An old daemon json-skips the field and runs tasks IN PLACE — the daemon-side unknown-mode refusal cannot protect a daemon that predates the field, so the server has to. Residual (documented): a daemon downgraded after the save needs a claim-time gate. - copyUntrackedFiles: read the -z listing raw instead of TrimSpace-ing it, which corrupted filenames beginning/ending with whitespace into paths that silently vanished from the replay. - docs + skill: describe the save-time version gate; drop the stale claim that old runtimes fail the task themselves. Co-authored-by: multica-agent <[email protected]> * feat(views): UI switch for local_directory execution mode (MUL-5707) Worktree mode shipped CLI/API-only, which for its target user — someone running several tasks at once from Desktop — means it does not exist. This adds the switch to the resources panel. The choice is framed by what the user gets back, not by the mode identifiers: "Edit this folder directly" (one task at a time, changes land in your working copy) vs "Run in parallel, isolated" (tasks run at the same time and each hands back an agent/… branch). `in_place` / `worktree` stay visible as a secondary hint for anyone cross-referencing the CLI or docs. Two entry points, matching where the decision is actually made: - The add-a-folder flow now asks for the mode after the folder is picked and validated, instead of creating the resource and leaving the mode to be discovered later. - Every local_directory row has a mode control. It is deliberately NOT gated on being the owning machine — switching the mode only rewrites a field, so it works from the web app too, unlike rename or the folder picker. Both blocked states are handled where the user chooses, not after they commit: - Non-git folder: the desktop validator now reports whether the path is inside a git working tree (walking up for `.git`, so a subdirectory of a repo counts), and the option is disabled with that reason. Unknown — an older desktop build, or an existing row — stays permissive; the daemon re-checks authoritatively. - Daemon too old: the version floor is mirrored from the server as MIN_LOCAL_WORKTREE_CLI_VERSION and checked against the runtime for the resource's OWN daemon, not the machine the browser happens to be on. A server rejection is rendered inline in the dialog rather than as a toast, so the dialog stays actionable. A "Parallel" badge on the row is always visible (not hover-only): without it there is no way to tell whether tasks on a folder edit it directly or hand back a branch, which is the first thing anyone asks when a task queues. Also adds `execution_mode` to LocalDirectoryResourceRef — the field existed server-side but had no TypeScript counterpart — and brings the zh/ja/ko project-resources docs in line with the English ones, which were the only locale updated when the mode landed. Co-authored-by: multica-agent <[email protected]> * fix(daemon,handler): close worktree isolation and delivery gaps (MUL-5707) Second review round. Five must-fix items, all on paths where the mode's promises could still break. 1. A failed sidecar cleanup no longer ships Multica's own files as the user's branch. The cleanup errors were logged and Finalize then ran `git add -A`, so a permission/disk/lock failure could deliver a branch whose entire content was the runtime brief and issue context. Worktree mode now escalates a cleanup failure to an abort: nothing is committed, the worktree is kept for inspection, and the task fails with the preserved path. In place it stays a warning — no commit, no branch, and the leftovers are visible in the user's own tree. 2. The untracked replay no longer drops files silently. `Lstat` failures and symlinks were `continue`d without counting, so the caller read a partial snapshot as complete. Both now count as skipped, which the existing fail-closed check turns into a refused prepare. Non-content entries (sockets, FIFOs, devices) stay uncounted deliberately. 3. Prepare rolls back a worktree it created. Any later failure — context files, provider home, MCP config — returned without an Environment, so nothing downstream knew a worktree existed, leaving a registration and a branch no task ever ran in. A deferred Discard now runs unless Prepare reached its successful return. 4. The daemon-version gate moved to where it can actually hold. Save-time validation cannot see a machine downgraded afterwards, and an old daemon json-skips execution_mode entirely — it would run the task in place, editing the working copy the user asked to isolate. Claims are now checked against the runtime that is actually claiming, and a blocked task is cancelled with a reason rather than left to be redelivered to the same too-old runtime forever. 5. branch_name is delivered end to end. The daemon sent it, but TaskCompleteRequest had no field so it vanished at decode, and the failure path never sent it at all. It now has a column, travels on both terminal callbacks, and renders as a copyable row in Run details. The failure path matters most: worktree mode commits the agent's leftovers before tearing the worktree down, so a run that died partway still has work worth finding. Docs (all four locales) and the projects-and-resources skill are updated for the claim-time gate and the branch surface. Co-authored-by: multica-agent <[email protected]> * fix(handler,daemon): migration renumber, cancel reasons, branch on every terminal path (MUL-5707) Third review round. 1. Rebased onto main and renumbered the migration to 285 — main had taken 273 and is now at 284. sqlc regenerated on top of the rebased queries; the conflicts were confined to generated files. 2. The claim gate now persists why it cancelled. It called CancelTask, which writes only status='cancelled', and returned the reason as a 4xx that reaches the daemon's log and nothing else — batch claim drops the task from its response entirely. A run refused for a durable reason the user has to act on cannot present as a bare "cancelled", so this adds CancelAgentTaskWithReason and records error + failure_reason on the row. 3. branch_name now survives every terminal path, not just the two direct callbacks. Three were dropping it: - the context-exhausted complete→fail reroute did not copy it; - the daemon's complete→fail fallback (server rejected the complete, agent had succeeded) did not set it; - both cancellation paths discarded the result wholesale, even though the worktree is finalized — and its work committed — before the daemon learns of the cancel. The branch now rides the cancel-ack and is recorded by SetAgentTaskBranchName, which never overwrites a name a terminal callback already wrote. 4. Rollout/rollback compatibility. Isolation is enforced by two server-side gates, so a daemon downgraded at any point after the resource was saved is caught. The gap they cannot close is rolling the SERVER back past this change while sub-floor daemons are still connected: an old server has no gate and an old daemon ignores execution_mode. That constraint is now documented where an operator will meet it (the migration and the docs), and the version floor is pinned across server and frontend by test so the two gates cannot silently drift apart. Co-authored-by: multica-agent <[email protected]> * fix(server,views): route claim-gate cancels through TaskService, make cancel reasons visible, harden cancel-ack branch delivery (MUL-5707) Closes the fourth-round review findings on worktree mode's cancellation chain: - Claim gate: cancel through a new TaskService.CancelTaskWithReason instead of a raw CancelAgentTaskWithReason query, so a gate-cancelled task gets the full cancellation side effects — audit capture, chat settle, agent status reconcile, task:cancelled broadcast, NotifyTaskFinished. Added REAL claim integration tests: singular claim (422 + row cancelled with reason), batch claim (task omitted + row cancelled with reason), and a current-runtime control. - Cancel reasons are now user-visible: execution log rows, agent activity rows, and the transcript dialog label a SERVER-cancelled task (persisted error/failure_reason) like a failed one, with the actionable text on hover and a Reason row in Run details. User-initiated cancels stay a plain "Cancelled". New cancelReasonLabel helper + local_directory_error label; details_reason locale key in en/zh-Hans/ja/ko; widened AgentTask.failure_reason to the open string the wire actually carries. - Cancel-ack is now a terminal delivery: the daemon retries it on transient errors (same schedule as complete/fail), the server fails LOUD (5xx) when persisting the branch/error fails instead of warn-and-200, and re-broadcasts task:cancelled after a successful write so clients that already refetched a branchless row pick up the delivery. Replays are idempotent (never overwrite). - Cancel + Finalize-abort no longer swallows the preserved-worktree pointer: the finalize error is wrapped in worktreePreservedError (joined onto an existing run error, never displacing it), extracted on the cancel path, and delivered via the ack into agent_task_queue.error through the new SetAgentTaskErrorIfEmpty query — never overwriting a reason recorded by a fail callback or the claim gate. Other run errors on a cancelled run stay discarded as before: they are expected noise. - Docs: the self-hosted rollback constraint callout now exists in zh/ja/ko, not just English. Co-authored-by: multica-agent <[email protected]> * fix(handler): guard cancel-ack writes to cancelled rows; requeue when the claim gate's cancel fails (MUL-5707) Fifth-round review fixes: - SetAgentTaskBranchName / SetAgentTaskErrorIfEmpty now carry a status='cancelled' CAS. The daemon acks on EVERY terminal status it observes, so a late or replayed ack from a stale run could previously backfill its branch or preserved-path error into a completed/failed row whose own callback — the authoritative channel — recorded nothing, without any event invalidating the change. A CAS-refused write is a deliberate no-op (still 200: nothing to retry), and the rebroadcast stays guarded by the same status check. Regression tests: a late ack against a completed row with empty fields and against a failed row leaves both untouched. - When the worktree claim gate's CancelTaskWithReason fails, the claimed row no longer strands in dispatched (daemon refused, nothing to release it but stale reclaim). The gate requeues via RequeueTaskAfterClaimFailure — the next claim re-runs the gate and retries the cancel — and reports 5xx so the singular daemon reads a transient server problem, not a claim refusal; the batch path omits the task as before, now with the row requeued. Fault injection tests (row-scoped trigger raising on the cancel UPDATE while letting the requeue through) cover singular and batch. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Bohan-J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-13 14:52:01 +08:00
3 people	d467cc9069	MUL-6075: complete Plugin V1 execution chain (#6853) ... * feat(server): add Plugin V1 lifecycle foundation Co-authored-by: multica-agent <[email protected]> * feat(server): complete Plugin V1 execution chain Co-authored-by: multica-agent <[email protected]> * feat(web): add temporary plugin settings demo Co-authored-by: multica-agent <[email protected]> * refactor(plugin): keep foundation free of demo content Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Lambda <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-13 02:29:49 +08:00
3 people	c4f0d8cc8c	MUL-5999: make workspace teardown index-driven, bounded and fenced (#6754) ... * perf(workspace): make teardown task discovery index-driven Workspace teardown found a workspace's tasks with a three-way `OR agent_id IN (…) OR issue_id IN (…) OR runtime_id IN (…)`, three times per delete, and swept task_token with the same shape. PostgreSQL costs that as a Seq Scan on agent_task_queue — the largest table in the database (5.08M rows / 8.3 GB in production) — so deleting even a tiny workspace paid for the whole table, inside the transaction that holds the workspace row lock and global advisory lock 4246. Resolve the task set one owner key at a time instead, in the handler, and reuse that snapshot for every task-keyed step. Measured on a 1.2M-row synthetic copy of the production shape (937 agents / 109 issues / 12 runtimes): the OR form and a 937-element `= ANY(array)` form both Seq Scan; single-key equality is a Bitmap Index Scan. A UNION of parent-key joins is worse than the OR (three hash joins, each seq scanning the table), which is why that earlier suggestion was dropped. All three ownership paths are preserved: nothing enforces that a task's agent, runtime and issue share a workspace, so dropping a path would turn a performance fix into a tenant-cleanup bug. task_token needs no loop. Its workspace_id has been NOT NULL since migration 108, so the workspace key alone covers this workspace's rows, and the two extra OR arms only ever matched tokens owned by another workspace whose task or agent lives here — both NOT NULL FKs with ON DELETE CASCADE, so the later task/agent deletes remove exactly those. Two indexes make the new shapes index-eligible: - 273 agent_task_queue(runtime_id): every existing runtime_id index is partial, so all-status consumers had none. This also covers the FK's own ON DELETE CASCADE probe, which runs per deleted agent_runtime row on the ordinary delete path. - 274 task_token(workspace_id): the column has never been indexed. Measured block usage for the same workspace, before → after: agent_task_queue discovery 25,665 → 14,485 blocks; task_token sweep 4,086 → 3 blocks. The point is not the ratio at this size but that the cost now scales with the workspace being deleted instead of with the global table. Refs MUL-5999 Co-authored-by: multica-agent <[email protected]> * fix(workspace): fence, bound and un-cascade the teardown task sweep Addresses all four blocking findings from the MUL-5999 review. 1. Concurrency (correctness / tenant isolation). The task set is no longer a lock-free snapshot reused across steps. Teardown now locks every row through which a task can belong to the workspace — its agents, issues and runtimes — FOR UPDATE, and holds them for the rest of the transaction. Inserting an agent_task_queue row takes FOR KEY SHARE on each referenced owner, which conflicts with FOR UPDATE, so a concurrent enqueue (or a reassignment onto one of these runtimes) can no longer slip a task in behind the sweep. Locking the tasks alone could not do that: a row that does not exist yet cannot be locked. This is the same technique the handler already uses on the workspace row to keep CreateChatSession out of the delete window. The per-batch page query also takes FOR UPDATE, so under READ COMMITTED PostgreSQL re-checks ownership after each lock: a task a concurrent commit already moved elsewhere is skipped rather than deleted on a stale claim, and a task we locked cannot move before we delete it. Deadlock (40P01) joins lock_timeout (55P03) as a retryable 503, because the owner locks can be taken in the opposite order by a concurrent task update. 2. Cleanup ownership (no cascade reliance). task_token keeps all three explicit paths, split into separate index-driven statements instead of one OR: workspace_id in DeleteWorkspaceLeafData, task_id in DeleteTaskBatch, agent_id in DeleteTaskTokensByAgent. Nothing in the teardown graph now depends on ON DELETE CASCADE to finish the job. 3. Bounded memory. The whole-workspace task array is gone. The sweep pages through one owner key at a time with LIMIT 1000 and deletes exactly the page it read, so process memory, the array parameter and each DELETE's row count are bounded by the batch size rather than by a workspace's lifetime task count. The task-keyed arms moved out of the leaf-data statement into DeleteTaskBatch, which runs per page, and the separate whole-workspace task delete is gone. 4. Migration retryability. The concurrent-index cleanup hooks are now derived from a version -> index-name map that covers 257, 261 and 273-277, so an interrupted CREATE INDEX CONCURRENTLY cannot be mistaken for success on retry. Three more indexes, each an unindexed FK referencing column that the per-batch statements need and that the FK's own ON DELETE action already scanned per row on ordinary deletes: task_token(agent_id), chat_draft_restore(task_id), autopilot_run(task_id). Plans re-verified on a 1.2M-row synthetic copy of the prod shape with the child tables populated: page query is a Bitmap Index Scan under LockRows; task_usage, chat_draft_restore, task_token and autopilot_run arms are all index scans. Tests: the ownership-path test now asserts the sweep is self-sufficient inside the transaction, before any owner row is deleted, so a cascade cannot stand in for teardown. New tests cover the enqueue / reassignment fence (blocked writers, unrelated writer unaffected), multi-page sweeps and the page bound, plus a migration-retry repair test and a check that every cleanup hook names the index its migration builds. Refs MUL-5999 Co-authored-by: multica-agent <[email protected]> * fix(workspace): keyset-page the teardown sweep and fail closed on leaks Addresses the second review round on MUL-5999. 1. Bounded scan, not just bounded result. The page query was `owner = $1 ORDER BY id LIMIT n` against indexes that cannot produce id order, so the executor had to read the owner's whole task set before applying LIMIT — quadratic in pages for a busy owner, which is the case this issue is about. Measured on a 550k-row probe: the old shape spent 11,630 buffers per page (planner chose a full pkey index scan; on other statistics it chose an explicit Sort), the keyset shape spends ~2,000 and a later page costs the same as the first. Pages are now `owner = $1 AND id > $cursor ORDER BY id LIMIT n` against composite indexes: 273 becomes (runtime_id, id), 278 adds (agent_id, id), 279 adds (issue_id, id) and 280 drops the single-column issue_id index it supersedes so the hot table does not carry both. 2. Owner enumeration is bounded too. The three LockWorkspaceTaskOwner* statements no longer return ids at all — they are a set-based write fence and now cost the API process nothing. Owners are walked separately in keyset pages of 500 (281-283 add the (workspace_id, id) indexes those pages need), so a workspace with a huge agent or issue set never has its whole owner list held in memory. The keyset column is id rather than a natural key on purpose: a cursor column must be immutable, and renaming an owner mid-teardown would otherwise let it sort behind the cursor and escape the sweep. 3. The fence is no longer the only guarantee. Blocking a concurrent enqueue still relies on an INSERT taking FOR KEY SHARE on the owner rows it references, which is a property of the legacy FKs rather than a protocol every enqueue path opts into. Two things now backstop it: - every owner is re-swept until a pass finds nothing, and teardown fails closed (rolling the whole transaction back) if tasks keep arriving, instead of committing a partially cleaned tenant; - a schema-contract test asserts the three owner FKs still exist, so a migration that removes them turns the missing fence into a red build rather than a silent hole. An explicit deleting-state protocol shared with all seven enqueue paths remains the right long-term fix and is out of scope here. End-to-end teardown, real handler, identical synthetic data, main vs this branch (1.2M-row agent_task_queue, 200k task_token, 300k task_usage): small workspace, 5k tasks: 29,247 ms -> 1,013 ms (4.38M -> 0.27M blocks) busy workspace, 60k tasks: 243,863 ms -> 1,724 ms (5.76M -> 2.23M blocks) Refs MUL-5999 Co-authored-by: multica-agent <[email protected]> * fix(workspace): fence task writes in-transaction, independent of the FKs Addresses the third review round on MUL-5999. 1. The re-scan did not close the window, and the reviewer is right that it cannot: a pass that comes back empty returns success, and a task inserted after that final scan but before COMMIT is not caught by any number of passes. The only thing that closed that window was the FOR KEY SHARE an INSERT takes on the agent / issue / runtime rows it references — a side effect of foreign keys that workspace_delete.sql itself documents as an expand-phase net a later contract removes. Migration 284 replaces it with an explicit fence: a BEFORE INSERT OR UPDATE OF (agent_id, issue_id, runtime_id) trigger on agent_task_queue that takes FOR KEY SHARE on the workspace row behind every owner the row references, and raises if one is gone. That conflicts with the FOR UPDATE LockWorkspaceForDelete already holds for the whole teardown transaction, so a task write against a workspace being torn down blocks until teardown finishes and then either proceeds (rolled back) or fails closed (committed). A trigger rather than a per-call-site check because the fence has to be in the same transaction as the write: there are seven INSERTs and several ownership-changing UPDATEs across agent.sql, autopilot.sql, chat.sql and runtime.sql, several of them single autocommit statements, so a separate "take the fence" statement from the caller would be its own transaction and protect nothing. In-transaction by construction, covers every current path, and cannot be forgotten by a path added later. TestTaskWriteFence_BlocksOnWorkspaceLockAlone isolates the fence from the FKs: the holder locks ONLY the workspace row — no agent, issue or runtime row — so no FK on agent_task_queue has anything to block on, since none of them references workspace. Inserts through all three ownership paths and a reassignment all block; an unrelated workspace's insert and a status-only update still pass. Dropping the trigger fails that test. Cost, measured with 5,000 bare inserts: 147 ms without the fence, 238 ms with it — about 18 us per inserted row for up to three indexed lookups and a shared row lock. It does not fire on the hot claim / dispatch / complete path, which updates status and timestamps rather than ownership. The verification passes stay as a self-check, no longer described as the concurrency guarantee. 2. Migration 280 is withdrawn. Its down path rebuilt the superseded index with CREATE INDEX CONCURRENTLY, and the runner only runs INVALID-index cleanup hooks in the up direction, so an interrupted rollback would leave an invalid index that a later `down` skips — and rolling back 279 too would then leave no usable issue_id index at all. The redundant single-column index stays for now; dropping it needs its own migration with a direction-aware cleanup. This also settles the stale comment in task_usage.sql, which still names the old index and remains correct. 3. Keyset cursors no longer start from the all-zero uuid, which is itself a valid uuid and would have made a row with that id invisible forever. Every walk now has an explicit first-page query with no cursor predicate. Refs MUL-5999 Co-authored-by: multica-agent <[email protected]> * fix(workspace): move the task-write fence into the write statements Addresses the fourth review round on MUL-5999. 1. The trigger is gone. Migration 284 now defines lock_task_owner_workspaces(agent_id, issue_id, runtime_id), a predicate that every statement writing agent_task_queue ownership calls in its own WHERE clause: INSERT INTO agent_task_queue (...) SELECT ... WHERE lock_task_owner_workspaces($1, $3, $2) Nine statements now carry it: the seven task INSERTs (agent.sql x5, autopilot.sql, chat.sql), LinkTaskToIssue, and ReassignTasksToRuntime — the last through a MATERIALIZED CTE so a bulk UPDATE evaluates the VOLATILE predicate once instead of per row. Clearing runtime_id is exempt: it cannot move a task into another workspace. Calling it from the writing statement keeps the lock in the writer's own transaction, which a separate caller-issued statement could not do for the autocommit enqueue paths. TestTaskOwnershipWritesCallTheFence is the trade for dropping the trigger: it scans the query files and fails the build if a statement writes ownership without the fence. 2. The fence no longer defers to the foreign keys. The trigger version counted only owner references that still resolved, so a deleted owner made itself invisible: with all three gone it returned early, and with one of three gone the count still matched. The predicate now compares resolved owners against the number of owner arguments supplied and returns false on any mismatch, so a stale write is rejected on its own terms. TestLockTaskOwnerWorkspaces_RejectsUnresolvableOwner covers each shape, including the one-of-three case. 3. Deterministic lock order. The workspace rows are locked with ORDER BY w.id, so mirrored cross-workspace writes cannot take the same pair in opposite orders. Honest note on the test: 25 mirrored concurrent pairs never deadlock either way, because the current plan happens to return the rows in a stable order — the ORDER BY is what makes that a guarantee rather than an accident of the plan, and the test is a regression test for the symptom. 4. The fail-closed test now tests what its name says. The previous one only inserted a neighbour-owned task and could not have failed. The replacement runs the actual race: a writer calls the real CreateAgentTask, blocks on the workspace lock, teardown deletes the workspace and commits, and the writer must come back with pgx.ErrNoRows — the fence's own verdict. An FK doing the work instead surfaces as SQLSTATE 23503, which the assertion rejects explicitly. Cost: 5,000 predicate calls in 53.7 ms, about 11 us per fenced write, for up to three indexed lookups and a shared row lock. Status, dispatch and completion updates do not call it. Refs MUL-5999 Co-authored-by: multica-agent <[email protected]> * fix(runtime): stop the legacy merge when the task fence refuses Addresses the P1 from the fifth review round on MUL-5999. ReassignTasksToRuntime returned only a row count, so a fenced refusal was indistinguishable from "the old runtime had no tasks". mergeLegacyRuntimes read both as success and went on to DeleteAgentRuntime(old), where agent_task_queue's ON DELETE CASCADE silently took the history the reassignment exists to preserve — and once that FK goes away, the same path would instead leave tasks pointing at a deleted runtime. Either way the merge was leaning on the cascade, which is what this PR set out to stop. The query now returns the fence verdict alongside the count: SELECT (SELECT ok FROM fence) AS fence_ok, (SELECT count(*) FROM reassigned) AS reassigned_tasks and the merge is a single helper, mergeLegacyRuntime, that aborts with errRuntimeMergeFenced before touching anything else when fence_ok is false. Tasks now move FIRST, because that is the step carrying the fence: nothing else in the merge — agent reassignment, legacy daemon_id bookkeeping, the old runtime delete — runs unless the fence agreed. The next daemon registration re-runs the merge, by which time the workspace is either gone or its teardown rolled back. TestMergeLegacyRuntime_KeepsOldRuntimeWhenFenceRefuses covers it: with a vanished merge target the old runtime and its task both survive and the task stays on the old runtime, while a merge onto a live runtime still completes. Removing the abort fails that test — and fails it with SQLSTATE 23503 from agent_runtime_id_fkey, which is precisely the "an FK is doing the work" shape the review objected to. Also replaced the fixed 300 ms sleep in the queued-writer race with a poll on pg_stat_activity for a backend actually parked on a lock, so the test cannot pass without the race being set up (it now fails on timeout instead). Refs MUL-5999 Co-authored-by: multica-agent <[email protected]> * fix(runtime): make the legacy runtime merge a single transaction Addresses the P1 from the sixth review round on MUL-5999. The merge ran four autocommit statements, so the fence's workspace lock ended with the statement that took it. Two ways that left a tenant inconsistent while daemon registration still reported success: * a transient failure on the agent reassignment committed the task move and nothing else, leaving tasks on the new runtime and their agents on the old one until some later registration happened to retry; * in the gap after the task commit, a workspace teardown could lock and delete the target runtime — and its UnbindTasksFromRuntime step clears runtime_id on exactly the tasks that had just moved. The next merge looks tasks up by the OLD runtime id, so that history was detached for good. mergeLegacyRuntime now opens a transaction and runs the whole merge on one qtx: fenced task reassignment, agent reassignment, the legacy daemon_id audit write, and the old-runtime delete, then commits. The fence stays the first statement, so the workspace lock it takes is held until COMMIT — a teardown cannot start deleting the target mid-merge — and the lock order against teardown is unchanged. Any failure returns an error and rolls the whole thing back. The audit write is no longer best-effort: inside a transaction a failed statement poisons the rest, so it either lands with the merge or the merge is abandoned. TestMergeLegacyRuntime_RollsBackWhenAStepFails injects the failure in the database rather than through a code seam — a trigger makes the agent move raise — and asserts the task, the agent, both runtime rows and the audit column are all exactly as they were, then that the same merge completes once the injection is removed. Reverting to autocommit fails it with "task moved to <new runtime>; the task reassignment was not rolled back". Also took the non-blocking suggestion: the queued-writer race now has the writer report its own pg_backend_pid() over a channel and waits for that specific backend to park on a lock, instead of matching statement text against every backend on a shared test database. Refs MUL-5999 Co-authored-by: multica-agent <[email protected]> * fix(runtime): fence late writes against the runtime a merge is collapsing Addresses the P1 from the seventh review round on MUL-5999, which the reviewer reproduced rather than inferred. The fence locked the workspace row and nothing else. A task write takes FOR KEY SHARE there, and so did the legacy runtime merge — and two KEY SHARE locks do not conflict. So an enqueue against the OLD runtime went straight through after the merge had scanned its tasks, and DeleteAgentRuntime then removed that brand-new task through agent_task_queue's ON DELETE CASCADE. Making the merge one transaction widened the window rather than creating it: the agent's new runtime_id is invisible until COMMIT, so concurrent writers keep resolving the old runtime for the whole merge. Both sides of the contract now lock the owner rows too, in one order: workspace rows (by id), then agent, issue, runtime. * lock_task_owner_rows (migration 284, renamed from lock_task_owner_workspaces) takes FOR KEY SHARE on each owner row after the workspace rows, and re-checks that they still exist. That is what conflicts with a delete. * The merge takes FOR KEY SHARE on the workspace and then FOR UPDATE on both runtime rows in id order, before the task scan, and holds them to COMMIT. FOR UPDATE is the level that conflicts with a writer's KEY SHARE; both runtimes in one ordered statement so two merges running in opposite directions cannot take the pair in opposite orders. Locking fewer rows than asked for means one disappeared, and the merge is abandoned. A late writer therefore either commits before the merge takes the lock — in which case the scan that follows sees its task and moves it — or waits, and then finds the runtime gone and writes no row. TestRuntimeMerge_LateWriteToOldRuntimeIsFencedNotCascaded drives the merge statement by statement so it can stop where the window was (after the agent update, before the old runtime is deleted), enqueues against the old runtime through the generated query, and requires that the writer is parked on a lock, that it comes back as pgx.ErrNoRows, and that the merge's own history ends up on the target. It explicitly rejects both 23503 and a row that lands and then vanishes. Both halves are load-bearing: dropping the runtime lock from the fence, or the FOR UPDATE from the merge, fails that test — the latter with "the late write was rejected by a foreign key (23503), not by the fence". Cost: 5,000 predicate calls in 74.4 ms, ~15 us per fenced write (was ~11 us with the workspace lock alone). Refs MUL-5999 Co-authored-by: multica-agent <[email protected]> * docs(workspace): correct the fence comment and drop a trailing newline Two review nits, no behaviour change. lockWorkspaceTaskOwners still described migration 284 as a BEFORE trigger on agent_task_queue. It became a called predicate, lock_task_owner_rows, in 9fc1d79, and this comment is the place someone reads to understand how the fence works — so it now says what it is: a predicate every ownership-writing statement calls in its own WHERE clause, taking FOR KEY SHARE on the workspace rows and then the owner rows. Also removed the blank line at EOF in the migration, which git diff --check was flagging. Refs MUL-5999 Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-12 14:09:48 +08:00
3 people	b06af2ae17	feat(runtime): unbind agents on runtime delete instead of destroying them (#6220) ... * feat(runtime): unbind agents on runtime delete instead of destroying them Deleting a runtime archived its agents and then hard-deleted the rows, so the agents and every conversation with them disappeared — while the confirmation dialog said "archive", which a user reasonably reads as recoverable. Retiring a laptop is an ordinary action; losing the agents configured on it is not an ordinary consequence. An agent is now a persistent business object and a runtime is replaceable execution capacity: deleting a runtime unbinds its agents. `runtime_id IS NULL` means unbound — orthogonal to archived — and the agent keeps its instructions, skills, chats, labels, channel installations, autopilots and task history. service.AgentReadiness already refused an agent with no runtime, so the scheduling safety gate needed no change. Two columns become nullable, not one. Without `agent_task_queue.runtime_id`, deleting the runtime still cascades the task history away (and task_message / task_usage / task_token with it), so the agents would survive with no record of anything they did — the same class of loss. A NOT VALID CHECK keeps NULL confined to history: an active task must always have a runtime, so claim / dispatch / delivery-CAS paths can never observe one without. It is written against completed_at rather than a status list so a future non-terminal status fails closed instead of slipping through. Two prerequisites this depends on: - 'deferred' (migration 128) was missing from CancelAgentTasksByRuntimeOrAgent. It went unnoticed because the delete used to cascade those rows away; with the new CHECK it would abort the delete and make the runtime undeletable. - The channel-installation / label / chat-pin / invocation-target / draft-restore cleanups were scoped to "archived agents on this runtime". Archived user agents now survive, so that scope is narrowed to kind='system' — otherwise the fix would produce a subtler loss: agent alive, configuration wiped. Also removes the squad guard that refused (409) when an active squad's leader was an archived agent on the runtime, plus the archived-squad delete that existed only to get past squad.leader_id's RESTRICT FK. The leader is no longer deleted, so nothing needs to be given up to retire a machine. Autopilots are no longer paused either: their assignee survives, and a rebind restores them without the owner having to remember to re-enable. Reason codes: an unbound agent reports agent_runtime_required, not runtime_offline. The copy for runtime_offline tells users to reconnect a machine; an unbound agent has no machine to reconnect, and the fix is to bind a runtime. Chat's bare 409 string gains the same code so the composer can offer that action. API: agents gain runtime_bound. runtime_id stays a string (empty when unbound) so installed clients keep parsing and no gated two-release rollout is needed. The confirmed-delete endpoint is /unbind-agents-and-delete; /archive-agents-and-delete still routes to it, and the compared expected_active_agent_ids set is unchanged — widening it would 409 every older client forever. Co-authored-by: multica-agent <[email protected]> * fix: make runtime unbinding recoverable Co-authored-by: multica-agent <[email protected]> * fix: address runtime unbind review nits Co-authored-by: multica-agent <[email protected]> * fix: resolve runtime unbind review blockers Co-authored-by: multica-agent <[email protected]> * fix(migrations): renumber runtime unbind after main merge Co-authored-by: multica-agent <[email protected]> * test(daemon): avoid late-request lease flake Co-authored-by: multica-agent <[email protected]> * test(autopilots): bind validation fixture runtime Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-08-03 12:39:27 +08:00
7 people	0fdc38704e	MUL-5149: add agent-generated Chat quick actions (#5766) ... * feat(chat): add agent-generated quick actions Co-authored-by: multica-agent <[email protected]> * fix(chat): preserve mid-response quick-action fences Co-authored-by: multica-agent <[email protected]> * fix(chat): drop quick actions on empty reply to keep no_response fallback An actions-only completion — a quick-actions footer with no visible text — wrote an empty-content assistant message (message_kind=message). Older Desktop/mobile clients ignore the quick_actions field and render that as an empty bubble, breaking the MUL-4351 contract that an empty turn always gives old clients a visible no_response fallback. Drop the quick actions when the visible body is empty so an actions-only turn falls through to the visible no_response outcome, and revert the completion switch to gate the message row on visible text only. Update the completion test to pin the corrected behavior. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(chat): generate quick actions via daemon suggestion pass Replace the in-band runtime-brief instruction with a dedicated post-completion provider turn: after a direct chat reply finishes, the daemon resumes the same session with a JSON-only suggest prompt and forwards the raw output on the complete callback. The server parses it leniently and reuses the existing sanitize/redact/store/broadcast pipeline; the stripped in-band footer stays as a fallback for older daemons and pre-upgrade sessions. The footer strip now covers every chat completion, fixing the intro-turn protocol leak. Adds a Settings → Chat toggle (client-persisted, default on) that hides the chips. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(chat): deliver quick actions async with skeleton placeholders Decouple suggestion generation from the turn: the daemon reports completion immediately (chat:done carries quick_actions_pending as a per-turn capability signal) and runs the suggestion pass in the background, delivering results through a new supplement endpoint + chat:quick_actions broadcast. A new turn on the same session cancels the stale pass. Clients render pill skeletons under the finished reply until the supplement resolves them (entrance animation on arrival, 30s safety timeout); older daemons never raise the flag so no skeleton dangles. Suggest usage re-reports merged totals because task_usage upserts replace per (task, provider, model). Prompt now asks for exactly 3 actions. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(chat): make the quick-actions toggle stop generation, not hide pills The Settings → Chat toggle previously only hid rendered pills while the daemon kept burning a suggestion call every turn. It now travels with each send (quick_actions_enabled, absent = enabled for older clients), is stamped on the chat task (migration 213), forwarded on the claim, and gates the daemon's suggestion pass at the source — no call, no pending flag, no skeleton. Existing suggestions stay visible; settings copy now says 'generate' instead of 'show'. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(migrations): renumber quick-action migrations onto current main Merging current origin/main brought the vcs migrations to their canonical 216-221 prefixes, which collided with the quick-action migrations that were sitting at 219/220 (backend CI red in TestMigrationNumericPrefixesStayUniqueAfterLegacySet). Renumber them to the next unused prefixes: - 219_chat_message_quick_actions -> 222_chat_message_quick_actions - 220_agent_task_quick_actions_disabled -> 223_agent_task_quick_actions_disabled Contents are unchanged; sqlc regeneration produces no drift since the added columns are independent of the vcs tables. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(mobile): render async chat quick actions via chat:quick_actions The daemon generates quick actions in a background pass after the turn finishes, delivering them on a separate chat:quick_actions event. Mobile only handled chat:done (which invalidates + refetches an actions-less message list) and keeps the messages query at staleTime: Infinity, so an active mobile session never rendered async-generated quick actions until a manual pull-to-refresh or refocus. Add applyChatQuickActionsToCache — mirroring web's patcher — which patches the supplement onto the targeted assistant message in the flat messages cache, and subscribe to chat:quick_actions in use-chat-session-realtime. Patch-only (no invalidate), matching web and mobile's cellular patch-over-invalidate rule; an empty supplement is a terminal no-op. Covered by chat-ws-updaters.test.ts. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(chat): cancel in-flight messages refetch before quick-actions patch The chat:done invalidate can leave a messages refetch in flight that read the assistant row before the daemon persisted the quick actions. If that refetch resolves after the chat:quick_actions setQueryData patch, it overwrites the freshly-patched actions with an actions-less row. Both message caches are staleTime: Infinity, so the overwrite never self-heals and the actions vanish permanently (MUL-5149, Howard review). applyChatQuickActionsToCache now awaits cancelQueries for the affected caches (web: flat messages + messagesPage, mobile: flat messages) before patching, so a stale in-flight refetch is cancelled and cannot land after the patch. Cancel must precede setQueryData because cancelQueries reverts to the pre-fetch state. WS handlers call it via `void` (fire-and-forget). Adds an active-query race regression test on both web and mobile that holds a refetch open across the supplement and asserts the patched actions survive; verified to fail without the cancel. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(chat): quick-actions refresh/regenerate + review hardening (MUL-5149) Co-authored-by: multica-agent <[email protected]> * fix(chat): address quick-actions re-review (MUL-5149) - Ack alignment: refresh request carries the target message_id; server atomically confirms it is still the session's latest turn (409 stale otherwise), so the client marker always matches the resolving chat:quick_actions — no response reconciliation. Adds a regression test. - Converge the pending marker on every terminal path: HandleFailedTasks (sweeper/orphan) now resolves it, and the daemon reports a failed supplement so FailTask resolves it instead of leaving a completed-but-unresolved task. - Timeout fallback now clears the real query state (useQuickActionsPendingTimeout) instead of a component-local flag that only masked the UI; drop the skeleton's and pill row's local timers. - frontend-test type-scale: text-xs -> text-caption. Strip EOF blank line. Co-authored-by: multica-agent <[email protected]> * fix(chat): close quick-actions refresh races and failure feedback (MUL-5149) Third-round review of the refresh button surfaced three issues; all three are addressed here. §1/§2 Session-busy race + concurrent-refresh double-spend: a newer reply that is queued/running but whose assistant row hasn't landed leaves the old turn as latest-persisted, so the stale check passes and the regen resumes the newer provider state — attaching suggestions to the wrong turn. And two concurrent refreshes each enqueue a quota-spending pass. Add HasActiveChatTaskForSession and refuse a refresh (ErrChatQuickActionsBusy → 409) whenever the session has any task in flight, checked under the same session lock as the enqueue so no sibling insert slips past. §3a Timeout re-arm on surface switch: the pending marker now carries an absolute expires_at deadline instead of a per-mount timer, so switching between the floating window and the chat tab resumes the same deadline rather than restarting a fresh 30s window each remount. §3b Generation failure masked as success: runChatSuggestPass now returns ok so an explicit refresh distinguishes a failed pass (didn't start / didn't complete / timed out) from a completed-but-empty one. On failure the regen task reports failure, resolveFailedRegenerateQuickActions broadcasts a FAILED chat:quick_actions, and the client resolves the spinner AND toasts "couldn't refresh" instead of silently stopping on unchanged pills. Co-authored-by: multica-agent <[email protected]> * fix(chat): count deferred tasks in refresh busy check; solid refresh icon tone (MUL-5149) Two re-review blockers on 2dc9404d. §1 (deferred window): HasActiveChatTaskForSession only treated queued/dispatched/running/waiting_local_directory as in-flight, so a chat auto-retry armed with a backoff fire_at — inserted 'deferred' by CreateRetryTask, as provider_network's ~5s final attempt is — slipped past the busy check. In that window the failed turn has no assistant row yet, so the old turn is still latest-persisted and refreshable; the regen would then resume a session the retry is about to advance and pin the new turn's suggestions onto the old one. Add 'deferred' so the set matches the canonical in-flight status list the rest of the queries already use (agent.sql has-active-task checks). New regression test covers a deferred active turn. CI (text-contrast gate): the refresh icon button used text-muted-foreground/70 (transparency standing in for a text tone), which the frontend-test contrast gate rejects. Switch to the solid text-faint-foreground token — the tone the gate recommends for icons/glyphs, already used repo-wide and clearing WCAG 1.4.11. Co-authored-by: multica-agent <[email protected]> * test(chat): assert quick-actions pending marker carries expires_at (MUL-5149) The chat:done supplement-flow test still expected the 2-field marker from before the absolute-deadline change; applyChatDoneToCache now stamps expires_at, so the deep-equal failed on frontend-test. Assert the deadline is present (expect.any(Number)) rather than a wall-clock-dependent value — its timing semantics are covered by the pending-timeout hook. Co-authored-by: multica-agent <[email protected]> * fix(db): renumber regenerate-quick-actions migration 237 -> 240 (MUL-5149) main merged Issue Quick Actions (MUL-5465) taking migrations 237/238/239 (quick_action, quick_action_workspace_index, comment_quick_action). This branch independently took 237 for agent_task_queue.regenerate_quick_actions_for. The two 237s do not textually conflict (different filenames) so the PR reads mergeable, but the merged tree would carry two migration 237s. Renumber this one to 240 so it applies after main's chain. The migration is a standalone `ALTER TABLE agent_task_queue ADD COLUMN IF NOT EXISTS` — order-independent, touches a column none of main's migrations reference. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Lambda <[email protected]> Co-authored-by: multica-agent <[email protected]> Co-authored-by: Walt <[email protected]> Co-authored-by: Claude Opus 4.8 <[email protected]> Co-authored-by: Naiyuan Qing <[email protected]> Co-authored-by: NevilleQingNY <[email protected]>	2026-07-30 21:25:03 +08:00
3 people	30318b79bc	MUL-5426: fix(daemon): retire sessions whose history the provider refuses to replay (#6083) ... * fix(daemon): retire sessions whose history the provider refuses to replay A run killed mid-reply (machine shutdown, force-quit, SIGKILL) can leave an empty assistant message in the agent CLI's transcript. Every later resume replays it, the provider rejects the request, and the (agent, issue) pair is bricked with no self-healing and no user-facing recovery. Multica already has the mechanism for this — poisoned-session classification — but its detector paired "400" with "invalid_request_error", which is the Anthropic wire shape. The same defect reported by any other provider carried neither token, so it classified as agent_error.unknown: resume-safe by omission. GetLastTaskSession kept handing back the dead session on every follow-up, manual Rerun resolved it through the same predicate, and the in-turn fresh-session retry never fired because ResumeRejected is false here (nothing rejected the resume — the transcript loaded and the provider refused to replay it). Add taskfailure.UnresumableHistory, which recognises the defect by what the provider says is wrong — some content is empty, and here is which message in the history — rather than by status code or provider name. Both signals are required, so a tool reporting "field must not be empty" does not match. Wire it into the four places that decide whether a session survives: - classifyPoisonedError, so the task is written as api_invalid_request - shouldRetryWithFreshSession, so the turn recovers on all 17 backends instead of the subset whose adapter learned to detect it; the tools == 0 gate is unchanged, so a run that already used a tool is never re-run - ResumeUnsafeFailure, covering the manual-Rerun path - both resume queries, as defense-in-depth for hosts whose daemon predates this (self-host daemons upgrade on their own cadence) Fixes #6066. Also covers the daemon half of #5760. Co-authored-by: multica-agent <[email protected]> * fix(session): close the Chat and fresh-retry paths that resurrect a poisoned session Review found the previous commit stopped short in two places, both of which put the dead transcript back in play. Chat never consulted the guarded query. The claim handler reads chat_session.session_id first and only falls back to GetLastChatTaskSession when it is empty, so a poisoned pointer there bypasses every filter that query applies. The fail path merely declined to OVERWRITE the pointer, leaving it in place. It now clears it in the same transaction, matched on session and runtime so a concurrent turn's newer pointer survives. The promote guard moves to ResumeUnsafeFailure as well — the reason-only check passed an un-upgraded daemon's agent_error.unknown row and re-pinned what the clear had just removed. GetLastChatTaskSession also kept the row-level filter the issue query dropped in GH #5975: it discarded the newest poisoned row and fell back to an older completed row carrying the same dead session. It now judges each session by its latest terminal state, matching GetLastTaskSession. A recovered turn could not retire anything. A terminal report carried one session_id, and an empty one meant both "nothing to report" and "forget the old session", so a fresh-session retry that SUCCEEDED left the id it retried away from selectable — through an older completed row on the issue, or through the chat pointer. agent_task_queue.retired_session_id records the abandonment itself, reported on every terminal path including completed, and both resume lookups exclude it. This is the contract gap the previous PR deferred; the fresh-retry path now runs on all backends, so deferring it is not safe. Also narrows what the cross-backend test claims: it pins the shared decision, not that all 17 adapters surface the error into Result.Error (#5760 is the counter-example), and says so. Co-authored-by: multica-agent <[email protected]> * test(session): require pgx.ErrNoRows in the resume-exclusion assertions The `if err == nil && prior.SessionID.Valid` form these tests shared is false-green: any real fault — undefined column, syntax error, dead connection — makes err non-nil, so the condition is false and the test passes. Run against a database missing this branch's new column, the exclusion tests reported PASS on a SQLSTATE 42703, meaning they could not have caught a broken query. requireSessionExcluded demands pgx.ErrNoRows specifically and fails loudly on anything else, so a green run now means the filter worked rather than the query never ran. Applied to all nine sites, not just the four this branch added: the other five guard the same GetLastTaskSession exclusion behaviour that this branch changes, so leaving them false-green would leave the change under-tested. All nine pass on a correctly migrated database. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Bohan-J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-29 15:54:51 +08:00
3 people	85a14cde37	fix(daemon): gate codex session pointer writes on rollout presence (MUL-5305) (#5960) ... * fix(daemon): gate codex session pointer writes on rollout presence (MUL-5305) Codex issue follow-ups on local_directory projects intermittently lost their session: the server sent a prior session whose rollout was not in the task CODEX_HOME, so the daemon dropped the resume and started a fresh thread (gateCodexResumeToRolloutPresence), losing the conversation. Root of the bad pointer: the daemon persists a Codex session id as the resumable pointer at two points -- the mid-flight pin and the terminal report -- before the rollout is guaranteed on disk. A task that exits early (crash / runtime offline / timeout) leaves a pinned/reported session id with no rollout; GetLastTaskSession (which accepts failed rows) then hands it to the next follow-up, which drops it. Enforce the invariant at write time: only record a Codex session as the resumable pointer once its rollout is present in the per-issue store, with a short bounded wait for flush. If it never lands, don't overwrite the last good pointer -- a blanked session_id becomes NULL server-side, so GetLastTaskSession falls back to the most recent session whose rollout is real. Non-Codex providers are unaffected; crash recovery is preserved because a present rollout still pins. - codexSessionResumable: shared write-time presence check (bounded wait) - runTask: gate the terminal session_id before reporting - executeAndDrain: gate the mid-flight pin (thread codexHome through) - tests: helper cases + behavioral pin test Co-authored-by: multica-agent <[email protected]> * fix(daemon): address review — don't silently downgrade completed sessions (MUL-5305) Follow-up to review feedback on #5960: - Must-fix 1 (silent downgrade): limit the write-time session withholding to NON-completed terminal states. A missing rollout means no resumable conversation was persisted, so a withheld non-completed attempt loses nothing; a completed session is authoritative and, if its rollout is anomalously absent, is still recorded so the next run's resume gate discloses the loss (PriorSessionResumeUnavailable, MUL-4424) instead of silently falling back to an older session. Extracted resumableTerminalSessionID. - Non-blocking risk: pin the mid-flight resume pointer with a per-status presence check instead of one fixed 2s window, and set sessionPinned only once the rollout is confirmed, so a rollout that lands shortly after the first status is still pinned this run. - Must-fix 2 (regression coverage): pin skipped when rollout absent (no /session call); terminal helper (completed keeps / failed withholds); and a DB-backed GetLastTaskSession test proving the next claim falls back to the older recorded session when the latest was blanked. Co-authored-by: multica-agent <[email protected]> * fix(daemon): disclose Codex session continuity gaps end-to-end (MUL-5305) Addresses review feedback on #5960. Must-fix 1 — a completed turn whose rollout is missing is exactly the #5934 case (the reporter waits for each turn to finish), so it can no longer be excluded from withholding. Withhold the session for ANY terminal state, and pair the withhold with a persisted continuity-gap signal so the next claim still discloses the loss even while resuming an older good session: - new agent_task_queue.session_rollout_missing column (migration 224) - daemon sends session_rollout_missing on the terminal report; the handler clears the resume pointer (MarkTaskSessionRolloutMissing, overriding FailAgentTask's COALESCE) and flags the row - claim reads GetLatestTaskRolloutMissing and sets a new prior_session_resume_unavailable response field, which the daemon ORs into the brief's PriorSessionResumeUnavailable disclosure Must-fix 2 — Codex reveals the session id on a single task_started status, so a one-shot presence check missed a rollout that flushed later and lost in-flight crash recovery. Pin via a background waiter bounded by the run's context that pins the moment the rollout lands. Tests: - completed + rollout missing -> next claim withholds the bad session AND flags the continuity gap (cross-layer DB test) - session pinned once its rollout appears after the status (mid-run) - pin skipped while the rollout is absent Co-authored-by: multica-agent <[email protected]> * fix(server): make continuity-gap write atomic + disclose on all claim paths (MUL-5305) Addresses review round 3 of #5960. Must-fix 1 — the previous handler-level marker ran AFTER the terminal transaction committed, and FailTask creates + wakes the auto-retry inside that same transaction, so a retry could claim the rollout-missing session before the marker cleared it (and a marker failure was swallowed). Move session_rollout_missing INTO the terminal write: CompleteAgentTask and FailAgentTask now force session_id NULL (overriding Fail's COALESCE that would keep a stale mid-flight pin) and set the flag in the SAME UPDATE, so the withhold + gap flag commit atomically with the retry creation. The flag is threaded through TaskService.CompleteTask/FailTask; the swallowed best-effort MarkTaskSessionRolloutMissing query is removed. Must-fix 2 — the daemon withholds for all Codex tasks, but only the issue non-rerun claim consumed the disclosure. Now every fallback path sets prior_session_resume_unavailable: the manual-rerun branch reads the source task's session_rollout_missing, and the chat branch reads a new GetLatestChatTaskRolloutMissing. Tests (cross-layer DB): - completed + rollout missing via the real CompleteAgentTask terminal write -> session withheld AND gap flagged - failed + rollout missing forces session_id NULL over the COALESCE- preserved mid-flight pin in ONE statement Deploy order: migration + server first, daemon second (new fields are omitempty and ignored by an old peer). Co-authored-by: multica-agent <[email protected]> * fix(handler): return 5xx on FailTask error + cover claim-response gap paths (MUL-5305) Addresses review round 4 of #5960. Must-fix 1 — the FailTask handler returned 400 on a service/DB error, but the daemon's terminal callback treats 400 as permanent (postJSONWithRetry / isTransientError bails without retrying). Since the fail transaction is now the sole persistence point for the withheld session + continuity-gap flag + auto-retry, a rolled-back fail must be retried, so return 5xx (an invalid request body still returns 400), mirroring CompleteTask. Regression: client.FailTask retries on a transient 5xx and eventually succeeds. Must-fix 2 — add claim-response-level regressions that drive the two new disclosure branches through buildClaimedTaskResponse: - chat: the latest terminal task on the session withheld -> the next chat claim sets prior_session_resume_unavailable - manual rerun: the source task withheld -> the rerun claim discloses These handler DB tests run under CI's fully-migrated database (the local workspace DB cannot set up the handler fixture). Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Bohan-J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-27 13:12:06 +08:00
3 people	4fac8d772f	feat(attribution): Human Attribution Phase 1 (MUL-4302) (#5150) ... * feat(attribution): Phase 1 foundation — provenance schema + resolver (MUL-4302) Human Attribution, Phase 1 (地基) first increment. Every agent run must be traceable to exactly one accountable human AND record at which waterfall level that human was resolved, so a NULL originator can be told apart from a genuine 'no human in the chain'. - migration 149: add originator_source (waterfall label) + delegation/retry/ rerun/rule-version lineage + kind-tagged trigger evidence to agent_task_queue. No FK, no cascade, no CHECK on the source enum (MUL-4302 §7); nullable ADD COLUMNs = fast metadata-only change on the hot queue table. - internal/attribution: the accountable-human vocabulary (Source, EvidenceKind, TriggerKind) + pure, unit-tested classification rules (ClassifyComment/ ClassifyDirect). No DB, no authorization — provenance labeling only. - service: attributionFor{IssueTask,TriggerComment} gather facts and delegate to the pure classifier; the legacy originator resolvers now delegate here so there is one source of truth. originator_user_id's VALUE is unchanged, so the Composio-overlay and canInvokeAgent A2A authorization boundaries are byte-for-byte preserved (MUL-4302 §1.3). - enqueueIssueTask / enqueueMentionTask stamp originator_source + evidence; CreateRetryTask carries the parent attribution forward and records retry_of_task_id so retry and manual rerun stay separable (MUL-4302 §5). Verified: go build ./..., go vet, gofmt clean; new attribution unit tests + enqueue stamping integration test green; existing resolve_originator tests unchanged. Co-authored-by: multica-agent <[email protected]> * feat(attribution): split accountable_user_id from originator, close enqueue bypasses (MUL-4302) Phase 1, per Bohan's decision on the MUL-4302 thread: audit and authorization answer different questions and get different columns. - Migration 151 adds agent_task_queue.accountable_user_id (no FK, no cascade). Authorization keeps reading ONLY originator_user_id (canInvokeAgent A2A gate, Composio overlay); audit/UI/usage read accountable_user_id + source + evidence. - Invariant (finalizeAttribution, single chokepoint + §11 tests): originator non-null ⟹ accountable equals it. The two diverge only when originator is null (autopilot / degraded fallback), which is the deferred rule_owner/owner_fallback increment; this lands the column + mirror-write so that split has a home. - Close the NULL-source enqueue bypasses Elon flagged: chat, quick-create, deferred-fallback and run_only-autopilot now stamp originator_source + evidence (+ accountable where a human exists). Autopilot stays unattributed until the rule-version snapshot table lands, but is no longer a silent NULL-source row. Retry inherits accountable_user_id like the rest of the attribution lineage. - Fix assign/promote attribution (§4): a member who assigns/promotes an existing issue is now the accountable human (and, by the invariant, originator) ahead of the issue creator. Threaded as an OPTIONAL actor override, so comment/rerun/ autopilot paths keep today's resolution and create-with-assignee (creator == actor) is unchanged. The squad leader gate already judged the same member. Also merges origin/main: renumbers the attribution migration 149→150 (main took 149 for issue_origin_agent_create) and folds agent_create into ClassifyDirect's origin inheritance. go build/vet/gofmt clean; attribution unit tests + service stamp/actor tests + handler suite pass on a fresh DB migrated through 151. Co-authored-by: multica-agent <[email protected]> * docs(attribution): fix accountable NULL semantics + close chat/quick-create evidence boundary (MUL-4302) Addresses Elon's 2nd-round review on PR #5150 (pre-merge doc/evidence items): - Migration 151 no longer overclaims NULL. accountable_user_id is NULL not only on pre-migration rows but on NEW rows whose audit source resolved no human yet (run_only autopilot writes originator_source='unattributed' with NULL accountable until rule_owner lands). Header + COMMENT ON COLUMN reworded so a schema reader does not misjudge the invariant. - Chat now uses the UNIFORM evidence pair (kind=chat, ref=chat_session_id), like autopilot_run/issue_assignment, instead of relying only on the dedicated chat_session_id column — new EvidenceChat kind. Added a service test asserting chat stamps direct_human + chat evidence. - Quick-create is documented as the ONE intentional no-antecedent-row path: no comment/issue/session/run exists at enqueue time (the run creates the issue), so trigger_evidence_kind/ref stay NULL while the human rides originator/accountable and source is direct_human — not a NULL-source bypass. No authorization behavior change. attribution + service + handler suites pass on a DB migrated through 151. Co-authored-by: multica-agent <[email protected]> * chore(attribution): renumber migrations 150/151 → 157/158 after merging main (MUL-4302) main's #5162 ("unblock release migrations") renumbered the chat migrations and took 150 (agent_task_coalesced_comments) and 151 (chat_read_cursor), colliding with this branch's attribution migrations. Renumber them above main's new highest (156) so TestMigrationNumericPrefixesStayUniqueAfterLegacySet passes: - 150_agent_task_attribution → 157_agent_task_attribution - 151_agent_task_accountable_user → 158_agent_task_accountable_user Fixed the internal "migration 150" references in 158's header to 157. Migrations apply cleanly through 158 on a fresh DB; migration lint green. Co-authored-by: multica-agent <[email protected]> * feat(attribution): autopilot rule_owner — accountable = rule version publisher (MUL-4302) Implements rule_owner (MUL-4302 §3.4), the first attribution source where the accountable human diverges from the (NULL) authorization originator. - Migration 159 adds the append-only autopilot_rule_version snapshot table (no FK, no cascade); migration 160 adds its CONCURRENTLY lookup index. - Write-on-publish: CreateAutopilot appends v1 (publisher = creator); UpdateAutopilot appends a new version when a SUBSTANTIVE autopilot-row field changes (assignee / status / execution_mode) — cosmetic edits (title/description/template) write none. Both run inside the existing handler tx (atomic with the autopilot write). - Dispatch resolution: both autopilot execution modes now resolve the active rule version and stamp originator_source='rule_owner', accountable_user_id=publisher, rule_version_id=<snapshot>, with originator_user_id left NULL (authorization unchanged). run_only stamps CreateAutopilotTask directly; create_issue resolves in attributionForIssueTask so both modes attribute identically. A missing version / non-member publisher degrades to unattributed — never fabricates a human. - finalizeAttribution now enforces the invariant ONE-WAY: it mirrors originator onto accountable only when originator is valid, leaving an explicitly-set accountable (rule_owner / future owner_fallback) intact when originator is NULL. Added rule_version_id to CreateAgentTask so the create_issue path persists it too. Also merges origin/main and renumbers this branch's attribution migrations 150/151 → 157/158 (main's #5162 took 150/151); rule_version table is 159/160. Tests: attribution unit RuleOwner + one-way invariant table; service integration tests proving an autopilot-origin issue stamps rule_owner + rule_version_id (and degrades to unattributed with no version). Full service/attribution/handler/ migration suites pass on a DB migrated through 160; build/vet/gofmt clean. Deferred (same PR): trigger-table republish (cron/webhook/event_filters) and system-pause/archive versioning; owner_fallback + fail-closed; manual rerun. Co-authored-by: multica-agent <[email protected]> * fix(attribution): manual autopilot trigger → direct_human to the triggering member (MUL-4302) Elon's blocking finding: a member manually triggering an autopilot was attributed rule_owner (accountable = rule publisher, originator NULL) like a schedule/webhook run, so member B triggering member A's autopilot landed accountable=A and carried no originator authorization context for the run. Per MUL-4302 §4 a manual "run now" is a direct human action and must attribute direct_human to the triggering member. - Thread the triggering member from TriggerAutopilot into dispatch: new DispatchAutopilotManual carries actorUserID (resolved via resolveActor + memberActorUserID, so only a member actor is a human; an A2A agent actor falls back to rule_owner). DispatchAutopilot / DispatchAutopilotForPlan keep their public signatures (pass an invalid actor); only the internal dispatchAutopilot / dispatchCreateIssue / dispatchRunOnly gained the param, so the many existing callers are untouched. - run_only: dispatchRunOnly stamps direct_human (originator == accountable == actor, no rule_version) for a manual actor, else rule_owner. CreateAutopilotTask gains an originator_user_id param for the manual case. - create_issue: dispatchCreateIssue enqueues a manual trigger via the actor-carrying *WithHandoff entry points; attributionForIssueTask's autopilot-origin rule_owner branch is now guarded on !actorUserID.Valid, so a valid actor falls through to the direct_human override. Both execution modes attribute identically. - schedule / webhook keep rule_owner (no actor). Trigger-table + system-pause/archive versioning remain the pre-merge follow-ups. Tests: the run_only row assertion Elon asked for (schedule → rule_owner row on CreateAutopilotTask), plus manual direct_human on BOTH modes (run_only and create_issue), including a manual actor distinct from the rule publisher. Full service/attribution/handler/migration/scheduler/cmd suites pass on a DB migrated through 160; build/vet/gofmt clean. Co-authored-by: multica-agent <[email protected]> * feat(attribution): owner_fallback + fail-closed policy, and manual-rerun direct_human (MUL-4302) Two of the three remaining Phase 1 items (trigger-table / system-pause versioning is deferred — see PR description). owner_fallback + fail-closed (§1/§3.5) — the never-null accountable guarantee: - attribution.OwnerFallback degrades an UNATTRIBUTED result to owner_fallback: accountable = agent owner, originator stays NULL (audit-only, authz untouched), Source.Precise()==false. finalizeAttribution's one-way invariant already allows accountable-set / originator-NULL divergence, so nothing else changes. - Migration 161 adds workspace.attribution_fail_closed (default FALSE) + a lean GetWorkspaceAttributionFailClosed read. (Also added the column to ListWorkspaces' explicit column list so its row type stays db.Workspace.) - applyAttributionFallback is applied at every enqueue boundary (issue, mention, chat, quick-create, deferred-fallback, autopilot run_only): unattributed → owner_fallback (agent owner) by default, or ErrAttributionFailClosed when the workspace is fail-closed, which the caller surfaces to refuse the enqueue (the run does not start). So no run is left without an accountable human, and a compliance workspace can block unattributable runs instead. manual rerun (§5) — a rerun is a NEW direct_human trigger to the rerunning member: - RerunIssue threads the acting member (resolved in the handler via resolveActor) down to enqueueRerunTask, and attributionForIssueTask is now actor-first so the actor wins over an INHERITED trigger comment (a rerun keeps the comment for the daemon's prompt context but must attribute to whoever clicked rerun, not the original comment's human). - rerun_of_task_id lineage is recorded via a targeted SetAgentTaskRerunOf update on the rerun path only (keeping the shared CreateAgentTask insert untouched), so system retry (retry_of_task_id) and human rerun stay separable in reporting. Tests: OwnerFallback unit test; owner_fallback + fail-closed-refusal + manual-rerun (direct_human + rerun_of_task_id) service tests; the prior "degrades to unattributed" test updated to owner_fallback. Full service/attribution/handler/migration/scheduler/ cmd suites pass on a DB migrated through 161; build/vet/gofmt clean. Co-authored-by: multica-agent <[email protected]> * fix(attribution): close fail-open holes + move rerun_of_task_id into creation snapshot (MUL-4302) Addresses Elon's two must-fixes on PR #5150. 1. accountable-never-null / fail-closed had fail-open holes. applyAttributionFallback now, for an UNATTRIBUTED run, refuses the enqueue (ErrAttributionFailClosed) in THREE cases instead of silently degrading to a runnable NULL-accountable task: - workspace policy read fails (or no workspace) → fail closed; we cannot confirm fallback is permitted, so we don't run an unattributable task on a DB hiccup. (Only the rare unattributed path pays this; precise runs never read the policy.) - workspace is fail-closed → refuse (unchanged). - owner_fallback has no valid agent owner → refuse rather than enqueue a task with a NULL accountable_user_id. ErrAttributionFailClosed's doc now covers all three "cannot guarantee an accountable human" refusals. Added missing-owner / policy-read-failure / precise-passthrough tests. 2. manual rerun rerun_of_task_id was a post-notify UPDATE (race: the queued event / daemon claim could see rerun_of_task_id = NULL, and a failed update degraded the run to a plain direct_human). It now rides the CreateAgentTask insert — threaded through enqueueIssueTask / enqueueMentionTask as a creation param (like retry_of_task_id) so it is written in the same statement before the daemon is notified. Removed the SetAgentTaskRerunOf follow-up query. Also merges origin/main (unrelated CLI fix #5167, no conflict). Full service / attribution / handler / migration / scheduler / cmd suites pass on a DB migrated through 161; build / vet / gofmt clean. Co-authored-by: multica-agent <[email protected]> * feat(attribution): rule_owner versioning on trigger edits + system-pause/archive (MUL-4302) The final remaining Phase 1 item: substantive publishes beyond the autopilot row now republish the rule version, so a run's rule_owner accountable follows whoever last changed what the rule does. - Extracted the config-summary + insert into service.RecordAutopilotRuleVersion so the handler and the (different-package) failure monitor share one writer; the handler's recordAutopilotRuleVersion is now a thin wrapper. - Trigger edits: UpdateAutopilotTrigger and DeleteAutopilotTrigger republish the rule version with the acting member as publisher, ATOMICALLY (tx-wrapped mutation + version write, mirroring CreateAutopilot/UpdateAutopilot). CreateAutopilotTrigger republishes best-effort — the webhook path mints its token with a retry loop that cannot share one tx, and a create is usually initial setup already covered by v1; a failed write there is benign (active version stays the current publisher, the new trigger fires under it, no immediate daemon claim rides it). - Archive (DeleteAutopilot) republishes (member, status=archived), tx-wrapped. - System auto-pause (failure monitor) republishes with a 'system' publisher, best-effort — a background sweep to a non-dispatching state (a paused autopilot never dispatches; a later member resume supersedes). - RotateWebhookToken / SetSigningSecret deliberately do NOT version: they rotate credentials, not the rule's behavior (not §3.4 substantive). Semantics: a system-published (no-member) active version degrades dispatch to unattributed → owner_fallback, never fabricating a human. Tests: republish-reattributes (member A → member B supersedes → dispatch resolves to B; system publisher → unattributed). Full service/attribution/handler/migration/ scheduler/cmd suites pass on a DB migrated through 161; build/vet/gofmt clean. Also merges origin/main (unrelated frontend feature #5074). Co-authored-by: multica-agent <[email protected]> * fix(attribution): make trigger-create rule-version republish atomic (MUL-4302) Addresses Elon's final Phase 1 blocking finding: CreateAutopilotTrigger recorded the rule-version republish best-effort AFTER the trigger insert. If member B added a schedule/webhook trigger to member A's autopilot and the version write failed, future schedule/webhook dispatches would keep attributing to A — violating the rule_owner invariant that the last member to substantively change the rule owns future runs ("no immediate daemon claim" doesn't save it, since the miss surfaces at the LATER trigger firing). Both create paths now write the version in the SAME tx as the trigger INSERT: - schedule create: wrap CreateAutopilotTrigger + recordAutopilotRuleVersion in one tx. - webhook create: each mint-with-retry attempt runs in its own tx (insert + version commit together; a token collision rolls that attempt back and retries with a fresh token; a version-write failure rolls the trigger back). Passes ap + the acting member id into the helper. - removed the best-effort recordTriggerRuleVersionBestEffort helper (and the now-unused slog import). Test: TestCreateTrigger_RepublishesRuleVersionAtomically drives both create paths through the handler and asserts a rule version is published by the acting member. Existing webhook/trigger/archive handler tests still pass. Also merges origin/main (unrelated avatar feature #5074). Full service/attribution/handler/migration/ scheduler/cmd suites pass on a DB migrated through 161; build/vet/gofmt clean. Co-authored-by: multica-agent <[email protected]> * feat(attribution): Phase 2.1 — surface run attribution on the task API (MUL-4302 §9) First Phase 2 (visibility) increment: the agent-task API now returns the resolved accountable-human provenance so the UI can render an "on behalf of" badge. - AgentTaskResponse gains an `attribution` object: source label (never blank — pre-migration NULL renders "unattributed") + `precise` flag (false for the degraded owner_fallback / backfill / unattributed sources), the initiator (accountable) and originator (authorization) user refs, the evidence {kind, ref_id} pointer, and the rule_version / delegated / retry / rerun lineage ids. - The label + evidence + raw ids are built in the PURE taskToResponse (no DB), so every task response carries them. Names are hydrated separately, only on the user-facing surfaces (ListAgentTasks, ListWorkspaceAgentTaskSnapshot, RerunIssue, CancelTaskByUser) — daemon-claim paths stay lean. - Hydration resolves initiator/originator from the GLOBAL user table (departed-member safe) via a new batch GetUsersByIDs query (no N+1); best-effort, so a lookup hiccup leaves the raw ids intact. Tests: pure taskAttributionBase (direct_human / rule_owner NULL-originator / owner_fallback degraded / pre-migration→unattributed) + DB hydration (fills known ref, leaves unknown id un-filled, skips nil). Full handler/service/attribution/ migration/scheduler/cmd suites pass on a DB migrated through 161; build/vet/gofmt clean. The field is additive — the frontend's parseWithFallback ignores unknown keys, so nothing breaks until the UI increment consumes it. Also merges origin/main (unrelated editor feature #5090). Remaining Phase 2 (next increments, same PR): frontend zod schema + "on behalf of" badge + evidence-chain jump; append-only correction events (write + display). Co-authored-by: multica-agent <[email protected]> * feat(attribution): Phase 2.2 — on-behalf-of badge in the execution log (MUL-4302 §9) Surface the accountable human on every agent run row: - AttributionBadge composes Badge + ActorAvatar, shows "on behalf of <member>" with the resolution source as a tooltip; degraded (non-precise) attribution gets a warning tone, and an unresolved initiator renders an explicit "no responsible member" chip. - Wire the badge into both active and past rows of the execution log. - Mirror the attribution shape into AgentTaskResponseSchema (defensive, .loose()) so the cancel-task path carries it through zod; add parse tests. - Export TaskAttribution/AttributionUser/TaskEvidence from @multica/core/types and add the attribution block to all four issues.json locales. Co-authored-by: multica-agent <[email protected]> * fix(attribution): hydrate initiator names on issue-facing task endpoints + bound the badge (MUL-4302 §9) Address Elon's PR #5150 review: - ListTasksByIssue (the execution-log data source), GetActiveTaskForIssue and the issue-scoped CancelTask now call hydrateTaskAttributions, so the "on behalf of <member>" badge shows the real member name on issue detail instead of falling back to "someone". Mirrors the existing ListAgentTasks / snapshot behavior. - AttributionBadge: cap width (max-w-40, min-w-0) and truncate the name span so a long name / narrow right column can't squeeze out trigger/status/actions; keep the avatar shrink-0. - Add a handler test asserting the issue task list returns a hydrated attribution.initiator.name. Co-authored-by: multica-agent <[email protected]> * fix(attribution): use semantic AvatarSize 'xs' for the badge avatar main refactored ActorAvatar.size from a raw pixel number to the semantic AvatarSize union (packages/ui/lib/avatar-size). Switch the on-behalf-of badge avatar from size={14} to size="xs" (16px) after merging main. Co-authored-by: multica-agent <[email protected]> * fix(attribution): stage-cascade falls back to parent-issue provenance, not agent owner (MUL-4302) When closing the last sub-issue in a Stage wakes the parent's assignee agent, the run was enqueued via a system-authored child-done comment with no actor, which the resolver classified as unattributed and then degraded to owner_fallback (the agent's own owner). That is the wrong accountable human: the woken run should be accountable to whoever caused the parent issue to exist. attributionForIssueTask now detects a system-authored trigger comment and falls through to the parent issue's own provenance — the same creator / agent_create-origin / autopilot-origin chain a direct enqueue resolves (so an agent-decomposed parent attributes via delegation to the human who drove it; a member-created parent to that member; an autopilot parent to the rule publisher). owner_fallback is now only the last resort when the parent provenance itself has no human. - Extract attributionFromComment so attributionForIssueTask can inspect author_type without a second GetComment; authorization resolution stays byte-identical. - Add a DB-backed test asserting a system child-done comment resolves to the parent issue's origin human (delegation), not owner_fallback. Co-authored-by: multica-agent <[email protected]> * feat(attribution): autopilot runs attribute to the firing trigger's creator (MUL-4302) Per Bohan: an autopilot schedule/webhook run should be accountable to the human who created the SPECIFIC trigger that fired it, not the rule publisher. (Manual triggers already attribute to the invoking member via direct_human — unchanged.) - Migration 162: add autopilot_trigger.created_by_type/created_by_id (nullable, no FK/cascade). Capture the creating member at both trigger-create sites (schedule + webhook). - New precise source trigger_owner: originator stays NULL (an autonomous fire carries no human authorization — same authz-safe divergence as rule_owner), accountable = the trigger's member creator. - triggerOwnerAttribution resolves run.trigger_id → creator; wired into run_only dispatch and the create_issue path (bridging issue → active run → trigger_id). Legacy triggers with no recorded creator, and agent-created triggers, degrade to rule_owner then owner_fallback — nothing regresses. - Frontend: trigger_owner source label in all four locales + badge switch case. - Tests: attribution TriggerOwner unit + Precise/invariant; DB-backed resolver tests (member creator → trigger_owner; creatorless → rule_owner fallback). Co-authored-by: multica-agent <[email protected]> * chore(attribution): re-trigger CI (dropped synchronize event on 249090260) Co-authored-by: multica-agent <[email protected]> * fix(attribution): mirror accountable_user_id on comment-coalescing merge (MUL-4302) The one-way invariant is 'originator_user_id IS NOT NULL ⟹ accountable_user_id = originator_user_id', enforced at finalizeAttribution for enqueues and preserved by the retry-clone (copies both columns). But MergeCommentIntoPendingTask (main #5192) re-stamps originator_user_id to the newly-coalesced comment's human WITHOUT touching accountable_user_id — so folding member B's comment into member A's queued task left originator=B / accountable=A, violating the invariant. Re-stamp accountable to mirror the new originator (same thing finalizeAttribution does). Add a DB-backed regression test. Co-authored-by: multica-agent <[email protected]> * fix(attribution): Elon's 3 must-fixes + DB cross-column invariant CHECK (MUL-4302) Bohan approved Elon's plan; this closes the three attribution boundaries he flagged and locks the one-way invariant at the DB. 1. Delegation now inherits the parent's ACCOUNTABLE, not just its originator. An autopilot-rooted chain (parent originator NULL, accountable = trigger creator) @mentioning an agent / creating a sub-issue used to drop to unattributed → owner_fallback and fail-closed workspaces wrongly rejected the fan-out. Added ParentAccountable/OriginAccountable to CommentFacts/DirectFacts; ClassifyComment/ ClassifyDirect copy accountable down (source=delegation, precise, originator NULL) so the chain root stays stable at any depth (§3.2). 2. The direct-chat send path (SendDirectChatMessage, MUL-4351) wrote only originator_user_id — no accountable/source/evidence, a NULL-source bypass. It now stamps the full direct_human attribution like EnqueueChatTask. 3. Comment-coalescing merge re-attribution is now ATOMIC: MergeCommentIntoPendingTask re-stamps the whole snapshot (person columns + source + delegation lineage + rule version + evidence) of the new comment, not just the two person fields, so a merged run never shows B accountable while pointing at A's stale source/evidence. 4. Migration 169: NOT VALID CHECK (originator_user_id IS NULL OR (accountable_user_id IS NOT NULL AND accountable_user_id = originator_user_id)). Enforces the invariant on every new write (the class of bug #5192 introduced); historical rows not blocked, VALIDATE after Phase 3 backfill. Updated test fixtures that seeded originator-only rows to also set accountable. Merged latest main (renumbered attribution migrations 163–168 after main took 161/162; merged the retry-clone chat_input_task_id + attribution columns). Verified: go build/ vet, attribution/service/handler/cmd-server tests on a migrated DB, frontend typecheck/lint/tests. Co-authored-by: multica-agent <[email protected]> * fix(attribution): trigger responsibility transfers to effective publisher; fail-closed comment merge Elon final-review must-fix 1 (MUL-4302): trigger_owner now resolves to the member CURRENTLY responsible for the firing trigger's effective config, not the fixed creator. Per-trigger published_by on autopilot_trigger, seeded to the creator and re-stamped to the editor on a substantive edit — a trigger-scoped edit bumps only that row (UpdateAutopilotTrigger), an autopilot-level edit bumps all its triggers (UpdateAutopilot). Editing one trigger never reassigns another. Adds real dispatchRunOnly transfer test + resolver-level isolation test. Must-fix 3: AttributionForMergedComment reuses applyAttributionFallback and returns ErrAttributionFailClosed; the merge caller refuses on fail-closed, keeping the queued task's original precise snapshot instead of degrading it to owner_fallback. Adds regression test. Renumbered attribution migrations to 166-172 after merging main. Co-authored-by: multica-agent <[email protected]> * fix(attribution): make migration 172 invariant CHECK upgrade-safe (Option A) Elon final-review must-fix 2 (MUL-4302), rollout chosen by Bohan. The NOT VALID CHECK still checks a pre-existing row on any later UPDATE (even one not touching attribution columns), so cross-deployment stale queued/running tasks (originator set, accountable NULL from before migration 167) would fail on their next claim/complete/cancel. Exempt exactly those legacy rows via 'originator_source IS NULL' — that column was added in 166 with no backfill, so it is NULL only on pre-migration rows and non-NULL on every attribution-aware write. New writes stay fully enforced; the #5192 bypass class (source always set) is unaffected. Phase 3 backfills legacy rows then drops+re-adds the strict form + VALIDATE. Adds TestAttributionInvariantCheck_ExemptsLegacyRows (legacy row survives a status UPDATE) and updates the reject-bypass test to the enforced regime. Co-authored-by: multica-agent <[email protected]> * fix(attribution): pin substantive/cosmetic edit boundary for trigger transfer Elon re-review must-fix 1: an autopilot-level edit only transfers trigger_owner responsibility when it changes what the automation instructs or who/whether it runs. autopilotRuleSubstantiveChange now includes description (the run Prompt) and issue_title_template; title and project_id stay cosmetic/routing. UpdateAutopilotTrigger no longer transfers on every PATCH — it compares the persisted before/after and transfers only on a real cron/timezone/enabled/ event_filters change, not a label-only or no-op PATCH. Adds real handler tests (prompt->all, title->none, cron->one+isolation, label->none, no-op->none). Must-fix 3: real merge-path regression (TestMergeCommentIntoPendingTask_ FailClosedKeepsOriginalSnapshot) drives mergeCommentIntoPendingTask and asserts a fail-closed workspace preserves the queued task's full snapshot; fail-open control completes the owner_fallback merge. Docs: migration 172 comment reworded to legacy-writer/unbackfilled-lineage semantics (source NULL is not strictly pre-migration); PR description synced. Migration renumber vs latest main (must-fix 2) deferred to pre-launch per Bohan. Co-authored-by: multica-agent <[email protected]> * chore(attribution): renumber migrations to 167-173 after syncing main Merged latest main (which took 166_project_dates) and shifted the attribution migration series off the 166 collision: 166->167 agent_task_attribution, 167->168 accountable_user, 168->169 rule_version, 169->170 rule_version_index, 170->171 fail_closed, 171->172 trigger_publisher, 172->173 invariant_check. Updated the internal cross-references in the migration comments accordingly. Fixes TestMigrationNumericPrefixesStayUniqueAfterLegacySet on the merge tree. Co-authored-by: multica-agent <[email protected]> * feat(admission): unify dispatch outcome + close rerun/chat/autopilot invoke holes (MUL-4525) P0 first increment toward a platform-wide execution-admission contract so a user who names an execution target always gets a definite result and never a silent no-op, and so blocked targets are reported without leaking private-agent details. Backend: - New shared contract (handler/admission.go): DispatchOutcome / DispatchStatus (queued/coalesced/deferred/blocked) + stable, enumeration-safe DispatchReasonCode set, plus writeDispatchBlocked() whose legacy `error` string never reveals target existence. - Rerun (task.go / task_lifecycle.go): re-validate the operator can invoke the RESOLVED target agent (historical agent for a task_id rerun) before any cancel/enqueue; blocked returns a structured 403 and mutates nothing (ErrRerunInvokeNotAllowed). - Chat send (chat.go): re-run canInvokeAgent on every send, not just the softer canAccessPrivateAgent view gate; a revoked permission blocks before the message/attachments/task persist. - Autopilot manual "run now" (service/autopilot.go): admission now keys on the current CLICKER, not the autopilot creator — clicker admission and clicker attribution no longer fork. Automation (schedule/webhook) still falls back to the creator gate. Added reason_code to the run response for the UI. Frontend: - triggerAutopilot response is schema-parsed; handleRunNow branches on run status and shows a localized, reason_code-based warning for skipped/failed instead of a false-success toast. - Chat send and rerun surface the structured 403 reason_code as localized toasts (dispatchReasonCode helper) instead of a generic failure. - Additive fields only; older clients keep working. i18n added to all 4 locales. Tests: rerun fail-before-mutation gate, autopilot clicker-vs-creator fork (service + handler), reason-code classification, and a malformed-response schema test. Backend handler+service suites and FE typecheck/lint green. Co-authored-by: multica-agent <[email protected]> * test(cmd/server): thread nil invoke gate through RerunIssue call sites (MUL-4525) Co-authored-by: multica-agent <[email protected]> * fix(admission): typed reason codes + run-now whitelist + real security tests (MUL-4525) Addresses Elon's review of the P0 first increment (must-fix 1–3). 1. Run now no longer has a false-success branch. handleRunNow now classifies on a whitelist via a pure runNowToastKind(): only issue_created/running → success; skipped → warning; failed and any unknown/future status → error. Add run-now-toast unit test over all five status classes plus reason-code → key mapping. 2. reason_code is a typed value decided at the admission source, not reverse-engineered from English failure text. New leaf package internal/dispatch holds the canonical ReasonCode enum (shared by handler + service so they can never drift). shouldSkipDispatch / errDispatchSkipped / the fail path now carry a typed code through DispatchAutopilotManual straight into the response; the substring classifier is deleted. Fixes the two missed branches: attribution fail-closed → attribution_blocked (typed errors.Is), "agent has no runtime bound" → runtime_offline. Regression tests for both. 3. Security acceptance tests exercise the REAL handlers, not injected callbacks: - Chat: create session while invokable → revoke invoke (flip to private, keep owner-view) → send returns 403 + reason_code with zero chat_message / task writes. - Rerun: private historical agent through RerunIssue + canInvokeAgent — a non-invoking workspace owner is refused 403 + reason_code and mutates nothing (fail-before-mutation); the agent owner is allowed 202. No migration; reason_code is a decision-time value only the manual "run now" response carries. Additive on the wire. Backend build/vet/handler+service suites and FE typecheck/lint/vitest green. (Migration-prefix collision with main remains the deferred pre-merge renumber.) Co-authored-by: multica-agent <[email protected]> * test(admission): make must-fix 3 acceptance tests prove the invariant (MUL-4525) Addresses Elon's round-3 narrow review — the two security tests were not yet falsifiable against the bugs they must catch. - Rerun: after enqueuing the historical task, reassign the issue to a SECOND agent that the denied user CAN invoke. Now the current assignee and the task_id agent differ, so a rerun that wrongly validated the current assignee would let the denied user through — the 403 proves the gate is keyed on the historical private agent. The allow case now asserts the reran task's agent_id is the historical agent, not the current assignee. - Chat: the blocked send now carries a valid, still-unbound attachment. After the 403 the test asserts the attachment's chat_session_id and chat_message_id are both still NULL, guarding against anyone moving attachment binding ahead of the invoke gate. Test-only. Full internal/handler Go suite green. Co-authored-by: multica-agent <[email protected]> * feat(comments): surface blocked @mention trigger_outcomes instead of silent no-op (MUL-4525 §2) A comment that @mentions an agent/squad the author cannot invoke used to save with zero feedback — the user assumed a bug. Now the explicit-mention path reports a per-target outcome on both preview and create/edit. Backend (server/internal/handler/comment.go): - resolveMentionedAgentCommentTriggers collects blocked outcomes instead of a silent `continue`. The invoke gate is evaluated BEFORE any archived/runtime state is read, so a caller who cannot invoke a private target only ever sees the generic invocation_not_allowed and can never enumerate its existence. - enqueueCommentAgentTriggers returns queued/coalesced/deferred/blocked per explicit mention; enqueue errors are typed (attribution_blocked via errors.Is), not swallowed. Implicit routing (assignee/thread/conversation) carries no outcome — the user never named those targets. - trigger-preview returns `blocked[]`; create/edit return additive `trigger_outcomes[]`. One blocked mention never fails the comment. Frontend: - Composer shows a warning chip for blocked mentions before sending; after sending, a "posted, but N not triggered" toast (blocked-only; coalesced/ deferred are success-shaped). Additive schema + defensive parse; i18n ×4. Tests: handler partial-success + enumeration-safety acceptance tests; core outcome-parse + preview-schema tests; hook/parity updated. Backend handler+service suites and FE typecheck/lint/vitest green. Co-authored-by: multica-agent <[email protected]> * i18n(admission): clearer, consistent blocked-trigger copy (MUL-4525) Reword the awkward "you are not allowed to run this autopilot's assignee" and polish all MUL-4525 blocked/partial copy across en/zh-Hans/ja/ko: - Unify on "you don't have permission to use this <agent|target>" (zh: 没有…的 使用权限) for autopilot Run now, comment mentions, rerun, and chat send — replacing the various "not allowed to run/trigger" phrasings. - Align zh to the glossary term 智能体 (was mixed "Agent"), matching the surrounding UI voice (e.g. agent_link_no_access). - Drop jargon: "blocked by an admission policy"/"被准入策略拦截" → "the run was blocked"/"本次运行已被拦截"; "attributed"/"归因" → plainer wording. - Comment copy counts "mentions" (was "targets") for consistency with the chip. Backend dispatchBlockedFallbackMessage (old-client English fallback) reworded to match; its enumeration-safety test assertion updated. Copy-only — no key/logic changes; parity + typecheck green. Co-authored-by: multica-agent <[email protected]> * fix(comments): one outcome per explicit mention + FE success whitelist (MUL-4525) Addresses Elon's round-2 review of the §2 comment trigger_outcomes. 1. Separate execution dedup from per-target outcomes. resolveMentionedAgent- CommentTriggers now returns triggers (deduped by executing agent) AND one commentMentionTarget per EXPLICIT mention. enqueueCommentAgentTriggers returns a per-executing-agent result map; commentTriggerOutcomes fans each agent's status to every target that resolved to it. So @Agent A + @Squad S(leader=A) coalesces to ONE task but yields TWO outcomes. The squad-leader self-suppress branch now returns a definite `deferred` outcome instead of no result. New CreateComment test asserts 1 task, 2 outcomes. 2. Frontend no longer treats an unknown status as success. unhandledComment- TriggerOutcomes whitelists queued/coalesced/deferred as handled; blocked and any unknown/future/empty status warn (mirrors the Run now whitelist). The preview schema's `blocked` now drops malformed entries INDIVIDUALLY instead of z.array(...).catch([]) discarding the whole set. Regression tests for the unknown status and the per-item drop. Backend handler suite + go vet, FE typecheck/lint/vitest green. Co-authored-by: multica-agent <[email protected]> * fix(comments): honest role + status in trigger_outcomes fan-out (MUL-4525) Addresses Elon's round-3 review of the §2 fan-out. 1. Execution merge preserves the squad-leader role instead of first-mention- wins. The dedup now UPGRADES an already-added plain @agent trigger to a @squad-leader trigger for the same agent, so @Agent A + @Squad S(leader=A) always runs as a leader task (is_leader_task + squad_id=S) regardless of mention order — the daemon still injects S's briefing. When two DIFFERENT squads share one leader, the single run carries one squad's context and the other squad is reported `coalesced` (folded), never a second `queued`. The enqueue result now records the executed squad so the fan-out can tell them apart. Tests assert the task role in both orders and the two-squad split. 2. Squad-leader self-suppression no longer fakes success. The self-trigger guard keys on the latest task ROLE with no status filter, so a long-completed task also suppresses; reporting `deferred/already_active` when nothing is active was a false success. The branch now reports `deferred` only when a real non-terminal task is active (its reconcile covers the comment), else a non-success `blocked` + new `already_handled` reason. Fixed the reversed helper-semantics comment. New handler test covers the completed-task branch. Backend handler+service suites and go vet green. Co-authored-by: multica-agent <[email protected]> * fix(comments): fail-closed active-task check, never fake deferred (MUL-4525) Elon round-4 must-fix: hasActiveTaskForIssueAndAgent swallowed DB errors by returning true, so both call sites could turn a query failure into a success-shaped `deferred/already_active` — a silent false success, exactly what this issue forbids for admission-query failures. - hasActiveTaskForIssueAndAgent now returns (bool, error). - Two pure decision helpers govern the branches, fail closed on error: - decidePostMergeMiss: on query error, do NOT enqueue a fresh task (duplicate concurrent-run risk) AND report non-success blocked/internal_error; a confirmed active task defers; a confirmed-none enqueues fresh. - decideSuppressedLeaderOutcome: on query error, blocked/internal_error; a confirmed active run defers; else self_trigger_suppressed. Never a fabricated deferred. - Renamed reason already_handled -> self_trigger_suppressed (Elon non-blocking note): the old name implied the new comment was already processed, but the real meaning is a suppressed self-trigger. Deterministic unit tests cover the query-failure branch at both call sites (no fresh enqueue, non-success outcome) — a real DB fault can't be forced through valid handler inputs, and the decision is what governs the behavior. Backend handler+service suites and go vet green. Co-authored-by: multica-agent <[email protected]> * fix(comments): honest merge outcome — refused merge is blocked, not fake coalesced (MUL-4525) A pending-task merge previously reported success (coalesced) even when it was refused or failed: attribution fail-closed and unknown DB errors both returned handled=true, so the caller recorded coalesced for a merge that never happened. mergeCommentIntoPendingTask now returns a distinguishable commentMergeResult; commentMergeTerminalOutcome maps a real merge to coalesced, a fail-closed refusal to blocked/attribution_blocked, and any other failure to blocked/internal_error. Only "no queued task to fold" falls through to the active-task decision. Adds pure coverage of the mapping plus a fail-closed regression asserting the non-success outcome and unchanged task count. Co-authored-by: multica-agent <[email protected]> * fix(comments): name blocked @mentions in preview + toast instead of a vague count (MUL-4525) The blocked-trigger preview showed a red "1 mention won't trigger" with no name, and the post-send toast said "but 1 mention wasn't triggered" — the user can't tell which target or why. Now each blocked mention renders its own chip named from the mention markup the user typed ("Go · No permission"), with an error indicator and a short reason; the toast names the single target too. The wire outcome still omits the target name (enumeration-safety) — the label comes from the user's own draft, so nothing new is disclosed. Shares a blocked-trigger-copy module (long + short reason labels) between the chip and the toast, and a pure mentionLabelsByTarget/parseMentions helper in core (fresh regex per call — a shared global leaked lastIndex). Adds core + chip tests; drops the now-unused trigger_blocked_count keys across locales. Co-authored-by: multica-agent <[email protected]> * feat(attribution): accountable-member avatar on agent task rows + transcript header (MUL-4302) Surface who each agent run is on behalf of where runs are actually browsed: - Agent detail activity tab: an avatar-only AttributionBadge on every task row's meta line (Now + Recent work), tooltip carries the name + resolution source. - Execution-record (transcript) dialog header: the full on-behalf-of badge next to the status pill. Adds a compact variant="avatar" mode to AttributionBadge, reusing its source-label mapping and degraded-attribution tone. Renders nothing when a run has no resolved accountable member. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-15 03:09:56 +08:00
YYClaw	9eddcaff10	fix(chat): defer cancellation-time finalization until the task transcript is stable (#5246) ... A quick Stop before the agent's first token no longer races a late reply. Started-but-empty cancellations defer the empty/non-empty judgment until the daemon acks its transcript flush (or a grace-period sweeper fires), then settle to a single outcome. Empty outcomes persist a durable, creator-authorized draft restore (fetched/consumed via a dedicated endpoint, reconnect-safe and at-most-once) instead of broadcasting the prompt over the workspace bus. Closes #5219	2026-07-15 00:52:27 +08:00
3 people	e07b5403ab	MUL-4502: make autopilot webhook admission durable (#5386) ... * fix(autopilots): make webhook admission durable Co-authored-by: multica-agent <[email protected]> * fix(autopilots): address webhook delivery review Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-14 16:20:33 +08:00
3 people	cb87dd106b	feat(chat): task-owned direct-chat input batches + explicit no_response outcome (MUL-4351) (#5195) ... * feat(chat): task-owned direct-chat input batches + explicit no_response outcome (MUL-4351) Direct (web/mobile) chat no longer uses the last-assistant-row as an implicit input cursor. Each direct send now owns an immutable input batch: - agent_task_queue.chat_input_task_id makes a task the owner of the user messages it must consume; the send path creates the task + user message + attachment bindings + session touch in one transaction, and the daemon is notified only after commit. A claim reads exactly that batch, so a message that arrives mid-run belongs to the next task and is never absorbed. - Auto-retry inherits the root input owner and is queued at a bumped priority, created inside FailTask's transaction so no newer chat task can jump ahead. - CompleteTask writes exactly one assistant outcome inside the completion transaction: a normal message, or a visible no_response outcome (with a non-empty English fallback) when the final output is empty. The write failing rolls the completion back and the handler returns 5xx so the daemon retries; the status CAS keeps it idempotent. chat:done carries message_kind. - Web/desktop/mobile render no_response as a localized 'no text reply' state (keeping the tool timeline), suppress Copy, keep it unread, and keep the session-list preview non-blank. - Legacy/channel tasks (chat_input_task_id NULL) keep the trailing-message selector, so a rolling deploy never replays Slack/Lark history. Co-authored-by: multica-agent <[email protected]> * fix(chat): scope no_response to direct tasks; don't cancel task on input read error (MUL-4351) Addresses PR review (Niko): - writeChatCompletionOutcome only writes a no_response row for task-owned direct tasks (chat_input_task_id set). Legacy/channel (Slack/Lark) tasks keep the prior behavior: empty output writes no assistant row, so chat:done carries empty content and the channel outbound silently drops it — the no_response fallback body never reaches an external channel. - The daemon claim distinguishes a genuine zero-input batch from a failed input read: on ListChatInputMessages / ListChatMessages error it returns 5xx and preserves the dispatched task for redelivery instead of cancelling a valid task on a transient DB error. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-10 16:22:42 +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	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	c4997af4d1	fix: archive autopilots on delete (#5042) ... Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-07-07 20:49:42 +08:00
5 people	cb68669c73	feat(composio): gate MCP apps behind feature flag (#4876) ... * feat(composio): server-side connect flow + connections REST (Notion MVP) (MUL-3720) (#4608) * feat(composio): server-side connect flow + connections REST (Notion MVP) (MUL-3720) Compose the merged server/pkg/composio SDK into a user-facing connection manager: signed-state connect handshake, local user_composio_connection mirror, idempotent disconnect, and a per-user MCP session helper (not yet wired into task dispatch). - migration 127_user_composio_connection (no FK/cascade, per DB rules) - sqlc queries: upsert (idempotent on user_id+connected_account_id), list active, owner-scoped get, mark revoked - internal/integrations/composio: signed HMAC-SHA256 state, BeginConnect, CompleteCallback (idempotent upsert), ListConnections, Disconnect (upstream 404 = idempotent success), CreateMCPSession (no-op when empty, pins connected_accounts per toolkit), CallbackRedirect - REST handlers under /api/integrations/composio (user-scoped, 503 when COMPOSIO_API_KEY unset): connect/init, callback (302), connections list, delete - router wiring gated by COMPOSIO_API_KEY; COMPOSIO_AUTH_CONFIGS_JSON maps toolkit->auth_config (MVP: notion); state secret from COMPOSIO_STATE_SECRET or derived from JWT_SECRET; callback base from COMPOSIO_CALLBACK_BASE_URL or MULTICA_PUBLIC_URL - tests: state (expire/tamper/wrong-secret), service (mapping, callback idempotency, non-success, disconnect owner/404 idempotency, MCP pin), handlers (httptest), redact regression for Bearer mcp_ tokens MVP scope: Notion only; no task-dispatch overlay, sharing, or webhook event handling (later stages). Co-authored-by: multica-agent <[email protected]> * fix(composio): bind callback account to user + idempotent revoked disconnect (MUL-3720) Address PR 4608 review (CHANGES_REQUESTED): - callback: verify connected_account_id with Composio before mirroring it. The signed state only proved user/toolkit/exp, so a valid state paired with a tampered connected_account_id would be written verbatim. CompleteCallback now calls ListConnectedAccounts and fails closed (ErrAccountVerification) unless the account belongs to the state's user (composio_user_id == multica user id) and was created under the toolkit's auth config. No row is written on mismatch / unknown account / upstream error. - disconnect: short-circuit to a no-op when the local row is already revoked, before touching upstream. Previously a second DELETE re-hit Composio and a non-404 upstream error surfaced as a 502, breaking the 204-idempotent contract. - CreateMCPSession: document the v1 single-active-connection-per-(user,toolkit) constraint and make duplicate selection deterministic (newest-wins, rows are connected_at DESC) instead of order-dependent map overwrite. Stage 3 owns the real single-account-enforcement vs multi-account-shape decision. Tests: tampered/wrong-auth-config/unknown-account callback rejection, revoked-row disconnect no-op (asserts upstream not re-hit). composio pkg 85% coverage; all green. Co-authored-by: multica-agent <[email protected]> * feat(composio): list all toolkits + dynamic auth-config resolution (MUL-3720) Yushen's follow-up to the Notion MVP: surface the full Composio toolkit catalog, render it in Settings, and drop the static env mapping in favor of dynamic auth-config discovery. Config correctness (per Composio docs): - Remove COMPOSIO_AUTH_CONFIGS_JSON entirely. The toolkit→auth_config mapping is now resolved at request time from the project's /auth_configs (cached, 5-min TTL), so enabling a toolkit is a dashboard action, not a redeploy. - Do NOT add COMPOSIO_PROJECT_ID. The project API key (x-api-key) authenticates to exactly one project; the project is resolved from the key. Only org-level endpoints use x-org-api-key, which this integration never calls. Backend: - SDK: server/pkg/composio/auth_configs.go — ListAuthConfigs (toolkit_slug, is_composio_managed, show_disabled, limit, cursor). - service: dynamic resolver (authConfigMap cache; betterAuthConfig prefers a custom/white-label config over Composio-managed, newest wins); BeginConnect and CompleteCallback resolve via it; ListToolkits fetches the full catalog (paginated, capped) annotated with connectable = has an enabled auth config, connectable-first ordering. - handler + route: GET /api/integrations/composio/toolkits (user-scoped, 503 when COMPOSIO_API_KEY unset) returning slug/name/logo/category/connectable. Frontend: - core: ComposioToolkit/ComposioConnection types, api client methods, and composio query options (@multica/core/composio). - views: Settings → Integrations now has a Composio section rendering every toolkit as a card with search. Connect is gated on `connectable`; non-connectable toolkits show a muted "not configured" hint instead of a dead button. Connected toolkits show a badge + Disconnect (with confirm). - i18n: composio block added to en/zh-Hans/ja/ko settings. Tests: SDK + service (dynamic resolution, custom-over-managed preference, connectable flag, resolver-error soft-degrade) and handler toolkits endpoint; composio pkg 85.7% coverage. go build/vet/gofmt clean; core+views typecheck, core+views lint, and core tests (691) all green. Co-authored-by: multica-agent <[email protected]> * fix(composio): close cross-toolkit callback fail-open by signing auth_config_id into state (MUL-3720) Re-review blocker: CompleteCallback resolved the toolkit's auth config at callback time and ignored a resolve error/empty result, while verifyAccountOwnership skipped the auth-config comparison when the expected value was empty. A user could then pass another toolkit's connected_account_id into this toolkit's callback — the owner check passed and it was written under the wrong toolkit_slug/account binding. Fix: the auth_config_id is already resolved in BeginConnect (before the state is signed), so sign it into the state and compare it exactly at callback. No re-resolve, no fail-open. verifyAccountOwnership now fails closed when the expected auth config is empty (rejects instead of skipping) and requires an exact match — closing the cross-toolkit binding gap. Tests: state round-trips auth_config_id; BeginConnect signs it; callback rejects wrong/cross-toolkit auth config and an empty (no-mapping) auth config fails closed. composio pkg 85.2% coverage, all green. Frontend (non-blocking): the Composio settings tab now surfaces an error when the connections query fails instead of silently rendering everything as unconnected. Co-authored-by: multica-agent <[email protected]> * fix(composio): hide Settings section entirely when integration unconfigured (MUL-3720) Decision (option 2, hide-then-merge): don't show a card that leaks the internal COMPOSIO_API_KEY env-var name to every end user. IntegrationsTab now gates the whole Composio section (heading + body) on the toolkits query — a 503 means the key is unset, so the section is withheld instead of rendering the not-configured card. Admin-only setup guidance is a later, role-gated affordance. Removed the notConfigured card (and now-unused ApiError import) from ComposioTab; it only mounts when configured. views typecheck + lint clean. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]> * feat(composio): Stage 2 frontend polish — callback toast, last_used & expired UI, e2e (MUL-3718) (#4688) * feat(composio): callback toast + refresh, last_used & expired UI, e2e (MUL-3718) Co-authored-by: multica-agent <[email protected]> * fix(composio): real callback redirect route + StrictMode-safe toast dedup (MUL-3718 review) Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]> * fix(composio): callback endpoint should not require Multica auth (MUL-3843) (#4709) * fix(composio): move OAuth callback out of the Auth group (MUL-3843) Composio 302-redirects the browser to /api/integrations/composio/callback at the end of the OAuth flow, but PR #4608 mounted it inside the cookie-auth middleware group. When the session cookie is absent (expired session, SameSite=Strict / Safari ITP, private window, self-hosted callback subdomain) the Auth middleware returned a hard 401 and a JSON blob instead of the settings redirect, breaking the flow. Identity never came from the cookie anyway: it is carried by the HMAC-signed state param that CompleteCallback verifies (signature, expiry, replay) and cross-checked by verifyAccountOwnership; h.Composio == nil still 503s. So the callback is registered alongside the other public OAuth/webhook routes; the other four composio endpoints stay session-gated. Refs MUL-3843, MUL-3715. Co-authored-by: multica-agent <[email protected]> * fix(composio): correct stale callback routing comments (MUL-3843) The package header and ComposioCallback doc comments still described the callback as sitting under the Auth middleware group. After the route was moved out (this PR), update both to state it is a public route whose identity comes from the signed state — addressing review nit from 张大彪. Refs MUL-3843. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]> * feat(composio): inject MCP overlay into agent runtime at task dispatch (MUL-3721) (#4704) Stage 3 of the Composio epic. Wires the per-user Composio MCP session into every agent task so the agent process sees the initiator's connected tools without any prompt-time plumbing. Server side - Migration 128 adds agent_task_queue.runtime_mcp_overlay JSONB plus a BEFORE-UPDATE trigger that wipes the column on any transition into a terminal status (completed / failed / cancelled). A trigger is the single source of truth — future queries that flip status cannot bypass it. - composio.Service.BuildTaskOverlay(userID) reuses CreateMCPSession and emits the Claude-style { mcpServers: { composio: { type: http, url, headers } } } shape the daemon's existing sidecar generators consume. Returns (nil, nil) on zero active connections so we never burn a Composio session for a user with nothing to call. - TaskService grows a Composio ComposioOverlayBuilder seam, wired in router.go after composiointeg.NewService succeeds. Five enqueue paths (issue / mention / quick-create / chat / auto-retry) attach the overlay after CreateAgentTask returns and before the daemon is notified — so every claim reads a settled row, with no second daemon hop. Best-effort: a builder failure logs and proceeds with no overlay. - resolveInitiatorFromTriggerComment derives the initiator user from the trigger comment when it was authored by a member. Agent-authored triggers are not treated as initiators (their connected-apps view is empty by construction). Daemon side - handler/daemon.go claim path merges task.runtime_mcp_overlay onto agent.mcp_config via mergeMCPOverlay before populating TaskAgentData.McpConfig. Overlay wins on server-name collisions because it carries the live user-scoped session URL. Errors fall back to the agent config unchanged — a bad overlay must not surprise-disable saved MCP tools. The existing execenv sidecar generators (cursor / codex / openclaw / opencode / hermes-kiro) need no changes: they keep consuming the merged result through TaskAgentData.McpConfig. Tests - 9 merge cases (mcp_overlay_test): both-nil short-circuit, agent-only pass-through, overlay-only canonicalization, two-side merge, name collision (overlay wins), top-level key preservation, malformed agent fallback, malformed overlay fallback, non-object server rejection. - 4 dispatch cases (composio): zero-connections returns nil without CreateSession, happy-path emits the right shape with the right user id, empty-URL defensive branch, SDK error surfacing. - 4 TaskService helper cases: nil Composio is a no-op (Queries-safe), invalid initiator does not call the builder, nil overlay skips the UPDATE, builder error swallowed without panic. - Migration 128 verified to roll up + down + up cleanly against the test database. Out of scope (deferred): assignment-triggered enqueue paths with no trigger comment get no overlay attached today (no initiator UUID flows through enqueueIssueTask in that case). Retry paths recompute the overlay fresh from the parent's initiator_user_id instead of inheriting the bearer from the parent row, so a stale token can never resurface on a retry. Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(composio): per-agent allowlist + originator-scoped MCP overlay (MUL-3869) (#4736) * feat(composio): per-agent allowlist + originator-scoped MCP overlay (MUL-3869) Stage 3.1 of the Composio epic (MUL-3721 parent). PR #4704 wired in the runtime_mcp_overlay column and a per-task dispatch hook; this change inverts the default from "all-on" to opt-in and locks the overlay to the agent owner's own connected apps: - Agents carry composio_toolkit_allowlist TEXT[]. NULL or [] => no MCP. Owner-only read/write; non-owner GET/PUT silently redacts/drops the field (same shape as mcp_config). - agent_task_queue carries originator_user_id UUID. Set from the top-of-chain HUMAN at every enqueue path: * issue/mention comment by member -> author_id * issue/mention comment by agent -> inherit via comment.source_task_id -> parent task originator_user_id * quick-create -> requester_id * chat -> initiator_user_id * retry -> SQL-inherited from parent row * autopilot -> NULL (system-driven) - BuildTaskOverlay (composio dispatch) now takes (ctx, originatorUserID, agent) and short-circuits on five gates: invalid originator, originator != agent.owner_id, empty allowlist, empty intersection of allowlist ∩ active connections, defensive empty session URL. Composio CreateSession is called with BOTH `toolkits.slugs` (the intersection) AND `connected_accounts` (the pinned account ids), narrowing the tool-router twice. - The originator-vs-owner gate closes the agent-fanout privacy hole: any workspace member who can @-mention a public agent used to project the owner's connected apps into their run. Now the overlay only mounts when the human at the top of the chain IS the agent owner. Tests: - dispatch_test.go covers all 5 gates plus uppercase/whitespace slug normalisation. - task_runtime_mcp_overlay_test.go covers the no-op gates of the new applyRuntimeMCPOverlay signature. - agent_composio_allowlist_test.go (handler): owner roundtrip (list/empty/null), workspace-admin silent-drop, owner-only GET visibility, pure normaliseComposioToolkitAllowlist. - resolve_originator_test.go (service, DB-backed): member-authored, agent-authored inherits via comment.source_task_id, invalid id. Migration 129 up/down/up verified against docker postgres. Co-authored-by: multica-agent <[email protected]> * chore(composio): gofmt + regenerate sqlc with v1.31.1 (MUL-3869 review nits) Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(composio): accept nested connected account auth config * feat(views): creator-only MCP tab for per-agent Composio allowlist (MUL-3870) (#4743) Stage 3.2 frontend on top of the Stage 3.1 backend (MUL-3869, 4708dba97). Adds an agent-detail tab that lets the agent owner pick which of their own active Composio connections this agent may mount as MCP servers, writing the selection to agent.composio_toolkit_allowlist via the existing PUT /api/agents. - core/types: composio_toolkit_allowlist (+ _redacted) on Agent; tri-state composio_toolkit_allowlist on UpdateAgentRequest (omit/no-change, null/clear, array/replace), matching the backend contract. - core/agents: useUpdateAgentAllowlist - optimistic mutation hook (patches the cached workspace agent list, rolls back on error, invalidates on settle). - views: AgentMcpTab renders the owner's active connections as checkboxes; empty state links to Settings -> Integrations; defensive redacted state. - views: wired into AgentOverviewPane as tab "composio_mcp", labeled "MCP Apps" to disambiguate from the existing raw-JSON "MCP" (mcp_config) tab. The entry is gated to the creator (currentUserId === agent.owner_id), matching the backend's owner-only read/write of the allowlist. - i18n: tabs.composio_mcp + tab_body.composio_mcp.* in en/ja/ko/zh-Hans. - tests: agent-mcp-tab.test.tsx (gating, toggle->allowlist body, active-only, empty, redacted); e2e/agent-mcp.spec.ts (creator sees tab + PUT body, non-creator hidden) with Composio + agent endpoints mocked at the boundary. Note: the product spec says "creator"; the schema has no creator_id - the backend gate and redaction are keyed on owner_id, so the tab uses owner_id. Co-authored-by: multica-agent <[email protected]> * fix(composio): mount remote MCP for codex * feat(agents): agent invocation permission system (MUL-3963) (#4844) * feat(agents): agent invocation permission system (permission_mode + invocation targets) MUL-3963: split who may INVOKE an agent out of the overloaded visibility column into an explicit, extensible model on feature/composio-integration. - DB: agent.permission_mode (private|public_to) + agent_invocation_target table (workspace/member/team targets) + lossless backfill from visibility (migration 130). - canInvokeAgent: owner-only for private (NO admin bypass, NO A2A bypass); public_to honours the allow-list; A2A judged by the top-of-chain originator. - All trigger paths rewired: issue assign, comment @agent/@squad, chat, quick-create, autopilot, squad leader, child-done. - Agent API: permission_mode + invocation_targets on responses and create/update (owner-only writes); legacy visibility kept as a derived field so old clients never see a permission widening. - Composio: BuildTaskOverlay now FOLLOWS invocation permission and uses the agent OWNER connection (removed the originator==owner gate); front-end warns when a shared agent enables Composio apps. - CLI: --permission-mode / --public-to-workspace / --public-to-member (legacy --visibility still mapped). - Frontend: AccessPicker (Private / workspace / specific people / team soon), permission rules mirror canInvokeAgent, Composio warning banner. - Tests: migration backfill, admin cannot invoke others private, public_to workspace/member whitelist, A2A by originator, Composio overlay uses owner connection. Co-authored-by: multica-agent <[email protected]> * feat(agents): stackable, mixed public_to invocation targets (MUL-3963) Follow-up on PR #4844: public_to now supports selecting MULTIPLE, MIXED targets on one agent (e.g. Public to workspace + specific people + team), with canInvokeAgent admitting on ANY matching target (OR). - Frontend AccessPicker: reworked from a single exclusive kind into a stackable multi-select — an "Everyone in workspace" toggle, a member multi-select checklist, and a (disabled, v1) team placeholder can be combined freely. Emits the full union of selected targets; empty union collapses to Private. Existing team targets are preserved across saves. Added the access.public_group locale string (en/zh-Hans/ja/ko). - Backend already supported this (agent_invocation_target is multi-row per agent; create/update take a target ARRAY and batch-replace the whole allow-list; canInvokeAgent OR-matches). Added tests to lock it in: mixed member+team targets, overlapping-member batch replace, and workspace+member stacking then narrowing. Refs MUL-3963. Co-authored-by: multica-agent <[email protected]> * fix(agents): address review on invocation permission (MUL-3963) 张大彪 review on PR #4844 — three blockers + product ruling + nits: 1. Migration 130: drop the FK/cascade on agent_invocation_target (agent_id, created_by) per the Multica no-FK rule; relationships are now maintained in the app layer (matching MUL-3515 §4). Added DeleteAgentInvocationTargetsByArchivedRuntimeAgents and call it before DeleteArchivedAgentsByRuntime in all three runtime-delete paths (runtime.go x2, runtime_profile.go) so hard-deleting agents can't orphan target rows. 2. revokeAndRemoveMember: prune the leaving member's member-target grants (DeleteAgentInvocationTargetsByMember) in the same tx as the member-row delete, so a re-invited user can't reclaim a stale invocation grant. 3. Empty public_to is a phantom — parsePermissionInput now normalises a public_to with no resolvable targets to a single workspace target, so `--permission-mode public_to` alone (and any empty target array) means "public to workspace" instead of "shared but nobody can run it". Product ruling: the system/no-human-originator → workspace-target path in canInvokeAgent is a deliberate, documented exception (webhook/system/ workspace-wide automation); member/team targets still fail closed without a resolved originator. Documented in code + locked with a test. Nits: refreshed the stale "originator must be owner" comments — models.go (via migration 130 COMMENT ON COLUMN + sqlc regen for composio_toolkit_allowlist and originator_user_id) and agent-mcp-tab.tsx — to the owner-connection + invocation-permission rules. Tests: member remove/re-add regression, system workspace exception + member fail-closed, empty public_to → workspace (plus the earlier mixed/overlap/ batch-replace suite). Migration 130 applied to the test DB; Go handler/service/ composio suites green; views typecheck clean. Refs MUL-3963. Co-authored-by: multica-agent <[email protected]> * fix(agents): scope member invocation-target cleanup to one workspace (MUL-3963) 张大彪 3rd review — cross-workspace permission bug + comment nits: - DeleteAgentInvocationTargetsByMember was a GLOBAL delete by user id, so removing a user from workspace A also wiped their member-target grants on agents in workspace B. Scoped it to a single workspace by joining through agent.workspace_id; revokeAndRemoveMember now passes (workspaceID, userID). - Regression test TestRevokeMember_InvocationTargetCleanupIsWorkspaceScoped: same user allow-listed by agents in two workspaces; removal from one leaves the other workspace's target intact. - Nits: refreshed the remaining stale "originator == agent.owner_id" / "owner-vs-originator" comments — CreateRetryTask (agent.sql, regenerated), and the AgentResponse allowlist doc + ListAgents/UpdateAgent redaction rationale in agent.go — to the owner-connection + invocation-permission rule. Migration 130 applied to the test DB; Go handler/service/composio suites green; go vet clean. Refs MUL-3963. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]> * fix(agents): agent access owner-only editable, read-only for others (MUL-3963) (#4853) * fix(agents): make agent access owner-only editable, read-only for others (MUL-3963) Interaction bug: a non-owner (incl. workspace admin) could open the AccessPicker and set an agent public — the backend silently ignored it and the UI bounced back to private. Access is owner-only, so non-owners must see a read-only state and the backend must reject real changes explicitly. Frontend: - AccessPicker renders a static, non-interactive read-only state when the viewer is not the owner: the current access value + a lock affordance + a tooltip "Only the agent owner can change who can run this agent." No clickable trigger is rendered, so a non-owner can never open a control the backend would reject (the GitHub/Notion pattern for permission settings you can see but not edit). The editable multi-select picker is unchanged for the owner. - agent-detail-inspector gates the picker on ownership specifically (currentUserId === agent.owner_id), NOT the general canEdit (which also admits admins, who may edit other fields but not access). - New locale key access.owner_only_readonly (en/zh-Hans/ja/ko). Backend: - UpdateAgent now returns an explicit 403 when a non-owner submits a REAL permission change (permissionInputChangesAgent compares requested mode + target set against the persisted state); a no-op resubmit (admin PATCH-as-PUT echoing unchanged permission) is still tolerated so admin edits of other fields keep working. Replaces the previous silent-drop that caused the bounce. Tests: - access-picker.test.tsx: non-owner gets a non-interactive read-only display with the owner-only tooltip; owner gets an interactive picker; owner can pick a member and stack workspace + member. - TestUpdateAgent_AccessChangeIsOwnerOnly: admin real change → 403; admin no-op resubmit → 200; admin editing other fields → 200; owner change → 200. Incidental: fixed a pre-existing base typecheck break in slash-command-suggestion.test.tsx (stray `signal` arg not in the suggestion items type) that otherwise fails the whole @multica/views typecheck. Refs MUL-3963. Co-authored-by: multica-agent <[email protected]> * fix(agents): compare legacy visibility, not expanded permission, for no-op detection (MUL-3963) PR #4853 review: permissionInputChangesAgent expanded a legacy-only visibility:"private" into a real private permission and compared it against the agent's actual permission. A member-only public_to agent derives legacy visibility "private", so an admin PATCH-as-PUT echoing visibility:"private" while editing another field was misread as a public_to→private downgrade and rejected with 403 — contradicting the "unchanged permission no-op is allowed" contract. Fix (per review): when a request carries ONLY legacy `visibility` (no permission_mode / invocation_targets), derive the agent's CURRENT legacy visibility from its real targets and compare the legacy string values. Equal = no-op (allowed); a real legacy change (e.g. "workspace") still returns 403. Requests that carry permission_mode / invocation_targets keep the precise mode+target comparison. Regression test TestUpdateAgent_LegacyVisibilityNoOpForMemberOnlyPublicTo: member-only public_to agent — admin submitting visibility:"private" + a non-permission field → 200 with targets unchanged; admin submitting visibility:"workspace" → 403. Go handler/composio suites green; migration 130 applied; go vet clean. Refs MUL-3963. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]> * feat(composio): brief agents on connected apps * feat(composio): gate MCP apps behind feature flag * fix(mobile): parse agent invocation permissions * fix(tests): update agent fixtures for access fields --------- Co-authored-by: multica-agent <[email protected]> Co-authored-by: Multica Eve <[email protected]> Co-authored-by: Eve <[email protected]> Co-authored-by: Eve <[email protected]>	2026-07-03 14:18:43 +08:00
3 people	d970b68ce7	feat(autopilot): View/Write permission layer + member access delegation (MUL-3807) (#4695) ... * feat(autopilot): add View/Write permission layer Autopilot write and execute operations were gated only by workspace membership, so any member could edit, delete, trigger, or rotate the webhook of any autopilot, and GetAutopilot returned webhook tokens to every member (a token alone can trigger the autopilot). - Add canWriteAutopilot / requireAutopilotWrite: update, delete, trigger, replay-delivery, and all trigger/secret management now require the autopilot creator or a workspace owner/admin. - Redact webhook_token/path/url in GetAutopilot for callers without write access; trigger metadata otherwise stays visible (View default = all members). Creating an autopilot stays open to any member. - ANDs with the existing private-assignee-agent dispatch gate. MUL-3807 Co-authored-by: multica-agent <[email protected]> * feat(autopilot): delegate write access via collaborators + manage-access UI Adds an explicit grant primitive so an autopilot's creator/admin can authorize specific workspace members to manage it, with a frontend entry point — beyond the implicit creator/owner-admin set from the prior commit. Backend: - New autopilot_collaborator table (migration 128, members-only, app-layer cleanup, no FK) + sqlc queries. - memberCanWriteAutopilot now also honors explicit collaborators; the write gate, webhook-secret redaction, and a new per-caller can_write flag (on list + detail) all flow through it. - POST/DELETE /api/autopilots/{id}/collaborators (writer-gated); GetAutopilot embeds the collaborators list. Delete cleans up grants in its transaction. - Tests: grant->write->revoke flow, non-writer can't grant, non-member rejected. Frontend (web + desktop via packages/views): - ManageAccessDialog: member picker to grant/revoke, current list with remove. - 'Manage access' entry in the autopilot detail header; edit/run/add-trigger/ delete and the list-row kebab + per-trigger rotate/delete now gate on can_write (absent => allowed, server stays the gate). - can_write wired through types/schema/api client/mutations; en + zh-Hans copy. MUL-3807 Co-authored-by: multica-agent <[email protected]> * fix(autopilot): add manage-access i18n keys to ja/ko locales The locale parity test requires every non-EN bundle to cover every EN key. The prior commit added detail.manage_access + the access.* block to en and zh-Hans only, failing parity for ja and ko. Add the translated keys to both. Co-authored-by: multica-agent <[email protected]> * fix(autopilot): restrict access-list management to creator/admin only Final-review fix: AddAutopilotCollaborator/RemoveAutopilotCollaborator used requireAutopilotWrite, which counts granted collaborators as writers — so a collaborator could in turn grant/revoke others, a privilege escalation contradicting the 'collaborators cannot re-grant' design. - New requireAutopilotAccessManagement guard uses the narrower autopilotWriteByOwnership predicate (creator or workspace owner/admin only); swapped into both collaborator endpoints. Collaborators keep their edit/trigger/secret write-execute rights. - GetAutopilot now also stamps can_manage_access (narrower than can_write); the detail page gates the 'Manage access' button on it so collaborators no longer see an entry that would 403. - Tests: collaborator grant-others -> 403, revoke-peer -> 403, while retaining edit; can_manage_access true for owner, false for collaborator. MUL-3807 Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-06-30 12:29:11 +08:00
Multica Eve	5d79696fb5	MUL-3794: rewrite comment routing cascade	2026-06-30 12:24:57 +08:00
3 people	a252f47337	fix(scheduler): advance autopilot next_run_at after each scheduled dispatch (MUL-3749) (#4618) ... * fix(scheduler): advance autopilot next_run_at after each scheduled dispatch The display-only autopilot_trigger.next_run_at column was written only on trigger create/update and never advanced afterward, so for a recurring schedule it froze at a past slot and the list rendered it as a 'next run' in the past (e.g. '53m ago'). The intended AdvanceTriggerNextRun query was dead code with zero callers. Wire it up at the scheduler's existing post-dispatch seam (replacing the last_fired_at-only TouchAutopilotTriggerFiredAt bump, which AdvanceTrigger- NextRun already supersets). The advanced value is computed on the app local clock via ComputeNextRun — the same path create/update use — so the whole next_run_at display column is owned by one clock and stays consistent; scheduling itself is untouched and still runs off DB time via NextOccurrencesUTC. On a cron/timezone parse failure we fall back to the last_fired_at-only bump. Adds a deterministic regression test for the reported scenario (hourly cron in America/New_York) and documents the local-clock ownership on ComputeNextRun. MUL-3749 Co-authored-by: multica-agent <[email protected]> * fix(scheduler): floor next_run_at advance at plan_time to survive clock skew Addresses review feedback on the next_run_at write-back (MUL-3749): - The post-dispatch advance computed the value from time.Now() alone. The handler is entered only after DB time judged the plan due, so if this app instance's clock lags the DB clock at a period boundary, time.Now() could recompute the slot that just fired and next_run_at would not advance — the original staleness bug, at the boundary. Extract advancedNextRun, which anchors at max(now, plan_time) via NextOccurrenceAfterUTC so the written value is always strictly after the fired plan_time while still tracking the local clock in the normal case. - Add scheduler-layer tests asserting the written value is strictly after plan_time across skew / on-slot / normal cases. The previous service-layer test only exercised the helper with an explicit after, not this path. - Sync the stale ListSchedulableAutopilotTriggers comment: the scheduler now writes last_fired_at via AdvanceTriggerNextRun (sqlc regenerated). MUL-3749 Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-06-26 18:54:51 +08:00
3 people	3692b6a862	fix(squad): inject leader briefing by task flag, not issue assignee (MUL-3730) (#4606) ... * fix(squad): inject leader briefing by task flag, not issue assignee Key squad-leader briefing injection off task.IsLeaderTask + task.SquadID instead of issue.AssigneeType=='squad'. The old gate missed the most common path — an @squad mention in a comment on an issue assigned to a plain agent (MUL-3724) — so the leader booted with zero squad context and did the work itself instead of orchestrating. - migration 127: add agent_task_queue.squad_id (no FK) + partial index - sqlc: CreateAgentTask stamps squad_id; CreateRetryTask inherits it - service: thread squadID through EnqueueTaskForSquadLeader(+WithHandoff), enqueueMentionTask, and the rerun path; all 5 call sites pass the squad id - daemon claim: unified injection keyed on leader-task + squad_id, with a defensive leader-identity re-check; quick-create block retained (it serves issue-less tasks and sets resp.SquadID/SquadName) - briefing: strengthen leader Operating Protocol opening - tests: claim-time injection (comment-mention/non-leader/null-squad), squad_id enqueue stamping, retry inheritance; existing fixture updated Co-authored-by: multica-agent <[email protected]> * test+docs(squad): dangling squad_id regression + clarify quick-create path Address review nits on #4606: - Add TestClaim_LeaderTaskWithDanglingSquadID_NoBriefing: squad hard-deleted after enqueue leaves task.squad_id dangling (no FK); claim still 200 and skips injection via the err!=nil guard. This is the load-bearing contract for dropping the FK. - Rewrite the daemon.go injection comment to state quick-create does NOT use the is_leader_task/squad_id columns — it routes squad via the context JSON branch (qc.SquadID) and must not be folded into the column-based path. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: 魏和尚 <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-06-26 16:01:33 +08:00
Multica EveandEve	00b9668cd2	fix(autopilot): cold-start planner honors trigger.last_fired_at (MUL-3551) (#4495) ... Post-deploy of the new scheduled-dispatch scheduler (PR #4444), an autopilot configured for "weekdays 17:10 Asia/Shanghai" fired at ~12:30 Beijing the day after deploy — ~4h 38m before the next scheduled time the UI showed. Traced to a cold-start regression in the planner hook: Old behaviour ------------- On the first tick after migration the hook found no `sys_cron_executions` row for the trigger (`latestPlan(...).Found == false`) and anchored on the trigger's `created_at`, then applied the 24h replay cap: after := cfg.CreatedAt if oldest := now.Add(-replayWindow); after.Before(oldest) { after = oldest // now - 24h } For a trigger created days/weeks earlier and last fired by the legacy goroutine at Mon 17:10 Beijing (= Mon 09:10 UTC), this set `after = Tue 04:13 UTC - 24h ≈ Mon 04:13 UTC`. The half-open enumeration `(Mon 04:13 UTC, Tue 04:13 UTC]` STILL contained Mon 09:10 UTC — the occurrence the legacy code had already handled — so the new scheduler dispatched it again the moment it took over. The result: a SCHEDULED-source autopilot_run with planned_at = Mon 17:10 Beijing but a wall-clock dispatch at Tue ~12:30 Beijing. Timezone math was correct; the bug was purely the cold-start anchor not respecting prior-fire history. Fix Co-authored-by: multica-agent <[email protected]> --- The `autopilot_trigger.last_fired_at` column is maintained by both the legacy goroutine and the new scheduler (via TouchAutopilotTriggerFiredAt), so it is the authoritative "most-recent successful fire" cursor across the migration boundary. The planner hook now anchors cold-start enumeration on it: case latest.Found: after = latest.PlanTime case lastFiredAt != zero: after = lastFiredAt default: after = cfg.CreatedAt For the regressed case, `after = Mon 17:10 Beijing`, the next enumeration window is `(Mon 17:10, Tue 12:30]`, and Tue 17:10 is in the future — the hook returns nothing and the trigger waits quietly for Tue 17:10 as the UI promised. For brand-new triggers (last_fired_at NULL), the original `created_at` path still applies. For long-dormant triggers the `replayWindow` cap remains. Changes ------- * `ListSchedulableAutopilotTriggers` SQL now returns `last_fired_at`. * `autopilotTriggerConfig.LastFiredAt` is populated by the scope provider on every tick. * `autopilotPlansForScope` cold-start branch uses the new anchor. Tests ----- * TestAutopilotScheduleJobColdStartHonorsLastFiredAt — seeds the exact dev-environment shape (created 3 days ago, last_fired_at 5 hours ago, no sys_cron_executions row), runs a tick, asserts zero exec rows AND zero autopilot_run rows. Without the fix this test produces one of each at a historical plan_time. * TestAutopilotScheduleJobColdStartBrandNewTriggerStillFires — asserts a brand-new trigger (last_fired_at NULL) still fires its first due occurrence on cold start. All existing `TestAutopilotScheduleJob*` tests still pass. Refs MUL-3551 Co-authored-by: Eve <[email protected]>	2026-06-24 13:01:59 +08:00
3 people	131ca80a6c	refactor(autopilot): migrate scheduled dispatch to scheduler.Manager (3/3 MUL-3551) (#4444) ... * refactor(autopilot): migrate scheduled dispatch to scheduler.Manager PR 3 of 3 for the scheduled-Autopilot refactor on MUL-3551. Replaces the legacy cmd/server/autopilot_scheduler.go goroutine (30 s app-clock polling, app-time cron advancement, weak crash recovery) with a JobSpec registered on the existing scheduler.Manager. sys_cron_executions is now the lease + audit table for scheduled Autopilot occurrences, and the unique key on (job_name, scope_kind, scope_id, plan_time) is the primary guarantee that the same planned fire time cannot produce two runs. What changed * server/internal/scheduler/jobs_autopilot.go New AutopilotScheduleDispatchJob factory: - scope_kind = "autopilot_trigger", scope_id = trigger.id - PlansForScope hook (from PR 1) enumerates cron occurrences in (lastPlan, dbNow] and collapses missed fires to the most recent one (CatchUpLatestOnly — same policy the legacy goroutine had, now provable via a one-row-per-tick audit). - Handler re-loads trigger + autopilot inside the handler so a between-tick state change (paused, disabled, deleted) takes effect immediately and is recorded as a no-op SUCCESS row with skipped_reason in the result JSON. - Calls AutopilotService.DispatchAutopilotForPlan (from PR 2) for the actual run creation; that path is itself idempotent on (trigger_id, planned_at), so a stale-steal retry reuses the run created by the prior attempt instead of duplicating. - RunTimeout=2m, StaleTimeout=5m, HeartbeatInterval=30s, AllowStaleReentry=true, MaxAttempts=3, RetryBackoff [1m, 5m, 15m], MaxPlansPerTick=5 (safety cap). * server/internal/scheduler/manager.go Manager.runOnce promoted to RunOnce (exported) so external test packages can drive deterministic ticks; existing call sites in this package + cmd/server tests updated. * server/internal/service/cron.go NextOccurrenceAfterUTC and NextOccurrencesUTC: cron evaluators that take an explicit "now" instant. Callers pass dbNow() so schedule decisions stay consistent across app instances with clock skew. Legacy ComputeNextRun is preserved (delegating to NextOccurrenceAfterUTC with time.Now()) for the display-only autopilot_trigger.next_run_at write path — scheduling decisions no longer use it. * server/pkg/db/queries/autopilot.sql ListSchedulableAutopilotTriggers replaces the legacy ClaimDueScheduleTriggers (the new path no longer mutates autopilot_trigger.next_run_at on claim). RecoverLostTriggers removed — sys_cron_executions lease theft now handles crash recovery without an in-handler restart sweep. * server/cmd/server/main.go The "go runAutopilotScheduler(...)" line is gone. The new JobSpec is registered alongside TaskUsageHourlyJob on the existing schedulerMgr (still using sweepCtx for lifecycle). * server/cmd/server/autopilot_scheduler.go DELETED. Tests * server/internal/service/cron_test.go — unit tests for the cron helpers: timezone-aware enumeration, half-open (after, until] window, plan_time-exclusive "after", invalid inputs surface parse errors, and the "ignores wall clock" property the scheduler relies on. * server/cmd/server/autopilot_schedule_job_test.go — DB-backed integration tests: - DispatchesOnce: one tick → 1 SUCCESS exec row + 1 autopilot_run with planned_at set; a second tick does not regress the count. - MissedSchedulesCollapse: an hour of missed */5 fires produce a single autopilot_run, not 12. - CrashRecovery: simulated stale RUNNING lease at the same plan_time → second tick reclaims it and DOES NOT duplicate autopilot_run. - TwoRunnersSingleWinner: two concurrent scheduler.Manager instances on the same trigger → per-plan_time uniqueness holds (sys_cron_executions never has two RUNNING rows at the same plan_time, autopilot_run count == exec row count). - DisabledTriggerSkips: a trigger disabled between scope-list and tick produces no exec row. - PausedAutopilotSkipsAtHandler: an autopilot paused after the first tick does not produce a new exec row. - BadCronFailsLoudly: an invalid cron expression never fires dispatch (parse error surfaces in the plan hook). Existing autopilot listener / squad / dispatch tests still pass. * server/internal/scheduler/plans_for_scope_test.go from PR 1 still passes (RunOnce rename only). Verification * go build ./... * go vet ./... * go test ./internal/scheduler ./internal/service ./cmd/server ./internal/handler — all green. Rollback * Reverting this commit re-introduces the legacy goroutine. Migration 124 (PR 2) and the scheduler hook (PR 1) stay in place. Autopilot data on disk is forward- and backward- compatible: planned_at columns are nullable, the legacy goroutine never reads planned_at and the new job never reads autopilot_trigger.next_run_at. Refs MUL-3551 Co-authored-by: multica-agent <[email protected]> * fix(autopilot): scheduler hook retries FAILED plans + tighten tests Review fix for #4444 (MUL-3551). Blocker: hook planner skipped the FAILED-with-retry plan_time `autopilotPlansForScope` unconditionally set `after = latest.PlanTime` when `latest.Found`, then enumerated cron occurrences in the half-open interval `(after, dbNow]`. That EXCLUDED the FAILED plan_time itself, so `tryClaim`'s "FAILED-with-retry" branch — which only fires when the planner returns the same plan_time — never ran. A claim + crash sequence left the FAILED row stuck at attempt<max_attempts forever and the scheduled occurrence was lost (MUL-3551 acceptance ③). Fix: hook now branches on `latest.RetryEligible(now)` BEFORE computing `after`. When the most recent stored row is FAILED with attempts remaining and next_retry_at <= dbNow, the hook returns `[latest.PlanTime]` unchanged. tryClaim's retry-from-FAILED path fires, attempt increments, the run is retried, and the audit row reaches SUCCESS at the same plan_time. Mirrors the cadence planner's `info.RetryEligible(now)` branch in manager.plansForTick. Tests * TestAutopilotScheduleJobCrashRecovery rewritten to actually pin the retry contract instead of just "no duplicate run": - assert first attempt completes at attempt=1 with a real task_id linkage (the "complete" snapshot the retry must reuse); - simulate a crash mid-dispatch (status=RUNNING, expired stale_after, ghost lease_token); - assert tick 2 transitions the SAME exec row (same plan_time) to status=SUCCESS at attempt=2 (proving the planner did NOT skip past the FAILED bucket); - assert autopilot_run stays at exactly one row, reused from the first attempt — proving DispatchAutopilotForPlan's complete-run reuse path is what closes the loop. * TestAutopilotScheduleJobPausedAutopilotSkipsAtHandler rewritten to invoke `job.Handler` directly (the previous version drove `mgr.RunOnce` which short-circuited at the scope-list SQL filter and never reached the handler). The new test pauses the autopilot AFTER setup, calls the handler with a fabricated HandlerInput, and asserts the handler returns skipped_reason=autopilot_inactive without creating an autopilot_run. * TestAutopilotScheduleJobBadCronFailsLoudly renamed to TestAutopilotScheduleJobBadCronStaysSilent and updated to match the real implementation: a parse error in the plan hook surfaces as a manager-level warning log, NOT a sys_cron_executions row (no plan_time was ever claimed). The test now asserts zero exec rows AND zero autopilot_run rows, documenting that bad cron is a permanent configuration error (caught at HTTP create/update time first), not a transient failure that belongs in the retry envelope. Refs MUL-3551 Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-06-24 12:09:07 +08:00
3 people	eca6102365	refactor(autopilot): autopilot_run.planned_at + DispatchAutopilotForPlan (2/3 MUL-3551) (#4443) ... * refactor(scheduler): add PlansForScope hook for non-cadence jobs The current Manager.plansForTick assumes a uniform Cadence grid: plan_times are derived via FloorPlan(db_now, Cadence). That works for rollup_task_usage_hourly but not for the upcoming Autopilot schedule dispatch job, where each trigger has its own cron expression and the plan_times do not snap to a single global grid. This change adds an optional JobSpec.PlansForScope hook. When set: * Manager loads the latest stored plan for (job, scope) and passes a new LatestPlanInfo to the hook (exported from the previously private latestPlanInfo). The hook returns the plan_times to attempt this tick. * Cadence, CatchUpMode and CatchUpWindow are bypassed; the hook is in full control of plan_time selection. * MaxPlansPerTick still acts as a safety cap on the hook's output. * All other timing fields (RunTimeout / StaleTimeout / HeartbeatInterval / MaxAttempts / RetryBackoff / AllowStaleReentry) and the lease/heartbeat/terminal-write SQL primitives are reused unchanged. JobSpec.validate now allows Cadence=0 when PlansForScope is set, and makes the every_plan MaxPlansPerTick > 0 invariant fire only on Cadence-driven every_plan jobs. Existing rollup_task_usage_hourly behaviour is unchanged — that JobSpec leaves PlansForScope nil. Tests: * TestJobSpecValidatePlansForScopeRelaxesCadence — validate() rules. * TestManagerPlansForScopeHookDrivesPlans — end-to-end hook delegation through the manager (DB-backed), proving that hook-returned plan_times go through the same tryClaim path, MaxPlansPerTick truncates without erroring, and LatestPlanInfo is populated on the second tick. * TestManagerPlansForScopeHookEmptyIsNoOp — empty hook output is a valid no-op. No behaviour change for callers that don't set PlansForScope. Refs MUL-3551 Co-authored-by: multica-agent <[email protected]> * refactor(autopilot): add planned_at + DispatchAutopilotForPlan for occurrence idempotency PR 2 of 3 for the scheduled-Autopilot refactor on MUL-3551. Adds dispatch-layer idempotency for scheduled triggers. This is the second line of defence behind the primary uq_sys_cron_execution guarantee in sys_cron_executions: if a runner crashes between "create autopilot_run" and "write SUCCESS in sys_cron_executions", the next stale-steal retry re-enters dispatch with the SAME (trigger_id, planned_at). Without a row-level guard, that retry would create a duplicate autopilot_run, issue, and task. Changes: * Migration 124: ALTER TABLE autopilot_run ADD COLUMN planned_at TIMESTAMPTZ + partial unique index on (trigger_id, planned_at) WHERE both are NOT NULL. Manual / webhook / api dispatch leaves planned_at NULL so they keep the existing semantics unchanged. * autopilot.sql: CreateAutopilotRun now takes planned_at; GetAutopilotRunByTriggerAndPlanned is the fast-path lookup used by DispatchAutopilotForPlan to detect a prior attempt's row without burning an INSERT. * service.DispatchAutopilotForPlan: new entry point for scheduled triggers that already know the canonical UTC plan_time of the occurrence they are firing. Looks up an existing run for (trigger_id, planned_at) and reuses it on a stale-steal retry; otherwise dispatches normally with planned_at stamped on the new run. * service.DispatchAutopilot keeps its current signature for manual / webhook / api callers (planned_at stays NULL). * recordSkippedRun also threads planned_at so the skip path participates in the same partial-unique guarantee. * sqlc v1.31.1 regenerated autopilot.sql.go + models.go. Unrelated workspace.sql.go drift restored. Tests (against local Postgres): * TestDispatchAutopilotForPlanIsIdempotent — first call creates a run; second call with same (trigger, planned_at) reuses it (autopilot_run row count stays at 1); third call with a different planned_at on the same trigger creates a second run (proves we are not collapsing legitimate occurrences). * TestDispatchAutopilotForPlanRejectsZeroArgs — invalid trigger_id and zero planned_at both fail loudly so callers cannot silently disable the idempotency guard. * Existing autopilot listener / squad / dispatch tests all still pass. This PR has no scheduler / handler / UI behaviour change on its own: the new entry point exists but is not yet wired into the schedule goroutine. PR 3 will register the autopilot_schedule_dispatch JobSpec that consumes it and remove the legacy cmd/server/autopilot_scheduler.go path. Refs MUL-3551 Co-authored-by: multica-agent <[email protected]> * fix(autopilot): DispatchAutopilotForPlan recovers partial-state runs Review fix for #4443 (MUL-3551). Before this change, DispatchAutopilotForPlan returned ANY existing autopilot_run for (trigger_id, planned_at), including the half-written rows produced when a runner crashed between "CreateAutopilotRun" and "create downstream issue/task". The scheduler handler would then write SUCCESS in sys_cron_executions even though no issue or agent task was ever created, silently losing the scheduled occurrence. Fix: * New isAutopilotRunComplete helper classifies an existing run: - terminal status (completed / failed / skipped) → reuse. - issue_created with valid issue_id → reuse (the issue listener owns task creation from here). - running with valid task_id → reuse (the task is queued). - anything else → partial; must NOT short-circuit. * New SQL RecoverPartialAutopilotRun marks a partial row FAILED with a recovery reason AND clears its planned_at. The cleared planned_at releases the partial-unique slot in uq_autopilot_run_trigger_planned, letting the fresh dispatch INSERT a new row at the same (trigger_id, planned_at) without conflict. * DispatchAutopilotForPlan now branches on the lookup: complete run → return; partial run → recover-then-fresh- dispatch; not-found → fresh dispatch. The fresh dispatch path still goes through dispatchAutopilot, so the new row carries the real issue_id / task_id by the time the handler returns. * Tests: TestDispatchAutopilotForPlanRecoversPartialRun seeds a partial run (status='running', task_id=NULL for run_only; status='issue_created', issue_id=NULL for create_issue) and asserts the retry: - returns a DIFFERENT run row (no false reuse); - leaves the partial row in status='failed', planned_at=NULL, with a non-empty failure_reason for ops; - produces a fresh row with planned_at preserved AND the appropriate downstream linkage (task_id for run_only, issue_id for create_issue); - exactly one live row at (trigger_id, planned_at) after recovery, so the partial-unique constraint is honoured. Existing TestDispatchAutopilotForPlanIsIdempotent and TestDispatchAutopilotForPlanRejectsZeroArgs still pass — the complete-reuse path is unchanged for the realistic SUCCESS-state case. Refs MUL-3551 Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Eve <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-06-24 12:01:10 +08:00
3 people	5038c983c0	MUL-3281: Add daemon skill bundle refs (#4445) ... * feat: add daemon skill bundle refs Co-authored-by: multica-agent <[email protected]> * fix: tighten skill bundle resolve safeguards Co-authored-by: multica-agent <[email protected]> * feat: add task prepare lease Co-authored-by: multica-agent <[email protected]> * fix: isolate prepare lease concurrent index migration Co-authored-by: multica-agent <[email protected]> * fix: keep prepare lease active through start Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-06-23 16:19:16 +08:00
4 people	4ab335b8a5	MUL-3416: Issue pre-trigger preview + Handoff Note (#4383) ... * feat(issues): unify run-enqueue decision behind WillEnqueueRun + preview endpoint Collapse the issue update/batch enqueue copies into one service predicate service.IssueService.WillEnqueueRun, shared verbatim with a new dry-run endpoint POST /api/issues/preview-trigger so the four entry points stop drifting (squad/self-loop/batch omissions, MUL-3375). The private-agent gate stays at the HTTP boundary: write paths inject allow-all, preview injects the real gate so it never leaks a private agent's readiness. Add suppress_run to issue update/batch: the change applies but no run starts. Remove the now-dead handler mirrors shouldEnqueueSquadLeaderOnAssign / isSquadLeaderReady. service.Create and the comment trigger chain are untouched. Tests: preview behavior, preview<->write-path match, batch aggregation, member no-trigger, suppress_run skip, malformed-body 400. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(issues): inject handoff note into assigned runs via first-class task field Add an optional handoff_note carried by issue assign/promote into the run's opening prompt and issue_context.md, via a dedicated agent_task_queue column (migration 122) and a daemon assignment-handoff render branch — never a fabricated comment, never trigger_comment_id (MUL-3375 §6.1). Thread the note through enqueueIssueTask/enqueueMentionTask + WithHandoff public variants and dispatchIssueRun; suppress_run or a parked write drops it (no run = nothing to inject). Soft version gate: MinHandoffCLIVersion + HandoffSupported, surfaced per-trigger as handoff_supported in the preview so the UI can gray the note box on old daemons; the assignment never hard-fails. Tests: daemon prompt + issue_context render via the assignment branch (not quick-create/comment), version helper matrix, note persists on the task, suppressed assign enqueues nothing. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(issues): leave a display-only handoff record on the timeline When an assign/promote with a handoff note starts a run, write one type='handoff' timeline record via TaskService.RecordHandoff — a direct Queries.CreateComment + timeline event that bypasses Handler.CreateComment, so it never reaches triggerTasksForComment and cannot start a second run (MUL-3375 §6.2, the must-not-retrigger invariant). Author is the actor who handed off; body is the note. Migration 123 admits the 'handoff' comment type. Recorded only on a real run start: suppress_run or a parked write writes nothing. enqueueSquadLeaderTask now reports whether it enqueued so the trace is gated on an actual dispatch. Test: exactly one handoff record on assign-with-note, exactly one task (no re-trigger), and no record when suppressed. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(issues): frontend plumbing for issue-trigger preview + handoff (core) Add api.previewIssueTrigger + IssueTriggerPreviewSchema (zod parseWithFallback), the use-issue-trigger-preview hook, issueKeys.issueTriggerPreview(+All) with WS queue-state invalidation, suppress_run/handoff_note on UpdateIssueRequest, the 'handoff' CommentType, and stripping of the control fields from optimistic update/batch cache patches (MUL-3375 §9). Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * fix(issues): exclude handoff records from new-comment counting type='handoff' is a display-only timeline record, not conversation. Exclude it from CountNewCommentsSince so a handoff note never inflates the count of "new comments to catch up on" fed to a claiming agent (MUL-3375 §12). Analytics already excludes it (RecordHandoff is a direct write that emits no analytics event), and the comment-trigger path is already bypassed. Test: a handoff record does not bump the new-comment count; a real comment does. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(issues): pre-trigger preview UI, handoff note, timeline card (web/desktop) Wire the §9 frontend onto the preview endpoint + handoff fields: - Delete the backlog blocking dialog (backlog-agent-hint*) and its modal type; the over-eager nag is gone. Backlog awareness is now a passive label. - RunConfirmModal: single assign + batch assign/status route here. Shows the backend predicate's verdict ("将启动 @X" / "将启动 N 个" / parked), an optional handoff note (assign only, soft-gated by handoff_supported), and 暂不启动 — then applies via update/batch. No frontend guessing. - create modal: passive CreateRunHint ("将启动 @X" / backlog parked). - single status change stays a direct apply (unchanged). - timeline: render type='handoff' as a distinct, non-interactive handoff card. - i18n run_confirm + handoff_card across en/ja/ko/zh-Hans; drop backlog action keys; locale parity green. Tests: use-issue-actions (assign → run-confirm modal, member → direct), create-issue + comment-card suites updated/green; views typecheck + lint clean. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * test(issues): use a valid anchor in the handoff count-exclusion test CountNewCommentsSince filters id <> @anchor_id; SQL id <> NULL is NULL and excludes every row, so an empty anchor made the control assertion read 0. The production caller always passes a real anchor — mirror that with a non-matching sentinel uuid. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * test(issues): RunConfirmModal apply logic (start/suppress/note-gate/batch) Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * test(core): preview schema malformed/missing/null fallback coverage Cover IssueTriggerPreviewSchema via parseWithFallback (MUL-3375): well-formed parse, top-level + item default fills (empty/older backend), and fallback to { triggers: [], total_count: 0 } for malformed shapes, a dropped required issue_id, a wrong-typed total_count, and null/non-object bodies — so the four entry points degrade to "nothing will start" instead of throwing. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * refactor(issues): remove display-only handoff timeline record (留痕) The handoff "留痕" timeline record (type='handoff' comment written on run start) was judged superfluous and dropped per product call. This removes only the display-only trace; the handoff NOTE injection into the run's opening prompt + issue_context.md is untouched. - backend: drop RecordHandoff + its call in dispatchIssueRun - db: drop the `type <> 'handoff'` exclusion in CountNewCommentsSince and migration 123 (comment_type_check reverts to the 4-type set from 001); no production data exists for this unreleased feature - frontend: drop the "handoff" CommentType, HandoffCard, and handoff_card i18n (all locales) - tests: drop handoff_count_test.go and the record-write assertions in issue_trigger_preview_test.go (note-injection tests retained) Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * feat(issues): dismissable run-confirm modal + team-handoff copy Two fixes to the pre-trigger confirm modal (MUL-3375). 1. Dismissable: switch RunConfirmModal from AlertDialog to the standard shadcn Dialog so it has the close (X) button + Esc + click-outside. Previously the only choices were "start" / "don't start now" with no way to abort the action entirely; dismissing now cancels with no write. 2. Copy: rework the action-surface wording away from the backend term "run" toward team-handoff voice — 指派 / 开始 / 交接 (run stays only on record surfaces). Unifies the note's three names to "交接说明", and parallels the rewrite across en/ja/ko. Co-Authored-By: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]> * chore(agent): bump handoff note min CLI version to 0.3.28 The daemon release that renders handoff notes ships in 0.3.28 (0.3.27 was the prior tag), so move the soft-gate threshold up. Below this the note is silently dropped and the frontend grays the note box — assignment is never blocked. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> * fix(issues): skip run-confirm when batch-moving issues to backlog A move into backlog never starts a run (service/issue_trigger.go), so the pre-trigger confirm modal degenerated to an empty "won't start" box with a single Apply button — pure friction. Apply directly instead, matching the single-issue status path. Other target statuses still route through the modal. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> * feat(issues): refine pre-trigger preview hint and copy - Move the create-issue run hint to a reveal band (grid 0fr→1fr) above the property toolbar. It was sharing the footer button row and, lacking a width constraint, reflowed the submit buttons whenever it appeared. Restyle to a borderless, comment-style avatar+caption that is purely a caption (non-interactive avatar). - Distinguish squad from agent in the pre-trigger copy: a squad's leader evaluates and delegates rather than "starting work" itself. Add will_start_named_squad / will_start_squad / create_will_start_squad across en/zh/ja/ko (reusing the squad_leader_* evaluate→arrange vocabulary) and branch run-confirm + the create hint on squad assignees. - Bold the assignee name in the run-confirm headline via a language-safe sentinel split (no per-language prefix/suffix keys). - Align zh "开始处理" → "开始工作" on the single-assign copy. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> * test(issues): stub ActorAvatar in create-issue suite CreateRunHint now renders an ActorAvatar for agent/squad assignees, which pulls in getActorInitials/getActorAvatarUrl + the workspace/presence/navigation hook tree. This form-focused suite only stubbed getActorName, so the squad-forwarding test crashed with "getActorInitials is not a function". Stub the avatar inert — its own behavior is covered elsewhere. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> --------- Co-authored-by: Walt <[email protected]> Co-authored-by: Claude Opus 4.8 <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-06-23 13:17:13 +08:00
3 people	2d71872daa	feat(autopilot): default subscriber template (MUL-2533) (#3060) ... * feat(autopilot): default subscriber template (MUL-2533) — server Add per-autopilot member subscriber template that fans out to every issue the autopilot spawns. New autopilot_subscriber table; extend issue_subscriber.reason with 'autopilot' so the dispatch-time fanout is distinguishable from manual subscriptions. API: POST/PATCH /api/autopilots accept a `subscribers` array (member user_type only for the first version); PATCH semantics are full-replace. GET returns subscribers on the detail endpoint; the list endpoint omits them to avoid an N+1. Dispatch: dispatchCreateIssue lists the template inside the same tx as the issue insert and writes the rows with reason='autopilot' before EventIssueCreated fires, so notification listeners see the full subscriber set on the first event. Co-authored-by: multica-agent <[email protected]> * feat(autopilot): default subscriber template (MUL-2533) — frontend New SubscriberMultiSelect picker (members-only search + chips) wired into the create / edit AutopilotDialog. The detail page renders the saved template as read-only chips; edits flow through the dialog. TS types expose the new `subscribers` field on Autopilot, plus an AutopilotSubscriberInput shape for the create/update wire payloads. Co-authored-by: multica-agent <[email protected]> * fix(autopilot): notify template subscribers on issue creation (MUL-2533) The autopilot create-issue path fans out template subscribers into issue_subscriber inside the same tx as the issue insert, but the issue:created notification listener only matches handler.IssueResponse payloads and only direct-notifies the assignee + @mentions. The autopilot publishes a map[string]any payload, so the listener falls through and the template subscribers never receive an inbox item for the creation event — breaking OQ3 ("reason='autopilot' subscribers receive all subscription events, consistent with reason='manual'"). Fix it where the divergence lives: in dispatchCreateIssue, right after EventIssueCreated fires, write an inbox_item (type='issue_subscribed', severity='info') for each member subscriber and publish EventInboxNew so the recipient's inbox WS feed updates in real time. The write is after the tx commit so an inbox hiccup can't roll back the issue; failures are logged, not propagated. The manual path is unchanged — manual subscribers don't exist at creation time, so there is nothing to notify there. Adds a new InboxItemType 'issue_subscribed' (en/zh labels) and two covering tests in autopilot_subscriber_test.go: one asserts the inbox row lands for a template subscriber on dispatch, the other asserts the no-subscriber autopilot stays silent. Co-authored-by: multica-agent <[email protected]> * fix(autopilot): align subscriber PR with current main Co-authored-by: multica-agent <[email protected]> * fix autopilot subscriber template transaction 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:06 +02:00
Naiyuan QingandClaude Opus 4.8	63cf0ed308	feat(lists): rebuild all six list surfaces on a shared Linear-style list grid (#4038) ... * fix(issues): render thread replies in chronological order (#3691) collectThreadReplies walked the parent_id tree depth-first, so an agent reply forced to nest under its trigger comment rendered before earlier sibling replies (A-D-B-C instead of A-B-C-D) whenever the agent returned late. Sort the collected subtree by created_at (id tie-break) so the thread reads in arrival order — the same order the server already feeds agents via `comment list --thread` (ListThreadCommentsForIssue). All other consumers of the array (resolution derivation, fold bars, counts, deep-link) are order-independent. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(skills): rebuild skills list on shared Linear-style list grid - new ListGrid primitives (subgrid: single source of truth for column tracks) - skills list: sortable columns, used-by avatar stack, source/creator columns, row kebab + batch toolbar with add-to-agent and delete - skill view store in core; addAgentSkills client method; HoverCheck extracted to views/common (issues header now imports the shared copy) - locale keys for list actions/filters and the reworked detail page Co-Authored-By: Claude Fable 5 <[email protected]> * feat(skills): rework detail page into overview/files tabs - tabs directly under the breadcrumb header: overview (default) and files - overview: identity block + rendered SKILL.md as the main column, right rail with metadata card (source/creator/updated, inline name+description edit toggle) and used-by panel with bind/unbind - files: file tree + viewer/editor unchanged; SKILL.md "edit" jumps here - header kebab menu (copy skill ID, delete); page-level save bar shared by both tabs; tab state persisted in ?tab= - file tree: ARIA tree roles + roving-tabindex keyboard navigation - drop the old right sidebar (metadata dl, permissions paragraph) Co-Authored-By: Claude Fable 5 <[email protected]> * revert(skills): restore detail page to main, keep branch list-only Drop the overview/files tabs rework from this branch so the PR scope is the list rebuild only. skill-detail-page.tsx and file-tree.tsx are back to the main versions; the locale detail/file_tree sections are restored to match. The detail rework is preserved on stash/skills-detail-tabs for a follow-up PR. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(skills): drop description column from skills list Description is agent-facing routing metadata, not a scannable list property — Linear's display options expose no description column for the same reason. Removes the cell, column key, display toggle, lg grid track, skeleton cells, and the now-dead table.description / table.no_description locale keys. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(skills): drive list column hiding by container width, drop by priority Replace viewport sm:/lg: breakpoints with Tailwind v4 container query variants (@2xl/@4xl) on the list wrapper, so an open sidebar or split pane narrows the column set instead of squashing tracks. Remove the min-w-fit + overflow-x-auto horizontal-scroll fallback: when space runs out, low-priority columns (created/source/creator, then updated) drop and return as the container widens; name and usedBy never drop. ListGrid conventions comment updated — this is the template for all list pages. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(skills): virtualize list rows with @tanstack/react-virtual Linear-style headless virtualization: the virtualizer computes the visible index range and offsets; offsets land as padding on the scrolling ListGridBody so mounted rows stay direct subgrid children and column alignment is untouched. Fixed 48px rows skip per-row measurement. Hideable column tracks move from max-content to deterministic widths (CSS vars) — with only the visible slice mounted, content-driven tracks would resize during scroll. A user-hidden column zeroes its var so the track still collapses; per-cell max-w caps move into the tracks. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(skills): list tiers must fit their container trigger width The @4xl tier's track sum (~1080px with gaps) exceeded its 896px trigger; with the horizontal-scroll fallback gone, the right-side columns were clipped unreachably between 896-1080px. Move tier 3 to @5xl (1024px), trim usedBy/source/creator tracks, and document the fit invariant with its arithmetic next to the template and in the ListGrid conventions. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(skills): show description as subtext under the skill name Lives in the name track as a second truncated line (max-w 36rem, title attr for the full text) — no track, no header, no slot in the responsive arithmetic. Both lines fit the fixed 48px row, so the virtualizer contract is untouched; rows without a description center the name. Co-Authored-By: Claude Fable 5 <[email protected]> * Revert "feat(skills): show description as subtext under the skill name" This reverts commit f39721301b. * fix(skills): anchor batch toolbar to the page, not the viewport fixed bottom-6 left-1/2 centered the bar on the window; with the sidebar open the list's visual center sits ~120px right of the window center, so the bar looked off-center (worse with desktop split panes). Page root becomes the positioning context (relative) and the bar uses absolute — same rule applies to future list pages. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(skills): show matching count next to search while list is narrowed "n / total" appears right of the search box only when search or filters are active — idle state would duplicate the total already in the page header. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(autopilots): derive trigger kinds, next run, last run status in list The list endpoint only selected the autopilot table, so the list UI could not answer "is this automation working" without N+1 detail calls. Each list row now carries trigger_kinds + next_run_at (enabled triggers only — the columns describe how it fires today) and last_run_status (most recent run). Fields are omitempty and absent from detail/create/update responses; clients must treat them as optional per the API compatibility rules. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(autopilots): list schema, parsed client, and view store in core - listAutopilots now runs through parseWithFallback with a zod schema (this endpoint was a bare fetch — overdue per the API compatibility rules); malformed bodies degrade to an empty list, old-server rows without assignee_type or the new derived fields parse cleanly, and enum drift passes through as plain strings - Autopilot type gains the three optional list-only derived fields - New autopilots view store (scope/sort/columns/filters, persisted per workspace): status is the promoted scope dimension so it does NOT appear in filters — one dimension lives in exactly one place Co-Authored-By: Claude Fable 5 <[email protected]> * feat(autopilots): rebuild list on shared ListGrid with scope buttons Same skeleton as the skills list (container-query tiers, deterministic var-width tracks with documented fit arithmetic, virtualized 48px rows, sortable headers, filter + display toolbar, page-anchored batch toolbar), plus the autopilots-specific pieces: - Status is the promoted SCOPE dimension: 全部/运行中/已暂停/已归档 segmented buttons with full-set counts; "all" = active+paused (archived gets its own visible home, Linear archive semantics); status is therefore absent from the filter dropdown - Columns: name (paused marker inline), assignee (agent/squad), trigger kind badges, last run (outcome dot + time, enum-drift safe default), next run; mode/creator/created opt-in hidden - Filters: assignee, trigger kind, mode, creator (composite type:id values for polymorphic actors); sort name/lastRun/nextRun/created with lastRun desc default - Row kebab (pause/resume/archive/unarchive/delete) and batch toolbar share one delete dialog; status changes ride useUpdateAutopilot's optimistic cache - Fix noUncheckedIndexedAccess errors the branch had never typechecked (skills virtual rows, UsedByCell, added_toast) Co-Authored-By: Claude Fable 5 <[email protected]> * fix(autopilots): scope buttons follow the issues header pattern Replace the bespoke segmented-pill control with the existing scope button convention from the issues page: outline buttons with bg-accent active state on md+, collapsing to a radio dropdown below md. Counts stay (stage inventories from the full set). Co-Authored-By: Claude Fable 5 <[email protected]> * fix(skills,autopilots): toolbar small-screen treatment follows issues header Below md: the search box (and its result count) disappear entirely, and the filter/display controls collapse to square icon-only buttons (labels and the clear-X are md+), matching the issues header's responsive pattern. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(skills,autopilots): two-zone columns — WYSIWYG with scroll escape valve Static width tiers silently hid user-enabled columns (toggle on, nothing appears — autopilots' mode/creator/created sat behind a 1280px container gate no laptop reaches; skills' source/created behind 1024px). Tiers can't know how many columns are enabled, so the mechanism is replaced, not retuned: - ≥@2xl container: every enabled column renders; the grid carries min-width = Σ(enabled tracks + gaps) (pure constants, no measurement) and the wrapper scrolls horizontally only when the enabled set outgrows the container - <@2xl: static core set (skills: name+usedBy; autopilots: name+assignee), no scroll, toggles don't apply Per-tier templates and the hand-maintained fit arithmetic retire; ListGrid conventions updated accordingly. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(skills,autopilots): widen name column minimums (120px base, 200px wide) Co-Authored-By: Claude Fable 5 <[email protected]> * feat(autopilots): drop the archived scope and the list search box Archiving never existed as a UI flow (the DB status value is only reachable via direct API; the detail page disables its switch when archived), so the list stops inventing it: no archived scope, no archive/unarchive row or batch actions. API-archived rows are excluded everywhere; a persisted retired scope value falls back to "all". The search box goes too — scope buttons already partition the small set, search is redundant (product call). Skills keeps its search (no scope there). Co-Authored-By: Claude Fable 5 <[email protected]> * feat(skills,autopilots): quiet outline create buttons in page headers Page-header chrome shouldn't carry the loudest element on the page: the create button becomes outline with text on md+ and collapses to a square plus icon below md (same responsive treatment as the toolbar controls). Primary stays reserved for empty-state CTAs. Agents follows when its list migrates to ListGrid. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(agents): rebuild list on shared ListGrid with identity rows Same skeleton as the skills/autopilots lists (two-zone container responsiveness, deterministic var tracks + min-width scroll escape valve, virtualized fixed-height rows, issues-style scope buttons, page-anchored batch toolbar, quiet outline create button), plus the agents-specific decisions: - Identity rows: the documented exception to the single-line rule — avatar + name + description two-line cells, 64px rows (agents are few, identity-rich entities); the italic "no description" placeholder is gone, empty descriptions just center the name - Scope: Mine (historical default) | All | Archived with full-set counts; archived ignores the ownership lens; no search box - The 7d sparkline column is replaced by a sortable "Last active" column derived from the same 30-day activity buckets (zero API change) — per-row-normalized mini bars can't be compared across rows, and the default sort finally has a visible anchor; the detailed histogram stays on the hover card / detail page - Workload folds into the status cell ("Online · 2 tasks") — a 0-2 integer doesn't earn a column - Columns: status, runtime, last active, runs (30d); model/created opt-in hidden; filters: availability, runtime - Operations unchanged: row kebab reuses AgentRowActions (cancel-tasks/duplicate/archive/restore with permissions); batch archive (confirmed) + restore; no delete — the API has none - View store extended (scope incl. archived, sort, columns, filters); agent-columns.tsx (DataTable columns) deleted Co-Authored-By: Claude Fable 5 <[email protected]> * fix(agents): trim status track to its real worst case (160 -> 144px) Co-Authored-By: Claude Fable 5 <[email protected]> * feat(runtimes): machine detail's runtime table on the shared ListGrid The master-detail console keeps its shape (machines are few and strongly categorized; left list, charts, update section untouched) — only the right pane's runtimes table moves from TanStack DataTable to the ListGrid family, taking the paradigm pieces that earn their keep at 1-5 rows: subgrid template + var tracks, two-zone container responsiveness (the pane is squeezed by the machine list, so the core-set collapse below @2xl matters more here than on full-width pages), min-width scroll escape valve, shared header/row/hover visual language. Deliberately NOT taken: virtualization, sorting, filters, column toggles, and batch selection — dead weight at this row count, and batch-deleting runtimes (a cascade-confirm operation) is unsafe by design. Workload folds into the health cell ("Online · Working 2") like the agents status cell; the owner column keeps its only-when-multiple- owners rule via a zeroed track var. runtime-columns.tsx is deleted; the row-menu/CLI tests render the exported cells directly. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(runtimes): collapse the kebab track when no row has actions On a healthy local machine every row's only action (delete) is hidden by the self-healing rule, leaving a permanent ~64px dead zone after the CLI column. The action track now follows the owner column's conditional-var mechanism: zeroed unless at least one row will show the menu. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(runtimes): drop doubled header border, align create button with convention PageHeader already carries border-b; the content wrappers' border-t stacked a second line right under it (the only list page doing this). "Add a computer" follows the chrome-button convention: outline with text on md+, square plus icon below md — primary stays reserved for the empty state CTA. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(runtimes): health cell load suffix matches the agents status cell "Healthy · 2 tasks" instead of the old workload vocabulary ("Working 2 +1q") — the count is unit-bearing and both surfaces now speak one language. The queued-anomaly distinction the old words hinted at belongs to the health layer if it ever earns surfacing. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(lists): pin overflow-y-hidden on the horizontal-scroll wrappers CSS coerces overflow-x:auto into overflow:auto on both axes, which silently armed the list wrappers with a vertical scrollbar they were never meant to have. Combined with the h-full grid's percentage resolution across scrollbar-induced reflows, the wrapper's vertical bar and horizontal bar fed each other in a non-converging layout loop (visible as two stacked, flickering scrollbars on the agents list — the same latent loop exists in all four wrappers; agents' wider min-width and 64px rows just hit the trigger zone first). Vertical scrolling belongs solely to ListGridBody; declare overflow-y-hidden explicitly to break the loop. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(agents): single scroll container for the list (trial before rollout) Both scroll axes move to the outer wrapper; the grid drops h-full and the rows wrapper drops its own overflow. Kills the percentage-height bridge between the two scroll elements that fed the flickering double scrollbars and clipped the last row under the horizontal scrollbar. Sticky header pins inside the scroller; vertical scrollbar now spans the full pane (Linear's structure). Skills/autopilots follow after visual confirmation. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(lists): roll single scroll container out to skills/autopilots, add bottom clearance ListGridBody retires its own scrolling entirely (the agents trial confirmed the structure): both axes live on the single outer wrapper, grids drop the h-full percentage bridge, virtualizers point at the wrapper. The rows wrapper gains LIST_GRID_BOTTOM_CLEARANCE (64px) appended to the virtualization padding so the last row scrolls clear of the chat FAB (~48px at bottom-right) and the batch toolbar (~62px). Runtimes' machine table is untouched: content-height at the top of a tall pane, no bridge and no practical FAB overlap. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(squads): rebuild list on shared ListGrid (identity rows, minimal) The last list joins the family. Squads are the fewest entity (1-5 rows), so this is the agents identity-row shell on the runtime-list minimal skeleton: ListGrid subgrid + var tracks + two-zone responsiveness + single scroll container, but NO virtualization, checkbox, or batch. - Identity two-line rows (squad avatar + name + description, 64px) like agents; columns: name / leader / members (polymorphic ActorAvatar stack from member_preview), creator + created opt-in hidden - Scope Mine/All (creator-based, issues-header styling, <md dropdown); no archived scope (list API hard-filters archived + no restore endpoint), no search (scope-bearing), no filters (set too small) - Sort name (default) / members / created - Row kebab = Archive (= the delete endpoint, which archives + transfers issues/autopilots to the leader); workspace owner/admin only, so the kebab track collapses for non-admins. Reuses the existing archive_dialog copy. No batch. - View store extended (scope + sort + columns); zero API change — pure frontend (member_preview/count already in the list payload) Co-Authored-By: Claude Fable 5 <[email protected]> * feat(agents,squads): owner/created-by columns + owner filter Surface ownership as a real column on both lists, named by what the field actually means in each permission model: - Agents: "Owner" — owner_id is the creator (set at creation, never transferred) and carries management rights. Promoted to a default- visible column (avatar + name); the half-baked inline owner avatar in the name cell is removed ("You" badge stays). - Squads: "Created by" (NOT Owner) — creator_id holds no rights (archiving is workspace-admin only), so Owner would mislead. Now a default-visible column with avatar + name. Agents also gains an Owner filter, kept orthogonal to the Mine scope by the single-axis rule: "Mine" is the clean no-filter personal view, so applying any filter (owner or otherwise) leaves Mine for All, and clicking Mine clears all filters. Owner and Mine therefore never coexist — no "mine + owner=someone-else = empty" contradiction. Squads keep the plain Mine/All toggle (too few rows for a creator filter). Both lists keep a Created (date) column, opt-in hidden. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(agents): backfill new filter dimensions on rehydrate (owners crash) A view payload persisted before the owners filter existed overwrote the default filters wholesale on rehydrate, dropping filters.owners to undefined and crashing the list's filter predicate (.length on undefined). The store merge now deep-merges filters over EMPTY_AGENT_FILTERS so newly-added dimensions always get their default. Regression test added. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(skills,autopilots): deep-merge filters on rehydrate too Same latent crash the agents store just hit: the copied view-store merge spread persisted.filters wholesale, so adding a new filter dimension later would drop it to undefined for users with older persisted state. Harden skills and autopilots the same way (merge over their EMPTY_*_FILTERS) before that bug can ship. Co-Authored-By: Claude Fable 5 <[email protected]> * feat(projects): rebuild table view on ListGrid + filters + pin/delete kebab Projects is the dual-view list: the compact table moves onto the shared ListGrid (subgrid tracks, two-zone responsiveness, single scroll container, FAB bottom clearance) while the comfortable card grid stays as the alternate view, toggled by a restyled view switch (Table/Cards outline buttons, active = bg-accent). Inline editing is preserved — rows are NOT whole-row links; the name navigates and status/priority/ lead stay click-to-edit (matching prior behaviour, no navigate-vs-edit conflict). - View store extended: viewMode + sort (name/priority/status/progress/ created) + hidden columns + filters (status/priority/lead); merge deep-merges filters (migration-safe). No scope (lead optional/often an agent; status is a 5-value lifecycle → filter, not scope). - Toolbar: search (kept — scopeless list) + result count + Filter (status/priority/lead) + Display (sort+columns, table view only). - Row kebab: Pin/Unpin (any member, reuses the existing project pin API — zero new endpoints) + Delete (workspace admin). Pin is the flexible per-user favourite the list previously lacked. - Zero API change; status/priority filtering is client-side like the other lists. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(projects): GRID_COLS must be a literal string (Tailwind can't see interpolation) The table view's grid-cols template interpolated ${STATUS_WIDTH}px, so Tailwind never generated the arbitrary-value class — the grid collapsed to one column and every cell stacked vertically. Inline the literal 116px. This is the documented ListGrid rule (keep the class literal so Tailwind scans it). Co-Authored-By: Claude Fable 5 <[email protected]> * fix(projects): single view-toggle button, decouple Display from view mode Two fixes from the same principle — view mode is pure presentation and must not couple to anything: - The view switch is now ONE button that flips table ⇄ cards (shows the current view's icon+label, tooltip names the target), instead of two side-by-side buttons. - The Display (sort/columns) control no longer disappears when you switch to cards — it was gated on isCompact, so flipping the view made it vanish (the "filter gone after switching" weirdness). It's always present now; only the columns *section* inside the popover is table-only (cards have no columns). Sort applies to both views. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(projects,squads): projects multi-select + squads FAB clearance/toast Cross-list consistency audit fixes: - projects: add multi-select (checkbox column + select-all header + page-anchored batch toolbar) — it's a dozens-scale full-page list like skills/autopilots/agents but was the only one missing it. Batch ops: Pin all (any member) + Delete (workspace admin). Table view only (cards have no checkboxes). GRID template + min-width updated for the checkbox track. - squads: add the FAB bottom clearance the other full-page lists have (last row/kebab was sliding under the chat FAB). - squads: archive success toast was showing the dialog's question title ("Archive this squad?"); use a proper "Squad archived" key. Intentional and left as-is (documented): squads/runtimes have no multi-select/virtualization (1-5 rows); projects table isn't virtualized yet (dual-view + card grid; tracked as low-risk debt). Co-Authored-By: Claude Fable 5 <[email protected]> * feat(agents,squads): close the filter/column consistency gaps Apply the principle "every categorical column is filterable" where it was missing: - agents: add a Model filter (model was a categorical column with no filter). Distinct non-empty models from the in-scope rows. - squads: add filters entirely (it had leader/creator columns + a column-toggle panel but no Filter button — the only such outlier). Leader (agent) + Creator (member) filters, with the result count and the same Filter dropdown shape as the other lists. Store gains SquadListFilters + toggleFilter/clearFilters + migration-safe filters deep-merge. autopilots creator stays default-hidden per product call (not every "who made it" must be visible). Filter stores' partialize tests updated. Co-Authored-By: Claude Fable 5 <[email protected]> * fix(autopilots): match list-page root to flex-1 convention skills/agents/projects roots use `relative flex flex-1 min-h-0 flex-col`; autopilots used `h-full`. Both anchor the batch toolbar correctly, but align the flex sizing for consistency across the six list surfaces. Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]> --------- Co-authored-by: Claude Fable 5 <[email protected]>	2026-06-15 14:12:24 +08:00
3 people	24b162cdbc	feat(daemon): surface the real task initiator to the agent runtime (MUL-2645) (#3899) ... * feat(daemon): surface the real task initiator to the agent runtime (MUL-2645) In a multi-person workspace the agent runtime only ever saw the runtime OWNER identity: the brief's `## Requesting User` is sourced from runtime.OwnerID and the task-scoped token is owner-bound, so every requester (whoever commented, @mentioned, or chatted) appeared to the agent as the owner. Agents that route by initiator for permission, privacy, or audit all misjudged. Resolve the real task initiator at claim time and surface it distinctly from the owner: - comment / mention trigger -> triggering comment's author (member or agent) - chat task -> chat session creator (sessions are creator-only) - on-assign / autopilot / quick-create -> no attributable initiator (omitted) Adds initiator_{type,id,name,email} to the claim response, the daemon Task, and TaskContextForEnv, rendered into the brief as a new `## Task Initiator` section. The section documents the privacy boundary: the agent's credentials stay owner-scoped, so this is an attested identity for the agent's own routing/privacy logic, not act-as. No DB migration — both paths are derivable from existing rows. Tests: brief rendering (member/agent/omit/sanitize) + email guard unit tests, and claim-handler tests for the comment and chat paths. Co-authored-by: multica-agent <[email protected]> * fix(chat): store real sender as task initiator, not chat_session creator (MUL-2645) Review fix (Niko, PR #3899). v1 resolved the chat task initiator from chat_session.creator_id at claim time. That is correct for web chat and Lark p2p (creator == sender), but WRONG for Lark group chats: the group session creator is deliberately the installer (stable identity across member churn), not the message sender. So in a Lark group, every member who triggered the agent showed up in the brief as the installer/owner — the exact bug this issue is about, still live at that entry point. Capture the real sender at enqueue time instead of deriving it from the session creator at claim time: - migration 117: agent_task_queue.initiator_user_id (FK user, ON DELETE SET NULL); NULL for non-chat and pre-migration rows. - EnqueueChatTask now takes an explicit initiatorUserID. Web chat passes the authenticated request user; the Lark dispatcher threads the inbound sender (binding.MulticaUserID) through scheduleRun -> flushChatRun. The debouncer keeps the latest scheduled flush per session, so in a multi- sender silence window the LATEST sender wins (documented + tested). - claim handler resolves the initiator from task.initiator_user_id and drops the creator_id fallback entirely. The Lark group session creator stays the installer (unchanged) — only the task initiator is corrected, keeping the two concepts cleanly separate. Tests: dispatcher group regression (initiator = sender, not installer), latest-sender-wins, p2p initiator assertion; the chat claim handler test now sets creator != initiator and asserts the stored sender wins. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: J <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-06-08 19:29:57 +08:00
Raúl Anatol	2b5696703f	MUL-2703: feat(autopilots): webhook event filters per trigger (MUL-2334 follow-up) (#3231) ... * feat(autopilots): webhook event filters per trigger (MUL-2334 follow-up) Adds schema-backed event/action filtering to webhook triggers so operators can declare exactly which GitHub (or generic) events should spawn autopilot runs. Events outside the declared scope are recorded as ignored with reason 'event_filtered' — visible in the delivery log but without expensive run/task creation. Closes #3093 (supersedes the description-parsing approach from that PR). Backend: - Migration 108 adds event_filters JSONB to autopilot_trigger - sqlc queries updated for CREATE / UPDATE / LIST / GET - HandleAutopilotWebhook filters against trigger.event_filters before dispatch - Create/Update trigger handlers accept event_filters in the request body - Response shape includes event_filters so the UI can render it Frontend: - New WebhookEventFilterSection component in the autopilot dialog - Inputs for event name + comma-separated actions - i18n strings added (en + zh-Hans) Tests: - Unit tests for splitWebhookEvent and webhookEventAllowedByTriggerScope - Handler-level integration tests for filtered / allowed / no-filter paths co-authored-by: ZephaniaCN <agent/autopilot-webhook-filter> * fix: recognize gitlab/bitbucket/gitea as providers in splitWebhookEvent TestSplitWebhookEvent failed because only 'github' was recognized as a provider prefix. Extract isKnownProvider() to handle gitlab, bitbucket, and gitea as well. * fix(autopilots): address PR #3231 review for webhook event filters Must-fix from PR #3231 review: 1. event_filters now uses typed []WebhookEventFilter at the HTTP boundary instead of []byte. encoding/json was base64-encoding the field on the way out, so the UI could not .map() the response, and a real JSON array on the way in failed to decode. Response field also decodes the stored JSONB into a typed slice before serialising back. 2. UpdateAutopilotTriggerRequest.EventFilters is *[]WebhookEventFilter with tri-state PATCH semantics: nil pointer = leave alone, [] = clear, [...] = replace. The handler marshals an explicit empty slice to the JSONB literal `[]` so COALESCE overwrites instead of preserves. AutopilotDialog now PATCHes the webhook trigger when event_filters change in edit mode (previously the toast said "updated" while the backend was unchanged). 3. webhookEventAllowedByTriggerScope no longer short-circuits to false on the first event-name match whose actions don't line up. Earlier code silently shadowed any later filter that shared the same event name with disjoint actions. Robustness: validateWebhookEventFilters rejects empty event names / actions at write time, and the matcher fails closed on malformed stored bytes instead of widening the allowlist. Tests: handler tests now post real JSON arrays (the prior []byte path masked the contract bug). Adds round-trip / clear-with-[] / preserve- when-omitted / replace / invalid-filter / filters-on-schedule coverage, plus matcher tests for same-event multi-filter and malformed-deny. Migration renamed 108 → 110 to avoid colliding with main's 108_task_token (came in via the merge from main).	2026-05-27 15:47:36 +08:00
3 people	341ce7bfa5	feat: support local working directory for projects (MUL-2618 v1) (#3283) ... * feat(project): add local_directory project_resource type (MUL-2662) Adds a second project_resource type alongside github_repo so a project can be pinned to an existing directory on a specific daemon (the v1 of the local-working-directory flow tracked in MUL-2618). The ref schema is { local_path, daemon_id, label? }; local_path must be absolute and daemon_id is required. The same (daemon_id, local_path) pair is allowed on multiple projects by design — no UNIQUE constraint is added. Implementation reuses the existing project_resource API surface: the new type is wired through the validator switch with no migration, no new events, and no daemon-handler changes (daemon already passes through arbitrary resource types via ProjectResources). The CLI gains --local-path / --daemon-id / --ref-label shortcuts so `multica project resource add --type local_directory` mirrors the existing `--type github_repo --url ...` ergonomics; the generic --ref flag still works for both types. Tests cover the full CRUD lifecycle, the same-path-across-projects allowance, the same-path-same-project conflict, the validator rejections (missing/blank/relative path, missing daemon_id, wrong payload type), and the cross-platform isAbsoluteLocalPath helper. Co-authored-by: multica-agent <[email protected]> * feat(project): add update endpoint + label-shadow guard for project_resource (MUL-2662) Addresses the Elon review on PR #3263: - Add PUT /api/projects/{id}/resources/{resourceId} with sqlc query, matching handler, CLI `project resource update`, and a new EventProjectResourceUpdated WS event. resource_type stays immutable; ref/label/position are all individually optional. - Catch same-project (daemon_id, local_path) collisions where only the embedded label differs — the row-level UNIQUE only matches the full ref JSON, so a label typo would otherwise let the same working directory bind twice. - Tests cover the update lifecycle (label-only / ref / clear / 404 / invalid path) and the label-shadow conflict on both create and update; the in-place rename still succeeds because the conflict scan ignores the row being edited. Incidental: regenerating sqlc picked up a missing skills_local scan in UpdateAgentCustomEnv that drifted in from #3200. Co-authored-by: multica-agent <[email protected]> * fix(project): close bundled-create label-shadow gap + merge resource_ref on CLI update (MUL-2662) Two follow-ups from MUL-2662 review round 2: - CreateProject inline resources path now dedupes local_directory entries on (daemon_id, local_path) before opening the transaction. The DB-level UNIQUE(project_id, resource_type, resource_ref) constraint only fires on a full JSON match, so two rows with the same target but different `label` would otherwise slip past. Standalone POST/PUT already cover this via findLocalDirectoryConflict; bundled create was the missing surface. - `multica project resource update` now seeds resource_ref from the existing row before applying per-type shortcut flags, so `--default-branch-hint x` on its own no longer constructs a payload missing `url` (which the server 400s on). Local_directory partial edits get the same merge behavior. Co-authored-by: multica-agent <[email protected]> * feat(desktop): local_directory project_resource UI (MUL-2665) (#3273) * feat(desktop): local_directory project_resource UI (MUL-2665) First UI surface for the local-working-directory flow tracked in MUL-2618. Lets users on the desktop pin a project to an existing folder on this machine; web stays read-only since the per-daemon check can't be done in the browser. What's new for the renderer: - ProjectResourcesSection grows a desktop-only "Add local directory" button next to the existing GitHub-repo popover. Clicking it opens Electron's native folder picker, validates the path through a new IPC pair (existence + r/w), and submits a project_resource of resource_type=local_directory with daemon_id pulled live from daemonAPI.getStatus. - LocalDirectoryRow renders the rename pencil + path tooltip, and greys out when ref.daemon_id != this machine's daemon_id (with a "only available on the machine that registered this directory" tooltip). Delete stays enabled so users can drop stale registrations from any device. - LocalDirectoryHint sits above the issue-detail comment composer and shows "Agent will work in-place at {label} ({path})" when the issue's project has a local_directory matching this daemon. Hidden on web. - TaskStatusPill picks up a new "waiting_for_directory_release" stage that the daemon will publish when it dequeues a task but can't acquire the path lock. The render is in place now so the daemon sibling subtask can wire the status string without an additional UI PR. Plumbing: - @multica/core/types gains LocalDirectoryResourceRef + UpdateProjectResourceRequest, and the api client gets the matching PUT method backed by the server endpoint that landed in 2ac3faebb (MUL-2662). A useUpdateProjectResource hook drives the in-place label edit. - New Electron handlers under apps/desktop/src/main/local-directory.ts: local-directory:pick -> dialog.showOpenDialog (openDirectory) local-directory:validate -> stat + access(R_OK + W_OK) exposed through the preload as desktopAPI.pickDirectory / validateLocalDirectory. View code talks to them via a thin packages/views/platform helper that returns reason=unsupported on web instead of crashing. - useLocalDaemonStatus exposes the local daemon's id, device name, and running flag from daemonAPI.onStatusChange so the renderer can do the cross-device match without coupling to the desktop preload typings. Tests: - pickStageKeys gets a unit test covering the new stage and proving the directory-release status outranks availability hints. - LocalDirectoryHint tests cover the four render branches (no project, no daemon, foreign daemon, matching daemon). - i18n parity stays green; new keys added under projects.resources.* and chat.status_pill.stages.waiting_for_directory_release in both locales. Out of scope (will land separately): - The daemon-side waiting/lock signal that flips the pill into the new state. - Adding local_directory to the create-project modal's bulk attach flow. - Docs page refresh for project-resources.mdx — left for the MUL-2618 umbrella sweep. Co-authored-by: multica-agent <[email protected]> * fix(desktop): hide rename for foreign daemon local_directory rows (MUL-2618) Address review nit on #3273: the rename pencil was gated only by `canEdit`, so a foreign / unknown-daemon row still showed it even though the spec says cross-device rows are disabled. Gate rename on `!mismatch` so it disappears on those rows; delete stays available so a stale registration can still be dropped from any device. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]> * feat(daemon): local_directory execution + path mutex + GC exception (MUL-2663) (#3274) * feat(daemon): local_directory execution + path mutex + GC exception (MUL-2663) Wires up the daemon side of the local_directory project_resource introduced in MUL-2662. When a task is dispatched against a project whose resources include a local_directory pinned to this daemon's UUID, the daemon now: - Validates the path (absolute, exists, daemon process can read+write, not in the system-root / $HOME blacklist) and fails the task fast on any precondition violation, with a user-readable reason. - Serialises concurrent tasks on the same on-disk path via a daemon-local LocalPathLocker keyed by symlink-resolved realpath. The lock is held for the entire task lifetime (claim → context write → agent → result report). - When the lock is contended, the daemon flips the row to a new waiting_local_directory status on the server (carrying a wait_reason like "<path> (held by task <short id>)") so the UI can render "等待本地目录释放" instead of leaving the row silently in dispatched past the sweeper timeout. The status accepts being woken into running once the lock is acquired. - Sets execenv.WorkDir to the user's path (no copy, no mount). envRoot still lives under workspacesRoot/<wsID>/ and hosts output/, logs/, and .gc_meta.json — the daemon's logbook for the run. - Stamps GCMeta.LocalDirectory=true so the GC loop never RemoveAlls envRoot for these tasks (gcActionClean → gcActionCleanArtifacts, gcActionOrphan → gcActionSkip). The user's directory was never under envRoot to begin with, so this is defense in depth. - Skips execenv.Reuse for local_directory tasks because the prior WorkDir is the user's path and reusing it through that code path loses the envRoot association the GC loop needs. Prepare is cheap here (no clone, no copy), so always running it is fine. Server-side protocol changes: - New CHECK value 'waiting_local_directory' on agent_task_queue.status plus a wait_reason TEXT column (migration 109). - All cancel / active / counted-as-running / orphan-recovery queries expanded to include the new status; FailStaleTasks intentionally excludes it (the daemon owns the wait). - New SQL MarkAgentTaskWaitingLocalDirectory(id, reason) and a relaxed StartAgentTask that accepts both dispatched and waiting_local_directory as preconditions (and clears wait_reason on the way through). - New POST /api/daemon/tasks/{taskId}/wait-local-directory endpoint, TaskService.MarkTaskWaitingLocalDirectory broadcaster, and matching daemon Client.MarkTaskWaitingLocalDirectory. Tests cover: path blacklist + R/W enforcement, mutex serialisation + ctx-cancelled wait, lock handover between two tasks, GC never returns gcActionClean / gcActionOrphan for local_directory rows (with negative control for the standard path), and Prepare/Cleanup correctly substitute + protect the user's WorkDir. The desktop UI side (UI for adding a local_directory resource, surfacing the "等待本地目录" badge) is MUL-2665; the agent-task lifecycle changes (no branch switch, dirty-tree tolerant, auto-commit) are MUL-2664. This PR targets the shared MUL-2618 v1 feature branch agent/j/912b8cb1, not main; the whole v1 will be merged to main together when complete. Co-authored-by: multica-agent <[email protected]> * fix(daemon): tighten local_directory status, symlink, cancel handling (MUL-2618) Address the 3 must-fix items from Elon's review of PR #3274. 1. Status string unified. The server / daemon publish `waiting_local_directory`; align views, locales, and the pickStageKeys test (PR #3273 had used `waiting_for_directory_release` on a placeholder string). Without this, the daemon's wait state never reached the pill once the two siblings merged. 2. validateLocalPath now also runs the blacklist against the symlink-resolved realpath, with macOS's `/etc` -> `/private/etc` redirect handled via `isBlacklistedRealPath` which compares canonical forms. Without this, a symlink such as `/Users/me/proj/home -> /Users/me` slipped the literal $HOME check while every daemon write still landed in the user's home. Tests cover symlink-to-home, symlink-to-system-root, and the negative case (symlink to a regular subdirectory). 3. acquireLocalDirectoryLockIfNeeded now spins up a cancellation watcher inside `onWait` (lazy — the fast path stays free) so the gap between dispatch and StartTask responds to server-side cancel or row deletion. If the watcher fires while the daemon is parked on the path mutex, the lock-wait context is cancelled, Acquire returns promptly, and the helper exits silently the same way the run-phase poller does. New TestAcquireLocalDirectoryLock_CancelDuringWait exercises the path end-to-end with a fake server. Co-authored-by: multica-agent <[email protected]> * fix(daemon): unconditional canonical blacklist + Windows drive-root generalisation (MUL-2618) - validateLocalPath now always runs isBlacklistedRealPath on the symlink-resolved path, not only when it differs from absPath. The old guard let users type the canonical form of an OS-symlinked banned root (e.g. /private/tmp, /private/etc, /private/var on macOS) straight through, since EvalSymlinks is a no-op on already-canonical input. - Windows drive-root rejection moved off the static C/D/E/F enumeration onto filepath.VolumeName via a new isDriveRoot helper, so removable / network drives mounted at G:..Z: and UNC \\server\share roots are also blocked. systemRootBlacklist keeps the well-known C:\ trees only. - Tests: macOS-only case exercises direct /private/{tmp,etc,var}; a new TestIsDriveRoot covers the Windows generalisation (skipped on POSIX runners by runtime guard). Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]> * feat(views): wire waiting_local_directory end-to-end in issue UI + presence (MUL-2618) Connect the daemon-emitted `task:waiting_local_directory` and `task:running` events through to issue execution log, sticky agent banner, activity indicator, and agent presence so a parked task is no longer invisible on the issue page. - Add `waiting_local_directory` to `AgentTask.status` and the typed `task:running` / `task:waiting_local_directory` WS event payloads. - Chat realtime sync writes both new statuses into the pending-task cache so the chat StatusPill flips out of a stale `dispatched` frame. - ExecutionLogSection: count `waiting_local_directory` as active, add tone + status label, treat parked tasks the same as dispatched for time anchor / transcript visibility / terminate-confirm note. - AgentLiveCard: subscribe to both new events, rank the parked state between dispatched and queued, and surface a "is waiting for the local directory" banner with the muted "Clock" treatment used for queued. - IssueAgentActivityIndicator: route parked tasks into the queued bucket so the hover stack and chip stay visible. - derive-presence: parked tasks count toward `queuedCount` so the agent workload chip stays out of `idle` while the daemon waits on the path lock. - Locales: add `agent_live.is_waiting_local_directory` and `execution_log.status_waiting_local_directory` (en + zh-Hans). Co-authored-by: multica-agent <[email protected]> * feat(project): enforce one local_directory per (project, daemon) (MUL-2618) The daemon-side resolver picks the first matching local_directory by daemon_id, so allowing two rows on the same daemon — even at different paths — let the agent silently write into whichever sorted first. Tighten the invariant top to bottom: - server: `findLocalDirectoryConflict` rejects any second row sharing a daemon_id, regardless of `local_path` or label. Bundled-create surface in `CreateProject` runs the same daemon-scoped dedupe up front. - daemon: `findLocalDirectoryAssignment` fails fast when it finds more than one row pinned to the current daemon (older API client / direct DB writes can still produce that state — refuse to guess). - desktop UI: hide the "Add local directory" action once the current daemon owns a row on this project, with a hint and a defensive toast on the call path; foreign-daemon rows stay visible read-only as before. - Tests: * daemon: new `two local_directory rows on this daemon fail fast` / `local_directory rows on different daemons coexist` cases. * handler: rewrite the legacy `LabelShadow` cases as `DaemonScopedConflict` / `BundledLocalDirectoryDaemonConflict` — asserts 409 on same-daemon different-path, 201 on per-daemon bundles. - Locales: en + zh-Hans copy for the new hint + toast. Co-authored-by: multica-agent <[email protected]> * chore(sqlc): drop stale skills_local in UpdateAgentCustomEnv (MUL-2618) Follow-up to the main-merge in 0f8e8ca7: the auto-merge preserved most of main's skills_local revert but kept the column reference inside the UpdateAgentCustomEnv scanner because that block hadn't been touched by either side. Re-running `sqlc generate` regenerates the file without skills_local in this query, matching the rest of the file and the post-revert schema. Co-authored-by: multica-agent <[email protected]> * feat(create-project): binary source picker — repos OR local directory Turn the create-project dialog's "Repos" pill into a binary Source picker. A project's source is mutually exclusive: either a set of GitHub repos (worktree mode, default) or a single local working directory (local mode, desktop-only). Mirrors the constraint the backend will enforce next. Behavior: - Pill shows the active mode's selection (GitHub icon + repo count, or folder icon + local label/path). - Popover has a 2-tab segmented control at the top; the Local tab is hidden entirely on web (local_directory needs a daemon_id). - Local tab requires the daemon online — amber notice + disabled picker when offline, re-renders automatically via useLocalDaemonStatus. - Switching tabs preserves the other side's stash, but handleSubmit only emits the resource matching the active sourceMode, so abandoned picks never leak into the created project. Backend mutual-exclusion validation + the resources-section conditional-add-button still to come — this PR just unblocks the dialog so it can be demoed. * fix(mobile): cover waiting_local_directory in run row status maps (MUL-2618) --------- Co-authored-by: multica-agent <[email protected]> Co-authored-by: Multica J <[email protected]>	2026-05-27 13:44:31 +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
Angular	1f978bf1ec	feat(autopilot): link created issues to projects (#2908) ... * feat(autopilot): link created issues to projects * test(autopilot): cover project flag	2026-05-20 15:37:23 +08:00
3 people	fc8528d64d	feat(autopilot): support assigning to a squad (MUL-2429) (#2888) ... * feat(autopilot): support assigning autopilot to a squad (MUL-2429) Path A (Squad-as-Leader) from the RFC: when an autopilot's assignee is a squad, dispatch resolves to squad.leader_id and executes against the leader's runtime — semantics match a human manually assigning the issue to that squad, no fan-out. Backend scope only; frontend picker change is a follow-up PR. Changes: - 096_autopilot_squad_assignee migration: drop agent FK on autopilot.assignee_id, add assignee_type column (default 'agent'), add autopilot_run.squad_id attribution column. - service.AgentReadiness: single source of truth for archived / runtime-bound / runtime-online checks. Shared by autopilot admission gate, run_only dispatch, and isSquadLeaderReady. - service.resolveAutopilotLeader: translates assignee_type/id to the agent that actually runs the work. - dispatchCreateIssue: stamps issue with assignee_type='squad' for squad autopilots and enqueues via EnqueueTaskForSquadLeader. - dispatchRunOnly: belt-and-braces readiness re-check after resolving squad → leader so a leader that went offline between admission and dispatch produces a clean failure instead of a doomed task. - handler.CreateAutopilot / UpdateAutopilot: accept assignee_type with squad/agent existence + leader-archived validation. Backward-compatible default of "agent" preserves the contract for older clients. - Analytics: AutopilotRunStarted/Completed/Failed events carry assignee_type and squad_id; PostHog can now group autopilot runs by squad without joining back to the autopilot row. Co-authored-by: multica-agent <[email protected]> * fix(autopilot): reject archived squads, route post-admission skips, cleanup dangling-agent autopilots (MUL-2429) Addresses three review findings on PR #2888: 1. Archived squad handling: validateAutopilotAssignee now rejects squads with archived_at set; resolveAutopilotLeader returns errSquadArchived so the admission gate fails closed; DeleteSquad now mirrors the issue transfer for autopilot rows (TransferSquadAutopilotsToLeader) so surviving autopilots flip to assignee_type='agent' (leader) instead of dangling at the archived squad. 2. dispatchRunOnly post-admission readiness: introduces errDispatchSkipped sentinel, recognised by DispatchAutopilot via handleDispatchSkip so the run is recorded as `skipped` (not `failed`). Manual triggers no longer 500 when the leader's runtime goes offline between admission and task creation. New TestManualTriggerDoesNotErrorOnPostAdmissionSkip locks the behaviour in. 3. Dangling agent assignee after migration 096 dropped the FK: shouldSkipDispatch now distinguishes pgx.ErrNoRows / errSquadArchived (hard skip — retrying won't help) from transient DB errors (fail-open). DeleteAgentRuntime pauses autopilots that target agents about to be hard-deleted (ListArchivedAgentIDsByRuntime + PauseAutopilotsByAgentAssignees) so the breakage surfaces as a paused row in the UI instead of a quiet skip-burning loop. Unit tests cover the sentinel unwrap contract and errSquadArchived errors.Is behaviour. Integration test TestAutopilotDispatchSkipsWhenRuntimeOffline re-verified against a fresh DB with migration 096 applied. Co-authored-by: multica-agent <[email protected]> * fix(autopilot): bump last_run_at on post-admission skip (MUL-2429) Match recordSkippedRun (pre-flight skip) and the success path so the scheduler / "last seen" UI both reflect that this tick evaluated the trigger, even when the post-admission readiness gate caught a late regression. Addresses Emacs review caveat #1 on PR #2888. Co-authored-by: multica-agent <[email protected]> * feat(autopilot): mixed agent/squad assignee picker in dialog (MUL-2429) End-to-end UI for assigning an autopilot to a squad. Closes the PR #2888 backend gap: the squad-as-assignee feature was already wired in Go (Path A, RFC §4) but the desktop dialog never offered the choice. - core/types/autopilot: add `AutopilotAssigneeType`, surface `assignee_type` on `Autopilot` + Create/Update request payloads. - views/autopilots/pickers/agent-picker: switch to a polymorphic AssigneeSelection (`{type, id}`); render agents and squads as two grouped sections with shared pinyin search. - views/autopilots/autopilot-dialog: maintain `assigneeType` state, send it on create/update, render the trigger avatar / hover dot with `assignee.type`. - views/autopilots/autopilots-page + autopilot-detail-page: render the assignee row using `autopilot.assignee_type` so squad-typed autopilots show the squad avatar + name, not a broken agent lookup. - locales: add `agents_group` / `squads_group` / `select_assignee` keys (en + zh-Hans), keep legacy `select_agent` for callers that still reference it. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: Lambda <[email protected]> Co-authored-by: multica-agent <[email protected]>	2026-05-20 05:30:13 +02:00
Bohan Jiangandmultica-agent	2323b72710	feat(autopilots): webhook delivery layer + idempotency/signature/replay (MUL-2334) [PR1] (#2774) ... * feat(autopilots): webhook delivery layer + idempotency / signature / replay (MUL-2334) Splits "inbound webhook receipt" from "autopilot run creation" so we can record duplicate attempts, signature outcomes, and ignored/skipped deliveries — and replay a delivery on demand. v1 ingress wrote straight into autopilot_run.trigger_payload, which collapsed the two concerns and left run_only autopilots vulnerable to provider retry storms. Backend only (PR1). UI Deliveries tab follows in PR2. Schema (migration 093): - autopilot_trigger.provider: 'generic' | 'github' (default 'generic'). - autopilot_trigger.signing_secret: nullable plaintext (HMAC needs it cleartext; mirrors how webhook_token is stored). - webhook_delivery: one row per inbound POST. Carries raw_body, selected_headers, dedupe_key/source, signature_status, autopilot_run_id, replayed_from_delivery_id, response_status / body. - Partial unique index on (trigger_id, dedupe_key) excludes NULL and 'rejected' rows, so a wrong-secret 401 does NOT permanently block a future retry with the same X-GitHub-Delivery once the operator fixes the secret. Ingress flow (autopilot_webhook.go), persist-first + sync dispatch: 1. IP rate limit -> 2. token lookup -> 3. token rate limit -> 4. read raw body -> 5. autopilot/workspace cross-check -> 6. normalize JSON (400 without persistence on parse failure) -> 7. compute dedupe key + signature status -> 8. INSERT delivery (status=queued). On (trigger_id, dedupe_key) unique-violation: bump attempt_count on existing row and return the original delivery_id + autopilot_run_id with 200 -> 9. invalid/missing signature: UPDATE -> rejected, return 401 with delivery_id (no dispatch, not replayable) -> 10. trigger disabled / autopilot paused/archived: UPDATE -> ignored, return 200 -> 11. DispatchAutopilot synchronously, UPDATE -> dispatched/skipped/failed with autopilot_run_id and the response body we returned -> 12. TouchAutopilotTriggerFiredAt and return 200. No new long-running worker. A stale 'queued' row only happens if the process dies between INSERT and UPDATE; that's a follow-up sweeper, not this PR. Authenticated API: - GET /api/autopilots/{id}/deliveries (slim list) - GET /api/autopilots/{id}/deliveries/{deliveryId} (with raw_body) - POST /api/autopilots/{id}/deliveries/{deliveryId}/replay -> creates a new delivery row (replayed_from_delivery_id set), dispatches a new run, never collapses onto the original via dedupe. - PUT /api/autopilots/{id}/triggers/{triggerId}/signing-secret Write-only; trigger response surfaces has_signing_secret + signing_secret_hint (last 4 chars), never the secret itself. Signature verification reuses the GitHub-compatible X-Hub-Signature-256: sha256=<hex(hmac(body, secret))> scheme; the HMAC helper is constant-time. Invalid/missing signatures still count against per-IP and per-token rate limits. autopilot_run.trigger_payload is intentionally preserved — delivery records the HTTP receipt; run records the normalized envelope handed to the agent. They are two different views. Tests (Postgres-backed): - delivery persistence on accept - dedupe via Idempotency-Key and X-GitHub-Delivery; run_only retry storm pin (3 retries -> 1 run) - invalid signature: 401 + rejected row + no run linkage - missing signature when secret configured: 401 + 'missing' state - valid signature dispatches - signing secret never echoed in trigger responses; hint shows last 4 - min-length and clear-by-empty for signing secret PUT - replay creates a NEW delivery + new run; rejected deliveries cannot be replayed - list omits raw_body; detail includes it; cross-autopilot ID returns 404 (workspace isolation defense in depth) - provider validation: unknown -> 400, github -> 201 round-trips - bad-signature stream still counts against per-token rate limit Co-authored-by: multica-agent <[email protected]> * fix(autopilots): address PR review on webhook delivery layer (MUL-2334) - Exclude `failed` from the (trigger_id, dedupe_key) partial unique index alongside `rejected`, so a transient ingress failure does not strand the provider's stable X-GitHub-Delivery / Idempotency-Key retry. Update the dedupe lookup to prefer non-terminal rows under the same predicate. - Tighten delivery status enum: drop `skipped` from the CHECK constraint and from the handler. A run that was admission-skipped (e.g. runtime offline) is now recorded as delivery=`dispatched` linked to the skipped run, with the response payload carrying status=`skipped`. Source of truth for skipped-ness is autopilot_run.status, not the delivery row — keeps the Deliveries UI enum unambiguous. - On dispatch error, link the (possibly non-nil) autopilot_run returned by DispatchAutopilot to the failed delivery so Deliveries UI can navigate to the run row for debugging. - Slim list projection: ListWebhookDeliveriesByAutopilot no longer pulls raw_body / selected_headers / response_body — a 100-row page × 256 KiB would otherwise round-trip ~25 MiB from Postgres per Deliveries reload. Detail endpoint continues to return the full row. - Fix backend CI: TestGetDelivery_ReturnsFullPayload now decodes the response and asserts on the parsed raw_body instead of substring- matching against an escaped JSON string; raise the test-suite default webhook rate limits in TestMain so the shared 192.0.2.1 IP bucket doesn't fill across the suite and leak 429s into unrelated tests. - Add regression coverage for the dedupe-after-failure path. cd server && go test ./... is green locally. Co-authored-by: multica-agent <[email protected]> --------- Co-authored-by: multica-agent <[email protected]>	2026-05-18 14:59:40 +08:00
Kerim IncedayiandKerim Incedayi	9418d2a2c1	feat(autopilots): webhook triggers (server + CLI + UI + docs) MUL-2049 (#2348) ... * feat(server): add webhook trigger DB migration + sqlc queries Lays the foundation for webhook autopilot triggers: - partial unique index on autopilot_trigger.webhook_token (kind=webhook only) so the public ingress route can resolve a trigger in O(1) - GetWebhookTriggerByToken / TouchAutopilotTriggerFiredAt / RotateAutopilotTriggerWebhookToken / SetAutopilotTriggerWebhookToken queries, regenerated with sqlc * feat(server): webhook token generator + payload normalizer Two pure helpers for the webhook autopilot work: - generateWebhookToken: 32 random bytes -> base64-url, "awt_" prefix. 256 bits of entropy keeps brute-force off the table; the prefix makes leaked tokens recognisable in logs. - normalizeWebhookPayload: turns arbitrary JSON into the WebhookEnvelope shape (event/eventPayload/request) used by trigger_payload. Header- and body-based event inference covers GitHub, GitLab, X-Event-Type, and caller-provided envelopes; scalar/empty/invalid bodies are rejected so the handler can answer 400. * feat(server): generate webhook tokens and expose rotate endpoint - New handler.Config.PublicURL fed by MULTICA_PUBLIC_URL env so /api/autopilots/.../triggers responses can include an absolute webhook_url alongside the always-present webhook_path. - CreateAutopilotTrigger now mints a webhook_token via crypto/rand for kind=webhook and ignores cron/timezone for non-schedule kinds. api triggers stay accepted-but-inert per PLAN.md. - New POST /api/autopilots/{id}/triggers/{triggerId}/rotate-webhook-token protected by the existing workspace auth group; old tokens stop working immediately because the unique-index lookup keys on the current row value. * feat(server): public webhook ingress route + per-token rate limiter - New POST /api/webhooks/autopilots/{token} route, mounted outside the authenticated group: the path token is the credential. Workspace context is derived from the joined autopilot row, never headers. - Body capped at 256 KiB via http.MaxBytesReader; oversized payloads return 413 mid-read instead of being fully buffered. - Disabled triggers / paused / archived autopilots return 200 {"status":"ignored"} so providers stop retrying. - Skipped-runtime dispatches surface 200 {"status":"skipped"} with the reason from the autopilot service's pre-flight admission check. - WebhookRateLimiter interface with sliding-window in-memory + Redis Lua-script implementations. Default 60 req/min per token. Test coverage on the in-memory path; Redis variant fails open on cache errors so a Redis hiccup never blocks ingress. - Integration tests exercise token generation, dispatch, payload envelope persistence, GitHub-header inference, paused/disabled short-circuits, oversized rejection, and rotate-then-old-token-404. * feat(server): include webhook payload in create_issue description When an autopilot run is triggered by a webhook and execution_mode is create_issue, the agent only sees the issue body — never the run's trigger_payload. Append a 'Webhook event:' line and a fenced JSON block with the normalized eventPayload so the agent has the inbound context inline. Schedule / manual runs are unchanged. Tests cover: - schedule path keeps existing italic note, no webhook block - webhook path emits event line + payload block, italic before block - non-envelope JSON falls back to raw body (defensive) - non-webhook source with payload still gets no webhook block * feat(core): types, API client and mutations for webhook triggers - AutopilotRunStatus gains 'skipped' so the run-list UI handles the admission-skipped state explicitly instead of falling through to a generic case (the backend already emits it via MUL-1899). - AutopilotTrigger picks up optional webhook_path / webhook_url. Both are optional so older self-hosted servers that pre-date this change still parse cleanly. - buildAutopilotWebhookUrl helper composes a usable absolute URL with the priority webhook_url > apiBaseUrl + path > origin + path > path. Tested with seven cases covering each branch. - ApiClient.rotateAutopilotTriggerWebhookToken posts to /api/autopilots/{id}/triggers/{triggerId}/rotate-webhook-token; the HTTP-contract test pins URL + method. - useRotateAutopilotTriggerWebhookToken mutation invalidates autopilotKeys.detail on settle, mirroring the existing trigger-mutation pattern. * feat(views): webhook trigger UI in Add Trigger dialog and trigger row Add Trigger dialog gains a Schedule/Webhook segmented toggle: - Schedule reuses TriggerConfigSection unchanged. - Webhook hides the cron config and shows a help line; the trigger is created with kind=webhook and the URL is generated server-side. - Toast text differentiates schedule vs webhook on success. TriggerRow grows a webhook branch: - Webhook icon, kind translated via trigger_kind. - URL shown in a truncating monospace pill, with copy + rotate buttons. Copy uses navigator.clipboard with toast feedback; rotate uses an AlertDialog confirm because the old URL stops working immediately. - api triggers render a Deprecated badge and skip URL/copy/rotate affordances. RunRow gains a 'skipped' RUN_VISUAL entry (muted dash) so admission- skipped runs don't fall through to a generic case. Source label uses the new run_source i18n key instead of capitalize. Locales: en + zh-Hans gain run_status.skipped, run_source.*, trigger_kind.*, trigger_row.{copy_url,rotate_url,*_confirm_*,toast_*}, add_trigger_dialog.{type_*,webhook_help,toast_added_{schedule,webhook}}. * feat(cli): support webhook trigger creation and URL rotation - multica autopilot trigger-add now takes --kind schedule|webhook (default schedule for backward compatibility). For webhook it skips --cron / --timezone validation and prints the resulting webhook URL, preferring the server-provided webhook_url and falling back to client.BaseURL + webhook_path. - New multica autopilot trigger-rotate-url <autopilot-id> <trigger-id> command for rotating the bearer URL of a webhook trigger. * docs(autopilots): add webhook trigger guide (en + zh) Replaces the 'Webhook and API triggers are not available yet' section with end-to-end webhook documentation: how the URL is generated, what payload shapes are accepted, the inferred-event rules, the bearer-secret warning + rotate flow, status-code semantics for accepted/skipped/ ignored/4xx/5xx outcomes, and the MULTICA_PUBLIC_URL self-host configuration. Run history list now mentions skipped status. The 'unavailable features' section narrows to api-kind triggers, HMAC signing, IP allowlists, and provider presets. * feat(views): add Schedule/Webhook toggle to the create autopilot dialog Closes the gap where a brand-new autopilot could only be created with a schedule trigger. The right-column config now has a Trigger section with a segmented Schedule/Webhook control: - Schedule keeps the existing cron/timezone UI. - Webhook hides the cron UI and shows a help line; on submit, a kind=webhook trigger is created right after the autopilot. In edit mode the toggle is intentionally hidden (PLAN.md treats trigger- type changes as delete-old + create-new, not in-place updates), but the panel still picks the right kind based on props.triggers[0].kind so a webhook autopilot doesn't render an irrelevant cron form. Locales: section_trigger_kind, trigger_kind_{schedule,webhook}, section_webhook, webhook_help_{create,edit} added in en + zh-Hans. * feat(views): show webhook URL inline after creating a webhook autopilot After a successful create with kind=webhook, the dialog stays open and swaps to a confirmation panel showing the freshly minted URL with a copy button + 'Treat this URL like a password' warning + Done button. Avoids the friction of "create the autopilot, then go find it in the list, click in, scroll to triggers, copy URL." Locales: dialog.webhook_created_{title,description,warning,done} added in en + zh-Hans. Schedule create flow is unchanged (toast + close). The success panel is gated on the trigger returned from the create mutation, so a partial failure (autopilot created, trigger creation errored) still falls through to the toast_create_partial path. * feat(views): show webhook payload in run detail dialog The agent transcript dialog now accepts an optional headerSlot that sits above the event list. The autopilot RunRow drops a WebhookPayloadPreview into that slot when the run came from a webhook and trigger_payload is non-empty. The preview is collapsed by default (the transcript itself is the main event), shows the inferred event name + receivedAt in the header, and reveals the eventPayload as pretty-printed JSON with a copy button on expand. Falls back gracefully if the row's trigger_payload doesn't match the WebhookEnvelope shape — the whole value is shown instead so nothing is hidden. Closes the "agent didn't echo the payload, now I can't see what triggered the run" gap. PLAN.md tracked this as "Payload preview in run history" under follow-ups. Locales: webhook_payload.{label, unknown_event, payload, content_type, copy, copied, copied_short, copy_failed} added in en + zh-Hans. * chore(server): wire MULTICA_PUBLIC_URL through self-host compose Two small follow-ups split out of the webhook trigger PR: - docker-compose.selfhost.yml passes MULTICA_PUBLIC_URL into the backend container so a self-hosted deployment behind a real domain gets absolute webhook URLs in the trigger response. Documented in .env.example with the rationale for not deriving the public host from request headers. - Drop a duplicated 'invalid json:' prefix in the webhook ingress 400 error path. normalizeWebhookPayload already prefixes its errors, so the handler doesn't need to re-prefix. * fix(migrations): renumber webhook trigger migration 081 → 089 to avoid collision The branch's 081_autopilot_webhook_triggers.{up,down}.sql collided numerically with 081_runtime_timezone.{up,down}.sql that landed on main, making migration apply order undefined. Renumber to 089 so the file slots after the latest main migration (088_squad_instructions). The SQL itself doesn't conflict — it only creates a partial unique index on autopilot_trigger.webhook_token — but the duplicate prefix is what the migration runner sees, so the filename must move. * fix(autopilot-webhook): address PR review blocking issues - Redact bearer tokens from request logs: paths matching /api/webhooks/autopilots/<token> now log "[redacted]" instead of the token. The resolved trigger ID is plumbed via context so audit lines stay useful for debugging. (Review item Blocking #1.) - Distinguish pgx.ErrNoRows from transient DB errors in token lookup: no-row stays 404 (so providers don't retry on a deleted webhook), other errors return 500 (which providers DO retry, avoiding silent drops on DB blips). (Review item Blocking #2.) - Add per-IP sliding-window rate limiter that runs BEFORE the token lookup, so spraying random tokens can no longer probe the autopilot_trigger index unboundedly. Reuses the existing Lua script with a separate Redis key namespace; falls open on Redis errors. Default budget 30 req/min/IP. (Review item Blocking #3.) The webhook handler now applies the gates in the order: per-IP rate limit → token lookup → per-token rate limit → handler logic. * fix(autopilot): atomic webhook trigger creation + strict kind/timezone validation - Mint the webhook bearer token BEFORE the INSERT and pass it via CreateAutopilotTriggerParams so the row never exists in a half-written kind=webhook + webhook_token=NULL state. On the (vanishingly rare) unique-index collision the whole INSERT is retried with a fresh token — no UPDATE second step. Removes the now-dead attachFreshWebhookToken helper. (Review item Recommended #4.) - Add new GET /api/autopilots/{id}/runs/{runId} endpoint that returns a single run including the full trigger_payload. The list response is now slim (omits trigger_payload) so worst-case payload size drops from ~5 MB to ~5 KB. (Review item Recommended #5, server side.) - Reject kind=api with 400 ("kind=api is deprecated; use schedule or webhook") and reject kind=webhook with --timezone with 400 — both surfaces stragglers loudly instead of silently dropping fields. CLI mirrors the check so --timezone with --kind webhook errors client-side. (Review nits.) - Add --yes (-y) flag and an interactive y/N confirmation prompt to `multica autopilot trigger-rotate-url` so the destructive rotate matches the UI's AlertDialog safety. (Review item Recommended #6.) * fix(views): fetch webhook payload on-demand and truncate at 4 KiB - Add useAutopilotRun query hook + getAutopilotRun API client method paired with the new server endpoint. The run-detail dialog now mounts a WebhookPayloadSlot that fetches the full run (incl. trigger_payload) lazily — list responses no longer carry up to 256 KiB × N runs of envelope data. - WebhookPayloadPreview truncates its in-DOM <pre> at 4 KiB with a localized marker so jank-y machines aren't asked to render a 256 KiB JSON blob. The Copy button still yields the full string. - Adds the truncated_marker i18n string to en + zh-Hans. Review items Recommended #5 (frontend) and a nit on the preview's unbounded <pre>. * test(autopilot-webhook): close coverage gaps flagged in PR review - request_logger: redactWebhookPath unit tests + integration test proving the bearer token never lands in slog output, plus the webhook_trigger_id context plumbing. - autopilot_webhook_handler: empty body → 400, archived autopilot → 200 ignored, per-IP rate limiter trips before DB lookup, kind=api and webhook+timezone are rejected at 400, slim list + full detail endpoint round-trip. - webhook_rate_limiter: Lua script structure guard (catches reordering even without a live Redis), plus live-Redis tests for both per-token and per-IP limiters (REDIS_TEST_URL gated, matching the existing Redis test pattern in the package). - WebhookPayloadPreview: envelope rendering, fallback shape, and the >4 KiB truncation path with full-payload-on-Copy guarantee. Two branches are documented as code-review-protected rather than covered by tests: the 500-on-DB-error path requires injecting a stub Queries (no interface here), and the cross-workspace defense-in-depth check is unreachable from valid SQL state. * fix(middleware): SetWebhookTriggerID must mutate request in place The round-1 helper returned a fresh *http.Request from WithContext, and the webhook handler did `r = SetWebhookTriggerID(r, ...)`. That swaps the handler's local pointer but doesn't propagate the new context back to RequestLogger, which is still holding the original *http.Request — so the audit line never actually included webhook_trigger_id in production. The round-1 test happened to pass because it pre-stashed the value on the request before calling ServeHTTP, bypassing the bug it was meant to verify. Switch to in-place mutation via `*r = *r.WithContext(...)` so the wrapping middleware sees the new context after next.ServeHTTP returns, and update the test to exercise the real call pattern (set the context from inside the handler, assert the surrounding logger reads it). Verified live: an accepted webhook now logs path=/api/webhooks/autopilots/[redacted] webhook_trigger_id=<uuid> * fix(autopilot-webhook): symmetric ErrNoRows split + trusted-proxy gate Round-2 review (Bohan-J, PR #2348 follow-up): - Must-fix #1: the second lookup at autopilot_webhook.go:258 (GetAutopilot after the token resolves) was folding every error into 404. A transient DB blip would tell a webhook sender "not found" and it would never retry. Apply the same errors.Is(err, pgx.ErrNoRows) → 404 / else → 500 split as the first lookup got in round 1. - Must-fix #2: clientIPForRateLimit was honoring X-Forwarded-For / X-Real-IP from any caller. An attacker spraying random tokens could just rotate the XFF header and the per-IP bucket became per-request, so the limiter that's specifically supposed to gate spraying before it hits the DB unique index was bypassed. New shape — matches Bohan's suggestion exactly: * Default: r.RemoteAddr only, headers ignored. * Operator opt-in via MULTICA_TRUSTED_PROXIES (comma-separated CIDRs). XFF/X-Real-IP are honored only when r.RemoteAddr is inside one of the listed prefixes; otherwise they're dropped. Wired through .env.example and docker-compose.selfhost.yml so self-host operators can configure their reverse-proxy's CIDR. Invalid CIDRs in the env var are dropped with a single slog.Warn at startup rather than crashing the server. Uses net/netip (stdlib, value-typed) for parsing and containment checks. Verified live on the rebuilt self-host backend: a 35-request spray from one source with rotating XFF gets the expected 30× 404 + 5× 429, proving the per-IP bucket is keyed on the real connection IP. * fix(autopilot): reject cron/timezone PATCH on non-schedule triggers Round-2 review should-fix. CreateAutopilotTrigger already 400s on kind=webhook + timezone/cron_expression, but UpdateAutopilotTrigger silently wrote those fields regardless of prev.Kind. The values then sat in the DB visible to nobody and read by nothing — a back door that left the API contract fuzzy across create vs update. Mirror the create-path discipline: after loading prev, if prev.Kind != "schedule" and the PATCH body sets cron_expression or timezone, return 400 with a clear message. enabled and label remain accepted on every kind. The existing prev.Kind == "schedule" guard on next_run_at recompute stays as belt-and-braces, but with this gate in place the recompute branch is now reachable only for the kind it was meant for. * test(autopilot-webhook): close round-2 coverage gaps - IPRateLimitNotBypassedByXFFSpoof: drives the must-fix #2 invariant by rotating XFF across three calls from the same RemoteAddr and asserting the third gets 429. Pre-round-2 this test would have passed for the wrong reason (limiter trusted XFF, so per-bucket collision was incidental); now it pins the bypass-closed property. - IPRateLimitReturns429BeforeDBLookup: updated to set RemoteAddr explicitly and drop the XFF header it was leaning on. With TrustedProxies empty (test default) the limiter keys on the real connection IP, which is what the test wants to assert anyway. - UpdateAutopilotTrigger_RejectsCronExpressionOnWebhookKind + UpdateAutopilotTrigger_RejectsTimezoneOnWebhookKind: drive the round-2 should-fix from the handler boundary. - UpdateAutopilotTrigger_AcceptsEnabledAndLabelOnWebhookKind: counter test so a regression to a blanket reject is caught. * fix(migrations): bump webhook trigger migration 089 → 091 origin/main added 089_squad_no_action_activity_index (and 090_task_is_leader) since our last rebase, re-colliding with our 089_autopilot_webhook_triggers. Bump to 091 so the filename ordering is unambiguous again. The SQL is unchanged — same partial unique index on autopilot_trigger.webhook_token — only the filename moves. * fix(views): dedupe skipped icon in autopilot RUN_VISUAL after rebase The rebase against origin/main merged main's add of `Ban` for the skipped status next to our round-1 `MinusCircle` entry, leaving the RUN_VISUAL map with two `skipped` keys (only the last would have been read at runtime, and MinusCircle had been dropped from the imports during conflict resolution — so the file would not compile). Keep main's `Ban` icon (latest design) and a single `skipped` entry. Carry over the round-1 comment about why the muted styling matters for failure-ratio readability. --------- Co-authored-by: Kerim Incedayi <[email protected]>	2026-05-18 12:17:39 +08:00
iYuan	d8635ad580	fix(issues): prevent duplicate active issue creation (MUL-2225) (#2602) ... * fix: prevent duplicate active issue creation * fix(issues): address duplicate guard review * fix(autopilot): skip duplicate issue admissions * fix(issueguard): tighten duplicate lookup edge cases * test(issues): cover duplicate guard autopilot skips * feat(autopilots): group skipped runs in history	2026-05-15 18:27:56 +08:00
LinYushen	319b23eb39	Revert "feat(task): add claim lease mechanism (Phase 2, MUL-2246) (#2660)" (#2674) ... This reverts commit 3137feecdf.	2026-05-15 16:07:23 +08:00
LinYushenandmultica-agent	3137feecdf	feat(task): add claim lease mechanism (Phase 2, MUL-2246) (#2660) ... Add claim_token + claim_expires_at columns to agent_task_queue and three new SQL queries for the claim lease protocol: - ClaimAgentTaskWithLease: generates a UUID token and sets a lease expiry when claiming a task, so the daemon must prove it received the response - StartAgentTaskWithClaimToken: validates the token on StartTask, preventing stale daemons from starting requeued tasks - RequeueExpiredClaimLeases: moves dispatched tasks with expired leases back to queued for re-claim This closes the reliability gap where a claim response lost in transit leaves a task stuck in dispatched until the 60s dispatch timeout fires. Co-authored-by: multica-agent <[email protected]>	2026-05-15 15:14:05 +08:00