328 Commits

Author	SHA1	Message	Date
Jiayuan Zhang	7803a5b9ea	feat(ui): establish a role-named type scale and migrate ad-hoc font sizes (MUL-5451) (#6136) ... tokens.css defined colours, radii and font families but not a single --text-* step, so font sizes had no baseline to align to and grew wherever they were needed: 51 distinct sizes across web + desktop, 370 written as arbitrary values, six at half a pixel (10.5 / 11.5 / 12.5 / 13.5 / 14.5 / 15.5px). text-xs and text-sm carried nearly all UI text while the range between them — 11, 13, 15px — could only be reached with arbitrary values. Hierarchy does not come from having more sizes; past a handful, each extra size makes the hierarchy blurrier. Add ten role-named steps, each with its own line-height so leading cannot fragment the way size did, and move every product-UI call site onto them. Steps are named for what the text is for, not for a t-shirt size, because that is what keeps the scale from drifting again. Six steps deliberately keep the exact size/line-height pairs of the Tailwind defaults they replace, so the ~1,900-call-site rename moves nothing on screen. The visible changes are confined to former arbitrary values snapping to a step: 8/9/10px -> micro (11px) on badges and overlines; 17 -> 18; 22 -> 24; 30 (text-3xl) -> 36 on headings and stat numbers; 12.8px -> label (13px) on small buttons and toggles. Half-pixel sizes are gone. This supersedes #6108, which was reverted by #6116 because the sidebar group labels rendered at the inherited 16px. The cause was not the scale but cn(): `text-<x>` is ambiguous in Tailwind, and tailwind-merge resolves it against a table listing only the default sizes, so it filed every role step under text-colour and dropped whichever of `text-caption` / `text-sidebar-foreground/70` came first. Registering the steps as a font-size class group restores the real conflict groups — size beats size, colour beats colour, the two coexist — and a test pins the list against the scale, since the failure is silent in source. Hand-written CSS is covered too. The transcript kept a 12.5px body long after every Tailwind call site was on the scale, so the "no half-pixel sizes" claim was true of the classes and false of the product; the editor's prose, code and mermaid ramps had the same blind spot, and seven of their eight values already equalled a step exactly. All now reference var(--text-*). The guard test reads raw `font-size:` declarations as well as class names, exempting only the 16px iOS input-zoom workaround in base.css and the landing pages' marketing ramp. apps/mobile (own NativeWind config) and apps/docs (fumadocs' own type system) keep Tailwind's default scale and are untouched. Landing display type (rem/clamp, 2.2-6.4rem) stays on its separate ramp, as do four decorative emoji / serif-hero sizes. Verified on a running local stack: pinned sidebar rows and group labels measure 12px/16px, nav items 14px/20px — identical to pre-migration. An audit of every rendered font size across the product surfaces finds nothing off the scale; the only exceptions are avatar initials and emoji, which actor-avatar.tsx sizes proportionally to the avatar diameter by design. Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-30 13:42:33 +08:00
Jiayuan Zhang	545afea827	Revert "feat(ui): establish a role-named type scale and migrate ad-hoc font s…" (#6116) ... This reverts commit d68d636c91.	2026-07-29 17:10:33 +08:00
Jiayuan Zhang	d68d636c91	feat(ui): establish a role-named type scale and migrate ad-hoc font sizes (MUL-5451) (#6108) ... tokens.css defined colours, radii and font families but not a single --text-* step, so font sizes had no baseline to align to and grew wherever they were needed: 51 distinct sizes across web + desktop, 370 of them written as arbitrary text-[Npx] values, six at half a pixel (10.5 / 11.5 / 12.5 / 13.5 / 14.5 / 15.5px). text-xs and text-sm carried nearly all UI text while the range between them — 11, 13, 15px — could only be reached with arbitrary values. Hierarchy does not come from having more sizes; past a handful, each extra size makes the hierarchy blurrier. Add ten role-named steps, each with its own line-height so leading cannot fragment the way size did, and move every product-UI call site onto them. Steps are named for what the text is for, not for a t-shirt size, because that is what keeps the scale from drifting again. Six steps deliberately keep the exact size/line-height pairs of the Tailwind defaults they replace, so the 1,900-call-site rename (text-sm -> text-body and friends) moves nothing on screen. The visible changes are confined to former arbitrary values snapping to a step: - 8 / 9 / 10px -> micro (11px): 102 sites, mostly badges and overline labels. Deliberate — under 12px is a counter role, not a text role. - 17px -> title (18px), 22px -> display-sm (24px), 30px (text-3xl) -> display (36px): 21 sites, all headings or stat numbers in flexible containers. - Half-pixel steps are gone entirely. Arbitrary sizes also inherited whatever line-height was above them; the tokens now pin one, which removes latent overflow risk in the fixed-height h-4/h-5 badges those sizes were used in. apps/mobile (own NativeWind config) and apps/docs (fumadocs' own type system) keep Tailwind's default scale and are untouched. Landing-page display type (rem/clamp, 2.2-6.4rem) is marketing typography on a separate ramp and stays out of the scale, as do four decorative emoji / serif-hero sizes. A guard test fails the build on any font size written outside the scale, reporting file:line — without it nothing in a Tailwind build makes an off-scale value look wrong, which is how the drift happened. Verified against a local stack: typecheck, lint and the full TS suite show no new failures, and before/after screenshots of issues, issue detail, runtimes (populated), usage, agents, inbox, my-issues and settings differ only in the intended 10px -> 11px labels, with no row-height, truncation or layout shift. Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-29 16:30:13 +08:00
Naiyuan Qing	e70e71fea1	fix(issues): repair the issue Table's column interactions, loading states and scroll rendering (#6036) ... * fix(ui): make table column resizing land where the pointer is (MUL-5166) Pressing the resize handle committed a width before any drag: it wrote the rendered width, which fixed table-layout had stretched past the configured one, so a stray click on a column edge silently rewrote and persisted that column and stopped it adapting to the window. Dragging then ran ahead of the pointer, because committing one width changes how much leftover space the layout has to share out and rescales every other column mid-gesture. And the gesture never ended if the pointer came up outside the window or the user switched apps — the column kept tracking the pointer on return, with the page stuck unselectable under a col-resize cursor. - Require 4px of travel before anything is committed, matching the column-reorder sensor's activation distance on the same header. - Pin every column to its rendered width on the frame the drag starts, so there is no leftover left to redistribute and the drag maps 1:1. - Capture the pointer and end on blur / pointercancel / lostpointercapture, the same four-part contract the sidebar rail already uses. - Own the cursor from a portaled full-viewport layer for the duration of the drag. document.body.style.cursor loses to any descendant that declares its own, which is why the cursor flickered over rows and text. Resizing also re-rendered every cell each frame, and each cell carries a popover, so a frame cost ~143ms. Widths now travel as custom properties published once on the <table>, and the body is swapped for a memoized copy while a drag is live — the browser applies each new width with no React work. Visually the table had no column rules at all, which left the pinned columns' trailing shadow as the only vertical line and made it read as a stray border on one column. Every column now carries a rule, the pinned shadow appears only once the surface is actually scrolled sideways, and the resize handle brightens its rule to brand rather than matching the faint resting colour. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(issues): drag a table column by its header, not by a hidden grip Reordering columns was advertised by a grip that only appeared once the pointer was already on the header, and dragging it moved a wrapper the height of its own line of text while the <th> around it clipped anything that travelled outside the cell — so the column being moved looked like it had vanished rather than slid. The header is now the handle. There is no grip: the cursor carries the affordance (grab, then grabbing), the whole cell responds, and only the sort/hide button opts out, since a press there is always the menu. The wrapper spans the cell's box at all times — the negative margins undo the <th>'s padding and put it back inside — so what travels is a header-sized block and going translucent is the entire drag state, matching how a desktop tab behaves. Overflow is lifted for the length of a reorder and the column in hand is raised over its neighbours. Columns are restricted to the horizontal axis, the same constraint the desktop tab bar puts on tab reordering, which is why packages/views now declares @dnd-kit/modifiers directly. Transforming the <th> itself would carry the header's height along for free, but `transform` on a table cell is a corner of the spec browsers take liberties with — Chromium lifts the cell out of the table's box model and its geometry stops matching the row. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(issues): stop a dragged table column stretching into its neighbour's width Dragging a column header applied dnd-kit's full transform, which carries scaleX/scaleY alongside the translation. Those come from its layout animation: old rect over new rect, tweening an item into the shape of the slot it lands in. Between two tabs of equal width the ratio is 1 and never shows. Between two columns it is not — swapping a 174px column with a 96px one stretched the header to 1.8x on the way across. Only the horizontal translation is applied now; reordering changes no column's width, so there is no shape for a tween to describe. The travel and the settle stay animated through `transition`. The travelling wrapper was also fixed at h-8 while the header strip measures 39px once row borders are counted, leaving the block short at both edges and misaligned by 3px — which read as the same flattening. Its height is derived from the cell now. The reorder grip returns as the drag handle, appearing on hover as before and staying visible for the length of a drag. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ui): mark the frozen column boundary while the table is scrolled sideways The edge where the frozen columns end had a shadow drawn inside the pinned cell with `--border`. That token is tuned for hairlines between adjacent surfaces — oklch .945 in light mode — and all but disappears once spread into a shadow, so the boundary read as unmarked while content slid underneath it. Darkening it in place only made the frozen column look outlined: an inset shadow can shade that cell's own edge and nothing else, while the depth being described belongs to the content passing beneath. Split into the two things MUI X's data grid separates, a permanent border for where the boundary is and a shadow for something crossing it right now: - the rule between the frozen columns and the rest stays put, as before; - a 12px gradient is cast past the frozen block, mounted outside the scroll container and shown only while scrolled sideways. Its position is measured off the DOM — the trailing frozen header carries a `data-pinned-edge` marker — rather than summed from column sizes. Fixed table-layout stretches columns past their configured widths whenever the container is wider than the table's min-width, so a sum lands the marker in the middle of visible content. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(ui): size a table column to its content on double-click Double-clicking a column's resize handle called column.resetSize, which cleared the stored width and let TanStack fall back to its generic default of 150 — a number unrelated to any width this table was designed with. "Reset" therefore widened priority from 130, collapsed labels from 220, and clamped title to its 260 minimum. It restored nothing. It now sizes the column to its widest rendered cell, the convention Excel, Sheets, AG Grid and Notion all share for that gesture. Fixed table-layout ignores content and the cells truncate their own text, so nothing on screen reports the width the content wants. The measurement lifts both constraints across the column's cells, reads them, and restores everything within the same task, so the browser paints once — after the restore — and the intermediate layout is never seen. Only the rows inside the virtual window are measured. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ui): stop the table header flickering black during scroll The sticky header carried backdrop-blur over a translucent fill. A backdrop-filter on a sticky element with content scrolling beneath it is a known Chromium compositing fault — the blur layer recomputes its backdrop every frame, and virtualisation is adding and removing the very rows it reads from, so the strip flickers black under fast scrolling. Chromium's fix for the same symptom was reverted, so upgrading does not carry it (electron#12906, electron#45854, chromium#339841685). The fill is now the opaque colour that bg-muted/30 was compositing to, which is the mix the pinned header cells already use. A header the content scrolls behind has no reason to show it through. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(issues): give the table's title column back the width its hover actions held The sub-issue and rename buttons sat inline in the title cell at opacity 0. Hidden is not absent: their boxes reserved around 40px of the column at all times, in the one column with the least room to spare, for controls that only appear on hover. They are positioned over the cell's trailing edge now, the way SidebarMenuAction is, with a gradient fading the title running underneath rather than icons sitting on top of it — the sidebar needs no gradient because its labels are short, a title runs to the cell's edge. focus-within keeps them reachable from the keyboard, where hover never fires. Reordering a column also scrolled the table vertically. Modifiers constrain a drag's movement but not its auto-scrolling, which reads raw pointer coordinates, so a few pixels of vertical drift sent the rows moving under a gesture that cannot act on them. Auto-scroll's y threshold is zero now; x keeps it, since a table wider than its viewport needs it to reach a distant slot, but at 0.05 rather than the default 0.2, which arms it a fifth of the way in from either edge — most of a wide header. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * feat(issues): show the table's own grid while its first page loads, and end its columns like every other surface Two loading-state gaps, both in how the table's non-issue rows are modelled. A cold load rendered a single "Loading…" line under a full header, which reads as an empty table rather than a loading one. The surface-level skeleton meant for it was unreachable: use-issue-surface-data hardcodes isLoading to false for table, so the `mode === "table"` branch never ran — and it would not have fitted, drawing rounded bars at p-2 where the table draws an edge-to-edge grid, so switching it on would have traded one wrong state for a layout jump. Placeholders are rows now, rendered through the ordinary cell renderer so they inherit the real column widths, pinning and borders. Everything the table knows before its data — header, toolbar, column layout — is up immediately, and the rows swap in without moving anything. The unreachable surface branch is gone. The end of a column was hand-rolled too, leaving the table the one surface where a failed page read as muted body text rather than an error, where the prompt sat left-aligned against three centred ones, and where reaching the end of a paginated branch said nothing at all. The row carries its state rather than a finished label and renders through ListLoadMoreFooter, the footer Board, List and Swimlane already share — which exists, per its own comment, so those states and their wording stay consistent. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ui): measure table rows instead of assuming they are all one height Virtualisation sized every row at the same 41px estimate, but the table does not have one kind of row: group headers are 37px, an end-of-column footer shorter still, and placeholders different again. Each one put the estimate a few pixels out, and the error accumulates — with grouping on, the rendered window drifts off the rows it should be showing and the scrollbar overshoots the bottom. Rows report their own height through the virtualizer's measureElement now, and the estimate only covers rows that have never been mounted. Rows built by renderRow are cloned to carry data-index and the measuring ref, so callers keep returning a plain <tr> and still take part. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(issues): scope the title cell's actions to the title cell The sub-issue and rename buttons keyed off the row's hover state, so pointing anywhere along a row — a status chip, a date, empty space — put controls that act on the title under a pointer that was somewhere else. They follow the title cell's own hover now. The gradient behind them still tracks the row colour, since that is what the cell is painted with while they are showing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(ui): let group rows report their height, and re-measure the frozen edge on resize Self-review of the branch turned up two places where a change did not reach as far as it was supposed to. Group rows never took part in the row measurement. DataTable clones the virtualizer's ref and data-index onto whatever renderRow returns, but IssueTableGroupRow declared only its own three props and absorbed them — and a group header, being shorter than a data row, is exactly the row the measurement was added for. The frozen-column shadow measured its boundary from the scroll handler alone. Resizing a frozen column while the surface is scrolled sideways moves that boundary with no scroll event to follow, leaving the shadow behind at the old position. Also drops a dependency left behind when the load-more rows stopped building their own labels. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 15:13:20 +08:00
Naiyuan Qing	831ef926e1	fix(editor): limit paste-as-file to chat (#6043) ... #6019 opted four composers into converting an over-threshold plain-text paste into a `pasted-text.txt` attachment. Only chat should: a wall of text there is context handed to an agent for one turn, and the body is not what anyone reads. In an issue comment the paste IS prose a human reader is expected to see in the thread, so hiding it behind an attachment chip makes the thread worse, not better. So the three comment surfaces — new comment, reply, comment edit — stop passing `pasteAsFileThreshold`. Nothing else changes: the extension, the threshold constant and the failed-paste recovery all stay, because the prop was always opt-in per editor and chat still uses every part of it. The recovery test moves from comment-composers to use-coordinated-uploads. Comments can no longer produce a paste-as-file upload at all, so hosting the test there would pin a path that cannot happen; the hook is where the contract actually lives, since the upload outlives its mount and no editor can own the failure. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 18:03:55 +08:00
Naiyuan Qing	18adb20c14	MUL-5391: unify upload placeholder UI (#6025) ... * fix(editor): an in-flight upload placeholder is never content, and is drawn once Two defects with one cause: a placeholder for an upload in progress was both serialised into the draft body and drawn a second time as a chip. The document IS the persisted draft (getMarkdown -> setDraft), so serialising an in-flight node turns it into text that outlives the upload: - fileCard emitted `!file[x.pdf]()`. Its own tokenizer cannot parse an empty href back, so the line survived reopen as dead literal text, sat next to the real link the write-back appended, and shipped with the comment. - image emitted its process-local `blob:` URL, which ContentEditor then scrubbed back out with a regex on every serialise. Both renderMarkdown implementations now emit nothing while `attrs.uploading` is set (or no URL exists). A node becomes content the moment it holds a real URL and never before, which is strictly stronger than scrubbing after the fact — so BLOB_IMAGE_RE / stripBlobUrls are deleted rather than extended. Separately, ComposerUploadChips rendered every non-`uploaded` entry, including ones whose placeholder node is right there in the editor. Every upload started from a live mount inserts a node first (uploadAndInsertFile is the uploader's only caller), so those chips were the same upload drawn twice, in two visual languages, shifting layout as they appeared and vanished. useCoordinatedUploads now exposes `orphanUploads` — the entries inherited from the persisted draft, whose originating mount is gone and whose node died with it. That is the case the chip strip was introduced for, and now the only one it covers. `getMarkdown()` deliberately stays untrimmed (see its safety-net test); only its stripBlobUrls wrapper is gone. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(editor): keep a failed upload visible after the chip/node split Self-review catch on the previous commit: suppressing the chip for every upload this mount started also suppressed it for FAILED ones. The document cannot stand in for those — uploadAndInsertFile removes the placeholder node on failure — so the outcome was left to a toast that has already gone. The rule is not "started here" but "the document is showing it", and the document only ever shows a live placeholder: still `uploading` AND started by this mount. `failed` / `interrupted` always get a chip, `uploaded` never does (the editor and AttachmentList render those), which also makes an `orphanUploads.length` gate mean what the call sites assume. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(editor): keep the chip when the user deletes a running upload's placeholder Code-review catch: "started by this mount" is necessary but not sufficient for "the document is showing it". Cmd+Z right after a paste removes the placeholder node while the upload keeps running — and gate.isBlocked keeps blocking send on the store entry regardless of the node — so the previous filter left a dead send button with nothing on screen explaining it. The filter now also consults editorGate.uploading, which is the document's own answer to "am I showing a placeholder right now" (sourced from the uploading-node scan via onUploadingChange). Started-here AND still shown is what suppresses a chip; either half failing brings it back. Also drops a stale stripBlobUrls reference from the use-upload-gate docstring — that helper no longer exists. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(editor): a failed upload leaves nothing behind The failure chip carried no information the toast had not already given at the moment it happened, and it could not act on it: the bytes were never persisted, so there is nothing to retry, and the file is still on disk to re-attach. Its only affordance was a dismiss ✕. It cost more than that. The entry lives in the persisted draft, so it survived reload and reopen until dismissed by hand — and `isMeaningful` counts uploads, so a single flaky request kept an otherwise-empty draft alive for the full 30-day TTL. Uploading again did not clear it either: a new upload is a new clientUploadId. Failures now remove their placeholder outright instead of marking it. Both failure paths (size check, coordinator settle) collapse into that one rule, which also folds the paste-as-file recovery into the shared branch rather than duplicating it. `interrupted` keeps its chip: it is discovered a session later, when the user no longer remembers attaching anything. `orphanUploads` still handles `failed` because an older client may have persisted one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * refactor(editor): one upload, one node, from start to finish The chip strip existed because the document could not answer for an upload it was not showing. Give it that ability and the strip has no reason to exist. Three changes make one model: - ONE IDENTITY. The node's `uploadId` and the draft's `clientUploadId` were two independently minted random values, because the node is inserted before the handler that created the draft record runs. `uploadAndInsertFile` now mints the id up front and hands it to the uploader, which adopts it. Asking "is this upload in the document" becomes a lookup instead of an inference. - REBUILD ON MOUNT. A placeholder is never serialised (it is not content), so it dies with the document that drew it and a reopened composer showed no trace of an upload still running. The draft record is enough to draw it again. Once per id per mount: a placeholder the user deleted mid-upload stays deleted (MUL-5181), and the guard is what stops the next store write from undoing that. Skipped entirely while chat pins its document to another draft — `uploads` follows the selected key, the document does not. - SETTLE IN PLACE. The write-back replaces the placeholder where the user last saw it instead of appending the link at the end. A card promotes to an image when that is what arrived; the rebuild path only ever has a filename, so it cannot know in advance. With that, the chips are deleted outright, along with `orphanUploads` and the three-condition rule that approximated all of the above. `interrupted` goes too: nothing could act on it, no surface rendered it after this change, and `isMeaningful` counted it — one dead record kept an empty draft alive for the full TTL. The attachment's absence from the body is the signal to re-attach. SubmitButton's `busy` now spins rather than only greying out, so an upload with no other on-screen trace (a composer still rebuilding, a placeholder the user deleted) does not read as a dead control. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(editor): whoever draws a placeholder registers it, not whoever finds it Review catch on the rebuild effect. An upload started by the current mount had its node drawn synchronously by uploadAndInsertFile, but its id only entered `rebuiltUploadIdsRef` once the effect ran and happened to find that node. In between, a delete (Cmd+Z right after a paste) left the effect looking at an unmarked `uploading` record with no node — so it drew a second one, undoing a removal MUL-5181 says must stick, and letting the settle land an attachment the user had taken out. The id is now registered where it is minted: an id handed into handleUpload means the editor already drew the node. The window is sub-frame and needs a keystroke inside one render pass, but "whoever draws it registers it" is a rule, where "the effect will notice in time" was a race. The composer mocks called `onUploadFile(file)` with no id, so they were not exercising the one-id contract at all — every mount-started upload looked inherited to the hook. They now mint and pass one like the real handle does, which is what lets the new regression test see the difference. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 17:08:09 +08:00
Naiyuan Qing	995ec8fcf2	feat(editor): 粘贴超长文本自动转为文本附件 (#6019) ... * feat(editor): convert over-threshold pastes into a text attachment Pasting more than PASTE_AS_FILE_THRESHOLD (4000) characters into a turn-based composer now uploads a `pasted-text.txt` attachment instead of writing thousands of characters into the body. Opt-in per editor: chat, new comment, reply and comment edit pass the threshold; issue and project descriptions deliberately do not, because there a long paste IS the content. The synthesised File goes through the existing upload pipeline unchanged (nothing in it inspects a File's origin), so draft persistence, status chips and .txt preview all come for free. Recovery is the part that needed real design. A dropped file survives a failed upload on disk; this text exists nowhere else — it was never written into the document and its source tab may be closed. Since uploads outlive their mount (MUL-5181), the editor cannot own that recovery, so useCoordinatedUploads does: deliverPastedTextBack mirrors deliverFinishedUpload (live editor, else the persisted body) and is the single responder, so the live and dead cases can neither both fire nor both be skipped. The text is restored as markdown because markdown-paste is what would have handled it had it never been converted. A paste inside a code block stays inline — opening a fence is the request to show the thing. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * test(editor): pin the paste handler order against the real extension array Both markdownPaste and fileUpload register catch-all handlePaste handlers, so which one ProseMirror consults first decides whether paste-as-file works at all. That ordering is not visible in either file: Tiptap reverses the extension array before collecting plugins (@tiptap/core `get plugins()`), and neither extension sets a priority, so the array position in createEditorExtensions is the whole contract. The existing tests mounted the fileUpload extension alone and could not see it. This one builds the production array via createEditorExtensions; swapping the two entries makes it fail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 14:31:44 +08:00
Jiayuan Zhang	2274f521dc	feat(issues): agents-working chip on the sub-issues header (#5825) (#5834) ... * feat(issues): aggregate agents-working chip on the sub-issues header (#5825) Add a live "N agents working" chip next to the sub-issues progress ring in issue detail. The per-row IssueAgentActivityIndicator shows which sub-issue is being worked; this chip shows how many agents are on the parent's children at a glance — and keeps that signal visible while the list is collapsed. Derives from the shared workspace agent-task snapshot narrowed by a new selectIssuesTasks select (structural sharing keeps unrelated snapshot churn from re-rendering the header). Counts unique agents to match the workspace chip, whose chip_agents_working / hover_header_queued strings it reuses — already translated in every locale. Hover opens the shared AgentActivityHoverContent task list. Fixes #5825 Co-authored-by: multica-agent <github@multica.ai> * refactor(issues): read the sub-issues chip from the working-agents projection (#5825) The chip landed deriving its own count from the workspace agent-task snapshot, which put a second definition of "an agent is working" in the client. It showed up immediately: the number came from the running tasks only while the hover body listed running plus queued, so a parent with 2 running and 3 queued agents read "2 agents working" over a five-row card. A header count is a claim about a scope, so let the server own both the scope and the arithmetic, exactly as the Issues list header already does. ListWorkspaceWorkingAgents grows an optional parent_issue_id narrowing and the chip reads /api/working-agents?type=issue&parent=<id>. The number, the avatars and the hover body are now one list rather than three derivations, so they cannot disagree. Row indicators keep reading the snapshot. One shared query sliced per row is the right shape for a per-row cue and a stale row decoration costs nothing; a header number is the opposite, it has to be authoritative. The new parameter is additive: omitted, the query and the response are byte-for-byte what they were, so an installed client that never sends it keeps the workspace-wide behaviour. A regression test pins that. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai> Co-authored-by: Naiyuan Qing <145280634+NevilleQingNY@users.noreply.github.com> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 14:30:19 +08:00
Naiyuan Qing	b5f19adbab	feat(composer): post-send caret policy per surface (afterAccepted) (#6014) ... * feat(composer): post-send caret policy per surface (afterAccepted) Where the caret goes after a send was hand-rolled per composer: chat blurred, quick-create hand-wrote its own requestAnimationFrame focus, and comment/reply did nothing at all. The mechanics are identical everywhere and easy to get wrong (must run after the clear, must survive a dialog focus trap, must not steal focus the user moved elsewhere mid-flight), so they now live once in the shared send contract. `useComposerSubmit` gains `afterAccepted` ("refocus" | "blur" | "none", default "none") plus an optional `containerRef` that bounds focus reclaim to the composer that sent. The mode may be a function so a surface can decide at accept time — chat only reclaims focus when the commit actually scrubbed the shared editor, never when a fire-and-forget send left another session's draft on screen. Per-surface policy: - Chat refocuses (one file, three mount points: chat page, floating window, agent creation studio). Replaces the deliberate blur. - Thread replies refocus — the user is mid-conversation. - A top-level comment blurs, and IssueDetail reveals what was posted instead: submitComment now returns the created id, and the page scrolls to that row and flashes it with the same jumpToThread the inbox deep-link uses. - Quick create's keep-open mode drops its hand-written rAF for the option. - Inline comment edit and Create Issue keep "none": both close on save. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * refactor(composer): drop the scroll-to-posted-comment reveal The top-level composer is sticky at the bottom of the timeline, so a comment posted from it lands directly above the box and is almost always already on screen — the scroll was a no-op and the flash re-announced something the user had just deliberately done. The flash earns its keep for inbox deep-links, where the user did not choose the landing spot. `submitComment` goes back to returning a boolean; it only carried the created id to feed the reveal. The composer still blurs after posting: the turn is over, so the caret is dropped rather than kept. The shared contract is untouched — `afterAccepted` never knew about comments, which is why removing this costs nothing outside IssueDetail. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * docs(composer): drop stale references to the removed comment reveal Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> * fix(composer): bind the post-send caret policy to an actually-cleared editor Review blocker: CommentInput passed a literal `afterAccepted: "blur"`, but its stale-submit guard declines to clear when the user typed during the request. Posting comment A on a slow connection while typing comment B therefore dropped the caret out of B mid-sentence — the guard kept the text, and the blur fired anyway. Both issue composers now resolve the mode from a ref set only on the branch that really wipes the editor, matching what ChatInput and quick-create already do. ReplyInput gets the same treatment: refocusing a box the user is typing in happens to be harmless, but leaving one surface on the unsafe shape invites the next one to copy it. The rule is now stated on the option itself: a surface whose `onAccepted` can decline to clear must pass a function and resolve to "none" on those paths. Both regressions are mutation-verified — reverting either binding fails the new assertions. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-28 13:15:43 +08:00
Naiyuan Qing	77b309a5ac	feat(drafts): unified draft lifecycle + upload ownership inversion (MUL-5181) (#5900) ... * feat(drafts): unified draft lifecycle + upload ownership inversion (MUL-5181) Unify how every composer preserves unsent work, sends, and handles uploads. L1 foundation (packages/core/drafts): - createDraftStore factory + self-registering cleanup-registry replacing the hand-maintained WORKSPACE_SCOPED_KEYS list; register-all-drafts guarantees registration completeness. Fixes the confirmed cross-user draft leak (persistence + in-memory) on logout / workspace delete. L3 send paradigm: - useComposerSubmit: one await-then-render contract (lock/spin, keep-on-fail, clear-on-success, single-flight, submit-time upload-gate), adopted by comment/reply/edit, create-issue, quick-create, and chat. Per-surface: - Comment/Reply/Edit: attachments moved into the persisted draft. - Create Issue: draft split into shared/manual/agent/activeMode with non-destructive mode switching + migration for old flat drafts. - Chat: optimistic send converted to await-then-render (kept server-driven cancel restore_to_input); chat draft keys registered for cleanup. L2 upload coordinator (ownership inversion, Linear-validated shape): - upload-coordinator + DraftUpload placeholder: uploads owned by a module coordinator that outlives the component, state persisted in the draft; AbortController + abort-on-logout; interrupted-on-reload. Comment surface fully wired. Create-issue/chat upload wiring is a documented residual. Verified: core + views typecheck clean; core 1064 + views 2928 tests pass. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(drafts): close three review gaps in the unified draft lifecycle (MUL-5181) 1. Logout resurrection: reset in-memory draft stores BEFORE removing their persisted keys — each reset is a setState and persist writes it straight back under the still-active slug, so the old order re-created the deleted keys. The issue draft store's reset is now a full reset including lastAssignee, which clearDraft deliberately re-seeds and would otherwise hand the previous user's last-picked assignee to the next login. 2. Submit gate blind spot: the composer gate now also reads the draft's coordinator-owned upload placeholders (hasUploadingDraft). A composer reopened over a still-in-flight upload could previously send past the editor-only gate, clearing the draft out from under the settling upload. 3. Attachment binding returns to reference-filtering: a submit binds only uploads the body references, so deleting an inline image really unbinds it. An upload that settles after its mount died gets its markdown link written back into the body instead — via the reopened composer's live editor (new ContentEditorRef.insertMarkdownAtEnd) or appended to the persisted draft (new appendToDraftContent) — so close-surviving files stay visible, deletable, and honestly bound. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): harden upload write-back delivery after independent review Review of the previous commit (fresh-context reviewer + probe against real @tiptap/react) found the write-back could still lose a file: - insertMarkdownAtEnd now returns a boolean: the imperative handle exists from first commit but the Tiptap instance arrives in a passive effect, so an insert in that window (or after destroy) no-ops. Callers previously assumed it landed. - Write-back is now confirmed delivery (deliverFinishedUpload): insert into the live editor and, on success, persist the same body as insurance against the debounced emit being dropped by a quick unmount; append to the store only when NO composer is mounted (a mounted editor's first emit would erase a store-only append); retry while a mounted composer's instance is still warming up. Every attempt re-checks the generation guard and the body reference. - mountedRef flips in a layout effect: React nulls the child editor ref in the unmount commit, and a settle in the gap before passive cleanup saw "mounted" with no editor left to swap. - uploadAndInsertFile guards editor.isDestroyed after the await: now that uploads outlive mounts, the swap/remove paths could dispatch against a destroyed EditorView and escape as an unhandled rejection. - Tests: the reopened-composer test now asserts the editor actually received the insert (it previously passed with liveEditors disabled), plus a warming-up retry case; the mock editor mirrors isDestroyed. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(drafts): roll coordinated uploads out to issue-create and chat (MUL-5181 L2) Completes the upload-ownership layer for every composer surface. The generic engine is extracted from the comment implementation into editor/use-coordinated-uploads (UploadDraftBinding adapter: store-backed accessors + registry key + body append), and use-comment-uploads becomes a thin binding over it — behavior unchanged, all comment tests green. Issue-create (manual + agent panels): - shared.attachments migrates Attachment[] -> DraftUpload[]; load normalizes legacy bare rows to `uploaded` and coerces stale `uploading` to `interrupted`. - Uploads are coordinator-owned: placeholder at pick time, survives dialog close, aborts on logout, chips for uploading/failed/interrupted, combined gate on Create and both mode-switch actions. - Write-back targets the body of the MODE that started the upload (manual description vs agent prompt); mount-time prune keeps placeholders and drops only unreferenced `uploaded` entries. Chat (tab + floating window): - inputDraftAttachments migrates to DraftUpload[] with load-time normalization; new store ops (add/settle/fail/remove upload, append-to- draft) mirror the comment store. - ChatInput adopts the engine; the upload target is snapshotted at pick time via resolveUploadTarget so a file dropped while the editor is pinned to a previous session's document files under THAT draft. - uploadMapRef is gone — the draft's uploads are the single binding source, reference-filtered at send. Hosts no longer own transport: onUploadFile prop becomes uploadEnabled, and the controller/window drop uploadWithToast. - commitDraft prunes only `uploaded` entries the body no longer references; placeholders survive keystrokes (chips are their only UI). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): harden L2 rollout after independent review - attachmentToDraftUpload now strips the response-scoped signed download_url before the row is persisted (draft uploads survive restarts; a stale signature 403s the preview on reopen). Covers comments, issue-create, and chat in one place; issue-create's settle reuses the helper, and the Signature assertion the rollout had dropped is restored. - chat's live-editor registry follows the LOADED draft key (reactive mirror of editorDraftKeyRef): a settle for draft B must not insert into an editor still pinned to draft A's document. - removeUpload aborts an in-flight request before dropping its placeholder. - issue-create hasDraft counts only uploaded/uploading entries so a failed remnant can't pin the sidebar draft dot forever. - Tests: mutation-proof coverage for the two placeholder-preservation rules (create-issue mount prune, chat commitDraft prune) — both previously survived rule inversion; direct core tests for the five new chat store upload ops incl. persistence and signed-URL stripping; quick-create test gets the editor i18n namespace; dead uploadWithToast scaffolding removed from both modal tests; chat-input mock aligned with the real append semantics. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): close third-round review gaps in the upload engine - The live-editor registry registers in a layout effect: chat's adopt swaps the editor's document and loaded key synchronously during commit, and a passive re-registration one task later left a settle window where the old key mapped to an editor already holding another draft's document. The registry key is also built only when a binding exists. - removeUpload aborts only a request THIS surface tracks as `uploading` (guarded before the abort), with the comment now honest about the path being defensive — no current chip exposes ✕ mid-upload. - Mutation-proof test for the loaded-key registry rule: a dead mount's settle for a pinned draft must insert into the editor HOLDING it, not the selected one (verified to fail with the registry keyed by selection). - hasDraft upload semantics pinned by tests (uploaded/uploading count; failed/interrupted remnants don't pin the sidebar dot). - Dead scaffolding dropped: identity use-file-upload mocks and a redundant assertion in the modal tests. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): stale-submit draft guard + registry layout timing (review BLOCKED items) Blocker 1 — a submit that outlives its composer may only consume the draft it submitted (MUL-5181 P0). Every accepted-submit clear is now guarded: - create-issue / quick-create snapshot the singleton draft's object identity at submit; a dead panel clears (and records last-assignee/mode) only if the draft is untouched, and never runs close/reset effects. A replaced draft B typed after close survives a late success of draft A. - comment / reply / edit snapshot the per-key draft entry; a dead composer clears only the exact entry it submitted. - chat snapshots the sent slot's value; a dead mount's commitInput clears only an unreplaced draft. Mutation-verified tests for the create panels and comments (guard inverted => tests fail), plus untouched-draft control cases. Blocker 2 — the live-editor registry is now genuinely registered in a layout effect. The prior commit claimed this fix but a test-time `git checkout --` discarded the unstaged engine edits before committing; re-applied: layout registration, binding-gated registry key, and the tracked-only abort in removeUpload. New registry timing test captures the registry from a parent layout effect across a key switch — verified to fail with passive registration. Also: `multica:chat:selectedProjectId` joins the workspace-scoped cleanup list (was leaking across logout; flagged as a pre-existing risk). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): mounted submits also clear only the draft they submitted The stale-submit snapshot guard previously protected only dead composers; a mounted one cleared unconditionally on success. But the editor stays interactive during a request (Tiptap cannot toggle editable post-mount), so text typed while draft A was in flight was wiped by A's success. The guard is now unconditional across every surface: success consumes exactly the submitted snapshot, and any later edit survives. - create-issue / quick-create: the editor's pending debounce is flushed into the store BEFORE snapshotting (a late flush of pre-submit typing must not read as a mid-flight edit); a touched draft skips clear AND close/reset — the dialog stays open on the newer work. Untouched behavior unchanged. - comment / reply / edit: same flush + snapshot; a touched entry keeps both the store draft and the editor content (edit mode stays open on it). - chat: commitInput's value compare now applies while mounted too, and the editor is scrubbed only for an untouched draft. - use-composer-submit docs no longer claim "editor locked": they state the real contract — send affordance locks, edits after submit survive. Regression tests: mounted mid-flight-edit cases for manual create (incl. "dialog must not close over draft B"), quick create, comment, and chat, plus mounted-untouched controls. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(drafts): idempotent draft writes so a tab switch cannot resurrect a posted comment Final-review blocker: the comment/reply visibilitychange/pagehide flush re-writes IDENTICAL content on every tab switch, and writeDraft minted a new entry object each call — the stale-submit guard's identity compare then read a mid-flight tab switch as "edited during the request", kept the posted comment's draft alive, and left Send enabled for a duplicate. - writeDraft is now a no-op when content and uploads are unchanged (also kills a spurious persist write per tab switch). Regression tests: entry identity preserved on identical setDraft (core), and the reproduced tab-switch-mid-send scenario clears the posted draft (views) — verified to fail with the idempotence removed. - onAccepted now flushes the editor's pending debounce before judging `untouched` on every surface, so typing still inside the debounce window counts as a mid-flight edit instead of being scrubbed. - create-issue records last-assignee/mode from the SUBMITTED values, outside the untouched gate — a created issue updates the preference even when the dialog stays open on newer edits. - Stale guard comments corrected in both create panels; the use-composer-submit docstring no longer claims project/feedback were migrated (they still hand-roll await-then-clear; registered debt). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-28 10:10:00 +08:00
Bohan Jiang	4d0475ce89	feat(usage): error/failure charts on the Usage page (MUL-5352) (#5991) ... * feat(usage): add error/failure visibility to the Usage dashboard The Usage page could only answer "how much did we spend"; nothing on it showed how often agents fail, what kind of failure it was, or which agent is responsible. Operators had to open failed tasks one at a time to spot a pattern. `agent_task_queue.failure_reason` already carries the refined 21-value taxonomy from server/pkg/taskfailure, so this is a read path over data that already exists. Backend — two rollups, both scoped by workspace/project/window like the existing dashboard endpoints: GET /api/dashboard/failures/daily per-(date, failure_reason) GET /api/dashboard/failures/by-agent per-(agent, failure_reason) They return every terminal task, not just failures: the `failure_reason: ""` row carries the succeeded count. That is what makes the error rate's denominator share filters with its numerator. The run-time rollups can't serve as that denominator — they require `started_at IS NOT NULL`, so a task that expired in the queue (the signature of a runtime outage) contributes nothing to their failed_count. A failed row with an empty reason column lands in an `unclassified` bucket rather than being mistaken for a success. Frontend: - "Errors" joins the trend toggle, daily and weekly, stacked by failure class with the bucket's error rate in the tooltip. - An Errors card breaks the window down by class and by agent, with the raw failure_reason strings behind a disclosure (unlocalised — an operator pastes them into a log search). Each agent row links to its Work tab, which lists the actual failed runs. - The 21 backend reasons fold into 7 display classes in @multica/core/dashboard. Unknown reasons — including ones from a backend newer than the client — land in "other" instead of being dropped, so the class totals always reconcile with the failure count. The Tasks KPI tile is deliberately left alone: its value counts started tasks only, so quoting the failure rollup's larger count there would put two denominators in one tile. The Errors card states its rate with the denominator spelled out instead. Migration 225 adds a partial index on agent_task_queue(completed_at) for terminal statuses. The table had no completed_at index at all, so the two pre-existing run-time rollups were already scanning it; these two new queries would have doubled that. Closes #4429 (MUL-5352) Co-authored-by: multica-agent <github@multica.ai> * fix(usage): correct the Errors drill-down, window and agent exposure Review findings on PR #5991. 1. The drill-down pointed at the wrong page. `?view=work` renders ActorIssuesPanel — the issues assigned to the agent — while its runs live in the Overview pane's ActivityTab. Link to Overview. That page also could not show why a run failed: `failureReasonLabel` was a `Record<TaskFailureReason, string>` indexed with a cast to the old 6-value coarse enum, so every refined reason the backend has written since MUL-1949 resolved to `undefined`. It is now a function over the full 21-value taxonomy plus the legacy coarse values, falling back to the raw wire string for anything newer than the client. Fixes the issue execution log too, which had the same cast. 2. The Errors card covered one more calendar day than the chart above it. `parseSinceParamInTZ` returns N+1 days of headroom on purpose and the dashboard trims the surplus client-side — but only a series carrying a date can be trimmed that way. Totals / classes / reasons now derive from the date-bucketed rollup after that trim, and the per-agent rollup (which has no date to trim on) closes its window server-side via a new `parseExactSinceParamInTZ`. At days=1 the card previously reported yesterday's failures beside a chart showing none. 3. The top-offenders list leaked agents the viewer cannot see. The failure rollups are workspace-scoped and deliberately skip per-agent visibility, but the agent list they are joined against does not — members only see a private agent when they own it or are owner/admin. `name ?? row.agentId` therefore rendered a bare UUID along with that agent's failure count, rate and dominant error class. Unresolvable agents now fold into one anonymous row, and the renderer never falls back to an id. Stricter than `bucketUnknownAgentRows` while the agent list loads: a transient flash of UUIDs is the leak, not a cosmetic glitch. Also from the review: the Errors tooltip echoed the raw Recharts dataKey ("rate_limit") instead of the translated label the legend already carries. Not changed — the schema's `failure_reason` default stays `""`. Defaulting a missing field to a failure bucket guards against a deflated rate, but the realistic drift is `omitempty` on the Go struct tag, which would strip the field from exactly the SUCCESS rows and read as a 100% error rate. Added TestDashboardFailureWireContractKeepsEmptyReason to pin that the server always emits the field, which is the assumption the default rests on. Co-authored-by: multica-agent <github@multica.ai> * fix(usage): renumber migration and fix the anonymous bucket's failure class Review findings on PR #5991, round 2. 1. Migration prefix 225 collided with `225_chat_message_channel_media_pending`, which landed on main while this branch was open — backend CI failed on TestMigrationNumericPrefixesStayUniqueAfterLegacySet. Merged main and renumbered to 231; main now carries 225 through 230, so 226 is taken too. 2. The anonymous "Other agents" bucket could announce the wrong failure class. It merged rows that had ALREADY collapsed to one dominant class per agent, then credited each agent's entire failure count to that class. An agent failing auth 6 / timeout 5 contributed 11 to auth and 0 to timeout, so a bucket whose real composition was timeout 15 / auth 6 rendered as Auth. Fixed by anonymizing the raw per-(agent, reason) rows instead: the sentinel becomes just another agent_id and `aggregateAgentFailures` computes its classes from real counts. That also deletes the parallel bucketing pass — one identity rewrite replaces it. `knownAgentIds` moves up to where both consumers can see it. Also from the review: - The wire-contract test decoded both payloads into one map. json.Unmarshal merges into a non-nil map rather than resetting it, so a residual failure_reason from the first case could have masked an omitempty regression in the second — exactly what the test is meant to catch. Now table-driven with a fresh map per case. - A test comment still described the drill-down as pointing at the Work tab. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-27 18:40:48 +08:00
Bohan Jiang	ceba14a227	fix(issues): MUL-5362 return to the source list after deleting an issue (#5997) ... * fix(issues): return to the source list after deleting an issue Deleting an issue from its detail page always pushed the workspace Issues list, so opening an issue from My Issues (or a project list, search, a pin, an agent panel) and deleting it dropped the user's navigation context — GH #5995. Go back instead. `useBackOrReplace` steps back when the platform reports in-app history and replaces with a fallback path when there is none, so a shared link opened cold or a new tab never steps off the app. Web answers via the Navigation API, falling back to counting its own pushes; desktop reads the active tab's virtual history. `replace`, not `push`: the deleted issue's URL must not stay in history for the back button to land on a 404. The not-found "Back to Issues" button loses the same context, so it moves to the same helper and its label becomes a plain "Back". Co-authored-by: multica-agent <github@multica.ai> * fix(web): track history position, not push count, for canGoBack The Navigation API fallback only ever counted pushes, so `pushes > 0` did not mean the current entry still had an in-app page behind it. Cold-open an issue, click Issues, press the browser's Back button, then delete: the tracker still claimed history and `back()` would step off Multica — the exact case the fallback exists to prevent. Count depth instead: a push adds one, any traversal takes one away (clamped at zero). Reaching the document's first entry requires traversing back at least as many times as we pushed, so a positive depth can never be claimed while sitting on it. A browser Forward is now conservative — it reports no history where a step back would have been fine — which costs a fallback navigation rather than an exit. Also corrects the useBackOrReplace contract comment: stepping back leaves the dead URL in forward history, so the guarantee is that it never lands on the back stack, not that it leaves history entirely. Co-authored-by: multica-agent <github@multica.ai> * fix(web): answer canGoBack from the browser alone, never from push counts Review found the counter still lied, one level deeper: it counted `router.push` calls, and a call is not a committed history entry. Next drops a push to `replaceState` when the canonical URL is unchanged (app-router.js, the `pendingPush && href !== canonicalUrl` branch), so clicking a self-link — the breadcrumb on an issue detail page, a pin to the issue you are on — incremented depth with no entry behind it, and a delete from there could still step off the app. Fixing the count needs per-entry markers, which means depending on both React effect ordering (our provider's effect runs before app-router's history commit) and Next's own preserveCustomHistoryState behaviour. Two rounds of review have now found holes in hand-rolled history tracking; a third layer of it is not the way to buy this guarantee. So stop deriving. `canGoBack` is the Navigation API's answer or `false`. Browsers without it take the fallback path, which is exactly what they did before any of this existed — nobody regresses, and the "wrong true walks the user out of the app" failure is now unreachable by construction. Drops the tracker, the popstate wiring and the push wrapper: the `multica:navigate` bridge returns to its original shape. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-27 18:39:25 +08:00
Naiyuan Qing	c7fe10e549	fix(issues): move the thread quick-jump rail to the right edge (MUL-4522) (#5990) ... The rail looks and behaves like a scroll affordance, but sat on the far left: on a wide screen it was hundreds of pixels from both the body text and the scrollbar the pointer was already on, so every jump cost a full sweep across the page. Move it to the right edge, just inside the scrollbar. right-3 plus a 20px strip is the inset that holds in both scrollbar modes: it clears a classic scrollbar's ~11px gutter, and lands exactly on the content column's 32px padding when the gutter is 0 (overlay scrollbars), so it covers neither the scrollbar nor body text. Ticks flush right and the hover wave grows them inward; the preview card opens leftward. The find bar steps inside the rail on desktop so it can't cover the top ticks. No left/right preference setting: the evidence is one-sided, and a toggle would mean maintaining and testing two layouts for a preference nobody has argued for yet. Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>	2026-07-27 15:50:36 +08:00
Bohan Jiang	ef69c3d4a3	feat(projects): add search and max-height to the project picker (MUL-5344) (#5979) ... * feat(projects): add search and max-height to the project picker (MUL-5344) Migrate ProjectPicker off the bare DropdownMenu onto the shared PropertyPicker (the same primitive assignee/label/status pickers use), so the project dropdown now caps its height with a scrollable list and gains a client-side search box. Search matches on title substring and pinyin, so Chinese project names are reachable by latin input. Preserves the full existing contract: controlled/uncontrolled open with the Base UI open-latch normalization, the disabled read-only lock, the inline hover/keyboard clear button, and every caller's custom trigger. Co-authored-by: multica-agent <github@multica.ai> * fix(pickers): reset picker search state on programmatic close (MUL-5344) PropertyPicker cleared its search query inside the popover's open-change handler. Every picker closes itself after a selection by calling its own setOpen(false), which flips the `open` prop directly and never routes through that handler — so the stale query survived into the next open and kept the rest of the list filtered out. Move the reset onto the open -> closed transition so it covers programmatic closes too. This also fixes the same latent staleness in the assignee and label pickers, which close on selection the same way. Adds a regression test: search -> select -> reopen must show an empty input and the full list. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-27 13:52:22 +08:00
Bohan Jiang	1869b1b5e0	test(issues): give table-view editor test 60s to survive CI CPU starvation (MUL-5326) (#5964) ... Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-27 03:12:50 +08:00
Bohan Jiang	ecce589867	MUL-5265: GitHub API-snapshot PR cards — CI status + mergeability (#5889) ... * feat(github): API-snapshot PR cards — CI status + mergeability (MUL-5265) Fetch each linked PR's CI checks and mergeability from the GitHub GraphQL API as the single source of truth (Plan C). Webhooks, page visits and a bounded TTL sweep are refresh triggers only; nothing is inferred from webhook payloads anymore. Backend (server/internal/integrations/ghsnapshot): - installation-token cache + GraphQL client (private key / tokens never logged) - one paginated pullRequest query -> normalized per-check snapshot - outbound queue: (installation,repo,PR) dedup + single in-flight per PR, bounded worker pool, Retry-After / rate-limit backoff, jitter - head-SHA-guarded atomic batch replace (a slow response for an old head can never overwrite a newer head's snapshot) - bounded chase window (30s->5m, stops on terminal/closed) + page-visit + TTL refresh; clean degradation when no App private key is configured Removes the old suite-level webhook aggregation display path (query + handlers + tests). check_suite / check_run / status are now pure triggers. Frontend: PR card shows two independent tri-state elements (CI status + mergeability). "Ready to merge" only when merge state is clean; no-checks and unknown-mergeable never assert a positive verdict; progress strip removed; four locales; stale marker. Docs: github-integration + environment-variables (four languages) — now required App private key, read-only Checks/Commit-statuses permissions, new event subscriptions, capability boundaries and troubleshooting. Co-authored-by: multica-agent <github@multica.ai> * fix(github): address PR snapshot review blockers Co-authored-by: multica-agent <github@multica.ai> * fix(github): bound snapshot refresh scheduling Co-authored-by: multica-agent <github@multica.ai> * fix(github): concurrent check-run index migration + singleflight token mint Address Elon's third-round review on the MUL-5265 PR snapshot pipeline. Must-fix — migration built a non-concurrent index. The github_pull_request_check_run table declared PRIMARY KEY (pr_id, ordinal) inside CREATE TABLE, which builds a unique index synchronously and violates the repo rule that every migration-created index (including on a new table) use CREATE UNIQUE INDEX CONCURRENTLY in its own single-statement file. Split: 222 now creates the table without a primary key; new 223 adds the (pr_id, ordinal) unique index CONCURRENTLY. The atomic delete-all/insert write path already guarantees ordinal uniqueness, so a plain unique index is sufficient; the index also serves the pr_id-prefix list aggregation and the workspace/PR cleanup deletes. Nit — token mint now singleflights per installation. installationToken released the lock before minting, so the N workers of one installation could mint N tokens on a cold cache or a simultaneous renew. Concurrent callers for the same installation are now collapsed via singleflight into one HTTP mint; added a -race concurrent-mint test asserting a single mint under 16 callers. Verified: fresh DB migrates through 223 (table has no PK, concurrent unique index present); ghsnapshot suite + new test pass under -race; migration lint and handler github/workspace-delete tests pass; sqlc produced no diff; go build / vet / gofmt / git diff --check clean. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-24 18:30:20 +08:00
Naiyuan Qing	f599fe3b85	fix(views): board/list load-more no longer flashes the skeleton + friendlier footer (#5893) ... * fix(views): board/list load-more stops flashing the full skeleton Tail (load-more) page fetches were folded into the surface-level isLoading through the per-branch aggregate, so scrolling to load more in List and status-grouped Board replaced the already-rendered rows with the full-surface skeleton. Track head-page pending separately and gate the surface isLoading/isRefreshing on heads only; per-branch pagination state that drives the load-more sentinel is unchanged. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * feat(views): friendlier infinite-scroll footer for board/list/swimlane Collapse four copies of the error/has-more/reached-end ternary into a shared ListLoadMoreFooter: the loading spinner now carries a "Loading…" label so a slow fetch no longer reads as stuck, and a column that actually paginated shows a muted "No more" marker at the end instead of stopping silently. InfiniteScrollSentinel gains an optional label; adds the table.no_more string in en/zh-Hans/ja/ko. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-24 17:14:11 +08:00
Naiyuan Qing	00e658401b	feat(views): revamp execution log — virtualized, readable, two-tier header (#5890) ... Combines the transcript work (previously split across #5860 virtual scroll and #5871 reading hierarchy) into one branch on current main, folding in the runtime-alias display from #5881. - Virtualize the event list (react-virtuoso) so a multi-thousand-event run mounts a bounded number of DOM rows (#5733), with firstItemIndex anchoring for newest-first live prepends. - Reading hierarchy via a pure trace-event-presenter: agent text and errors render expanded in place through RichContent (compact, log-scale markdown); thinking/tool rows fold to one line; tool detail expands into a quiet surface with "show all". - Persisted 3-way expand density (smart/expanded/collapsed) with per-row overrides; legacy defaultExpanded boolean migrated. Filters always persist (dropped the preserve-filters toggle). - Two-tier header: identity row (status, agent, trigger source, triggered-by) + list toolbar (created/duration/events facts left, shared Button controls right); runtime/provider/workdir/timestamps move to an ⓘ popover, runtime shown via runtimeDisplayName (#5881). - Copy-all exports full event bodies (redacted) with RFC 3339 timestamps (#5873), not the truncated summary. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>	2026-07-24 16:44:43 +08:00
Bohan Jiang	2aafa41a5f	MUL-5258: feat(issues): show agent-working indicator in Table view (#5875) ... * feat(issues): show agent-working indicator in Table view Reuse the self-contained IssueAgentActivityIndicator (already in List and Board views) in the Table view's Issue column, rendered right after the identifier and before the title — matching the List view placement so the 'agent working' cue sits in the same spot across all three views. The indicator returns null when no agent is active, so inactive rows are unchanged. MUL-5258 Co-authored-by: multica-agent <github@multica.ai> * test(issues): cover Table agent-working badge insertion The previous stub returned null with no assertion, so deleting the badge insertion in table-view.tsx would still pass every test here. Render a marker carrying the issue id and assert the Table cell mounts it for the row's issue, positioned between the identifier and the title (identifier → activity → title, matching List/Board). Verified the new test fails when the insertion is removed. MUL-5258 Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-24 15:02:33 +08:00
Bohan Jiang	8d18d3a9ec	Revert "MUL-5180: fix(github): surface CI status on PR cards (#5811)" (#5855) ... This reverts commit 139cc89200. Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-24 02:52:22 +08:00
Bohan Jiang	139cc89200	MUL-5180: fix(github): surface CI status on PR cards (#5811) ... * fix(github): surface CI status on PR cards (MUL-5180) The CI mirroring pipeline (MUL-2228, MUL-2392) has never received a single event in production. The GitHub App setup docs only ever asked operators to grant `pull_requests: read` and subscribe to `pull_request`, so GitHub never delivered `check_suite` — `handleCheckSuiteEvent` sat dead behind a subscription nobody was told to enable. Every linked PR reports checks_passed/failed/pending = 0 and the sidebar row falls through to "Checks haven't reported yet" forever. Docs (the root cause), all four locales: - add `Checks: Read-only` permission + `Check suite` event to the App setup table - drop the stale "CI check states are not modeled" claim, which predates MUL-2228 and is what let the setup table stay incomplete - add a "PR rows show no CI status" troubleshooting entry with the public `/apps/<slug>` probe to confirm what an App is actually subscribed to, and a warning that existing installations must accept the new permission before any `check_suite` is delivered UI: - give the actionable status kinds (checks failed/pending/passed, conflicts, ready) their own icon + color. CI outcome previously rendered as plain muted 11px text, visually identical to the diff stats beside it — a failing build read the same as "+437 −6 · 6 files". Terminal and unknown kinds stay muted; the row's state icon already carries that meaning. Co-authored-by: multica-agent <github@multica.ai> * fix(github): unbreak docs build, stop overclaiming CI completeness (MUL-5180) Both must-fixes from review. 1. docs production build failed. `<your App>` in prose was parsed as a JSX tag, so `pnpm --filter @multica/docs build` died with `Expected a closing tag for <your>`. Dropped the angle brackets. Repo CI never caught this because no workflow runs the docs production build — only Vercel does, which is why the PR's GitHub checks were green while the deployment errored. 2. `Checks: Read-only` cannot support the pending status the docs promised. GitHub's webhook contract delivers `check_suite.requested` / `.rerequested` only to Apps holding Checks *write*; read-level access receives `completed` only. Verified against GitHub's published docs. Direction chosen: keep read-only, degrade honestly to final-results-only. Checks *write* is a repo-write capability (create/update check runs), not a wider read — escalating every installation to it just to render an in-flight spinner is not a trade to make on the operator's behalf, and it contradicts the integration's read-only posture. The concrete bug this leaves is premature green: with two reporting apps, the first to complete makes total=1/passed=1 and the row claimed "All checks passed" while the second was still running and might fail. Copy is now "Checks passed" in all four locales — it reports what reported and never asserts completeness. `derivePullRequestStatusKind` documents why. Docs gain a "what CI status can and cannot tell you" section (all four locales) with the read-vs-write delivery table, both consequences stated plainly, and the opt-in path for teams that do want in-flight status: set Checks to Read and write on their own App and the existing pending code lights up with no code change. The pending promise is removed from the read-only setup path. Co-authored-by: multica-agent <github@multica.ai> * fix(github): ignore non-completed check_suite actions (MUL-5180) Review was right: the `Read and write` opt-in the previous commit documented does not produce reliable pending, and following it would break the card. `check_suite.requested` / `.rerequested` are not observations that some CI provider started. GitHub sends them only to Apps holding Checks write, and per the CI-checks App docs they mean "GitHub has created a check suite for YOUR app on this commit; now add your check runs to it". Multica observes other apps' results and never creates check runs. Recording such a suite parks a `queued` row nothing can ever complete, and since `checks_pending` outranks `checks_passed` in derivePullRequestStatusKind, one stuck row freezes every PR on that installation at "checks running" and hides the real pass/fail result. Any self-hoster who already grants Checks write hits this on every push, so the gate is on the action, not the permission. - handleCheckSuiteEvent drops every action except `completed`, with the reasoning and the "don't resurrect requested as a running signal" warning recorded at the gate. - TestWebhook_CheckSuite_QueuedCountsAsPending encoded the wrong delivery semantics (two external apps sending `requested`, which GitHub never does). Replaced by TestWebhook_CheckSuite_NonCompletedActionsIgnored, which pins the drop and checks a later `completed` suite still lands. - The two out-of-order stash tests used `requested` payloads to exercise paths that are really about completed suites; both now use `completed` and assert the same guarantees. - Docs (four locales): the write opt-in is gone. In-flight CI is documented as unsupported at any permission level, with the actual reason and the note that real running status needs polling or a check_run model instead. Co-authored-by: multica-agent <github@multica.ai> * fix(github): make legacy non-completed check suites inert (MUL-5180) Review was right again: the previous commit gated the webhook entry point but left the pre-upgrade state — and the people it was meant to protect (self- hosters who already granted Checks write) are exactly the ones holding it. Two leftovers, both now closed: 1. Rows already in github_pull_request_check_suite. The old handler stored GitHub's `requested` suites as `queued`; nothing will ever complete them. ListPullRequestsByIssue still counted them, so `checks_pending` kept outranking `checks_passed` and the PR stayed pinned to "checks running" for as long as its head SHA stood. The aggregation now selects only `completed` suites. Filtering beats deleting here: recovery is automatic on deploy, needs no migration over a table that can be large, and holds for any writer that misses a gate — not just for today's legacy rows. DISTINCT ON runs after the filter, so an app whose newest suite is a stuck `queued` still reports its most recent completed verdict instead of disappearing. 2. Rows already in github_pending_check_suite. replayPendingCheckSuitesForPR is a second write path into the live table that never passes through handleCheckSuiteEvent, so the next `pull_request` event would re-inject a permanently-queued suite after the fix shipped. It now skips non-completed rows; the drain is DELETE ... RETURNING, so skipping discards them. Both are covered by regression tests that seed the legacy row directly — the fixed handler can no longer produce one — and both were confirmed to fail with their respective fix reverted. The stash test additionally asserts its fixture landed under the repo address the drain keys on; the first draft used the wrong owner and passed vacuously. Also corrects the aggregateChecksConclusion doc comment, which still described "pending" as a not-yet-completed suite. It is now reachable only for a completed suite carrying a null conclusion, and is explicitly not a "CI is running" signal. Co-authored-by: multica-agent <github@multica.ai> * test(github): assert the legacy stash row is consumed by the drain (MUL-5180) Review nits. The stash test proved its fixture existed before the webhook but never that the drain consumed it, so a future change to firePullRequestWebhookWithHead's repo address would make the assertions pass for the wrong reason again — the same way the first draft of this test did. Asserting the stash is empty afterwards closes that gap from the other side. Also fixes two comment typos: `an "CI is running"` -> `a`, and drops the "merged-but-open PR" state, which cannot exist. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-23 21:23:25 +08:00
Multica Eve	98072e2e56	fix(issues): filter working agents by active task issues (#5839) ... Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-23 17:54:52 +08:00
Multica Eve	423a5c59cb	MUL-5200: unify working-agent filters across issue views (#5819) ... * fix(issues): query workspace working agents independently Co-authored-by: multica-agent <github@multica.ai> * feat(agents): filter working agents by source type Co-authored-by: multica-agent <github@multica.ai> * feat(issues): scope working agents to My Issues Co-authored-by: multica-agent <github@multica.ai> * test(agents): cover My Issues squad relations Co-authored-by: multica-agent <github@multica.ai> * fix(issues): unify working-agent filters across views Co-authored-by: multica-agent <github@multica.ai> * fix(issues): preserve empty working-agent filters Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-23 16:54:41 +08:00
YYClaw	e3ebf317ae	fix(i18n): capitalize on-behalf-of attribution label (MUL-5026) (#5670)	2026-07-23 16:35:22 +08:00
Multica Eve	40f9ecdd56	MUL-5202: unify Issue Query across List, Board, and Swimlane (#5820) ... * MUL-5202: migrate status issue surfaces to table query Co-authored-by: multica-agent <github@multica.ai> * MUL-5202: unify grouped issue surfaces Co-authored-by: multica-agent <github@multica.ai> * MUL-5202: cover move safety boundaries Co-authored-by: multica-agent <github@multica.ai> * MUL-5202: preserve server swimlane semantics Co-authored-by: multica-agent <github@multica.ai> * MUL-5202: keep grouped surface facets exact Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-23 15:58:25 +08:00
Multica Eve	8065cead85	MUL-5198: Restore server-backed issue table grouping (MUL-5100) (#5817) ... * revert(issues): restore server-backed table grouping Co-authored-by: multica-agent <github@multica.ai> * test(skills): stabilize import completion coverage Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica-ai.local> Co-authored-by: multica-agent <github@multica.ai>	2026-07-23 12:03:27 +08:00
Bohan Jiang	0d8a7ce5c2	fix(inbox): drop the agent activity hover card from inbox rows (MUL-5189) (#5813) ... * fix(views): raise hover delay on the agent activity badge The per-issue agent activity badge sits on the right edge of dense scrolling lists (inbox rows, issue rows, board cards) and appears on every issue an agent currently touches. Base UI's 600ms default opened the 288px activity card on pointer travel rather than on intent. Raise the open delay to 900ms and drop the close delay to 150ms. The card body is read-only, so there is no hover bridge to protect. MUL-5189 Co-authored-by: multica-agent <github@multica.ai> * fix(inbox): drop the agent activity hover card from inbox rows The badge already shows who is running and whether they are working or queued. On a triage surface the card's only incremental fact is elapsed time, which never changes the one decision an inbox row supports — do I open this? The row also carries the ActorAvatar hover card on the left, so a second popup was mostly noise. Add an opt-out `hoverCard` prop to IssueAgentActivityIndicator and pass false from the inbox row. Issue lists and board cards keep the card: monitoring work in flight is what those views are for, and they keep the 900ms dwell delay from the previous commit. MUL-5189 Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-23 11:11:00 +08:00
Jiayuan Zhang	e0e9383efe	Improve UI animation transitions (MUL-5172) (#5718) ... * Improve UI animation transitions * Remove implementation plan documents Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-07-23 01:38:16 +08:00
Jiayuan Zhang	4d74db89cb	feat(issues): richer sub-issue rows in issue detail (MUL-5098) (#5721) ... * feat(issues): richer sub-issue rows in issue detail (MUL-5098) The sub-issues panel showed only status, identifier, title and assignee — priority, due dates, labels, live agent activity and nested breakdowns were invisible without opening each child. - SubIssueRow now shows priority (checkbox-slot swap like list rows), the agent-activity indicator, label chips (+n overflow), the child's own done/total progress ring, and an inline-editable due date with overdue emphasis (muted when the child is done/cancelled) - Right-click opens the shared issue actions menu via a section-level IssueContextMenuProvider — parity with list/board surfaces - ListChildIssues + ListChildrenByParents now bulk-load labels (same labelsByIssue pattern as the other list endpoints) - patchIssueLabels patches per-parent children caches; invalidateIssueLabelDerivatives refetches the Map-shaped batched children caches so label changes stay live everywhere Co-authored-by: multica-agent <github@multica.ai> * feat(issues): customizable property display for sub-issue rows (MUL-5098) The enriched sub-issue rows were a fixed field set — no way to trim them or surface workspace custom properties. - New user-level persisted preference (useSubIssueDisplayStore): built-in field toggles (priority / labels / sub-issue progress / due date / assignee) + opted-in custom property ids. Defaults match the previous fixed layout, so existing users see no change. - SubIssueDisplayPopover on the section header — same switch-row interaction as the main views' Display panel, reusing its card_* locale keys (no new translations needed). - Rows render opted-in custom property chips (PropertyIcon + CustomPropertyValueDisplay, list-row parity) only when the child carries a value; ids resolve against live non-archived definitions, so foreign-workspace or archived ids are inert. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): reconcile sub-issue cache updates Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-22 22:43:34 +08:00
Bohan Jiang	dd45f30553	MUL-5164: refactor(issues): drop the table toolbar loaded-count and structure-paused copy (#5778) ... * test(issues): repair table-view editing tests orphaned by the grouping revert Reverting "Move issue table grouping to the server" (#5777) removed the server-driven `serverIssues` fixture, but two tests still assigned to it, so packages/views typecheck and vitest have been failing on main. Pass the issue through the Harness `issues` prop like the sibling tests do. Co-authored-by: multica-agent <github@multica.ai> * refactor(issues): drop the table toolbar loaded-count and structure-paused copy The table toolbar rendered a permanently visible "Loaded X of N" counter plus a long "Grouping and hierarchy are paused — ..." notice. Neither is worth the horizontal space it took between search and Export, so remove both strings and their locale keys. The load-failure Retry button stays: it only renders on a failed window fetch and is the explicit resume path for the infinite-scroll sentinel. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: J <agent@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-22 18:40:02 +08:00
LinYushen	4dc47ef113	Revert "MUL-5100: Move issue table grouping to the server" (#5777) ... This reverts commit d43e500ff6.	2026-07-22 18:06:37 +08:00
Jiayuan Zhang	15326c5090	fix(issues): open table issues in new tabs (#5767) ... Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-22 17:03:04 +08:00
Jiayuan Zhang	d43e500ff6	MUL-5100: Move issue table grouping to the server ... Merge approved after review; CI checks are green.	2026-07-22 14:36:51 +08:00
Jiayuan Zhang	fe12278863	feat(issues): add table sub-issue action (#5738) ... Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-22 05:33:18 +00:00
Jiayuan Zhang	1a37063bba	fix(issues): keep table cell editors open across refreshes; title click opens the issue (MUL-5108) (#5730) ... * fix(issues): keep table cell editors open across refreshes; title click opens the issue (MUL-5108) Table view interaction fixes: - Cell/header renderers are now stable module-level components reading data via table.options.meta. flexRender mounts function cells as component types, so the per-render closures rebuilt on every data refresh (new childProgressMap / property / actor identities) remounted every cell and closed any open picker popup. - One hoisted editingCellKey drives all cell editors (controlled open), and while an editor is open the row structure renders from a frozen snapshot (live issue values, frozen order) so window materialization, hierarchy assembly, and realtime reorders cannot move or unmount the popup's anchor row mid-interaction. Structure catches up on close. - Clicking an issue title now opens the issue (it previously started inline rename despite the link-style hover). Renaming moved to a hover pencil affordance; dead space in the title cell navigates too. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): address table editor review — blur-click nav, virtual-unmount key release, deterministic test (MUL-5108) Follow-up to the MUL-5108 table fixes, per code review on PR #5730: - R1#2 (P1): committing a rename by clicking away also navigated into the issue. onBlur flips `editing` off synchronously before the commit-click lands, stripping the click-time guard so the click bubbled to row navigation. Record whether the gesture began while editing (mousedown, before blur) and swallow that click in the capture phase, before it can reach the row or the title's open handler. Dead-space clicks while not editing still open the issue. New blur-click regression test. - R1#3 (P2): the hoisted editingCellKey (and the frozen row structure keyed off it) never cleared when row virtualization unmounted the anchor cell — Base UI does not fire onOpenChange(false) on unmount, so the table stayed frozen and the picker silently reopened / dropped the rename draft on scroll-back. Add useReleaseEditingCellOnUnmount: an unmount responder that releases the key iff the unmounting cell still owns it. Focused tests. - R1#1 (P1): the new integration test exceeded the 5s default under concurrent CI worker load (real-timer gaps between userEvent steps). Drive userEvent with delay:null and give the heavy full-mount test explicit headroom so it is deterministic. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-21 18:47:14 +08:00
Naiyuan Qing	41315989bd	fix(editor): prevent incorrect comment autolinks (#5665)	2026-07-20 14:57:41 +08:00
Bohan Jiang	1be1fd3be1	fix(issues): label board display-settings button as Display (MUL-5011) (#5664) ... The display-settings trigger showed the current sort mode (e.g. "Manual") as its label, which reads as an unclear button name. Show a fixed "Display" label with the sliders icon instead, matching the existing "Display settings" tooltip. The sort mode remains visible inside the popover's Ordering section. Co-authored-by: Bohan-J <bohan@devv.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-20 14:49:12 +08:00
Naiyuan Qing	fcb4798f12	fix(issues): stop cold-load render loop on the Issues route (MUL-4985) (#5643) ... Board and Swimlane crashed with "Maximum update depth exceeded" on first paint of the Issues route. During cold load the member/agent/squad directory queries are unresolved, so useActorName's `= []` defaults allocated a fresh array every render and its `getActorName` memo changed identity each render. BoardView's `groups` (and SwimLaneView's `laneGroups`) list `getActorName` as a dep, so they churned every render and re-fired the column-resync effect without end; react-virtuoso escalated the loop into the reported crash. This predates MUL-4797 — it was exposed when board/swimlane columns were virtualized with a real <Virtuoso>. - Share stable empty references for the loading directory snapshot so getActorName is referentially stable across cold-load renders (root cause). - Equality-guard the shared column setter in useDragSettle so a content-equal rebuild returns the previous reference and cannot spin the resync effect (defense-in-depth). Regression coverage: useActorName stability during cold load; the column-setter equality guard; and Board (40 cards) + Swimlane rendered with the REAL react-virtuoso under pending directories, which reproduce "Maximum update depth exceeded" without the fix and pass with it. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>	2026-07-20 08:52:02 +08:00
Jiayuan Zhang	002ea0d879	MUL-4797: add configurable issue table view (#5454) ... * feat(issues): add configurable table view Co-authored-by: multica-agent <github@multica.ai> * test(issues): cover table columns in page fixture Co-authored-by: multica-agent <github@multica.ai> * fix(issues): make table column picker interactive Co-authored-by: multica-agent <github@multica.ai> * fix(issues): repair quick create and virtualize table rows Co-authored-by: multica-agent <github@multica.ai> * fix(issues): keep pinned table cells opaque Co-authored-by: multica-agent <github@multica.ai> * fix(issues): anchor full-width table rows Co-authored-by: multica-agent <github@multica.ai> * fix(issues): consolidate table controls Co-authored-by: multica-agent <github@multica.ai> * fix(issues): harden table pagination and export Co-authored-by: multica-agent <github@multica.ai> * feat(issues): add table quick search Co-authored-by: multica-agent <github@multica.ai> * fix(issues): make table window filters, selection, and export authoritative Round-2 review fixes for the issues table (MUL-4797): - Send the agents-working filter as a server ids facet so matches on unfetched pages surface and total/pagination/export agree; a present- but-empty id list yields an empty window instead of an unfiltered one. - Reset surface selection when the membership window changes and act on selection ∩ visible rows in the batch toolbar, so batch actions, Export selected, and the count all share one authoritative set. - Materialize the full flat window while table grouping is active, and suspend hierarchy nesting / parent-based grouping until the window is complete so structure cannot reshuffle as pages arrive; suppress header facet-count badges while the table window is partial. - Resolve actor directories and the property catalog at export time and fail the export instead of writing Unknown* actors or dropping configured property columns on cold/errored lookups. - Append a unique id tie-break to the list/grouped ORDER BY and mirror it in compareIssuesForSort so offset pages are stable across same-timestamp ties. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): bound table structure window and align chip/transport/selection Round-3 review fixes for the issues table (MUL-4797): - Cap whole-window materialization at TABLE_STRUCTURE_MAX_WINDOW (1000): below it the remaining pages load automatically — hierarchy applies without scrolling to the last page — and above it grouping/hierarchy suspend with an explicit toolbar notice instead of triggering an unbounded workspace download from a persisted view option. - Give the agents-working chip the authoritative in-window running set (the ids-facet window query, shared key with the filter-on state) so its badge can no longer say 0 while the filter would find matches on unfetched pages; falls back to loaded-row scoping elsewhere. - Route ids-facet windows through a new POST /api/issues/query twin — hundreds of running-issue UUIDs overflow the ~8 KB GET request-line budget of common proxies. The body carries the same key/value pairs; the handler rebuilds the query string and delegates to ListIssues. - Reset surface selection during render (key-change pattern) instead of a post-commit effect, so no frame ever pairs new membership with the old selection. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): harden table auto-pagination against errors and stale totals Round-4 review fixes for the issues table (MUL-4797): - Stop the structure materialization loop (and the scroll sentinel) when the window query is in error state — a persistently failing page left hasNextPage true and isFetchingNextPage false after every attempt, so the ungated effect refired forever. Resuming is an explicit toolbar Retry. The advancement decision now lives in a pure, tested shouldAutoLoadNextStructurePage helper. - Make the structure ceiling a hard stop: the ceiling check reads the LATEST page's total (pagination already advances on it, so a stale small page-1 total could re-open unbounded materialization), and the loop additionally halts on loaded count >= ceiling regardless of any reported total. - Drive the working (ids-facet) window to completion — it is inherently bounded by the running set — and treat it as the chip's authoritative scope only when complete, so >100 running issues no longer under-count as a single page. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): make working-window pagination capped and unknown-aware Round-5 (final) review fixes for the issues table (MUL-4797): - The working (ids-facet) window now advances through the same shouldAutoLoadNextWindowPage gates as the structure loop — it shares the main table's cache key while the agents-working filter is on, so an uncapped chip-driven loop re-opened the very ceiling the table just enforced. An over-ceiling window stops after page one. - A cold-load failure of the flat window is an ERROR state, not an empty workspace: isEmpty only claims empty on a successful zero-result fetch, and the surface renders a dedicated failed-to-load state with a reachable Retry (the in-table Retry never mounted without data). - The chip scope is now tri-state honest: a COMPLETE window (or an empty running set) yields a precise count, keepPreviousData carries the last-known-complete set across re-keys, and everything else — cold resolving, failed, over the ceiling — presents as an explicit unknown ('Agents working: —') instead of a number derived from whichever incomplete window happened to be loaded. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): single pagination owner and placeholder-honest chip scope Round-6 review fixes for the issues table (MUL-4797): - Exclude placeholder data from the working-window completeness gate: on a re-key (running set or facet change) keepPreviousData leaves the OLD key's rows visible, and pairing them with the new task snapshot published a precise-looking number for a scope nobody fetched. The scope now reads unknown until the new key resolves. - Make the shared table query single-owner while the agents-working filter is on: the chip's background loop no longer answers the same render snapshot as TableView's structure loop, and every auto caller (structure loop, working loop, scroll sentinel, retry) now uses fetchNextPage({cancelRefetch: false}) so a concurrent responder no-ops instead of cancel/restarting a fetch whose HTTP request is not abortable — which had been duplicating every offset. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-17 19:21:27 +08:00
Naiyuan Qing	ce15300493	MUL-4884: feat(issues): anchor the working chip on agents + real colour tiers (#5540) ... * fix(issues): anchor the working chip on issues the filter actually shows (MUL-4884) The header chip showed three units at once: the number counted distinct issues, the avatar stack counted agents (with a rival "+N"), and the hover card counted tasks — under a label with no noun at all. Each figure was self-consistent; together they read as a miscount. c4209ec7c flipped the number from agents to issues but left the other three surfaces on their old units. The chip now says one thing — "N issues in progress" — where N is the number of rows clicking it leaves. Data layer: - The count is no longer re-derived from the task snapshot. The surface exposes `workingScopeIssues`: the render pipeline's own output with `workingOnly` forced on, so "chip count === row count" holds by construction instead of by convention. It previously counted running issue_ids against the PRE-filter set, so any active status/assignee/label filter — or a sub-issue hidden by the display toggle — made the chip disagree with the list it was filtering. - Chat/autopilot tasks carry issue_id "" (not null). They used to collapse into one bucket and read as a phantom issue, inflating the count by exactly one whenever any were running. They are now bucketed out and disclosed. - The list loads one page per status (50), so running work can exist past the window. The count stays list-anchored — counting rows a click cannot show would break the chip's whole promise — and the gap is stated in the hover card rather than dropped silently. UI: - Avatar stack is ambience, not a statistic: no "+N"; the tail fades and the exact roster lives in the hover card. - Hover card groups rows by issue, names both counted units in its header ("3 issues in progress · 4 tasks"), and footnotes anything excluded — only when non-zero. - Colour is two-step: idle activity is a brand tint, the filled state is reserved for "filter is ON". Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> * fix(issues): scope the working chip to the rows swimlane and gantt actually draw (MUL-4884) Review found two modes where `workingScopeIssues` still came from a different set than the one on screen — the exact drift this change set is meant to remove. Swimlane: scoped to the statusless `swimlaneIssues`, but SwimLaneView draws its cards from `issues` (status filter applied) and only uses the statusless set for LANE DISCOVERY. A status-filtered swimlane counted rows the canvas never drew. Swimlane needs no branch at all — it renders the flat filtered list like board and list do — so the special case is gone rather than corrected. Gantt: the canvas applies two rules of its own before drawing — a row needs a date to be placed, and done/cancelled hide unless `ganttShowCompleted` is on — so a done issue with a running agent counted toward the chip while the canvas refused to draw it. Those rules now live in the surface (`ganttCanvasRows`) instead of privately inside GanttView, and both `filteredGanttIssues` and the working scope go through them. Mirroring the rules in a second place would have reproduced the original bug with extra steps; hoisting them means the chip narrows the same set the canvas draws, by construction. GanttView goes back to being a renderer: it orders rows, it does not decide which ones exist. Regression tests cover both, and each was confirmed to fail against the code it guards: swimlane asserts the statusless lane source still holds the wider set, so a revert fails loudly rather than passing by luck; gantt covers the hidden done row, the undated row, and the show-completed toggle widening both the canvas and the scope together. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> * feat(issues): anchor the working chip on agents, and give it real colour tiers (MUL-4884) Follows the approved final mock. Two changes, one root cause each. SEMANTICS: the chip now counts agents, not issues. The original bug was "+1" (agents) sitting next to "3" (issues) — two units in one control. Anchoring on issues fixed which number was authoritative but left the units mismatched, so the avatar stack had to lose its +N and the label had to grow a noun to suppress the contradiction. Counting agents makes the number and the heads beside it the same list: the mismatch is gone rather than managed. It also settles the subject — only agents emit a runtime signal, so "N agents working" cannot be misread as "N issues someone is working on", which "N issues in progress" invited. Accepted trade-off: the number no longer predicts the row count of the click. One agent on two issues reads "1 agent working" and opens two rows. The chip answers WHO, the list answers WHERE — different questions, so they don't compete, and the hover card's issue grouping shows the mapping. The workingScopeIssues pipeline stays: it still decides WHICH agents count. The hover card drops both "not counted" footnotes. They explained an absence the user never perceived — chat/autopilot runs leave no row, no head, no indicator on this page — so they invented a discrepancy instead of resolving one. The empty-issue_id guard stays: that is data correctness (those agents aren't on any issue), independent of whether we narrate it. Avatar overflow returns to the component's standard +N badge; the fade variant is deleted. With an agent-anchored number, "3 shown + 1 = 4" corroborates the text instead of competing with it. COLOUR: three tiers, each a self-contained Button variant. Layering brand classes over `outline` could never work in dark mode: `outline` ships dark:bg-input/30 / dark:border-input / dark:hover:bg-input/50, tailwind-merge keeps them (different modifier group), and they win the cascade — `dark` compiles to `&:is(.dark *)`, so they outrank a bare .bg-brand on specificity, not just order. Both brand tiers were dead in dark; --brand-foreground equals --foreground there, so filter-on and filter-off rendered pixel-identical. New `brand` / `brandSubtle` variants own every state instead: hover, pressed, and aria-expanded pinned to the hover value so opening the popover doesn't read as a colour change. `brand` needs no dark: at all — the token flips per theme. `brandSubtle` runs one notch hotter in dark, where the same alpha reads weaker. Verified against the compiled stylesheet rather than by asserting class strings — a string assertion is what let the dark bug through. A cascade check resolves each tier x {default,hover,pressed,popover-open} x {light,dark} by specificity and source order; all 16 brand cells land on their intended notch, identical in both themes for `brand`. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> * fix(issues): stop the empty-state muted text from overriding the brand tier (MUL-4884) Review caught the colour rule breaking itself, and the test that was supposed to guard it being unable to. `filter ON + 0 agents` is a real state — the filter stays on after the last agent finishes. There the variant is `brand`, and the chip appended `text-muted-foreground` for the empty state regardless of the filter. tailwind-merge keeps the last class in a group and `className` is merged after the variant, so the muted grey WON: grey text on a brand-blue fill. The irony is exact — this change set exists because colour classes in `className` lose to a variant's `dark:` chain, and here one beat the variant instead. Either way the lesson is the same: a tier's colours only ever come from its variant. `chipAppearance` now makes that a rule with one gated exception instead of an inline ternary, and says why. The variant assertion could not catch this: the variant IS `brand` while the text is overridden. That is the same shape of false confidence as the class -string assertion it replaced, so this commit brings the cascade check into the repo instead of leaving it as something a commit message claimed. `apps/web/app/brand-variant-cascade.test.ts` compiles the real globals.css — web's and desktop's, since each defines its own `dark` variant — and resolves what a browser would paint for the merged class strings: filter declarations matching the element's classes and state, then take the winner by specificity, then source order. It asserts both tiers across default / hover / pressed / popover-open x light / dark, and pins the two ways the colour has actually been lost as executable failures: layering brand over `outline` (dark:bg-input/30 wins by specificity) and appending a colour class (wins by merge order). Both new guards were confirmed to fail against the code they guard: reverting the gate fails the chipAppearance test; giving `brand` a dark: rule fails the cascade test in both bundles. Also refreshes the comments still describing the retired issue-anchored invariant ("chip count === row count"). The scope pipeline they describe is unchanged and still load-bearing — it decides WHICH agents count — but the chip's number is agents, so it is no longer this list's length. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>	2026-07-17 13:56:23 +08:00
Jiayuan Zhang	ed9adc2bbe	feat: improve create issue field controls (#5532) ... Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-17 11:11:52 +08:00
Naiyuan Qing	3b08456264	feat(views): block draft-fixing actions while attachments upload (#5465) ... Submitting a composer mid-upload silently lost the file: the editor holds a `blob:` placeholder that gets stripped during serialization, and the attachment id does not exist yet, so the send succeeded without the file. Chat and Quick Create gated this; manual issue create, Feedback's button, comments, replies and comment edit did not. Gate every action that FIXES a draft — Send/Create/Save, Cmd/Ctrl+Enter, Enter on the title, and the manual/agent mode switches — behind one source of truth: the editor document, which IS the upload queue. ContentEditor publishes queue transitions via `onUploadingChange` (a transaction listener, not `onUpdate` — that path is debounced and skips no-change emissions, and a failed upload leaves byte-identical markdown, so the un-gate would never fire). `useUploadGate` pairs that render state with an `isBlocked()` re-read at submit time, since the shortcut paths never consult the button. The publisher emits its current answer on subscribe rather than only on flips: hosts outlive editor instances (comment edit remounts on cancel, chat swaps by key on agent switch), and an editor torn down mid-upload would otherwise leave submit wedged shut with no pending node left to reopen it. Also fixes the failure toast that never fired: `uploadWithToast` only reported errors if a caller passed `onError`, and none did, so failed uploads removed their placeholder and vanished unexplained. `useEditorUpload` now supplies it once for every composer. Per MUL-4808: drops Quick Create's upload-time lock on the attach button (files can queue), and leaves description autosave ungated by design. Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>	2026-07-16 09:56:24 +08:00
Jiayuan Zhang	0ec7c22901	fix(issues): render create picker trigger content (#5491)	2026-07-16 08:42:00 +08:00
Jiayuan Zhang	ea8511340e	MUL-4820: support custom property icons (#5468) ... * feat(properties): add custom icons Co-authored-by: multica-agent <github@multica.ai> * fix(migrations): use unique property icon prefix Co-authored-by: multica-agent <github@multica.ai> * fix(properties): replace emoji icons with Lucide picker Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-15 22:37:57 +08:00
Naiyuan Qing	ea03912baf	perf(desktop,issues): single-router tab sessions (MUL-4741 Phase 2) + trace-driven surface mount/render overhaul (MUL-4474/4750 reland) (#5403) ... * Reapply "perf(issues): virtualize inbox/list/board/swimlane (MUL-4474, 方案2) (#…" (#5395) This reverts commit c10bfa8f56. Co-authored-by: multica-agent <github@multica.ai> * fix(issues): seed virtualized lists so route-return doesn't flash blank (MUL-4750) The relanded MUL-4474 virtualization flashed an empty card area (group / column headers present, rows blank) when returning to /issues or crossing inbox<->issues. Two stacked blank windows caused it: 1. The scroll element reaches Virtuoso via a callback ref that lands in state, so the first render after a remount has customScrollParent === null and the code rendered nothing. 2. Even once mounted, Virtuoso renders 0 rows until its post-paint ResizeObserver measures the viewport. Fix both, four surfaces (list / board / swimlane / inbox): - New shared <VirtuosoSeed> renders a bounded slice of the real rows while the scroll parent is still null, reusing each caller's own itemContent / computeItemKey so a seeded row is identical to its virtualized counterpart. - Pass initialItemCount={Math.min(len, SEED)} so the measurement frame keeps those rows instead of collapsing to empty. SEED is capped at 30 and floored by Math.min, so small workspaces (hasMore=false) and short columns never over-mount — the path that crashed on real Desktop before. restoreStateFrom (tab-switch Activity restore) is intentionally out of scope for this round. Verified: @multica/views tsc --noEmit, eslint, and full vitest (1936 tests) pass. Real-Desktop route-return / DnD / keyboard / scroll-position regression pass still owed on device. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> * perf(issues): defer per-card popup mounting, share one context menu per surface Tab-switching to a board froze the main thread for seconds: every card eagerly mounted ~6 popup roots (context menu, pickers, hover cards) plus per-card query subscriptions, multiplied by seed x columns x remount. - DeferredPopup: pickers render a pixel-identical static trigger and mount the real popover on first pointerenter/keydown (Base UI opens on click, so the warm mount always wins the race) - AssigneePicker/PriorityPicker/DateOnlyPicker defer when uncontrolled; AssigneePicker's members/agents/squads/frequency subscriptions now only start on interaction - IssueActionsContextMenu: one controlled ContextMenu per surface anchored at the cursor via a virtual anchor; items delegate (issue, position) up. Known debt: iOS Safari long-press no longer opens it - ActorAvatar hover cards warm-mount on pointerenter with a manual first-dwell timer matching Base UI's OPEN_DELAY Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(issues): stabilize board column scrollbar across mounts Column scrollbars redrew visibly on every surface mount (route switches, first open): the seed frame's scroll height covered only the seeded cards, then Virtuoso spaced out the full count. - VirtuosoSeed: optional estimatedItemHeight renders a trailing spacer so the seed frame's scroll height already approximates the full list - Board columns: seed capped at 10 (one column viewport of ~110px cards, not the 36px-row-sized generic 30) and the same estimate feeds Virtuoso's defaultItemHeight so both phases agree until real measurements land - Columns at <=30 cards skip virtualization entirely and render plainly (same itemContent), making their scroll height browser-measured truth in every scenario -- the per-column split Linear ships (data-virtual-cluster=false for small clusters) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * perf(editor): reduce issue detail mount cost Parse long Markdown in smaller chunks without the duplicate initial sync, defer title and empty composer editors until intent, and keep the description editor eager to avoid layout shifts. * chore(desktop): add navigation boundary lint rule (MUL-4741 Phase 2 prereq) The tab Coordinator protocol requires that application code never navigates directly (invariant 1: a Router location change without a Coordinator token is a protocol error). Enforce it statically: - renderer app code may not import useNavigate/Navigate from react-router-dom nor call router.navigate; src/platform is exempt - the five known legacy sites (the RFC §8.1 migration checklist, cross-validated: the rule fires on exactly those and nothing else) carry inline eslint-disable directives tagged MUL-4741 — the Phase 2 migration removes them one by one, and this rule holding with zero disables is the machine check that the migration is complete Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(views): open deferred pickers on click, align triggerRender types Pointerenter warm-mounting swapped the trigger element mid-gesture: real browsers re-hit-test so the click lands on the new trigger, but synthetic pointer sequences (tests, assistive tech) keep dispatching on the detached node and the first click dies. Upgrade now happens on click/Enter/Space only — the same timing as Base UI's own trigger — with the in-flight click stopped so the popup's just-mounted outside-press dismissal doesn't close it in the same breath. Also widen triggerRender to ReactElement<Record<string, unknown>> (React 19 defaults ReactElement props to unknown) and mount the IssueContextMenuProvider in the swimlane test harness like IssueSurface does in production. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * refactor(desktop): single-router tab sessions with Coordinator protocol (MUL-4741 Phase 2) Replace the per-tab-router + <Activity> keep-alive model with the approved single-router session architecture: - TabSession: tabs are pure serializable state (url, resourceKey, virtual history stack, scroll memento). Persist v4 does the one-time legacy view-state import from v3; mountGeneration is deliberately unpersisted. - Coordinator (platform/tab-coordinator.ts) is the only router writer: it reconciles THE app router to the active session URL with navigation tokens; a location change without a token is a protocol error handled by bounded recovery (invariant 1). The router history is never used — every reconcile is a replace; back/forward are session-stack operations. - ActiveTabHost mounts exactly one tab, keyed on tabId:mountGeneration. reload() = generation bump + active-scope query invalidation (never router.revalidate, never a global cache invalidation). Warm switches restore scroll pre-paint; cold restores pre-size containers from the memento's saved scrollHeight and settle when data lands. - resourceKey dedup (pathname only) replaces exact-path dedup: opening /slug/issues?filter=b focuses the existing issues tab (RFC §8.2, deliberate semantic change). - All five §8.1 legacy navigation sites migrated (index <Navigate>, error page recovery, workspace-layout login bounce, overlay parking, shell back/forward); their MUL-4741 ratchet eslint-disables are removed, so the navigation boundary rule now holds with zero exemptions outside src/platform. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(issues): register board columns and list scroller for scroll mementos Per-container scroll registration for the MUL-4741 tab session memento: board columns key by group id (each column's offset restores independently, the per-column split Linear ships), the list view keys as "list". Chat and issue-detail already carry the marker. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * feat(tabs): pull-based scroll restoration fed into virtualized lists (MUL-4741) Rebuild the restore side of the memento protocol on first principles (the model Linear ships): a saved offset is an INPUT to the mounting view, not a post-hoc DOM mutation from outside. - ScrollRestorationProvider (views/platform): views pull their saved offset while mounting. Virtualized lists feed it into Virtuoso's initialScrollTop so the first render already materializes the rows around it — this replaces the pushed spacer+scrollTop hook, whose foreign spacer deadlocked against Virtuoso's own height model (restore landed the viewport in phantom space, Virtuoso rendered nothing, and the spacer's removal condition could never be met → blank issue detail). Plain containers assign the offset at ref-attach, pre-paint. Web has no provider and behaves as before. - Memento keys gain a route dimension (`${pathname}::${containerKey}`) and capture now also fires before in-tab navigation, so back/forward restores each route's own offsets and same-named containers on different routes no longer collide. - commitScrollMemento uses REPLACE-per-route semantics: a container scrolled back to 0 clears its stale offset instead of resurrecting the old position on the next visit. - List view gets the same estimate alignment as the board (36px rows into the seed spacer and defaultItemHeight), which keeps the shared scroller's height truthful from the first frame so the restored offset sticks. Known gap: chat's bottom-anchored list captures offsets but has no restore consumer — intentional, it re-anchors to bottom on mount. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * perf(editor): make unlabelled code fences plaintext instead of auto-detected Follow-up to the issue-detail mount work: lowlight's highlightAuto runs every registered grammar over the full block for code fences without a language, which dominated mount cost on code-heavy comments. Extract a shared syntax-highlight module whose auto fallback deterministically renders plaintext; explicitly labelled languages highlight as before. Also ignore .gstack/. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * perf(issues): lazy-mount column-header popups, right-size swimlane seed Trace analysis of tab/view switching (30s session): a swimlane mount spent its largest slice on eagerly-mounted header machinery — ~170 tooltip roots (one per lane x status cell add-button), 13 column dropdown-menus, and up to 30 fully-materialized lanes from the generic seed count. - DeferredTooltip (views/common): renders only the trigger until first hover, then mounts a controlled Tooltip anchored to the SAME element (no trigger swap, so mid-gesture events never land on a detached node); ui TooltipContent grows an `anchor` passthrough for it. - Board/list/swimlane header add-buttons and hide-column dropdowns now defer via DeferredTooltip / DeferredPopup (which gains an ariaHasPopup option for menu triggers). - Swimlane lane seed drops 30 -> 6 (a lane row is ~300px+; a viewport fits ~3) on both the pre-scroll seed and Virtuoso's initialItemCount. - openTab gains an `activate` option so "open and focus" paths (pinned-tab redirect, explicit open-in-new-tab) are ONE store write instead of openTab + setActiveTab back-to-back — one full subscriber pass per user action instead of two. - Dev-only breadcrumb logs IssueSurfaceContent's remount key: the trace showed the surface mounting twice inside one task, and the my-issues relation toggle is one confirmed key-flip source; the log ties the next trace's mounts to exact key transitions. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * perf(issues): stop double full-tree render passes on surface interactions Trace forensics on view switching showed every interaction paying TWO full surface render passes (React's own Cascading Update marker sits between them): entering swimlane flips controller-level loading state (loadProjects enables the projects query), and any such flag flip re-rendered the entire unmemoized view tree (~600-1000ms dev per pass). - Memoize BoardView / ListView / SwimLaneView: controller/data outputs are already useMemo/useCallback-stable, so a controller flag flip now re-renders the header, not the whole board. The one unstable prop — BoardView's inline assigneeGroups.flatMap — moves into a useMemo. - Selection reset on mount swapped the initial empty Set for a NEW empty Set, buying a guaranteed extra full pass per surface mount; functional bail keeps the reference when nothing was selected. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * perf(ui): drive sidebar resize by direct DOM writes, drop motion/react Trace analysis showed sidebar motion.div mounts costing ~1s across a session. Width previews during drag now write straight to the two layout shells (CSS disables their transitions while data-sidebar-resizing is set); React only sees the single committed width on pointer-up, and framer-motion leaves the sidebar entirely. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> * fix(issues): wire swimlane's outer scroller into tab scroll restoration Review blocker on #5403: board/list/issue-detail register their scroll containers with the tab session memento protocol, but the swimlane outer scroller did not — under the single-router architecture an inactive tab unmounts, so a deep-scrolled swimlane returned at top after a tab switch or reload. Same wiring as the other surfaces: data-tab-scroll-root="swimlane" for capture, useRestoredScrollRef in the scroller's attach callback for the pre-paint assignment, and the saved offset into the lane Virtuoso's initialScrollTop. Regression test asserts both the capture marker and the restored offset. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> --------- Co-authored-by: multica-agent <github@multica.ai> Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>	2026-07-15 16:30:51 +08:00
Jiayuan Zhang	50e28d539c	feat(settings): open issue links in new tab by default, configurable in preferences (#5445) ... Issue mention chips in descriptions (tiptap), comments (readonly markdown), and chat now open the linked issue in a new tab on plain click — a browser tab on web, a foreground app tab on desktop. A new Settings → Preferences switch (default on) restores in-place navigation when turned off; the preference persists via a zustand store. AppLink now honors target="_blank": desktop delegates to the navigation adapter's openInNewTab with activate, web leaves the native anchor behavior intact. This also fixes dead cmd/ctrl-click on web for comment and editor mentions, which previously preventDefault'd without an adapter fallback. MUL-4793 Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-15 14:33:00 +08:00
Jiayuan Zhang	b85bb71a58	feat: custom issue properties — typed workspace-defined fields with list-surface support (MUL-4463) (#5335) ... * feat(server): custom issue properties — definitions, typed values, CLI (MUL-4463) Workspace-level property definitions (issue_property table; 7 types: text/number/select/multi_select/date/checkbox/url) plus a typed value bag on each issue (issue.properties JSONB keyed by definition UUID, mirroring the metadata machinery: single-key atomic writes, 16KB cap, GIN index). - Definitions: owner/admin only; agent actors rejected (agents propose, humans confirm). 20 active per workspace, 50 options per select, reserved built-in names blocked, archive instead of delete. - Values: any member or agent; per-type validation with self-correcting error messages that enumerate legal option ids. - API: /api/properties CRUD + PUT/DELETE /api/issues/{id}/properties/{propertyId}; issue responses always emit the properties bag. - CLI: multica property list/get/create/update/archive/unarchive and multica issue property list/set/unset with name→id translation. - Events: property:created/updated, issue_properties:changed. Co-authored-by: multica-agent <github@multica.ai> * feat(web): custom properties settings tab + issue sidebar editors (MUL-4463) - Settings → Properties: definition management mirroring the Labels tab (list with type badges/option chips/usage counts, create/edit dialog with option editor, archive/restore, 20-cap indicator). Admin-gated; members see a read-only catalog. - Issue detail sidebar: custom properties join the built-in optional props' progressive disclosure — set values render as rows with type-appropriate editors (select/multi-select pickers, calendar, yes/no, inline input for text/number/url), unset ones live in the same '+ Add property' menu behind a separator. Archived definitions render read-only until cleared. - Core: property types, zod schemas (lenient type strings for forward compat), api client methods, React Query hooks with optimistic single-key value writes, ws-updaters + realtime wiring for property:created/updated and issue_properties:changed. - Locales: en/zh-Hans/ja/ko strings; Issue fixtures gain properties: {}. Co-authored-by: multica-agent <github@multica.ai> * fix(properties): address MUL-4463 review round 1 — mobile CI, option guard, mutation safety, schema tolerance - mobile: EMPTY_ISSUE_FALLBACK gains the required properties field (mobile typecheck was the red CI check). - server: PATCH /api/properties/{id} rejects config updates that remove select options still referenced by issues (409 with a per-option usage census via jsonb ?); renames keep ids and pass. Integration test included. - core: property value mutations are serialized per workspace via mutation scope, snapshot the bag from detail OR list caches (board surfaces have no detail cache — the old path overwrote whole bags with one key), roll back to the snapshot or invalidate on error, and the last settled mutation does an authoritative detail+catalog invalidate (usage counts reconcile). - schemas: unknown-shaped property values (future server types) are dropped per-entry in a preprocess step instead of failing the whole IssueSchema and blanking lists through parseWithFallback; test updated to lock the tolerant behavior. - realtime: reconnect invalidation covers the property catalog; every issue_properties:changed event also refreshes catalog usage counts. - ui: number editor accepts decimals (step=any); settings usage count pluralizes (issue/issues) with CJK-safe plural keys. Co-authored-by: multica-agent <github@multica.ai> * fix(migrations): renumber issue properties to 179 and build the GIN index concurrently main's migration sequence advanced twice under this PR (167 collision, then an upstream renumber wave that claimed 178), so issue properties now sits at 179 — verified against main's current tip by the prefix-uniqueness lint. The properties GIN index moves to its own single-statement migration (180) using CREATE INDEX CONCURRENTLY — a plain CREATE INDEX on the hot issue table would block writes for the duration of the build. Mirrors the 119_user_created_at_index pattern; full-chain dry-run on a fresh database passes through 180. Co-authored-by: multica-agent <github@multica.ai> * feat(web): custom-property list surfaces — filter, cards, sort, board grouping (MUL-4463 M2) Brings custom properties to the issue list surfaces on top of the M1 definitions/values core: - Filter: per-definition sections in the Filter dropdown (select / multi_select options with color dots and counts; checkbox as Yes/No pseudo-options). OR within a definition, AND across definitions; client-side in applyIssueFilters, mirrored into filterAssigneeGroups for the assignee-grouped board. Included in active-filter count and Clear all. - Cards: per-property Display toggles (cardPropertyIds) render value chips on board cards and list rows via CustomPropertyValueDisplay. - Sort: SortField gains property:<id> for number/date definitions. Server keeps position order (fixed sort enum); the surface controller re-sorts client-side, swimlane/gantt reuse the same comparator. Date-only strings compare lexically; missing values sort last. - Board grouping: IssueGrouping gains property:<id> for select definitions — one column per option (definition order) plus a trailing No-value column, option-colored headings. Drag-drop moves position via UpdateIssue and applies the value through useSetIssueProperty/useUnsetIssueProperty (properties are not part of UpdateIssueRequest). Stale persisted property groupings fall back to status columns. View-store: propertyFilters + cardPropertyIds persisted via the partialize allowlist; clearFilters resets property filters; new fields deep-merge cleanly into pre-existing persisted snapshots. Co-authored-by: multica-agent <github@multica.ai> * fix(properties): address MUL-4463 review round 2 — desc sort, option bucketing, archived-state reconciliation - sort: direction now applies to value comparison only; issues without a value sort last in BOTH directions (the whole-array reverse flipped them to the front on desc). Test covers the desc+missing case. - board: values referencing an option removed from the definition bucket into the No-value column instead of vanishing (unmatched column ids dropped the issue entirely). Defense-in-depth behind the new server-side in-use guard; drag-utils test locks both behaviors. - controller: persisted propertyFilters keyed by archived/deleted definitions are stripped before reaching the filter predicates, and a persisted property sort on a non-active definition degrades to manual order — previously both kept silently applying while the header claimed otherwise. The filter badge counts only active-definition filters. Co-authored-by: multica-agent <github@multica.ai> * feat(properties): server-side property filtering and sorting on list endpoints Property filter/sort now execute in the database, so results are correct across the full issue set — not just the loaded 50-per-status window (closes MUL-4493 item 1's filter/sort half; requested on MUL-4463). - New `properties` query param on ListIssues and ListGroupedIssues: JSON {definitionId: [values]} compiled to an AND-of-ORs containment check (double NOT EXISTS over jsonb_array_elements). One value expands to every storage shape it could match — string (select), array element (multi_select), boolean (checkbox) — so the handler stays type-agnostic. Guarded at 20 definitions / 50 values. - `sort=property:<definitionId>` resolves the definition and orders by a typed expression (numeric CASE cast for number, NULLIF text for date/text/url); missing values sort last in both directions. Malformed ids 400; unknown/archived definitions degrade to position order instead of breaking stale clients. - Frontend: the property filter and property sort ride the IssueSortParam window bag, so every surface (workspace + my-issues variants), query key, and per-status load-more page carries them automatically. The client-side re-sort layer is gone; applyIssueFilters keeps its property predicate as an optimistic-update backstop. - Regression test seeds 55 issues and proves a match at position 55 is returned by a filtered 50-row page, plus sort order/missing-last, AND-across-definitions, and the 400/fallback sort paths. Co-authored-by: multica-agent <github@multica.ai> * fix(properties): address review round 3 — cache reconcile, merged-scope order, GIN-indexable filter, pool loader - Cache reconciliation: property value writes (mutation settle + WS event) now invalidate every issue window whose server-side shape depends on property values — queries filtered by `properties` or sorted by `property:<id>` (detected via query-key predicate), covering flat lists, assignee groups, and my-issues variants. Windows without property params keep the cheap in-place patch. Fixes stale ordering/membership/counts under staleTime:Infinity. - My Issues "All" scope: merged assigned/created/involves results are re-sorted with a comparator mirroring the server ORDER BY semantics (including property sorts and missing-last, created_at DESC tiebreak) in both the flat and assignee-grouped merge paths — relation concatenation no longer overrides the user's sort. - Filter predicate rebuilt as plain bind-parameter containment ORs (AND across definitions): EXPLAIN now shows BitmapOr over idx_issue_properties_gin (the correlated jsonb_array_elements form defeated the index). Alternatives capped at 256 bind params. - Property-grouped board gains a pool loader strip: one sentinel per status that still has server rows, keeping every issue reachable until per-column pagination lands (MUL-4493). - Windowing regression test hardened: explicit positions + an assertion that the unfiltered first page excludes the target (the old fixture tied at position 0 and the created_at DESC tiebreak put the target on page one, proving nothing). - Rollback safety: /api/properties 404 (old server) degrades to an empty catalog instead of a query error, which also keeps property params from ever being sent to pre-property servers; migration 179's CHECK constraints switch to NOT VALID + VALIDATE so the exclusive lock is instantaneous. Co-authored-by: multica-agent <github@multica.ai> * fix(properties): harden concurrency and cache coordination from clean-room review Backend (MUL-4762 F1/F4/F5): - withPropertyLock: pg_advisory_xact_lock helper; definition create/update and value writes now serialize config-vs-value and cap-vs-insert races (workspace-level 'props:' lock + per-definition 'prop:' lock, ordered). - propertySortExpr degrades archived definitions to position sort. Frontend (F2/F3/F6): - onIssuePropertiesChanged invalidates plain assignee-group caches too. - Property value mutations cancel list refetches in onMutate and roll back only the touched key against the current bag (concurrent WS writes to other keys survive a failed write). - useUpdateIssue reconcile drops the stale properties bag from the server snapshot; the property pipeline owns that field. - Surface controller passes persisted property filters/sorts through until the catalog query settles (cold cache no longer strips them). Co-authored-by: multica-agent <github@multica.ai> * fix(properties): open_only branch honors the properties filter ListOpenIssues takes the parsed AND-of-ORs containment groups as a single jsonb properties_filter param and unrolls them with a static double NOT EXISTS; previously the open_only path parsed the properties param and silently dropped it (clean-room review F7a). Co-authored-by: multica-agent <github@multica.ai> * fix(properties): toast on failed board drag to a property column Property-column drags rolled the card back silently on failure; mirror the status/assignee drag path (use-issue-surface-actions) so the snap-back is explained (clean-room review F3, drag half). Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-15 12:00:28 +08:00
Jiayuan Zhang	8f92b5fdeb	feat(search): add fold/unfold all comments commands to the command palette (#5417) ... On an issue page, Cmd+K now offers Fold All Comments / Unfold All Comments. Folding collapses every thread card via the persisted comment-collapse store; unfolding also expands resolved threads, whose session-only expand state moves from issue-detail useState into a new core resolved-expand store so the palette can drive it (MUL-4763). Co-authored-by: Lambda <lambda@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-15 11:21:54 +08:00
Bohan Jiang	5999eabd92	fix(views): stop showing backfilled attribution as a warning (MUL-4768) (#5421) ... * fix(views): stop showing backfilled attribution as a warning (MUL-4768) The transcript/activity AttributionBadge colored the "on behalf of <name>" chip yellow (text-warning) whenever attribution.precise === false. That flag is the backend's attribution-*coverage* health bit — owner_fallback, backfill, and unattributed all fail it — but coverage is an ops metric, not a reader-facing signal. A backfilled attribution names a human the same waterfall resolved, just retroactively, so it is confident; rendering it identically to a genuine owner_fallback guess made a correct "on behalf of Bohan" read like an error. Fire the cautionary tone only for a fallback guess (any non-precise source except backfill). Keeping the precise === false base means a future unknown degraded source still warns (fail-safe). The backfill nuance stays in the tooltip. Co-authored-by: multica-agent <github@multica.ai> * docs(views): correct backfill wording in AttributionBadge (nit MUL-4768) Review nit: describing backfill as "confident / same waterfall resolved" overstated the backend contract, which defines backfill as a historical, non-realtime, non-compliance-grade source. Reword the docblock, the tone rationale, and the test note to the accurate framing: backfill does not mean the displayed name is wrong (so no warning tone), but its historical origin is still preserved in the tooltip and the raw source field. Comments only; no behavior change. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: J <j@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-15 04:09:19 +08:00
Bohan Jiang	09f69dfa05	refactor(attribution): drop on-behalf badge from execution log rows (MUL-4766) (#5419) ... The "on behalf of <member>" attribution chip on each execution-log row added visual noise to the dense run list. Remove it from both the active and past run rows and restore the original layout. The attribution stays discoverable where it belongs: the task transcript header and the agent detail page's recent-work list still render AttributionBadge. Co-authored-by: J <j@multica.ai> Co-authored-by: multica-agent <github@multica.ai>	2026-07-15 03:26:10 +08:00