mirror of
https://github.com/multica-ai/multica.git
synced 2026-06-17 03:38:32 +02:00
v0.2.16
636 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Naiyuan Qing
|
f7fe0829f2 |
refactor(skills): wrap list as card, use shared PageHeader, add scroll fade (#1614)
The skills page rolled its own HeroHeader instead of the shared PageHeader, which meant no mobile sidebar trigger and visual drift from other list pages. The table was also edge-to-edge inside the dashboard container, so it felt "naked" compared to the rest of the product. - Replace custom HeroHeader with shared PageHeader (gives mobile hamburger and h-12 chrome for free); move "New skill" into the PageHeader as the page-level action. - Keep search + scope filters in a toolbar, but move that toolbar *inside* a bordered, rounded card together with the table, so the whole unit reads as a single scrollable surface with internal padding. - Use the existing useScrollFade hook on the row list so the top/bottom edges fade while scrolling. - Drop `divide-y` in favor of `border-b` per row — divide-y leaves the last row without a bottom rule, which looks unfinished when only a couple of skills exist and the scroll area is taller than the content. - Drop the redundant description paragraph from the old hero; keep the "Shared with your workspace" banner above the card since it carries non-obvious UX context. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
c7e725ef66 |
feat: surface docs from onboarding + landing, unify Autopilot naming (#1613)
* docs(autopilot): rename Routines → Autopilots to match product UI
Unify naming between docs and product. Sidebar label, URL route,
CLI command, and onboarding copy all call this feature "Autopilot";
the docs were the only surface that diverged. Aligning the docs to
the product (rather than the reverse) because the 830+ code-side
references would be a much larger rename to propagate.
- Rename routines.mdx / routines.zh.mdx → autopilots.mdx / autopilots.zh.mdx
- Update meta.json / meta.zh.json index entries (routines → autopilots)
- Drop the reconciliation note ("docs say Routines, CLI says autopilot")
that shipped in the original routines.mdx and the cli.mdx section header
- Update cross-references in cli, how-multica-works, tasks,
assigning-issues, chat, mentioning-agents, daemon-runtimes (EN + ZH)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* feat(onboarding): link to docs from key steps and starter tasks
Users who want to dig deeper now have a next hop from inside the flow
instead of having to dig through the help menu. Placed as secondary
links (muted, underline-offset-4) so they don't pull focus from the
primary CTA on each step.
Placement — one link per surface, placed in secondary regions:
- Welcome: "Learn how Multica works" below the subhead
- Questionnaire: "Learn how agents work" in the Why-we-ask aside
- Runtime aside (shared by desktop + web): "Learn about runtimes"
- Agent step: "Creating your first agent" in the About-agents aside
- StarterContentPrompt dialog: "Learn how Multica works"
Starter tasks (content/starter-content-templates.ts): added a single
"Learn about X" tail link per task, only on first occurrence of each
concept within a branch. 8 links on the agent-guided branch + 8 on
the self-serve branch + 1 on the welcome issue header (17 total).
URL scheme: absolute https://multica.ai/docs/{slug} throughout —
absolute so desktop (Electron) opens them in the system browser, and
the /en prefix is omitted because the docs middleware redirects it
away (English is the default, Chinese is /zh/).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* feat(landing): add docs link to footer and how-it-works section
Docs were previously reachable only from the in-app help menu. Landing
now surfaces them in two places, both locale-aware (/docs for English,
/docs/zh for Chinese):
- Footer Resources group: Documentation link was pointing at the
GitHub repo; replaced with the real docs URL
- How-It-Works section CTA row: added "Read the docs" between the
primary CTA and the GitHub link, same ghost styling
Locale resolution: href is picked per-render based on the landing's
current locale (cookie-driven via useLocale). The docs app itself
does not auto-detect language, so we must pick the right path
explicitly when emitting the link.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(onboarding): clean up Autopilot rename leftovers and link formatting
- comments.mdx: "not routine updates" → "not day-to-day updates"
(adjectival holdover now that the feature is renamed Autopilot;
zeroes out remaining "routine" mentions in user-facing docs)
- starter-content-templates.ts: move the arrow inside the markdown
link — "[text →](url)" instead of "→ [text](url)" — so the arrow
is part of the clickable region. 17 occurrences.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* fix(onboarding): drop docs link from welcome screen and starter-content dialog
"Learn how Multica works" was showing up too often in the first two
screens users see. Keep the link in the post-import welcome issue
header (where users actually have time to explore); remove it from
the two earlier surfaces where it competes with the primary CTA.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
Naiyuan Qing
|
fe84e29b64 |
fix(ui): stop menu hover from overriding icon colors (#1612)
Menu primitives (context/dropdown/menubar/select/command) had rules like `focus:**:text-accent-foreground` and `*:[svg]:text-destructive` that forced descendant svg colors on focus, overriding icons that set their own color (e.g. StatusIcon's `text-warning`). Remove them so icon color comes from inheritance only: colored icons keep their color on hover, uncolored icons still inherit the item's focus/destructive color as before. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
4f40f70ea7 |
fix(skills): remove double-flicker on CreateSkillDialog close (#1610)
CreateSkillDialog used a controlled \`open\` prop while staying mounted, so closing meant a data-open → data-closed flip on the already-mounted Popup plus a tail re-render from \`useEffect([open])\` resetting \`method\`. Visible as a double-blink: first the close animation, then a second fade when the reset effect fired. Align with the CreateIssue / CreateProject pattern: parent conditionally renders the dialog and \`<Dialog open>\` is hard-coded. Close now unmounts the component and Base UI's Portal owns the single exit animation. The per-open method reset becomes unnecessary — fresh mount, fresh state. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
7067d8f125 |
refactor(skills): redesign list page and add skill detail page (#1607)
* feat(core): add skill detail path and query helpers - paths.workspace(slug).skillDetail(id) → /:slug/skills/:id - skillDetailOptions(wsId, skillId) for fetching a single skill - selectSkillAssignments(agents) folds the cached agent list into Map<skillId, Agent[]>; returns a stable reference so consumers can memoize against agent-array identity without re-rendering on unrelated agent updates Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(views): add cross-platform openExternal helper On Electron, route through window.desktopAPI.openExternal so the http/https-only guard in the main process kicks in — direct window.open inside Electron opens a new renderer window instead of handing the URL to the OS shell. On web, fall back to window.open with noopener+noreferrer. SSR-safe. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(skills): extract edit-permission hook and origin helper - use-can-edit-skill: mirrors the server's rule (admin/owner ∨ creator) so the UI can hide/disable actions instead of waiting for a 403. Takes wsId explicitly per the repo rule for workspace-aware hooks. - lib/origin: discriminated view over Skill.config.origin (manual / runtime_local / clawhub / skills_sh) so consumers don't spread JSONB parsing across the UI tree. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(skills): rewrite skills list page and collapse import UI - SkillsPage rewritten: new hero header, single table layout with columns (Name / Used by / Source · Added by / Updated), agent avatar stack per skill, filter tabs aligned with Issues/MyIssues header (Button variant=outline + Tooltip + bg-accent active state). - CreateSkillDialog: dedicated dialog for the manual/import entry points, replaces the inline row-triggered dialog. - runtime-local import: dialog variant deleted; panel is now the single entry point, embeddable inside CreateSkillDialog. Panel covered by a new test. - Deleted runtime-local-skill-row (no longer needed — row rendering lives in SkillsPage directly) and the old skills-page.test.tsx (structure diverged beyond salvaging; will be re-added alongside the detail-page tests). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(skills): add skill detail page and wire routes on web and desktop - SkillDetailPage: dedicated view for a single skill (name, description, origin, assignments, file listing). Uses skillDetailOptions and the new origin / use-can-edit-skill helpers. - apps/web: /:workspaceSlug/skills/:id Next.js route. - apps/desktop: /:slug/skills/:id added to the memory router under WorkspaceRouteLayout. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(skills): bump runtime-local-skill-import-panel timeouts for CI The test chains a five-step async cascade (runtime list → setSelectedRuntimeId effect → skills query → auto-select effect → row render). Comfortable on local (~600ms) but tight against RTL's 1 s default on CI where jsdom + Vitest import takes ~100s. Bump findByText and the two waitFor calls to 5 s each — no production behaviour change. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
devv-eve
|
9ed1fa95fc |
feat(server): add readiness health endpoints (#1605)
* feat(server): add readiness health endpoints * fix(server): cache readiness checks * fix(server): raise readiness cache ttl --------- Co-authored-by: Eve <eve@multica.ai> |
||
|
Naiyuan Qing
|
147fb2ee66 |
fix(autopilot): confirm before deleting autopilot or trigger (#1604)
Destructive actions in the autopilot detail page fired immediately on click. Wrap "Delete autopilot" and per-trigger delete with AlertDialog confirmation, matching the existing issue-delete pattern. Also fix a latent bug in trigger deletion where the success toast was shown synchronously after mutate(), so failures still reported success — switch to mutateAsync + try/catch. |
||
|
Naiyuan Qing
|
5bab95ad26 |
fix(issues): unify board card hover and active visual (#1603)
Hover and popup-open states now share the same bg-accent + border-accent treatment. Drop the shadow-md hover (invisible in dark mode) and the multi-property transition in favor of a single transition-colors. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
0bd6ba9354 |
fix(issues): cleaner board card hover with shadow elevation (#1600)
Replace translucent tinted hover (border-accent/50 + bg-accent/20) with a single-dimension shadow lift. The previous overlay was visually weak because --accent is nearly identical to --card, so a 20% tint rendered as almost no change. Active (popup-open) state now uses solid bg-accent so hover and active are distinguished by different dimensions — elevation vs color — instead of competing on the same axis. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
40cea8454d |
feat(autopilot): redesign modal — simpler schema, consistent schedule UI (#1595)
Drop priority and project_id from autopilot. project_id was never exposed in the UI and priority duplicated the agent's own task queue priority. Redesign the create/edit modal as a Runbook (left) + Configuration (right) layout. Rework the Schedule section around a single visual shell so every picker aligns pixel-for-pixel on the same row: - TimeInput (new): segmented HH:MM control adapted from openstatusHQ/time-picker, driven by keyboard (ArrowUp/Down to step, ArrowLeft/Right to jump segment, digit typing with a 2s two-digit window). Replaces <input type="time">, whose native UI broke the design system. Supports a minuteOnly variant for hourly schedules. - TimezonePicker (new): searchable Popover with a fixed-width left check slot so rows stay aligned and GMT offsets never collide with the selected indicator. - Runbook editor now lives in a bordered card, giving the placeholder an input surface instead of bare document flow. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
d54daa62c5 |
feat(issues): right-click context menu + unified issue actions (#1594)
* feat(issues): add right-click context menu on list rows and board cards Extract the detail page's ⋯ dropdown (~180 lines of inline JSX) into a shared `useIssueActions` hook plus two thin wrappers so the same action set (status / priority / assignee / due date / sub-issue ops / pin / copy link / delete) can be mounted as both a DropdownMenu and a Base UI ContextMenu. Right-click on any list row or board card now opens the full action menu without entering the detail page. Shell-level modals replace the detail-page-local state for set-parent / add-child / delete-confirm / backlog-agent-hint, so any trigger (detail page, list, board) can open them through `useModalStore`. Detail page detects its own deletion via a query-transition effect, avoiding the need to smuggle callbacks through the store. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(issues): hover and active styling on list rows and board cards Mirror the sidebar's same-color/different-intensity pattern for the new right-click context menu states. Base UI adds `data-popup-open` to the ContextMenuTrigger when the menu is open; `hover:not-data-[popup-open]` suppresses hover feedback on the already-active item. List rows apply the pattern directly to background color (`accent/60` hover, `accent` active). Board cards additionally modulate the card's border and a lighter background tint (`accent/20` hover, `accent/40` active) so the card's own bg/border/shadow identity stays intact. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(modals): show target issue banner in SetParent/AddChild pickers When triggered from an issue's action menu, the IssuePickerModal now displays a banner at the top showing "Setting parent of" / "Adding sub-issue to" followed by the originating issue's status, identifier, and title. Previously the operation target was only implied by the modal's sr-only title. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(modals): create-issue gains ⋯ overflow menu with parent issue linkage Add a dropdown-menu with "Set parent issue..." / "Remove parent" at the end of the property pill row. The ⋯ button is always the last DOM child of the row so it stays at the tail even when the row wraps to multiple lines. Menu state reflects current selection — unset shows a single "Set parent…" entry, set shows the current identifier plus a separate Remove option. When a parent is set (either via the new menu or via `data.parent_issue_id` from a "Create sub-issue" trigger), a chip appears in the pill row showing "Sub-issue of {identifier}" with the same click-to-change / click-×-to-clear semantics. This replaces the old header breadcrumb disclosure that was neither editable nor visible in the form. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(issues): group relationship actions under "More" submenu Nest Create sub-issue / Set parent issue / Add sub-issue inside a `More >` submenu in the issue actions menu (both Dropdown and Context variants). Top-level keeps Status/Priority/Assignee/Due date category submenus plus Pin and Copy link; the relationship ops are lower-frequency and will grow with future relation types (blocks, duplicates, related) that fit the same category. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(modals): create-issue adds Add sub-issue with deferred linking The create modal's ⋯ menu gains an "Add sub-issue..." entry that queues existing issues as children of the new one. Picked issues appear as chips in the pill row (downward arrow, distinct from the upward parent chip), each individually removable. Linking is deferred because the new issue's ID doesn't exist at pick time. Once createIssueMutation resolves, we run updateIssueMutation for every queued child in parallel and surface any partial failures via toast — the new issue itself is already committed and never rolls back. Parent and child pickers exclude each other so a single issue can't occupy both relations simultaneously. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * polish(issues): add MoreHorizontal icon to "More" submenu trigger The "More" label was visually misaligned because every other top-level entry has a leading icon. Use MoreHorizontal (same icon as the outer ⋯ trigger — semantically "more options, nested") and drop the `inset` padding hack. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * revert(modals): drop target-issue banner from IssuePickerModal The banner sat directly above the search input and rendered the target issue with bolder styling than the "Setting parent of" / "Adding sub-issue to" caption, which made it read like a pre-selected search result rather than a context label. Users opening the modal from a menu item already carry the context, so the extra chrome was redundant. Remove the contextIssue / contextLabel API from IssuePickerModal and drop the now-unused issueDetailOptions query in SetParentIssueModal. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * polish(modals): exclude current parent from create-issue parent picker Re-opening the parent picker to change the already-set parent used to show that parent in the results — picking it was a silent no-op. Mirror the child picker's exclude-list construction so the current parent is always filtered out. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Jiayuan Zhang
|
71cc646951 |
fix(chat): prevent UI flicker when streaming response finalizes (#1583)
The live timeline was rendered in a separate <div> from the persisted messages list. When the streamed task finished and its ChatMessage landed, the live <div> unmounted and a new <MessageBubble> mounted — two different DOM elements showing the same content. useAutoScroll's ResizeObserver + MutationObserver fired on both the unmount and the mount, causing the visible jump-then-re-render. Merge the two paths: inject a synthetic assistant message with the pending task_id while streaming, and key every assistant bubble by task_id. When the real message arrives (same task_id), React preserves the DOM element across the invalidate → refetch window — no remount, no double scroll, no flicker. Co-authored-by: Lambda <f252c2c5-7d1d-4f3c-b394-a61abfe673fc@users.noreply.multica.ai> |
||
|
Jiayuan Zhang
|
bb767e0ea6 |
fix(chat): prevent chatbox jump when sending first message (#1582)
The ChatInput wrapper toggled between pb-8 (empty state) and pb-4 (has messages), causing a 16px vertical jump the moment hasMessages flipped. EmptyState already centers itself inside flex-1, so the extra padding wasn't needed — collapse to a single pb-4. Co-authored-by: Lambda <f252c2c5-7d1d-4f3c-b394-a61abfe673fc@users.noreply.multica.ai> |
||
|
Jiayuan Zhang
|
35aca57939 |
feat(chat): Chat V2 — sidebar entry + main-area page (#1580)
* feat(chat): Chat V2 — sidebar entry + main-area page Replace the floating drawer + FAB with a first-class workspace route `/:slug/chat`. Sidebar gets a single `Chat` entry under Inbox with an unread dot; session history lives inside the Chat tab via a popover rather than leaking into the global sidebar (keeps Multica's "nouns in the nav" semantic — Inbox / Issues / Projects are work objects, Chat is a tool). - Add `paths.workspace(slug).chat()` + update link-handler route set. - New `ChatPage` view with PageHeader, history popover, centered messages/composer column, and empty-state starter prompts. - Delete `ChatWindow`, `ChatFab`, resize helpers, and standalone `ChatSessionHistory` (history now embedded in the popover). - Drop `isOpen`/`toggle`/`showHistory`/resize fields from `useChatStore` — the page is a route now, not an overlay. - Wire the new `/chat` route on web (App Router) and desktop (react-router + tab-store icon mapping). Addresses MUL-1322. * fix(chat): align composer width with message column The ChatPage wrapper added px-4 on top of ChatInput's own px-5, making the composer 32px narrower than the messages column. Drop the outer px-4 so both share the same max-w-3xl outer + px-5 inner padding provided by ChatMessageList / ChatInput. * fix(chat): taller default composer (~3 lines visible, 8 max) min-h 4rem → 7rem, max-h 10rem → 15rem. Empty state previously showed only 1 text row after pb-9 for the action bar; raise the floor so there's visible writing room and lift the ceiling so a longer draft can grow before scrolling kicks in. * fix(chat): restore anchor + in-flight indicator + cold-start session restore Three issues surfaced by review: 1. ContextAnchorButton always disabled on /:slug/chat — useRouteAnchorCandidate only matches issue/project/inbox pathnames, so moving chat to its own route dropped 'bring the page I was on into the conversation'. Track the last anchor-eligible location globally (new useAnchorTracker mounted in AppSidebar + lastAnchorLocation on useChatStore) and substitute it when on /chat. 2. No global 'Multica is working' cue after ChatFab deletion. Subscribe the sidebar Chat entry to pendingChatTasksOptions and swap the unread dot for a spinner while any chat task is in flight. 3. ChatPage restore effect latched didRestoreRef before the sessions query resolved, so cold-start direct nav to /chat landed on the empty state even when the server had an active session. Wait for isSuccess before locking the ref. * fix(chat): clear lastAnchorLocation on workspace rehydration The pathname captured in workspace A would otherwise be reused against workspace B's wsId, triggering a cross-workspace issue/project fetch and silently leaking anchor context into chat messages. --------- Co-authored-by: Lambda <f252c2c5-7d1d-4f3c-b394-a61abfe673fc@users.noreply.multica.ai> |
||
|
Jiayuan Zhang
|
977b0c0558 |
feat(agents): show profile card on agent avatar hover (#1577)
* feat(agents): show profile card on agent avatar hover Hovering an agent avatar now opens a preview card with name, status, runtime mode + connectivity, model, skills, and owner. Wired through the shared ActorAvatar wrapper so every render site gets it; opt-out via disableHoverCard in pickers and the agent's own detail header where the card would be redundant or interfere with click selection. * fix(agents): keyboard-focusable hover card + opt out on settings avatar - Make the agent profile-card hover trigger focusable (tabIndex=0 with visible focus ring), so keyboard users can open the card. Drops cursor-default so the trigger inherits the parent control's cursor instead of fighting it. - Disable the hover card on the agent settings avatar — it's a click-to-upload target on the agent's own settings page, where the card would be redundant and the trigger conflicted with the upload affordance. * fix(agents): scope hover-card tab stop to standalone avatars only Detect a focusable ancestor (link/button/role=button/tabindex>=0) at mount and only flip the agent profile-card trigger to tabIndex=0 when none exists. Avatars rendered inside an existing focusable parent (issue list rows wrapped in AppLink, button-style cards, etc.) keep the trigger unfocusable so they don't add redundant nested tab stops or bloat keyboard navigation. Standalone avatars (e.g. comment author, issue detail meta) remain keyboard-accessible with a focus-visible ring. --------- Co-authored-by: Lambda <f252c2c5-7d1d-4f3c-b394-a61abfe673fc@users.noreply.multica.ai> |
||
|
Black
|
17136742b9 |
fix(runtimes): fix dark mode chart visibility and invalid CSS color syntax (#1573)
All chart components used `hsl(var(--chart-X))` but `--chart-X` holds a full oklch value, not bare HSL components — making the expression invalid CSS. Browsers silently fell back to black, so bars/areas/heatmap cells were invisible against the dark background. - Replace `hsl(var(--chart-X))` with `var(--color-chart-X)` across all runtime chart components and the landing feature section - Fix heatmap opacity using `color-mix(in oklch, ...)` instead of the invalid `hsl(var(--chart-3) / 0.3)` syntax; switch to foreground color so cells blend with the neutral theme in both light and dark mode - Raise dark-mode chart-2 through chart-5 lightness values so they contrast clearly against the dark background Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
044d1443b5 |
fix(issues): keep reply editor expand icon muted on focus (#1565)
The expand button relied on the parent row's inherited color, which flipped to text-foreground via group-focus-within while the editor was focused. The attach and submit buttons set text-muted-foreground on themselves and stayed muted regardless of focus, so expand was the only one changing color — inconsistent with the "default muted" convention the other icon-buttons in this editor follow. Give expand its own text-muted-foreground and drop the now-unused color classes from the button row container. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
502add4bd1 |
fix(issues): restore compact single-line reply editor, keep expand overlap fix (#1562)
#1558 fixed the expand button covering trailing text, but also collapsed the reply editor's "empty = 1 line, has content = 2 lines" behavior by making the button row a permanent flex sibling below the editor. Restore the original absolute-positioned button row on both editors: - comment-input: back to `pb-8` container + `absolute bottom-1 right-1.5` buttons (pre-#1558 layout; never had the overlap bug). - reply-input: absolute buttons + `pb-7` gated on `!isEmpty || isExpanded`. Empty → single-line compact; any content → two-row layout with buttons below text (no overlap by construction). Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
e994d77982 |
feat(help): mark external links with arrow, move Feedback last (#1560)
Add an ArrowUpRight glyph next to Docs and Change log to signal they open externally, and reorder so Feedback (internal modal) sits at the bottom. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
efc08a1e37 |
fix(issues): stop expand button from covering text in comment/reply editors (MUL-1297) (#1558)
The comment and reply editors positioned their three trailing buttons (expand, attach, submit) with `absolute` and relied on `pr-14` / `pb-8` magic numbers to reserve space. The reserved 56px is smaller than the actual 80px button row, so the leftmost button (expand) visibly overlaps the trailing characters of a long line of text. Restructure the button row as a normal flex sibling below the editor. Text can no longer flow under the buttons, and the layout no longer needs the `pr-14` hack, `pb-8` padding, or the ResizeObserver that toggled `pb-7` when content overflowed. Also align the expand button in comment-input with the reply-input version (`h-6 w-6` + `h-3.5 w-3.5` icon) so the two entry points match. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Bohan Jiang
|
6fd1255873 |
feat(runtimes): remove Test Connection / runtime ping feature (#1554)
* feat(runtimes): remove Test Connection / runtime ping feature The Test Connection action invoked a real single-turn agent run to verify runtime connectivity. In practice it was expensive (reuses none of the normal task exec env, so it also gave misleading results) and low value — daemon heartbeat + Online status already covers the "is the runtime alive" question. Dropping the whole end-to-end probe path: - deletes server handler and in-memory PingStore - drops pending_ping from the heartbeat response and daemon poll loop - removes daemon.handlePing, PendingPing, ReportPingResult - removes the CLI `multica runtime ping` command - removes the PingSection UI block and RuntimePing types / api methods * docs: fix runtime CLI subcommand list in product-overview |
||
|
Naiyuan Qing
|
6c72c71e3e |
feat(analytics): add onboarding_runtime_detected event on desktop Step 3 (#1553)
Answers "did the user have an AI CLI installed locally when they hit Step 3" — currently unanswerable from the existing funnel because the bundled daemon fails to register at all when zero CLIs are on PATH, so `runtime_registered` is silent on that cohort. Splits the 40% of `completion_path=runtime_skipped` into "had CLIs, skipped anyway" vs "no CLIs available, had no choice" — the two cases need opposite product fixes. Fires once per Step 3 mount in `step-runtime-connect.tsx` (desktop only), when the scanning phase resolves — either immediately on first runtime registration or after the 5 s empty timeout. Reports `runtime_count`, `online_count`, sorted `providers`, convenience booleans (`has_claude` / `has_codex` / `has_cursor`), and `detect_ms`. Also writes `has_any_cli` + `detected_cli_count` via `$set` as cohort signals. Not emitted from the web Step 3 (`step-platform-fork.tsx`) — web users don't run the bundled daemon, so their runtime list can reflect daemons on other machines and would corrupt the "CLI installed locally" signal. Refs MUL-1250. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Bohan Jiang
|
fae3afee79 |
fix(agents): drop auto-loading Local Runtime Skills section from Skills tab (#1551)
* fix(agents): drop auto-loading Local Runtime Skills section from Skills tab Every visit to an agent's Skills tab fired POST /api/runtimes/<id>/local-skills + a polling GET, which: - Created noise on every tab open (the section was rarely the user's reason for entering the tab — they came in for workspace skills). - Currently 404s under the dev backend's multi-replica deploy because the runtime-local-skills request store is in-process; the polling GET frequently lands on a different replica than the POST. The protocol fix is tracked separately; this PR just stops the unsolicited polling. Removes the entire `Local Runtime Skills` inline section, the `runtimeLocalSkillsOptions` query, and the per-skill Import dialog mount on this tab. Users who want to import a local skill go through the Skills page's `+ Add Skill` → `From Runtime` tab — the same flow that handles all other skill creation, only triggered explicitly. Top blue callout stays — still accurate: local runtime skills are auto-available to the agent, importing creates an editable workspace copy. * test(agents): replace stale Local Runtime Skills assertion with negative case The previous test required the inline section + auto-loading runtime local skills query, both removed in this PR. Replace it with a regression test that asserts the section is gone, the per-row import button is gone, and the top informational callout still renders so we know the tab body actually mounted. Drops the now-unused @multica/core/runtimes mock; if a future change re-introduces that import, the missing mock would surface immediately. |
||
|
Naiyuan Qing
|
d6e7824ff1 |
feat(feedback): in-app feedback flow + Help launcher (#1546)
* feat(feedback): add in-app feedback flow and Help launcher Replaces the duplicated bottom-sidebar user popover and "What's new" links with a single Help menu (Docs / Feedback / Change log) pinned to the sidebar footer. Feedback opens a rich-text modal that POSTs to a new /api/feedback endpoint; submissions land in a dedicated feedback table with per-user hourly rate limiting (10/hr) to deter spam without adding middleware infrastructure. User identity (avatar + name + email) moves into the workspace dropdown header so the sidebar is no longer visually redundant. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(feedback): harden submit path and cap request body - Read editor markdown via ref at submit time instead of debounced state, so ⌘+Enter immediately after typing doesn't drop the last keystrokes. - Block submission while images are still uploading; toast prompts the user to wait instead of silently sending markdown with blob: URLs that get stripped. - Cap /api/feedback request body at 64 KiB via MaxBytesReader so an authenticated client can't bloat the metadata JSONB column with an oversized url field. - Add Go handler tests covering happy path, empty-message rejection, and the hourly rate limit boundary. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(analytics): instrument feedback funnel Adds two events pairing frontend intent with backend conversion so we can compute a completion rate for the in-app Feedback modal: - `feedback_opened` (frontend) — fires once on FeedbackModal mount. Source is currently always "help_menu" but the type is a union so future entry points have to extend it explicitly. Workspace id is attached when present. - `feedback_submitted` (backend) — fires from CreateFeedback after the DB insert succeeds and the hourly rate-limit check has passed. Message content itself is never sent to PostHog; the event carries a coarse length bucket (0-100 / 100-500 / 500-2000 / 2000+), an image-presence flag, and the client platform / version pulled from X-Client-* headers via middleware.ClientMetadataFromContext. Affects no existing funnel; seeds a new Feedback funnel for product triage. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Mack
|
f2ba087f74 |
fix(editor): preserve nested ordered lists through readonly render (#1512)
Default @tiptap/markdown serializer emitted nested list items with 2-space indent, but CommonMark (remark-gfm) requires ≥3 spaces under a `1.` marker — so ReadonlyContent (autopilot detail / issue / comment) flattened nested ordered lists, with third-level items glued onto their parent line. Configure Markdown extension with indentation.size = 3. Closes #1510 |
||
|
Bohan Jiang
|
6717db1fad |
feat(agents): surface task source on AgentTaskResponse + use it in Tasks tab (#1455)
Follow-up to #1453. That PR fixed the Tasks tab crash by filtering empty issue_id out of the detail lookup and rendering a neutral "Task without linked issue" label, but every issue-less task — chat-spawned or autopilot-spawned — looked the same. The server already stores the origin in `agent_task_queue.chat_session_id` / `autopilot_run_id`; only the HTTP serializer was dropping them. Server: - `taskToResponse` now populates `ChatSessionID` and the new `AutopilotRunID` on `AgentTaskResponse`. Backward compatible: both omit when UUID is invalid, and existing clients ignore unknown fields. Types: - `AgentTask` (TS) gains `chat_session_id?` + `autopilot_run_id?` and a comment clarifying when `issue_id` is empty. Tasks tab: - Row label for issue-less tasks is picked from the populated source field: "Chat session" for chat tasks, "Autopilot run" for autopilot tasks, "Task without linked issue" as the neutral fallback. Rows stay inert (no anchor) in all three cases; existing issue-linked path is unchanged. Tests: - Two new regression tests assert the chat and autopilot labels render correctly and neither row becomes an anchor. Existing neutral-label test stays as the "neither source populated" case. |
||
|
Naiyuan Qing
|
f84d216794 |
fix(views): restore issue-mention class on <a> for mention card (#1516)
PR #1502's IssueChip extraction moved the `issue-mention` class from the outer <a> into IssueChip's inner <span>, breaking three consumers that select on `<a>.issue-mention` directly: - `.rich-text-editor a.issue-mention` underline-exemption in content-editor.css (stopped matching -> mentions in editor gained a spurious underline). - `link-hover-card.tsx` classList check that suppresses the URL preview on issue mentions (stopped matching -> hover card wrongly pops up over mention chips). - Tailwind Typography prose (`prose a { text-decoration: underline }`) covers a separate path — markdown bubbles in chat. prose's specificity (0,1,1) beats `.no-underline` (0,1,0), so `not-prose` is the right escape hatch on the AppLink. Put `issue-mention` back on the <a> in both wrappers (IssueMentionCard and the editor's MentionView), and add `not-prose` only to the markdown wrapper. IssueChip's BASE_CLASS keeps `issue-mention` too (inert on the span; removing it is a separate scope that needs a full consumer audit). Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
f6dd47c944 |
fix(chat): disable focus button on pages without an anchor (#1509)
The focus toggle was only disabled when focusMode was already ON *and* the current page had no anchor. Off-state on the same page stayed clickable — clicking turned it on, and the button instantly greyed out, making the missing fourth state visible. Decouple "clickable" from focusMode: the button is disabled whenever the current page has no anchor, regardless of the persisted on/off preference. Both the chip render (context-anchor.tsx:173) and send path (chat-window.tsx:176) already guard on candidate presence, so leaving focusMode=true on an unanchorable page has no side effects — the preference is preserved for the next anchorable page. Tooltip now reads "Nothing to share with Multica on this page" whenever the button is disabled, regardless of focusMode. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
2d0916ee38 |
feat(chat): focus mode — share current page as context (#1502)
* refactor(views): extract IssueChip shared primitive from mention card IssueMention (in editor NodeView) and IssueMentionCard shared 95% of their markup — StatusIcon + identifier + title inside a bordered chip. They drifted into two parallel implementations so changes had to be made in two places. Extract the presentational chip into IssueChip. The navigable variants (IssueMentionCard, the editor NodeView) become thin shells that layer routing + cmd/shift behaviour onto the shared chip. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(chat): add focus mode to share current page as context Adds a Focus button next to the chat submit. When on, the chat auto-attaches whatever the user is viewing (issue, project, or inbox-selected issue) as a context prefix on outgoing messages, so the agent knows what "this" refers to without the user pasting ids. The attached object is derived from the route + react-query cache on every render — no separate copy in state. Only the boolean focusMode is persisted (global to the user, not per-workspace), matching the "my preference" mental model. The button has three visual states driven by two dimensions (focusMode + whether the current route resolves to an anchorable object): - off: ghost + muted, click turns on - on + anchor: secondary (bright), click turns off - on + none: disabled (nothing to attach here) The derived anchor renders above the input as a chip — IssueChip for issues, a new ProjectChip for projects — wrapped in AppLink so the visual target matches the clickable target (mirrors IssueMentionCard's hover + navigation). Prefix format reuses the editor's mention markdown: Context: [MUL-1](mention://issue/<uuid>) — "Fix login bug" Context: Project "Authentication" so the agent sees an identical token whether the user @-mentioned inline or focus-mode attached. Backend is untouched. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Naiyuan Qing
|
5335edd50d |
feat(web): /download page + desktop promotion across landing, login, onboarding (#1500)
* docs(download): add redesign plan and copy positioning source of truth Captures motivation (Desktop is Multica's native form; CLI is a distinct scenario for servers/remote boxes, not a Desktop fallback), four-step execution plan, and every touchpoint's current-vs-new copy in EN + ZH. Subsequent UI steps read strings from the positioning doc instead of inventing them inline. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(web): /download page with OS auto-detection New landing-group route that serves as the single canonical download destination. Auto-detects OS + arch via navigator.userAgentData (Chromium) with UA-string fallback, then surfaces the matching Desktop installer as the primary CTA. All platforms stay visible below, plus a CLI section (positioned for servers / remote boxes / headless setups, not as a lightweight Desktop) and a Cloud waitlist. Version + asset URLs come from api.github.com/repos/.../releases/latest with Vercel ISR (revalidate=300) so every release automatically propagates — no manual redeploy. Optional GITHUB_TOKEN env var lifts the 60/hr unauthenticated rate limit for local dev. Failure degrades cleanly to "Version unavailable" + a link to GitHub releases. Also points landing hero + footer Download links at /download (previously pointed at the GitHub releases page directly), and re-exports CloudWaitlistExpand from @multica/views/onboarding so the new Cloud section can reuse the existing form. Intel Mac has no binary today (electron-builder targets mac arm64 only); the page is honest about it and routes Intel users to CLI. i18n copy sourced verbatim from docs/download-positioning.md. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): rewrite Step 3 fork + web Welcome Desktop CTA Welcome screen now self-segments: on web (runtimeInstructions present), the primary CTA is "Download Desktop" with a benefit-led subtitle ("Desktop bundles the runtime — nothing to install. Continue on web to connect your own CLI.") that lets developers with their own CLI recognize their path while guiding everyone else toward the desktop app. Desktop branch drops the "3 minutes" estimate in favor of the aha promise. Download button is a real <a href> link so middle-click / copy-link / screen readers all behave correctly. Step 3 fork drops the stale isMac gate — Windows / Linux binaries now ship, the macOS-only muted card was a lie. The single Desktop card now routes to /download (not GitHub releases directly) so users land on the auto-detect page. CLI card is reframed around its real scenario (servers, remote dev boxes, headless) rather than posing as a lightweight Desktop, and the CLI dialog's stall tier redirects users to Desktop instead of Cloud waitlist when the daemon never registers — Desktop is the genuine retreat. cli-install-instructions gets a one-liner acknowledging the CLI's server use case, mirroring the card copy. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(web,auth): desktop promotion on login + solid landing hero download LoginPage accepts a new `extra?: ReactNode` slot rendered below the Google button. The web shell injects a hardcoded-EN "Prefer the desktop app? Download →" nudge there — catching users at their lowest-investment moment, before they've typed an email. Desktop's login wrapper omits the slot (a download prompt inside the app would be absurd), so only the web surface renders it. Copy is English-only for now because the /login route sits outside the landing group's LocaleProvider. Lifting locale detection into the root layout would force every page dynamic and kill the Router Cache — a trade-off not worth two strings. The `auth.login.extra*` i18n keys added during Step 2 are removed for the same reason: they're dead code without a LocaleProvider wrapping login. Landing hero "Download Desktop" upgrades from ghost to solid and swaps its handwritten monitor SVG for lucide-react's Download icon. Both hero CTAs are now solid-weighted — the icon + distinct label differentiates them. href already points to /download from the Step 2 landing nav pass. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(web/download): anchor dark LandingHeader with relative wrapper LandingHeader's dark variant uses `absolute top-0 inset-x-0`, which only reads correctly when wrapped by a positioned ancestor — see multica-landing.tsx:14 for the canonical pattern. Without the wrapper the header escaped to the initial containing block and appeared fixed as users scrolled the page. Also drops the <main> element around the body sections for consistency with the rest of the landing group (neither multica-landing nor about-page-client wraps in <main>). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(landing/hero): keep Download Desktop as ghost to preserve CTA hierarchy Upgrading to solid alongside the existing "Start free trial" CTA killed the primary / secondary distinction — both buttons were white on dark, competing for attention. Revert to ghost so the conversion CTA (trial) stays the visual primary. The lucide Download icon swap stays (cleaner than the handwritten monitor SVG). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(onboarding): update platform-fork assertions for /download route The Desktop card in Step 3 now opens the new /download page instead of GitHub releases, and the post-click feedback text changed to match ("Continuing on the download page…" in place of "Downloading Multica…"). Update the expectations and drop the isMac navigator stub that was only needed when the component had a macOS-only primary branch. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * Merge origin/main into NevilleQingNY/download-redesign Main added onboarding funnel analytics (#1489) that captures `is_mac` as a dimension for each Step 3 path selection. This branch had removed the `isMac` state because the UI no longer branches on it (Windows / Linux desktop builds ship now). Git auto-merged the two diffs into a file that referenced a deleted variable. Reintroduce `isMac` as a lazy client-only computation scoped to analytics capture only — the UI stays platform-agnostic. Handlers fire client-side so SSR safety isn't needed; a plain const reads navigator on first render. typecheck passes across all 6 packages; all 166 views tests green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(analytics): instrument download funnel across 5 surfaces + /download Closes the gap left by PR #1489: onboarding analytics captured Step 3 path selection but missed the four surfaces that advertise the desktop app earlier in the funnel (landing hero, landing footer, login, Welcome), and the /download page itself had zero coverage — so we could see the last-mile path but not the top-of-funnel entry nor the page-to-installer conversion. Three new events, wired via `@multica/core/analytics`: 1. `download_intent_expressed` fires on any CTA pointing at /download. `source` splits the five surfaces cleanly; every authenticated emission also writes `platform_preference=desktop` on the person (same convention Step 3 already uses). 2. `download_page_viewed` fires once per /download mount after OS detect resolves. Carries `detected_os`, `detected_arch`, `detect_confident` (Chromium userAgentData vs UA fallback), and `version_available` so the Safari-on-Mac arm64-default cohort and GitHub-rate-limited degraded sessions are each isolable. Also $set_once's `first_detected_os/arch` on the person so every downstream event gains a platform dimension without re-emitting. 3. `download_initiated` fires on every installer click — Hero's primary CTA and each All Platforms matrix row. `primary_cta` splits hero-recommended from manual picks; `matched_detect` quantifies detect accuracy from the single event (no cross-join to download_page_viewed needed). Augments the existing `onboarding_runtime_path_selected` with a `source: "step3"` property — literal today, reserved for future surfaces reusing the same event name. `is_mac` kept for backward-compat with PR #1489's dashboards; the new events use `detected_os` + `detected_arch` instead. New `setPersonPropertiesOnce` wire helper in `packages/core/analytics/download.ts` for `$set_once` — mirrors the backend's `Event.SetOnce` semantics. docs/analytics.md update lands in the follow-up commit. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(analytics): document download_intent_expressed / page_viewed / initiated Adds the three new download-funnel events to the frontend-only section. Also notes the semantic shift on onboarding_runtime_path_selected: its `path: "download_desktop"` now signals Step 3 path choice, not actual download start — download_intent_expressed is the new canonical "user expressed intent to download desktop" signal across surfaces. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Bohan Jiang
|
205e8c1e9c |
feat(analytics): client_type super-property + Desktop $pageview (MUL-1253) (#1490)
* feat(analytics): client_type super-property + Desktop $pageview (MUL-1253)
Register a `client_type` super-property ("desktop" | "web") plus optional
`app_version` inside `initAnalytics`, so every PostHog event from the
renderer can be split by client without relying on `$lib` (both Electron
and Next.js report "web"). `appVersion` flows in from `ClientIdentity`
via `CoreProvider` → `AuthInitializer`.
Add a Desktop `PageviewTracker` mounted in `DesktopShell` that fires
`$pageview` whenever the active tab's path changes, mirroring the Web
tracker. Restores the `/ → signup → workspace_created` funnel for the
desktop client and enables web-vs-desktop breakdowns.
* fix(analytics): preserve super-props on reset + cover overlay/login pageviews
Two blockers from PR review:
1. `posthog.reset()` wipes persisted super-properties, so after logout or
account switch the next session's events silently dropped `client_type`
and `app_version` until a full reload. Cache the set at init time and
re-register it inside `resetAnalytics()` so the breakdown survives the
auth transition. Added unit tests to pin the invariant.
2. Desktop `PageviewTracker` only watched the active tab path, which
missed pre-workspace overlays (`/onboarding`, `/workspaces/new`,
`/invite/<id>`) — those aren't tab routes on desktop — and also missed
the logged-out `/login` state. Move the tracker to the app root and
derive the visible path from `(user, overlay, activeTabPath)` with
overlay > tab precedence so the `$pageview` stream matches the
surface the user actually sees.
|
||
|
Naiyuan Qing
|
cd6bb48283 |
feat(autopilots): unified create/edit dialog with issue-modal layout (#1501)
Replace separate CreateAutopilotDialog / EditAutopilotDialog with a single
shared <AutopilotDialog mode="create"|"edit"> that mirrors the issue create
modal — dynamic sizing, expand/collapse, richtext Prompt, pill toolbar.
- Tiptap ContentEditor replaces plain textarea for Prompt; detail page
renders description via ReadonlyContent for visual parity.
- Pills: Agent, Priority, Execution Mode, Schedule (Popover hosting
TriggerConfigSection). 0/1/N trigger strategy: add on 0, edit inline on
1, disabled with tooltip on 2+ (power users edit in detail page).
- Exposes priority + execution_mode at creation time (backend always
supported them; old UI only offered them in Edit).
- parseCronExpression reverse-parses stored cron back to TriggerConfig for
Edit-time prefill (with round-trip tests).
- PillButton extracted to packages/views/common for reuse across modals.
- DialogContent uses showCloseButton={false} so the shared header renders
the Maximize + Close buttons next to the Rocket-prefixed breadcrumb.
- Conditional mount at call sites (`{open && <AutopilotDialog/>}`) keeps
state fresh on each open.
- Schedule dirty detection compares cron+timezone payloads vs mount
snapshot, and edit-mode submits against a snapshotted trigger id so
concurrent WS refetches can't mis-target the update.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
||
|
devv-eve
|
fbf41bde73 |
feat(selfhost): ship public GHCR deployment flow
Publish stable GHCR self-host images, switch self-host deploys to official image pulls with a source-build fallback, and move self-host signup / Google OAuth config onto runtime /api/config. |
||
|
Bohan Jiang
|
936df59fa1 |
feat(analytics): instrument onboarding funnel (MUL-1250) (#1489)
* feat(analytics): capture onboarding funnel events + person-property $set Closes the visibility gap introduced by the Onboarding relaunch: the five new steps between signup and workspace_created were invisible to PostHog, and we couldn't see Step 3 web-fork drop-off, cloud waitlist intent, or starter-content acceptance at all. Server-side events (see docs/analytics.md for full contracts): - onboarding_questionnaire_submitted — fires once when all three answers first land; also $set's role/use_case/team_size on the person so every subsequent event is cohortable - agent_created — not onboarding-specific; is_first_agent_in_workspace isolates the Step 4 signal - onboarding_completed — fires on the actual NULL → timestamp flip with completion_path (full / runtime_skipped / cloud_waitlist / skip_existing / unknown) + joined_cloud_waitlist - cloud_waitlist_joined — sizes hosted-runtime interest - starter_content_decided — imported vs dismissed, split by agent_guided / self_serve branch on both sides Also adds Event.Set (→ PostHog $set) alongside the existing SetOnce so the same events can carry mutable cohort signals without a separate identify round-trip. * feat(analytics): wire frontend onboarding events + completion_path - captureEvent / setPersonProperties helpers in @multica/core/analytics, with the same pre-init buffering as identify/pageview so config races don't drop step transitions - onboarding_runtime_path_selected fires from step-platform-fork for the three web-fork choices (download desktop / CLI / cloud waitlist), plus platform_preference on person properties for downstream splits - completeOnboarding now takes an OnboardingCompletionPath; the onboarding shell derives full / runtime_skipped / cloud_waitlist from runtime + waitlist state (lifted to the shell so StepFirstIssue can see both), and handleWelcomeSkip passes skip_existing - saveQuestionnaire mirrors team_size/role/use_case into person properties via $set so every event on this user becomes cohortable - StepAgent sends the template slug, StarterContentPrompt passes workspace_id on dismiss so the server can mirror the branch label * docs(analytics): document onboarding funnel events + $set person properties |
||
|
Joey
|
fa7e4cbdca |
Feat/la te x (#1365)
* 排除提交文件 * feat(editor): 添加数学公式渲染支持 - 集成 KaTeX 库用于数学公式渲染 - 在编辑器样式中添加数学节点相关 CSS 样式 - 实现 BlockMathExtension 和 InlineMathExtension 两个数学公式扩展 - 为 Markdown 组件添加 remarkMath 和 rehypeKatex 插件支持 - 在 package.json 中添加 katex、remark-math、rehype-katex 依赖 - 更新 pnpm-lock.yaml 文件以包含新的依赖包 - 为只读内容组件添加数学公式渲染功能 - 创建 math.tsx 文件实现数学公式节点的完整功能 - 添加只读内容的数学公式渲染测试用例 |
||
|
Bohan Jiang
|
747d9492cf |
feat(changelog): surface release notes from sidebar menu + update prompt (#1485)
Two entry points to multica.ai/changelog so users actually find out what shipped: - Sidebar user menu (both expanded popover + collapsed dropdown variants) gains a "What's new" item with a Sparkles icon, sitting above Log out. Plain `<a target="_blank">` works on both surfaces: web opens a new tab, desktop's main-process setWindowOpenHandler intercepts and routes through openExternalSafely. The shared view doesn't need to branch. - Desktop's UpdateNotification "ready to restart" card grows a secondary "See changes" button next to "Restart now", giving the user a reason to actually restart instead of dismissing. Mirrors Conductor's update prompt pattern. The "available" / "downloading" states stay action-only — the changelog isn't useful before the download finishes. No version-detection / unread-tracking yet. Web users still need to click into the menu to see the changelog; that's a follow-up if the team wants Linear-style "new" dot. |
||
|
Naiyuan Qing
|
c787546ede |
refactor(pin): drop server-side enrichment, derive sidebar fields client-side (#1484)
`ListPins` used to join `issues` / `projects` so each pin row carried a `title`, `status`, `identifier`, and `icon`. Convenient for the sidebar but architecturally wrong: those fields live on a different cache key than the pin query, so an `issue:updated` WS event invalidates `issueKeys` and never touches `pinKeys`. The sidebar therefore showed stale issue status / titles on pinned rows until a hard refresh — and the same shape would silently re-emerge for any new enriched field added later. This refactor moves the join to the client so display data flows from its real source of truth: Server (`server/internal/handler/pin.go`): - `PinnedItemResponse` keeps only pin-owned columns (id, workspace_id, user_id, item_type, item_id, position, created_at). - `ListPins` no longer fetches issues / projects in the loop and no longer hides orphaned pins; the client decides how to render a pin whose target was deleted. - `formatIdentifier` helper deleted (was only used by the enrichment branch); `strconv` import dropped along with it. Types (`packages/core/types/pin.ts`): - `PinnedItem` interface now mirrors the bare server shape. The four enriched fields are removed. Sidebar (`packages/views/layout/app-sidebar.tsx`): - New smart wrapper `PinRow` resolves each pin's display data via `useQuery(issueDetailOptions(...))` or `useQuery(projectDetailOptions(...))` with `enabled` gates on `pin.item_type` so the hook order stays stable. Loading renders a flat skeleton; error / 404 renders null (orphan pins hide themselves). - `SortablePinItem` becomes purely presentational: it now takes `label` and `iconNode` as props instead of reading them off the pin object. dnd-kit / navigation wiring untouched. - Same pattern as `packages/views/search/search-command.tsx:151`, which already uses per-row detail queries for Recent issues. WS sync layer is unchanged: `onIssueUpdated` already patches `issueKeys.detail`, so changing an issue's status now flows directly into the sidebar without any cross-entity invalidate. The `pin:*` prefix handler still invalidates `pinKeys` for create / delete / reorder — that's still the correct signal for the pin LIST itself. Verified: views typecheck + core typecheck + web typecheck + desktop typecheck + go test ./internal/handler/... + vitest (views: 165 tests, core: 83 tests) all pass. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Bohan Jiang
|
14a9b5293e |
feat(slugs): reserve homepage + expand reserved slug list (MUL-961) (#1483)
* feat(slugs): reserve homepage + expand reserved slug list (MUL-961) - Fix: `homepage` was a live `/homepage` landing route in apps/web but not in the reserved list, so a user could register a workspace slug that shadowed the landing page. Now reserved on both backend and frontend. - Add likely-future global routes (home, dashboard, profile, account, billing, notifications, search, members) so we don't have to do another audit/rename pass when these get wired up. - Add API/ops prefixes (v1, v2, graphql, webhooks, sdk, tokens, cli, health, ws, metrics, ping) as defense-in-depth against collision with API aliases and ops endpoints. - Clarify in both source files that the dotted/underscored entries in the "Next.js / web standards" section are currently unreachable under the slug regex `^[a-z0-9]+(?:-[a-z0-9]+)*$` and are kept as defense-in-depth in case the regex is ever relaxed. - Add audit migration 056 following the 047/049 pattern to fail loud if any production workspace slug collides with the newly reserved set. * fix(slugs): rename prod conflicts in migration 056 (home → home-1, dashboard → dashboard-1) Per db-boy's prod audit in the MUL-961 thread, two §3 slugs had live prod workspaces at reservation time. Decision on MUL-961: force-rename both in the audit migration (scheme 1), same playbook as MUL-972 for admin/multica/ new/www. - `home` → `home-1` (68a982da, zzlye, 2026-04-14) - `dashboard` → `dashboard-1` (ea5a332f, 王争, 2026-04-22) Targeted UPDATEs land first, followed by a generic `<slug>-N` fallback that handles any row that slips in between the audit snapshot and deploy. A post-condition block re-queries the reserved set and fails loud if anything slipped through. Down migration reverts the two targeted renames deterministically (they're keyed by workspace_id, so rollback is safe). Owner outreach (email zzlye@ + 王争@ about the URL change) is tracked as a follow-up outside this PR. |
||
|
Naiyuan Qing
|
3036c6418e |
fix(onboarding): pin sync, welcome layout, runtime bootstrap state (#1482)
Follow-ups on the onboarding flow shipped in #1411. Pin state synchronization: - ImportStarterContent now publishes pin:created after commit so the sidebar refreshes without a hard reload (previously the pins landed in the DB but no event was fired). - ReorderPins publishes pin:reordered, keeping order in sync across web + desktop sessions. - StarterContentPrompt.onImport invalidates queries locally, mirroring the useCreatePin / useDeletePin / useReorderPins onSettled pattern, so the originating session's refresh doesn't depend on the WS round-trip (WS is the signal for OTHER sessions). - ImportStarterContent rejects malformed workspace_id up front with 400 instead of falling through to a misleading 403. Welcome step layout: - Switch the two-column hero from CSS Grid to a flex row. Both columns share the container's full height via items-stretch + justify-center, so the bg-muted/40 backdrop fills edge-to-edge on tall viewports and left/right content stays vertically centred. Desktop runtime bootstrap state: - New DesktopRuntimesPage wrapper subscribes to window.daemonAPI and forwards a `bootstrapping` prop to RuntimeList. While the bundled daemon is booting, the empty state renders "Starting local runtime…" instead of the misleading "Run multica daemon start" hint. Web leaves the prop undefined — behaviour unchanged. Small polish: - CLI install dialog caps at 85vh with an internal scroll so the Connect button stays reachable when multiple runtimes are registered. - Drop the env-aware CLI setup command; onboarding always targets cloud, so `multica setup` is enough — no need to thread apiUrl / appUrl through the dialog. Developer tooling: - pnpm dev:desktop:staging — parallel dev command that loads .env.staging (copilothub backend) via `electron-vite --mode staging`, so switching between local and staging no longer requires hand-editing env files. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Ark
|
26a2db2540 |
feat(transcript): add multi-select tool filter to agent execution dialog (#1460)
* feat(transcript): add multi-select tool filter to agent execution dialog Adds a Filter dropdown to AgentTranscriptDialog that lets users multi-select tool types (e.g. tool:Bash, tool:Edit) to narrow down the event list, timeline bar, and copy output. Non-tool items (text, thinking, error) are also filterable. Clear filters is placed at the bottom of the dropdown with a separator. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(transcript): address review comments on tool filter - Replace index-based selection with seq-based (selectedSeq) to fix highlight/scroll jumping when toggling filters - Use full tool count for the "X tool calls" chip (task-level stat) instead of filtered count - Title-case filter labels: Thinking, Error (was lowercase) - "Copy all" → "Copy filtered" when filter is active - Replace raw <button> with DropdownMenuItem for Clear filters so it participates in keyboard navigation - Drop redundant idx from row key (seq is already unique/stable) Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(transcript): use proportional width in timeline bar After removing segment grouping, the timeline bar lost proportional widths. Restore proportional width per item (1/items.length * 100%) so each event's width reflects its share of the timeline. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(transcript): show individual event dividers in timeline bar When filtering by a single type (e.g. Agent), all events share the same color and blend into one solid bar. Split each event into its own clickable button so users can see and click individual events, while keeping proportional widths based on item count. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(transcript): simplify timeline bar to segment-level buttons Remove per-item nested buttons in timeline segments; each segment is now a single clickable area. Reduces DOM nodes and aligns with the original design where segments are coarse color blocks. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * refactor(transcript): reuse getEventLabel for filter option display Replace the manual displayMap with getEventLabel() so filter option labels stay in sync with row labels automatically. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> * fix(transcript): address round-2 review comments - Remove dead `onClick` prop from TranscriptEventRow (caused TS6133 under noUnusedParameters; row never wired a click handler) - Align `itemFilterKey` guard with `filterOptions` derivation (tool_use/tool_result type check) - Fix TimelineBar `isSelected` from seq range to actual membership via `.some()` — avoids false highlight when a filtered-out seq falls within a segment's range Note: `DropdownMenuItem` uses `onClick` not `onSelect` because this codebase uses Base UI, not Radix. Base UI's Item.Props has no `onSelect`; the inbox/members-tab code uses `onClick` as the pattern. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> --------- Co-authored-by: Ark <lifangzhou@shizhuang-inc.com> Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> |
||
|
Bohan Jiang
|
aa9932e4e1 |
fix(skills): unify Add Skill UX + surface every local skill with real file count (#1480)
* fix(skills): unify Add Skill UX + surface every local skill with real file count Iterating on the local-skill import flow that just landed. Three fixes shipped together because they all surfaced while testing the same code path on the Skills page. UX — fold runtime import into the existing "+ Add Skill" dialog - Drop the standalone HardDrive icon button + the empty-state "Import From Runtime" buttons. Adding a skill is now a single entry point: the "+" header button (or empty-state button) opens one dialog with three tabs: Create / Import URL / From Runtime. - Extract the runtime-import body into RuntimeLocalSkillImportPanel so it can mount inline as a tab. The standalone Dialog wrapper stays for the per-runtime "Import this skill" flow on the agent skills tab, which preselects runtime + skill and benefits from its own modal. - Cap the dialog at max-h-[85vh] with a scrollable tabs body so the From-Runtime tab (runtime selector + skill list + name/description form) no longer overflows the screen on shorter displays. - Filter the runtime selector to runtimes the caller owns. Other users' runtimes were listed but the import endpoint rejects them anyway, matching the Runtimes page's "Mine" default. - The selected-runtime label in the trigger now shows the runtime name (`Claude (MacBook-Air.local) (claude)`) instead of the raw UUID — the shadcn SelectValue needs explicit children when items don't render the bare value as their label. - Drop the placeholder Sparkles icon to the left of the skill name / description inputs in the detail header — it was decorative noise. Daemon — surface every installed local skill and report the right count - listRuntimeLocalSkills used filepath.WalkDir, which silently dropped every symlinked skill via the os.ModeSymlink early return. Skill installers like lark-cli ship every skill at ~/.agents/skills/<name> and symlink each one into ~/.claude/skills/, so users with dozens of skills only saw the few they had cloned in place. Switch to ReadDir + os.Stat (which follows symlinks) on the runtime root. - collectLocalSkillFiles also failed for symlinked skill dirs because filepath.WalkDir does not descend into a symlinked root, so every such skill reported 0 files. Resolve the skill dir via EvalSymlinks before walking. - Bundle file count purposely excludes SKILL.md (it travels in the bundle's `Content` field to avoid duplication on import). The summary now adds 1 back so the user-facing count matches the real file total — every skill has SKILL.md, we just required it to be parseable. Tests - New TestListRuntimeLocalSkills_FollowsSymlinkedSkillDirs seeds a shared installer dir, symlinks one skill into the runtime root, and asserts both regular and symlinked skills come back with the right source path (~/.claude/...) and metadata. - TestListRuntimeLocalSkills_Claude updated to expect file_count = 2 (one supporting file + SKILL.md) and a comment explains the +1 split. * test(skills): drive new Add Skill dialog flow in skills-page test Old test asserted the standalone "Import From Runtime" button. The PR folded that into the unified "+ Add skill" dialog as the third tab, so the test now opens the dialog, switches to the "From Runtime" tab, and asserts the same end state. Also stub useAuthStore so the runtime panel's "Mine"-only filter sees the seeded runtime owner (user-1). * fix(daemon): list nested skills, not just depth-1 entries Per #1480 review (MUL-1246): switching listRuntimeLocalSkills from filepath.WalkDir to flat ReadDir lost coverage for nested skill layouts. opencode stores skills as e.g. `release/reporter/SKILL.md`, and loadRuntimeLocalSkillBundle accepts that slash-delimited key, so the import dialog could no longer surface skills the load endpoint was perfectly happy to fetch. Replace the flat ReadDir with a recursive enumerator that: - Follows symlinks at every level (so installer-style symlinked skill trees still work — that was the original reason for moving off WalkDir). - Short-circuits at every SKILL.md: a directory that qualifies as a skill is registered, and its children are NOT scanned for further skills. Stale nested SKILL.md files inside a parent skill's bundle stay part of that bundle. - Caps recursion at maxLocalSkillDirDepth=4 (covers opencode's depth=2 with headroom) and tracks visited resolved paths so a cyclic symlink can't loop forever. New regression test seeds both a top-level skill (with a decoy SKILL.md inside its templates dir) and a depth-2 nested skill, and asserts the walker registers exactly two keys — "top" and "release/reporter" — with the inner templates SKILL.md correctly ignored. |
||
|
LinYushen
|
b624cd98ad |
feat: identify clients via X-Client-Platform/Version/OS (#1477)
* feat: identify clients via X-Client-Platform/Version/OS
Adds client identification headers (and matching WS query params) across
all first-party clients so the server can split logs/metrics/gating by
caller without parsing User-Agent.
- HTTP: X-Client-Platform, X-Client-Version, X-Client-OS
- WS: client_platform, client_version, client_os query params
- Platform ∈ {web, desktop, cli, daemon}; OS ∈ {macos, windows, linux}
Wired through the shared TS ApiClient/WSClient via a new identity option
on CoreProvider. Web reads its version from package.json/env; Desktop
captures version + OS synchronously in preload via sendSync IPC. Go CLI
and daemon clients populate the same headers using runtime.GOOS
(normalized darwin → macos).
Server-side adds a ClientMetadata middleware that stashes the headers in
request context; the request logger and logger.RequestAttrs surface them
on every access log and handler-level log. Realtime hub logs the same
fields on websocket connect.
CORS allowlist extended for the new headers.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
* test: address client-identity PR nits
- Memoize the CoreProvider identity object on Web and Desktop, and key
WSProvider's effect on identity primitives instead of the object
reference, so unrelated parent re-renders no longer tear down and
reconnect the WebSocket.
- Add direct header-injection tests for the CLI and daemon Go HTTP
clients (X-Client-Platform/Version/OS) and a normalizeGOOS unit test
on both packages.
- Add a TS test for WSClient that asserts client_platform/client_version/
client_os land on the upgrade URL and never leak the auth token.
- Add a hub test that dials the WS endpoint with client_* query params
and asserts the "websocket connected" log entry surfaces them as
structured attributes.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---------
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
||
|
gezilinll
|
f247a4f544 |
feat(skills): import runtime local skills into workspace (#1431)
* feat(skills): import runtime local skills into workspace * fix(skills): address runtime local skill review feedback * docs(skills): annotate local provider skill paths --------- Co-authored-by: zhangliang <zhangliang@gaoding.com> |
||
|
Bohan Jiang
|
387f76d328 |
fix(agents): tasks tab crashes when agent has autopilot run_only tasks (#1453)
* fix(agents): tasks tab crashes when agent has autopilot run_only tasks
Autopilot `run_only` tasks have no linked issue; the server serializes
that as `issue_id: ""` (not null) via `uuidToString` on an invalid
pgtype.UUID. The agent detail Tasks tab assumed every task had a real
issue id and fed `""` into `api.getIssue(id)` → `/api/issues/` and into
`paths.issueDetail("")`, crashing the whole tab as soon as one such
task existed on the agent.
Handle the empty-issue case explicitly:
- Filter empty ids out of `issueIds` so `useQueries` doesn't fire
`/api/issues/` for a nonexistent issue.
- Render run_only rows as non-link `<div>`s labeled "Autopilot run"
instead of clickable issue links.
No server-side change — the `""` serialization stays as-is; callers
just need to treat it as "no issue".
* fix(agents): neutral label for issue-less tasks + regression test
Review feedback on #1453: not every task without a linked issue is an
autopilot run. `ListAgentTasks` returns the agent's full queue; both
autopilot `run_only` runs and chat-spawned tasks persist with NULL
issue_id, which arrives here as "". Labeling both as "Autopilot run"
mislabels chat tasks.
Swap the label to the neutral "Task without linked issue" and update
surrounding comments. A follow-up will surface the real task source
once the server populates it on AgentTaskResponse.
Adds a regression test that empty issue_id rows render the neutral
label, aren't wrapped in an anchor, and don't trigger a detail fetch.
|
||
|
Naiyuan Qing
|
3fd2fb2ae3 |
feat(onboarding): redesigned flow + post-landing starter content opt-in (#1411)
* docs(onboarding): add redesign proposal Captures motivation (two activation funnels), research-backed principles, final 5-step flow (welcome+questionnaire → workspace → runtime → agent → first-issue), Q1/Q2/Q3 personalization matrix, backend user_onboarding schema, API design, resume policy, and development ordering (frontend-first with Zustand stub, backend-last, server swap). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): scaffold redesigned flow and state foundation Work-in-progress scaffold toward the redesign documented in docs/onboarding-redesign-proposal.md. This commit is intentionally broad — subsequent commits will replace step content and wire real personalization. Not ready for merge. Included: - packages/views/onboarding/: flow orchestrator + 5 step components (welcome/workspace/runtime/agent/complete) and the CLI install card. Step content is the placeholder version; Step 1 (questionnaire) and Step 5 (first issue) are the next changes. - packages/core/onboarding/: dev-phase Zustand store + types. Not persisted — every page refresh starts at Step 1 so each step can be iterated in isolation. Will swap to TanStack Query + PATCH /api/me/onboarding once the backend user_onboarding table ships (keeps the exported hook surface stable). - packages/core/paths/resolve.ts + .test.ts: centralized resolvePostAuthDestination. Priority is flipped so !hasOnboarded wins over workspace presence — during frontend development every login re-enters /onboarding. useHasOnboarded() reads from the store so the real onboarded_at semantic lands automatically once the backend ships. - Post-auth wiring: callback page, login page, landing redirect, dashboard guard, realtime workspace-loss handler, settings leave/ delete, invite acceptance, and desktop app shell all delegate to the shared resolver instead of inline logic. - Desktop overlay: 'onboarding' added as a WindowOverlay type alongside new-workspace / invite, with a navigation-adapter interception so push('/onboarding') opens the overlay. - packages/core/package.json / packages/views/package.json: add new subpath exports. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(onboarding): revise questionnaire to role-driven 3-question form Aligns the proposal with the corrected product positioning: Multica is an AI agent orchestration platform for diverse users (developers, product leads, writers, founders), not a coding-focused tool. Key changes: - Drop Q1 "which agents do you already use?" — daemon auto-detects installed CLIs on PATH; asking is both redundant and less accurate - Add Q2 "what best describes you?" (role) to drive Step 4 template default and Onboarding Project sub-issue filtering - Keep Q1 team_size, refine Q3 use_case (recover writing/research option); all three now have "Other" with an 80-char text field - Q3 use_case_other is embedded into Step 5 first issue prompt so Other users get maximally personalized aha moments, not generic ones - Agent templates: 3 → 4 (Coding / Planning / Writing / Assistant), matrix driven by Q2 × Q3 - Onboarding Project sub-issues: surface Autopilot and Workspace Context (product differentiators), replace "orchestration" wording - Schema JSONB example and §5/§9 execution plan updated to match Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(onboarding): align questionnaire shape with role-driven redesign Prepares the core state layer for the Step 1 questionnaire rewrite. Type-only and initial-value changes; no behavior changes (nothing was reading the removed `existing_agents` field, since no questionnaire UI exists yet). - Add `Role` type (Q2: developer / product_lead / writer / founder / other) - Add `*_other` sibling fields for team_size / role / use_case so each question's "Other" selection can carry 80-char free text - Drop `existing_agents` — daemon auto-detects CLIs on PATH at Step 3, so the signal no longer belongs in the questionnaire - Extend `TeamSize` / `UseCase` unions with `"other"` member - Refine `UseCase` option label (`writing` → `writing_research`) so it matches the widened Q3 scope in the proposal Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): implement Step 1 questionnaire Replaces the placeholder welcome step with the 3-question questionnaire defined in docs/onboarding-redesign-proposal.md §3.4. Answers land in the core onboarding store for later use by Steps 4 and 5. Added: - packages/views/onboarding/components/option-card.tsx — OptionCard + OtherOptionCard. Radio-group ARIA semantics; Enter/Space select; Other variant reveals an 80-char input that auto-focuses on mount. - packages/views/onboarding/steps/step-questionnaire.tsx — merges welcome + Q1/Q2/Q3 into one screen. Local draft state for responsiveness; writes to the core store only on submit. Skip/ Continue CTA swap driven by "any answered?"; the only disabled case is "picked Other but the text box is blank". - Test coverage for the CTA rules, Other-clear-on-switch behavior, initial-answers pre-fill, and full payload shape. Modified: - packages/views/onboarding/onboarding-flow.tsx — render questionnaire as the first step; persist answers and advance the stored current_step on submit. Other steps still run off local useState for now; full store-driven orchestration follows when Step 5 lands. Removed: - packages/views/onboarding/steps/step-welcome.tsx — superseded. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(onboarding): split welcome + questionnaire, unblock scroll, drop Q1 evaluating Three fixes prompted by first real browser testing of the Step 1 questionnaire. All three are about making the flow usable before pursuing visual polish. 1. Split Welcome and Questionnaire into two screens The previous merge-welcome-into-questionnaire decision dropped Multica's product introduction entirely. For a product with no established mental model (AI agents as first-class teammates in a task platform), first-time users need 5 seconds of framing before the questionnaire makes sense. StepWelcome carries that framing; it's UI-only (not a persisted step), shown only on first entry (pristine store), and skipped automatically on resume. 2. Remove `my-auto` vertical centering from both platform shells Long questionnaire content pushed the centered block's top above the scroll origin, making Continue/Skip unreachable. Top-alignment + natural body/overlay scroll is the boring-but-correct baseline for content of variable height. 3. Drop Q1 "Just exploring for now" option Q1 asks about team structure, not attitude. "Evaluating" was a category error. Low-commitment users already have a zero-friction path (skip all questions). Removing the option simplifies the question and the downstream mapping table. Types, store initial value, proposal doc (§3.1 flow diagram, §3.4 options, §3.5 sub-issue sorting, §3.6 conditionals, §4.1 JSONB schema, §5.2 file list, §7 decisions row, §9.2 execution order) all synced. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(onboarding): center short steps, scroll long ones — correctly this time Previous attempt removed `my-auto` thinking it was responsible for blocked scrolling. That diagnosis was wrong: the real blocker was the root layout's \`body { overflow: hidden }\` (an app-shell convention so sidebar/topbar stay put while the inner content region scrolls). Removing `my-auto` broke vertical centering of short steps (Welcome) without fixing the scroll issue. Correct fix: - Web: page now owns its own scroll container — `h-full overflow-y-auto` on the outermost div decouples from the body's overflow-hidden. - Desktop: the overlay's existing `flex-1 overflow-auto` container already provided scroll; just restoring `my-auto` was sufficient. - Both platforms: inner `flex min-h-full flex-col items-center` + content `my-auto` gives the "short centers, long top-aligns and overflows down" behavior. Per the flex spec, auto margins are ignored on overflowing boxes (they overflow in the end direction), so Continue/Skip remain reachable via scroll even on long steps like the questionnaire. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): add progress indicator + stable header anchor Adds a consistent visual anchor at the top of every step (except Welcome), so transitioning between steps of different content heights no longer shifts the vertical baseline. - packages/core/onboarding/step-order.ts — single source of truth for step order; indicator math reads from here so adding/reordering a step touches only one line - packages/views/onboarding/components/step-header.tsx — dot row + "Step N of M" counter; three dot states (done/current/pending); accessible progressbar semantics - onboarding-flow.tsx — non-welcome steps now render under a shared `<div flex flex-col gap-8>` wrapper with StepHeader on top. Maps the local `complete` render step to the store's `first_issue` until Step 5 lands (one-line function, self-deleting). - step-welcome.tsx — keeps its own min-h-[60vh] + justify-center so the short intro still feels centered once the shell drops my-auto - apps/web + apps/desktop shells — removed `my-auto`. Every non-welcome step now anchors to the same top position, so only the content below the header changes during transitions. Welcome's own internal centering handles its "short content, no header" case. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): add web Step 3 platform fork (Desktop / CLI / waitlist) Web users now see a three-way choice at the runtime step instead of being dropped directly into CLI install instructions: - Primary CTA: Download Multica Desktop (bundled runtime) - Alternate: install the CLI (reveals existing StepRuntimeConnect) - Alternate: join the cloud waitlist (captures email, completes onboarding early with cloud_waitlist_email set) Desktop unchanged — its platform shell doesn't pass cliInstructions, so OnboardingFlow routes it straight to StepRuntimeConnect for the bundled-daemon auto-connect path. Rename step-runtime.tsx → step-runtime-connect.tsx to reflect its new single responsibility (connect UI only; platform choice lives in StepPlatformFork). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): capture optional use-case on cloud waitlist Adds a textarea to the waitlist form asking what the user wants to use Multica for. Optional (submit still works with email alone) but surfaces a clear prompt + placeholder example so most users will fill it in. Stored as cloud_waitlist_description alongside the email. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(onboarding): make !hasOnboarded a first-class gate on both platforms Triggering condition was wrong on both sides. Web's dashboard-guard only checked hasOnboarded when the URL slug failed to resolve; desktop's App.tsx effect returned early when wsCount > 0 before even looking at hasOnboarded. Users with existing workspaces never got routed into onboarding regardless of their flag state. Also wire store.complete() into the happy-path finish — previously only the waitlist branch wrote onboarded_at, so every normal completion left the flag false and (now that triggers work) would loop users back into onboarding on refresh. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): Step 5 auto-bootstrap — welcome issue + Getting Started project After agent creation, the flow transitions to a loader screen that runs the bootstrap in the background: - Creates a welcome issue with a Q3-driven prompt, assigned to the new agent (so it starts working immediately) - Creates a "Getting Started" project with tutorial sub-issues filtered by Q1/Q2/Q3 - Stores first_issue_id + onboarding_project_id via store.complete() - Navigates the user straight into the welcome issue detail page, where they see the agent already responding Degraded path: if welcome issue fails, shows error with Retry / Continue anyway. If project or sub-issues fail, logs and proceeds with just the welcome issue — the aha moment still happens. No-agent paths (runtime skip, agent skip) short-circuit to onComplete without bootstrap. Local flow step union now aligns with the store enum; removed the mapLocalToStoreStep bridge and deleted the old step-complete.tsx placeholder. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(onboarding): converge all no-agent paths to a single bootstrap step Before: skip-runtime, skip-agent, and waitlist each finished onboarding independently, bypassing Step 5 entirely. Users without an agent landed in an empty workspace with no tutorial project — the "self-serve" case had no bootstrap at all. Now: all three paths converge on the first_issue step with agent=null. Bootstrap branches on agent presence: - agent ✓ → welcome issue (assigned to agent) + project + agent-guided sub-issues ("watch your agent do X"). Lands on the welcome issue. - agent ✗ → project only + self-serve sub-issues ("try X yourself" — configure runtime, create agent, write first issue, etc.). Lands on the workspace issues list with the Getting Started project in the sidebar. Both web and desktop shells already handle firstIssueId=undefined → fall back to /<slug>/issues, so no shell-side change was needed. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): pin starter project + assign sub-issues to the user Bootstrap now also: - Pins the Getting Started project so users see it in the sidebar immediately (both paths) - Pins the welcome issue too (path A only) so the first conversation with the agent stays one click away - Assigns every sub-issue to the current user (via their workspace member record). Only the welcome issue stays assigned to the agent — that's the aha-moment hand-off; everything else is for the user to work through Pin calls are fire-and-forget (failure logged but non-blocking). Member lookup is defensive — if listMembers fails or the user isn't found, sub-issues gracefully fall back to unassigned rather than breaking the bootstrap. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(onboarding): remove cloud waitlist option Cloud runtime is not on the immediate roadmap and there's no backend table to persist emails. Keeping the UI around would silently drop user submissions — small trust leak. Revisit once cloud product lands alongside a proper waitlist table + notification pipeline. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): persist onboarded_at end-to-end Phase 1 of bringing onboarding from dev stub to production. A single persisted column drives every trigger — no separate user_onboarding table yet (that's a later phase for questionnaire persistence, cloud waitlist, analytics). Backend - Migration 050: ALTER TABLE "user" ADD COLUMN onboarded_at TIMESTAMPTZ (no backfill — existing users see onboarding next login, Skip affordance lands later) - sqlc: MarkUserOnboarded with COALESCE for idempotency - UserResponse DTO + userToResponse now emit onboarded_at via existing util.TimestampToPtr helper — single edit covers GetMe, VerifyCode, GoogleLogin, LoginWithToken - New handler POST /api/me/onboarding/complete - Route registered in the authenticated user-scoped group Frontend - User type gets onboarded_at: string | null - api.markOnboardingComplete() - Auth store adds refreshMe() — lightweight getMe + setUser, complements existing initialize() - useHasOnboarded switches source from onboarding-store (dev stub) to auth-store (user.onboarded_at). Every call site — dashboard guard, desktop App.tsx, invite page fallback, realtime workspace-loss handler, settings leave/delete — picks up the real signal without any direct change - onboarding-store.complete() now hits the server: POST + refreshMe before local state update, so the next router effect sees the non-null timestamp and won't bounce the user back Triggers + route guards - StepWorkspace drops the Skip button — every onboarding user must create their own workspace even if invited into one - /onboarding page redirects already-onboarded users away (guards against manual URL access) - login page + auth callback: onboarding wins over ?next= for unonboarded users; invite links are revisitable after onboarding Tests - apps/web callback tests updated: mocks now return User objects so onboarded_at is readable; new "onboarded user honors next" scenario added, "unonboarded ignores next" scenario kept - test/helpers mockUser gets onboarded_at field - questionnaire already-existing strict-required tests bundled in from a prior uncommitted change Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(onboarding): review findings — dead state, error recovery, cache races From independent review of the prior onboarded_at commit. - Remove the dead OnboardingState.onboarded_at field, its INITIAL_STATE entry, and its write in store.complete(). useHasOnboarded now reads auth-store exclusively; leaving a parallel field here violates the "don't duplicate server data in Zustand" rule and risks drifting into a second source of truth. - Wrap handleBootstrapDone/handleBootstrapSkip in try/catch with toast recovery. complete() is idempotent server-side (COALESCE), so a retry after a failed POST/refreshMe is free — letting the error bubble into the React error boundary trapped the user with no way forward. - RedirectIfAuthenticated: swap `!list` for `isFetched`-gated check, matching the pattern added on the /onboarding page. Same one-tick race where a stale cache [] could fire a premature replace before the fresh list settles. - (Self-review fixups picked up along the way) /onboarding page now waits for workspacesFetched before redirecting already-onboarded users, and login handleSuccess reads useAuthStore.getState() so the hasOnboarded value is fresh after setUser (the closure captured a stale pre-login value otherwise). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(onboarding): shrink store surface + firm up flow invariants Post-review cleanup. End-to-end flow is already complete (user.onboarded_at is the single source of truth); these are quality-of-life fixes on top. Store surface - Drop six dead fields from OnboardingState (workspace_id, runtime_id, agent_id, first_issue_id, onboarding_project_id, platform_preference) and the PlatformPreference type. None had readers — they were stub placeholders for a future user_onboarding table that isn't coming this phase. CLAUDE.md "don't design for hypothetical future". - store.complete() signature simplifies to () — no more patch arg, since the only patch fields were the ones just deleted. Welcome as a first-class step - Add "welcome" to OnboardingStep enum and make it INITIAL_STATE's current_step. Removes the pristine-heuristic "did user see welcome?" check, which could misfire on remount. - pickInitialStep() collapses to `state.current_step ?? "welcome"`. - ONBOARDING_STEP_ORDER stays unchanged (welcome isn't a progress point). advance() chain - Every transition handler now persists the new current_step to the store (handleWorkspaceCreated, handleRuntimeNext, handleAgentCreated, handleAgentSkip). Refresh lands on the right step instead of jumping back to Step 2. Invariants - OnboardingFlow throws on null user instead of spreading defensive `?? ""` and `if (userId)` that silently degraded to unassigned sub-issues. Shell guards already ensure user is present. - Desktop WindowOverlay's onComplete gains a paths.root() fallback when workspace is undefined — matches web's symmetry. docs/product-overview.md: committed from untracked. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): persist questionnaire + current_step; resume + Back End-to-end questionnaire persistence + resume capability. User answers are now server-side (analytics-ready); refreshing or revisiting lands on the furthest reached step with previous answers pre-filled; a Back button on each step lets users edit earlier answers without losing progress. Backend - Migration 051: ALTER TABLE "user" ADD onboarding_current_step TEXT, onboarding_questionnaire JSONB NOT NULL DEFAULT '{}'::jsonb - sqlc: new PatchUserOnboarding with sqlc.narg for optional fields (COALESCE preserves unspecified columns). MarkUserOnboarded also clears current_step — once complete, the step pointer has no meaning - Handler PATCH /api/me/onboarding accepting partial {current_step, questionnaire}. Questionnaire passthrough via json.RawMessage, no server-side validation of inner shape (keeps schema evolution free) - UserResponse DTO emits both new fields; userToResponse coalesces JSONB to '{}' defensively Frontend - User type gains onboarding_current_step + onboarding_questionnaire - api.patchOnboarding(payload) - Delete Zustand onboarding store — replaced with plain async advanceOnboarding() / completeOnboarding() that call the API and sync auth store. Source of truth is the user object, no client-side shadow state that could drift - pickInitialStep reads user.onboarding_current_step; StepQuestionnaire initial pre-fills from user.onboarding_questionnaire - Monotonic furthestStepRef: Back edits don't regress server-side progress, and re-submit returns the user to where they were - Back buttons on Steps 2/3/4. Back is local-only — just changes the rendered step, no PATCH - Loading indicator on Welcome + Questionnaire submit buttons while PATCH is in flight - CreateWorkspaceForm.onSuccess accepts Promise<void> so the flow can await advance() from its onCreated handler Test mocks (helpers + callback test) updated with new User fields. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(onboarding): resume to Step 3+ needs workspace/runtime fallback Self-review caught: resume lands the user on their saved step, but React state (workspace, runtime, agent) is empty on fresh mount. The render conditions gate on those — without fallbacks the page stays blank. - workspaceListOptions() query fills runtimeWorkspace from cache when stepping past Step 2. Only one workspace exists during onboarding (StepWorkspace always creates one), so [0] is unambiguous. - StepWorkspace accepts an `existing` prop. On resume / Back to Step 2 with a pre-existing workspace, render a "Continue with <name>" confirmation instead of the create form, which would otherwise hit a slug conflict the moment the user clicks Create. - runtimeListOptions(wsId, "me") similarly seeds Step 4's runtime — prefer first online, fall back to first. Step 5 resume path unchanged: if `agent` React state is null on re-entry, bootstrap runs the self-serve branch. Not ideal (user may have actually created an agent), but bootstrap's list-check approach (future work) will handle orphan detection symmetrically. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(onboarding): delete all skip/resume jump logic Flow always starts from Welcome. Questionnaire answers still pre-fill from user.onboarding_questionnaire. current_step is still PATCHed for future analytics but no UI code reads it for navigation. Removed from onboarding-flow.tsx: - pickInitialStep + isOnboardingStep (no server-driven entry point) - furthestStepRef + resolveNextStep (no edit-vs-first-pass branching) - runtimes useQuery + stepRuntime fallback (user walks through Step 3 linearly, so runtime React state is always populated by Step 4) - workspace resume fallback in runtimeWorkspace (same reasoning) Kept: - advanceOnboarding({ current_step, questionnaire? }) — server persistence, analytics-ready - StepQuestionnaire's initial prop from stored answers - workspaces useQuery (gated to step === "workspace" only) for existing-workspace detection on Step 2 to prevent slug conflicts when a previous onboarding was abandoned - Back buttons + handleBack (local-only navigation) - Error recovery on completeOnboarding via try/catch + toast Every transition handler is now a straight advance + setStep line. Users who close mid-flow and return walk the full flow from Welcome again — slight extra clicks, but each step shows meaningful confirm UI (existing workspace, connected runtimes, etc.) so it doesn't feel like repeated work. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(onboarding): grandfather existing users in the onboarded_at migration Folded the backfill into 050 itself (branch has not shipped to prod, so editing the migration in place is clean). Without this, once this branch deploys, every pre-existing user would be walled off into onboarding on their next login — a real production incident. Uses created_at rather than NOW() so analytics like "signup → onboarded interval" read correctly for pre-launch users. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(onboarding): Step 1 questionnaire — two-column editorial layout Matches the onboarding(3) design spec: full-bleed two-column on lg+ (main + "Why we ask" side rail), collapses to single column below. - StepQuestionnaire rewritten with: - Mono 01/02/03 markers per question - Serif question headings (22px) - Editorial serif title ("Three answers. We'll handle the rest.") - Right-side rationale panel explaining what each answer unlocks - Sticky footer with hint + Continue CTA - Embeds StepHeader on the left column so it escapes the flow's narrow max-w-xl wrapper, same pattern Welcome uses - OptionCard redesigned: radio-dot marker + inset ring on select, matches design's .opt pattern - OtherOptionCard: text input appears below the row (not inside the card) with bottom-border-only styling, aligned under the label - onboarding-flow: questionnaire now early-returns full-bleed, joining Welcome as a hero-layout step Placeholder copy updated to match design examples; tests adjusted. * fix(onboarding): questionnaire uses 3-region app-shell layout Previous version had everything in a single scroll container with a sticky footer. As the user scrolled into the questions, the Back button and StepHeader progress indicator scrolled out of view, and sticky-bottom had edge cases with width-constrained flex nesting. Classic 3-region shell now: - Fixed header row: Back button (left) + StepHeader progress indicator — persistently visible regardless of scroll position - Scrollable middle: eyebrow / serif title / lede / 3 question blocks. Uses `flex-1 overflow-y-auto min-h-0` — the min-h-0 is the critical bit that lets a flex-1 child shrink below content height inside a flex column - Fixed footer row: hint (hidden < sm) + Continue CTA — always reachable, never scrolled off Right "Why we ask" panel is now an independent grid column with its own overflow, so the two columns scroll independently instead of the whole page having one shared scrollbar. Side panel width reduced 520 → 480 to give the question column more room on 1280/1366 screens where 1fr_520 left ~760px for content; 1fr_480 gives ~800-900px which comfortably fits the 620px max-w content column plus breathing room. * fix(onboarding): questionnaire needs DragStrip like every full-window view Traffic lights were overlapping the StepHeader progress dots because Step 1 escaped onboarding-flow's non-welcome wrapper (which renders <DragStrip />) without rendering its own. The codebase convention per packages/views/platform/drag-strip.tsx is: every full-window view places a DragStrip as the first flex child of each visible column. Adds DragStrip at the top of both the left (shell) and right ("Why we ask") columns, matching step-welcome.tsx which already did this. Traffic lights now land in the 48px transparent strip with no content collision; dragging from any top edge moves the window on Electron; border-l between columns runs edge-to-edge. Also made the right column's scroll container use `min-h-0 flex-1 overflow-y-auto` so its internal scroll activates independently of the left column. (Separately investigated: useImmersiveMode is no longer called anywhere in production code — the codebase has fully committed to the DragStrip pattern. No action needed on the hook itself.) * style(onboarding): drop top/bottom borders on questionnaire shell * style(onboarding): use chat-style scroll fade mask instead of border The questionnaire's scroll area now fades softly at top/bottom edges via `useScrollFade` (already used by chat-message-list.tsx) — the same mask-image linear-gradient pattern that fades content under the header/footer based on scroll position: - At top: only bottom fades (hint: more content below) - At bottom: only top fades (hint: content above) - In middle: both fade - Fits entirely: no mask This replaces the removed border-b/border-t on the header/footer with a softer, more editorial visual separation while giving an actual scroll-position affordance the border can't. * feat(onboarding): show "n of 3 answered" progress next to Continue Gives the user a glance-able progress signal as they fill the questionnaire. Static text, no extra UI primitives, no dynamic state variants — just `{n} of 3 answered` updating in place, left of the Continue button. Replaces the static "Your answers shape the next screens..." hint, which was always there regardless of progress and added noise. Same canContinue gate as before (all 3 answered), just derived from the new per-question check so we don't compute validity twice. * style(onboarding): drop redundant lede under questionnaire title The title already conveys the "we'll handle the rest for you" promise — the lede just rephrased it at length. Removed; bumped the question-list top margin (mt-8 → mt-10) to keep breathing room. * feat(onboarding): land redesigned flow + post-landing starter content opt-in This commit bundles the final onboarding-redesign work that sat in the working tree with today's architectural reshape of how starter content is handled. Splitting across sqlc-regenerated files would be fragile, so it ships as one logical unit — "onboarding is ready for production". Flow redesign (Steps 1–5) ------------------------- - Editorial two-column shells on Steps 1/2/3/4 (DragStrip + hero column + aside panel) — Welcome, Questionnaire, Workspace, Runtime, Agent - Web-only Step 3 fork (Download desktop / Install CLI / Cloud waitlist) lives alongside desktop's direct runtime picker; cloud path is interest-capture only, doesn't advance the flow - DragStrip extracted to packages/views/platform as a cross-platform component — 48px transparent drag row, no-op on web - recommend-template.ts + test: Q1–Q3 → AgentTemplate mapping Cloud waitlist -------------- - Migration 052: cloud_waitlist_email VARCHAR(254) + cloud_waitlist_reason TEXT - Handler: net/mail.ParseAddress + length bounds + reason trim - Frontend: CloudWaitlistExpand component + api.joinCloudWaitlist Drop persisted onboarding_current_step -------------------------------------- - The interim implementation persisted the user's furthest-reached step; the final design starts every entry at Welcome, so the column is dead - Migration 051 no longer adds it; migration 053 drops it IF EXISTS on any environment that ran the interim 051 — schema converges cleanly - UserResponse / User type / patchOnboarding signature all drop the field Post-landing starter content (new architecture) ----------------------------------------------- Why: the old design ran bootstrap inside Step 5 (welcome issue + Getting Started project + sub-issues, all in one try block). That had three defects — (1) non-idempotent: Retry after partial failure created duplicates; (2) sub-issue assignee raced listMembers → showed as "Unknown"; (3) skipped users (paths A/C/D) never got any starter content. All three are structural, not patchable. New design: onboarding ends at completeOnboarding() as before (gate is unchanged for useDashboardGuard). The 4 completion paths (Welcome skip / full flow / Runtime skip / Error recover) all just call completeOnboarding() and navigate to workspace. On landing, a StarterContentPrompt dialog renders exactly once per user (starter_content_state == null) with Import / No thanks. The dialog is mandatory — no X, no ESC, no outside-click — so state always ends in a terminal value. - Migration 054: starter_content_state TEXT, backfill 'skipped_legacy' for pre-feature onboarded users so they're never prompted - Server POST /api/me/starter-content/import: transactional claim (NULL → 'imported') + bulk create project + optional welcome issue + sub-issues + pins, all in one tx. 409 Conflict on second call - Server POST /api/me/starter-content/dismiss: transactional NULL → 'dismissed' - Import decides agent-guided vs self-serve by inspecting the workspace's agent list at dialog time — fixes path A (Welcome skip + existing agent) which was previously excluded from starter content - starter-content-templates.ts replaces bootstrap.ts: pure template builders, no API calls. Copy is reviewed as UI; server owns atomicity - StepFirstIssue is now just completeOnboarding() + navigate; error surface collapses to a Retry button (no more "Continue anyway" branch) - OnboardingCelebration + just-completed.ts removed (replaced by StarterContentPrompt which reads server state, not sessionStorage) Handler hardening ----------------- - PatchOnboarding: MaxBytesReader 16KB so the JSONB column can't be weaponized as bulk storage (every /api/me read returns the payload) - JoinCloudWaitlist: net/mail format check + explicit 254-char cap - ImportStarterContent: MaxBytesReader 64KB (templates are markdown-heavy but still bounded); welcome issue's agent_id verified in-workspace Tests ----- - Existing onboarding_test.go (waitlist) passes - step-platform-fork.test.tsx + recommend-template.test.ts (new) - apps/web test helpers updated for User.starter_content_state Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(onboarding): resolve Unknown assignee/creator + tighten prompt copy Two surface issues on the post-landing starter content dialog: 1. Unknown assignee & Created by ------------------------------- ImportStarterContent stored `member.id` (the membership row UUID) in `assignee_id` and `creator_id` for sub-issues. That mismatched the rest of the codebase — AssigneePicker and resolveActor in issue.go both store `user_id` for type="member", and `useActorName.getMemberName` looks members up by `user_id`. The mismatch meant the lookup never matched any member and fell through to the "Unknown" fallback. Fix: use `parseUUID(userID)` for both fields. The existing membership check stays for the 403 signal; we just no longer need the returned `member.ID`. 2. Dialog copy too long, button labels unclear ---------------------------------------------- Old copy was 3–4 paragraphs of instruction; users need to read less than that to make a binary choice. Buttons "Import starter tasks" and "No thanks" also didn't make it clear what "No thanks" actually does — it starts a blank workspace, so say so. New: - Title: "Welcome — add starter tasks?" - Body: one sentence describing the seeded content - Left button: "Start blank workspace" - Right button: "Add starter tasks" Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(onboarding): server decides starter content branch Problem: the old ImportStarterContent gated the agent-guided vs self-serve branch on a client-supplied `welcome_issue.agent_id` or null `welcome_issue`. The client made that decision by reading its React Query cache of the workspace's agent list — any timing quirk (cache not populated, stale, race with WS event) could lie to the server, and there was no way for the server to disagree. Users with an agent in the DB could still end up on the self-serve branch. Fix: the server is now authoritative. The client always sends both template arrays (agent_guided_sub_issues, self_serve_sub_issues) and a welcome_issue_template (title + description + priority, NO agent_id). Inside the import transaction the server runs ListAgents on the workspace — if there's at least one agent, it picks agents[0] (same ordering the client used: created_at ASC), uses agent_guided_sub_issues, and creates the welcome issue assigned to that agent. Otherwise it uses self_serve_sub_issues and skips the welcome issue. Side effect: the Unknown assignee/creator bug is structurally gone — no client-supplied id flows into assignee_id/creator_id for type= "member". The server uses actorID = parseUUID(userID) everywhere, matching resolveActor in issue.go. Client surface also simplifies: StarterContentPrompt drops useQuery(agentListOptions), the hasAgent check, the agentsFetched button gate, and the branch-specific copy. Dialog description is a single generic line ("If you already have an agent, we'll also seed a welcome issue it replies to right away"). buildImportPayload no longer takes an agentId parameter — one unconditional return shape. Payload grows ~15 KB (both sub-issue arrays always present); still well under the 64 KB MaxBytesReader cap. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(onboarding): clarify runtime prerequisite, revert dialog agent list Step 3 runtime (desktop step-runtime-connect.tsx) — scanning and empty subtitles now name the local AI coding tools Multica drives (Claude Code, Codex, Cursor, and others), so users understand a runtime alone isn't enough: they also need one of those tools installed on the machine. Uses "and others" rather than a closed list so we don't lock the copy to exactly three integrations. StarterContentPrompt dialog — reverted the short-lived "try Coding, Planning, Writing agents and more" rewrite. That was a misread of feedback meant for the Step 3 prerequisite, not the dialog. The dialog's current single-sentence "how agents, issues, and context work in Multica" is enough. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
|
Bohan Jiang
|
c6d54e8ce5 |
fix(ui): replace smiley with check mark in quick emoji list (#1446)
Swap the 4th quick reply emoji 😄 for ✅ so approval-style acknowledgements are one tap away. |
||
|
Bohan Jiang
|
6366e2f4ba |
fix(inbox): don't archive after deleting an issue (#1444)
* fix(inbox): don't archive after deleting an issue Deleting an issue from the Inbox page was calling the archive API on the inbox item right after deleteIssue succeeded. Because the inbox_item row has ON DELETE CASCADE on issue_id, it was already gone by then and the archive call 404'd with "inbox item not found", surfacing a "Failed to archive" toast. Drop the redundant archive call and invalidate the inbox cache through the issue:deleted WS handler so every tab stays in sync without an extra round trip. * fix(inbox): keep stale selection on /inbox instead of the deleted issue When another tab deletes the selected inbox issue, onInboxIssueDeleted prunes the cache and `selected` becomes null. The existing fallback then redirected to the issue detail page — which is also gone, so the user landed on a "This issue does not exist..." screen instead of back in the inbox list. Track the last key that actually resolved against the inbox list. If it used to be in the list and just disappeared, clear the selection and stay on /inbox. Only shared links that were never in the user's inbox continue to fall back to the issue detail page. Also add ws-updaters tests covering onInboxIssueDeleted and onInboxIssueStatusChanged. |
||
|
Bohan Jiang
|
642844c736 |
feat(issues): paginate every status column, not just done (#1422)
* feat(issues): paginate every status column, not just done
Previously the workspace issues list fetched all non-done/cancelled
issues in a single unbounded `open_only=true` request and only
paginated the done column. In workspaces with many open issues this
ballooned the initial payload and skipped pagination entirely.
Restructure the issue list cache into per-status buckets
(`{ byStatus: { [status]: { issues, total } } }`) fetched in parallel,
generalize `useLoadMoreDoneIssues` into `useLoadMoreByStatus(status,
myIssuesOpts?)`, and render an infinite-scroll sentinel inside every
accordion group and kanban column. Sort and filter stay client-side,
matching the done column's existing behavior.
Backend `ListIssues` already supports per-status pagination, so no
API changes are required.
* fix(issues): handle project / hidden-column / lookup regressions from paginated list cache
After bucketing the issue list cache by status, three consumers that
treated `issueListOptions()` as a complete local index broke:
- `project-detail.tsx` filtered the workspace list by `project_id`
client-side, so projects whose issues sat past the first 50-per-status
page rendered empty. Switch to `myIssueListOptions(wsId,
'project:<id>', { project_id })` so the server returns only this
project's issues; add `project_id` to `ListIssuesParams` /
`MyIssuesFilter` / api client.
- `board-view.tsx` HiddenColumnsPanel read counts from the in-memory
`issues` array — a paginated fragment. Pass `myIssuesOpts` through to
a per-row subcomponent that reads the real per-status total from the
cache.
- `tasks-tab.tsx` and `search-command.tsx` used the list as a global
lookup for task titles / Recent items / current-issue chrome. Switch
both to per-id `issueDetailOptions` via `useQueries` so they're
independent of which page the issue lands on.
Drop the now-redundant `doneTotal` override prop on BoardView/ListView
and the `allIssues` prop on BoardView (only HiddenColumnsPanel consumed
it).
Tests updated: tasks-tab now mocks `api.getIssue`; search-command mocks
`issueDetailOptions` + `useQueries`; project-issue-metrics drops the
`doneColumnCount` assertion.
|
||
|
Bohan Jiang
|
d5071abb75 |
fix(inbox): stop remounting IssueDetail on new comment/reaction (MUL-1199) (#1439)
The inbox detail panel keyed `<IssueDetail>` by `selected.id` (inbox-item id). `deduplicateInboxItems` picks the most recent inbox notification per issue, so every new `comment:created` / `reaction:added` event for the currently open issue produced a fresh inbox item with a new id — flipping the React key and forcing a full unmount/remount of `IssueDetail`. That wiped the comment composer draft, dropped focus, and reset scroll. Key on `selected.issue_id` instead: stable for the life of an open issue (so input + scroll survive incoming events) and still changes when the user picks a different issue (so state resets between issues, as before). |
||
|
Bohan Jiang
|
9481350ef0 |
fix(analytics): disable posthog-js default autocapture and recording (#1433)
posthog-js ships with autocapture, heatmaps, dead-click detection, session recording, exception capture, and surveys all on by default. Staging verification showed the Activity view flooded with "clicked button" / "clicked span with text \"…\"" events — they leak user-typed content into PostHog, burn the billed event budget, and dilute the explicit funnel. Our product analytics surface is narrow and intentional (see docs/analytics.md): only the events we emit server-side plus one manual $pageview belong. Opt all the auto surfaces off at init time so the Activity view reflects the funnel. |