71 Commits

Author	SHA1	Message	Date
Jiayuan Zhang	4d6b5ad06f	fix(squad): wake leader when dual-role agent posts as worker (MUL-2218) (#2626) ... * fix(squad): wake leader when dual-role agent posts as worker (MUL-2218) The squad-leader self-trigger guard skipped a comment whenever the author equalled the squad's leader id, regardless of the role the agent was acting in. For an agent that holds both leader and worker roles in the same squad, this meant the leader role never reacted to its own worker output and the issue stalled. Tag each enqueued task with is_leader_task and consult the agent's most recent task on the issue from both self-trigger guards (comment path + @squad mention path) — skip only when that task was itself a leader task. Co-authored-by: multica-agent <github@multica.ai> * fix(squad): inherit is_leader_task on retry task clone (MUL-2218) CreateRetryTask cloned a parent task into a fresh queued attempt but omitted is_leader_task from the column list, so the child silently fell back to the column default (false). For a leader task that hit auto-retry through MaybeRetryFailedTask, the retried task posed as a worker task — the self-trigger guard then no longer recognised the leader's own comments, re-opening the very loop MUL-2218 closes. Inherit p.is_leader_task in the clone and add a query-level test that covers both leader and worker retries. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-14 15:23:36 +02:00
LinYushen	29082f7cfe	feat: implement Squad feature MVP (#2505) ... * feat: implement Squad feature MVP - Add migration 084_squad: squad, squad_member, squad_activity_log tables - Extend issue.assignee_type to support 'squad' - Add sqlc queries for squad CRUD, member management, activity logs - Add Go handler with full Squad API (CRUD, members, activity log) - Register routes: /api/squads/*, /api/issues/{id}/squad-activity, /api/squad-activity - Add Squad trigger logic: - Assign Squad immediately triggers leader - Every external comment on squad-assigned issue triggers leader - Anti-loop: squad members' comments don't trigger leader - Dedup: skip if leader already has pending task - Add squad activity log API (方案 B) for leader no-op recording - Add frontend TypeScript types (Squad, SquadMember, SquadActivityLog) - Add protocol events: squad:created, squad:updated, squad:deleted Co-authored-by: multica-agent <github@multica.ai> * fix: address PR review blocking issues 1. validateAssigneePair now accepts 'squad' assignee_type 2. All squad endpoints validate workspace ownership via GetSquadInWorkspace 3. CreateSquadActivityLog restricted to squad leader agent only 4. AddSquadMember validates member exists in workspace 5. UpdateSquad auto-adds new leader to squad members 6. DeleteSquad transfers assigned issues to leader before deletion 7. IssueAssigneeType includes 'squad' in frontend types Co-authored-by: multica-agent <github@multica.ai> * feat: soft-delete squads via archive instead of hard delete - Add migration 085: archived_at + archived_by columns on squad table - ListSquads now excludes archived squads (ListAllSquads for admin) - DeleteSquad → ArchiveSquad (sets archived_at, preserves all records) - Transfer squad-assigned issues to leader before archiving - SquadResponse includes archived_at/archived_by fields - Frontend Squad type updated with nullable archived fields Co-authored-by: multica-agent <github@multica.ai> * feat: re-add Squads frontend entry (sidebar nav + pages) Re-applies the frontend squad entry that was lost during a merge: - Sidebar nav: Squads item with Users icon - Paths: squads() and squadDetail() in workspace paths - Routes: /squads and /squads/[id] pages - Views: SquadsPage (list) and SquadDetailPage - i18n: en 'Squads' / zh '小队' - Reserved slug: 'squads' Co-authored-by: multica-agent <github@multica.ai> * fix: fix SquadsPage rendering - use PageHeader children pattern PageHeader takes children, not title/actions props. The incorrect usage caused a React rendering error. Now matches the pattern used by autopilots and agents pages. Co-authored-by: multica-agent <github@multica.ai> * fix(squads): add API client methods and package export for squads pages * feat: complete Squad frontend - create dialog, member management, API methods - Add CreateSquadModal with name/description/leader selection - Register 'create-squad' in modal registry - Wire 'New Squad' button to open the modal - Add full API client methods: createSquad, updateSquad, deleteSquad, addSquadMember, removeSquadMember - Rewrite SquadDetailPage with: - Member list showing resolved names - Add/remove member UI - Archive squad button - Back navigation to squads list Co-authored-by: multica-agent <github@multica.ai> * feat: improve Squad UI - match create agent dialog style - CreateSquadModal: proper Dialog with Header/Description/Footer, agent picker with avatars, textarea for description - SquadDetailPage: centered max-w-2xl layout, ActorAvatar for members, Crown badge for leader, textarea for member description, improved spacing and visual hierarchy - Renamed 'role' field label to 'Description' in add member form (describes the member's responsibilities in the squad) Co-authored-by: multica-agent <github@multica.ai> * feat(squad): add avatar, instructions; drop unique-name constraint - 086: add squad.avatar_url - 087: drop unique constraint on squad.name (squads with the same name are legitimate across teams; uniqueness was an accidental product constraint) - 088: add squad.instructions (text, default '') - UpdateSquad now COALESCEs avatar_url + instructions - handler exposes Instructions in SquadResponse and accepts it in UpdateSquad Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * feat(squad): assignable + mention target; trigger leader on assign - assignee picker and @mention suggestion list squads alongside agents and members; renders squad avatar/icon - creating or updating an issue with assignee_type=squad enqueues a task for the squad's current leader (mirrors agent-assignee parking-lot rule: skip backlog only) - workspace queries/hooks expose squads where needed for the pickers - locales updated for new picker copy Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * feat(squad): agent-style detail page with members + instructions tabs - restructure squad detail page to mirror the agent detail page: 320px inspector (creator, leader, created/updated) + tabbed pane (Members | Instructions) with dirty-guard AlertDialog - inline name + avatar editing on the inspector - inline description editor (modal textarea) - members tab: leader + member picker with role descriptions, swap leader, edit member roles, remove - instructions tab: ContentEditor + Save (mirrors agent pattern) - squads list shows the squad avatar/icon - core types + api.updateSquad accept avatar_url + instructions Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * feat(squad): inject leader briefing on claim (protocol + roster + instructions) When a squad's leader agent claims a task on a squad-assigned issue, append a system-level briefing to the agent's Instructions composed of: 1. Squad Operating Protocol — hard-coded rules: leader is a coordinator, dispatch via @mention, stop after dispatching, resume on re-trigger, do not work outside the roster. 2. Squad Roster — leader self-row plus one row per non-archived member with a literal mention markdown string ([@Name](mention:// agent|member/<UUID>)) the leader can paste verbatim. Round-trips through util.ParseMentions, enforced by a contract test. 3. Squad Instructions — the user-defined squad.instructions block, omitted entirely when empty so we do not leave a dangling heading. Non-leader members claiming the same issue receive no briefing. Tests cover: full squad with mixed agent/human members, lone leader, archived agents skipped, empty user instructions, mention round-trip, and the leader/non-leader claim-handler gate. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(squad): tell leader not to restate issue context in dispatch comment After observing leaders padding their delegation comments with full re-summaries of the issue body and prior discussion, make the Operating Protocol explicit: - assignees on Multica already have the full issue (title, description, all comments, attachments) and workspace context; - delegation comments should add only what cannot be inferred (who is picked, why, extra constraints), aim for two or three sentences; - restating context is now an explicit hard rule violation. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * feat(squad): unify leader evaluation into activity_log, add CLI command - Squad member comments now trigger leader (only leader self-excluded) - Replace squad_activity_log with activity_log (action: squad_leader_evaluated) - Add CLI: multica squad activity <issue-id> <outcome> --reason - Add API: POST /api/issues/{id}/squad-evaluated - Update squad operating protocol to require evaluation recording - Remove squad_activity_log table from schema and generated code * feat(cli): add squad list, get, member list commands * fix(squad): address review findings (P1+P2) P1 fixes: - Add 'squads' to reserved_slugs.json (source of truth) - Add 'create-squad' to ModalType union - Remove unused leaderOpen/selectedLeader in create-squad modal - Replace literal JSX strings with i18n selectors (en + zh-Hans) P2 fixes: - Add 'squad' to mention regex (MentionRe) - Fix human member lookup in squad briefing (use GetUser directly) - Add squads routes to desktop app - Add squad:created/updated/deleted to WSEventType + invalidation - Reject archived squads as issue assignees * fix(squad): restore zh-Hans key, publish activity event, invalidate issues on archive - Restore create_project.title in zh-Hans modals.json (dropped by prior edit) - Publish activity:created WS event after squad leader evaluation - Invalidate issue queries on squad:deleted (archive transfers assignees) - Add creator info to squad list cards * fix(squad): realtime sync, rerun support, leader validation - Use workspaceKeys.squads prefix for detail/member queries (realtime invalidation) - Publish squad:updated after add/remove/role-change member mutations - Support rerun for squad-assigned issues (targets leader agent) - Reject assignment to squads whose leader is archived --------- Co-authored-by: multica-agent <github@multica.ai> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>	2026-05-13 18:46:20 +08:00
Bohan Jiang	96695a79c5	feat(dashboard): workspace/project token + run-time dashboard MUL-1882 (#2462) ... * feat(dashboard): workspace/project token + run-time dashboard Add a `/{slug}/dashboard` page showing per-agent token spend and execution time across the whole workspace, with an optional project filter. Backend: - Three new sqlc queries against task_usage + agent_task_queue: daily usage, per-agent usage, per-agent total run-time. All optionally scoped to a project via sqlc.narg('project_id'), reaching project through the issue join. - Handlers under /api/dashboard return the same wire shape the runtime page already consumes (model preserved for client-side cost math). Frontend: - Shared DashboardPage in packages/views/dashboard reusing KpiCard, DailyCostChart, ActorAvatar, and estimateCost from the runtime page so the visual style and pricing math stay in lock-step. - Period selector (7/30/90d), project dropdown, four KPI tiles (cost, tokens, run time, tasks), daily cost chart, and a combined "cost + run time by agent" list. - Routed in both web (app/[slug]/(dashboard)/dashboard) and desktop (memory router); sidebar nav entry added under Workspace group. Co-authored-by: multica-agent <github@multica.ai> * fix(dashboard): drop stale project filter and stop double-counting tasks Two issues caught in PR #2462 review: 1. Project filter held the previous selection's UUID across workspace switches and project deletions: the dropdown gracefully showed "All projects" (because the title lookup missed) while the three dashboard queries kept forwarding the dead UUID, leaving the UI looking like a full-workspace view but populated with empty project-scoped data. Validate the picked UUID against the current projects list before passing it to the queries. 2. The "by agent" table read its task count from the token rollup, which is grouped per (agent, model). A single task that spans two models lands twice and the agent's row reads e.g. "2 tasks" when the real count is 1. Prefer `ListDashboardAgentRunTime`'s per-agent distinct count when available; fall back to the token aggregate only for agents with no terminal run yet (in-flight tasks). Extract the merge into `mergeAgentDashboardRows` so the precedence rules are unit-tested directly. Co-authored-by: multica-agent <github@multica.ai> * test(dashboard): allocate per-workspace issue.number explicitly TestDashboardEndpoints creates two issues in the shared fixture workspace. issue.number defaults to 0 (migration 020), and the table carries UNIQUE (workspace_id, number), so the second insert raced the first on the same default and failed in CI. Allocate MAX(number) + 1 per insert so each row gets a fresh number without stepping on rows other tests left behind in the same workspace. Co-authored-by: multica-agent <github@multica.ai> * feat(dashboard): rollup table + cron-driven aggregation for dashboard Mirror the per-runtime rollup in `task_usage_daily` (migrations 073/077/082) to remove the per-request raw aggregation the dashboard was doing. Migration 084 adds: - `task_usage_dashboard_daily` keyed on (bucket_date, workspace_id, agent_id, project_id, model) — the dimensions the dashboard actually queries, with project_id nullable via UNIQUE NULLS NOT DISTINCT (PG15+) so "no-project" buckets upsert cleanly. - `task_usage_dashboard_rollup_state` watermark table. - `task_usage_dashboard_dirty` invalidation queue. - Triggers on agent_task_queue DELETE, task_usage DELETE, and issue.project_id UPDATE — the cases the updated_at watermark can't see. The project_id trigger re-attributes existing rollup rows when a user moves an issue across projects. - `rollup_task_usage_dashboard_daily_window(from, to)` — idempotent recompute primitive (same shape as 077). - `rollup_task_usage_dashboard_daily()` cron entry — own advisory lock (4244) so it serialises independently of the runtime rollup. - `task_usage_dashboard_rollup_lag_seconds()` health helper. Sqlc queries `ListDashboardUsageDailyRollup` / `ListDashboardUsageByAgentRollup` read from the new table; the handler dispatches between rollup and raw on a separate `UseDailyRollupForDashboard` config flag (`USAGE_DASHBOARD_ROLLUP_ENABLED` env). Same fail-safe default (false → raw) so operators can roll out independently of the per-runtime flag. Bucket date is UTC (the dashboard aggregates across runtimes that may sit in different tzs; there's no single correct local boundary). Adds `cmd/backfill_task_usage_dashboard_daily` mirroring the existing per-runtime backfill — operator runs it once before flipping the flag. Tests: - TestDashboardEndpoints now also exercises the rollup read path (raw vs. rollup, same project-scoped totals). - TestDashboardRollupReattributesOnProjectChange verifies the issue.project_id trigger enqueues both old + new buckets and the next rollup tick zeroes the old project + populates the new one. Co-authored-by: multica-agent <github@multica.ai> * fix(dashboard-rollup): close two invalidation gaps Two leak paths missed by migration 084 review: 1. Issue cascade DELETE — the atq BEFORE DELETE trigger runs AFTER the issue row is gone, so `LEFT JOIN issue` returns NULL project_id and the original-project bucket never gets cleared (issue 077 calls this out for the runtime rollup but didn't need to act on it). Adds an `issue BEFORE DELETE` trigger that enqueues using OLD.project_id while the issue row is still readable. 2. `LinkTaskToIssue` (quick-create task attaching to a real issue post- completion) UPDATEs `agent_task_queue.issue_id` from NULL to a real id. Migration 084 only watched DELETE on atq, so usage already rolled up under the no-project bucket stayed attributed to NULL forever. Extends the atq trigger to fire on UPDATE OF issue_id too, enqueueing both OLD (NULL project) and NEW (linked issue's project). Tests: - TestDashboardRollupClearsOnIssueDelete asserts rollup row drops to zero after issue delete + rollup tick. - TestDashboardRollupReattributesOnLinkTaskToIssue verifies tokens move from the NULL bucket to the project bucket after the UPDATE. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-13 12:51:16 +08:00
Bohan Jiang	caeb146bac	feat(github): GitHub App integration for PR ↔ issue linking (#1817) ... * feat(github): GitHub App backend for PR ↔ issue linking - New tables: github_installation (workspace ↔ App install), github_pull_request (mirrored PR state), issue_pull_request (M:N link). - Webhook handler verifies HMAC-SHA256, upserts PR rows, parses issue identifiers from PR title/body/branch and auto-links them. Merging a linked PR moves the issue to done. - Connect/setup endpoints power the zero-config "Connect GitHub" install flow; state token is HMAC-signed so the setup callback can recover the workspace. - Workspace-scoped admin routes for listing/disconnecting installations, plus a per-issue `pull-requests` list endpoint. Co-authored-by: multica-agent <github@multica.ai> * feat(github): UI for connecting GitHub and viewing linked PRs - Settings → Integrations: new tab with Connect GitHub / installations list / disconnect, gated on the deployment having the App configured. - Issue detail sidebar: Pull requests section showing linked PR title, repo, state (open/draft/merged/closed), and author, with deep link to GitHub. - Real-time refresh: github_installation:* and pull_request:* events invalidate the matching TanStack Query caches. Co-authored-by: multica-agent <github@multica.ai> * fix(github): address review — null actor, role gating, configured guard, scoped uninstall broadcast - listeners: use optionalUUID(e.ActorID) so the system actor on the github-driven issue:updated event no longer panics activity / notification listeners; merged-PR → issue done now produces a status_changed activity and inbox entry. - IntegrationsTab: gate the admin-only installations query on canManage so members no longer hit /github/installations 403; the configured/not-configured copy is also scoped to admins. - backend: introduce isGitHubConfigured() requiring both GITHUB_APP_SLUG and GITHUB_WEBHOOK_SECRET, and surface that single flag from list-installations + connect endpoints so the frontend Connect button stays disabled until both are set. - DeleteGitHubInstallationByInstallationID now RETURNs workspace_id; webhook handler publishes github_installation:deleted scoped to the right workspace so already-open Settings tabs invalidate in real time. ErrNoRows on a re-fired delete short-circuits cleanly. - tests: focused webhook integration coverage (auto-link + merge → done, cancelled preservation, uninstall returns workspace). Co-authored-by: multica-agent <github@multica.ai> * fix(github): i18n the new GitHub UI strings to satisfy lint CI flagged every literal string in the Integrations tab, the Pull requests sidebar section, and the per-PR row label. Move them through useT() and add the matching `integrations.*` block to settings.json (en / zh-Hans) plus `detail.section_pull_requests` / `detail.pull_request_state_*` / loading + empty copy under `issues.json`. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-12 13:49:03 +08:00
Naiyuan Qing	86aa5199fc	feat(chat): support attachments & images in chat input (#2445) ... * docs(plans): chat attachment & image support implementation plan Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> * feat(db): add chat_session_id/chat_message_id to attachment Co-authored-by: multica-agent <github@multica.ai> * feat(db): sqlc — chat_session_id on CreateAttachment + LinkAttachmentsToChatMessage Co-authored-by: multica-agent <github@multica.ai> * feat(file): upload-file accepts chat_session_id form field Co-authored-by: multica-agent <github@multica.ai> * feat(chat): SendChatMessage links uploaded attachments to the new message Co-authored-by: multica-agent <github@multica.ai> * feat(api): uploadFile accepts chatSessionId; sendChatMessage accepts attachmentIds Co-authored-by: multica-agent <github@multica.ai> * feat(core): useFileUpload supports chatSessionId context Co-authored-by: multica-agent <github@multica.ai> * feat(chat): support paste/drag/upload attachments in chat input Co-authored-by: multica-agent <github@multica.ai> * test(e2e): chat input attachment upload + send round-trip Co-authored-by: multica-agent <github@multica.ai> * chore(chat): keep lazy-created session title empty so untitled fallback localizes Co-authored-by: multica-agent <github@multica.ai> * fix(chat): address review — dedupe ensureSession + parse upload response - chat-window: cache in-flight createSession promise in a ref so a file drop followed by a quick send no longer spawns two sessions (and orphans the attachment on the losing one). - Attachment type + EMPTY_ATTACHMENT + AttachmentResponseSchema: include the new chat_session_id / chat_message_id fields the server now returns. - uploadFile: route the response through parseWithFallback so a malformed body returns EMPTY_ATTACHMENT instead of an undefined-keyed Attachment, matching the API boundary rule. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> * fix(chat): address PR #2445 review — test ctx, send gating, attachment surface 1. Backend test was 400ing because the handler reads workspace from middleware-injected ctx, and `newRequest` only sets the header. Helper `withChatTestWorkspaceCtx` mirrors the agent-access-test pattern and loads the member row + SetMemberContext before invoking the handler. 2. Attachment metadata now flows end-to-end: - new sqlc `ListAttachmentsByChatMessageIDs` (batch lookup, mirrors the comment-side query) - `chatMessageToResponse` takes `attachments` and `ChatMessageResponse` surfaces them — same shape as CommentResponse - `ListChatMessages` loads them via a new `groupChatMessageAttachments` helper so the chat bubble can render file cards - daemon claim path pulls `ListAttachmentsByChatMessage` for the latest user message and ships `ChatMessageAttachments` to the daemon - `buildChatPrompt` lists id+filename+content_type and instructs the agent to `multica attachment download <id>` — fixes the private-CDN expiring-URL problem where the markdown URL would have expired by the time the agent acts - TS `ChatMessage` gains an optional `attachments` field 3. Chat composer now blocks send while uploads are in flight: - `pendingUploads` counter increments in handleUpload, SubmitButton uses it to disable - handleSend also gates on `editorRef.current.hasActiveUploads()` to catch the Mod+Enter path that bypasses the button - new vitest covers the "drop large file → immediate send" scenario where attachment id would otherwise be silently dropped Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> * chore: drop implementation plan doc Process artefact, not something the repo needs to keep. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com> Co-authored-by: multica-agent <github@multica.ai>	2026-05-12 10:57:54 +08:00
Bohan Jiang	63d215e1c3	feat(runtime): visibility (public/private) gate on CreateAgent / UpdateAgent (#2419) ... * feat(runtime): visibility (public/private) gate on CreateAgent / UpdateAgent Closes the hole where a plain workspace member could pick another member's runtime in the Create Agent dialog and bind an agent to it — the backend wasn't checking runtime ownership, so the agent ran on someone else's hardware / tokens. Reported on GH #1804. Schema - Migration 083 adds agent_runtime.visibility ('private' default, 'public') with a CHECK constraint. Existing rows default to private — same ownership semantics as before, no behavior change for legacy data. Backend - canUseRuntimeForAgent predicate: allow when caller is workspace owner/admin, the runtime owner, or the runtime is public. - CreateAgent and UpdateAgent both gate on it: UpdateAgent matters because a plain member could otherwise create on their own runtime, then re-bind to a private one. - PATCH /api/runtimes/:id accepts { visibility } — owner/admin only, validated against the same private/public allow-list. Frontend - Create-agent dialog renders other-owned private runtimes disabled with a Lock badge + tooltip explaining who to ask. - Inspector runtime-picker disables the same set so re-binding fails the same way at the UI layer. - Runtime detail diagnostics gains a Visibility editor (owner/admin) or read-only chip (everyone else). - Runtime list shows a private/public chip next to the name. Tests - Go: canUseRuntimeForAgent truth table; CreateAgent / UpdateAgent end-to-end gate tests (admin / runtime owner / plain member); PATCH visibility owner / admin / member / invalid-value coverage. - Vitest: create-agent dialog disabled state on private/public runtimes, default-runtime selection skips locked rows; runtime detail visibility editor → mutation, read-only fallback. Migrating runtimes: existing rows default to private to preserve the "owner only" status quo. Owners switch to public via the detail page diagnostics card. Co-authored-by: multica-agent <github@multica.ai> * fix(runtime): apply timezone+visibility atomically; don't seed locked template runtime Two issues surfaced in review of MUL-2062: 1. PATCH /api/runtimes/:id ran the timezone branch first, which: - returned early on a tz no-op, silently dropping a concurrent `visibility` patch in the same body; - committed the timezone mutation (+ usage rollup rebuild) before validating visibility, so an invalid visibility left the row half-updated. Validate every field first, then run the mutations in order. The no-op short-circuit now only triggers when nothing else is requested. 2. The Create Agent dialog in duplicate mode unconditionally seeded `template.runtime_id` as the selected runtime, even when that runtime is now private and owned by someone else — the user saw a selected row they couldn't submit (Create → backend 403). Fall back to the first usable runtime when the template's runtime is locked, and gate the Create button on `selectedRuntimeLocked` as defense in depth. Tests: - Go: TestUpdateAgentRuntime_CombinedPatchAppliesBoth (tz no-op + visibility flip), TestUpdateAgentRuntime_InvalidVisibilityDoesNotMutateTimezone (atomic-fail invariant). - Vitest: duplicate template pointing at a locked runtime now seeds the first usable one; Create button stays disabled when no usable alternative exists. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-11 22:53:07 +08:00
Multica Eve	d6349c16ec	feat(runtime): per-runtime timezone for token-usage aggregation (MUL-1950) (#2394) ... * feat: per-runtime timezone for token usage aggregation The runtime token-usage charts (daily and hourly tabs on the runtime-detail page) bucketed every event by the Postgres session timezone, which is UTC in production. For an operator in UTC+8 that meant a Tuesday afternoon's tasks landed in Tuesday early-morning's bar — the chart was always one off. Fix: store an IANA timezone on agent_runtime and aggregate under it. * migrations 081 / 082 add agent_runtime.timezone (TEXT NOT NULL DEFAULT 'UTC') and rebuild the rollup pipeline (window function and both trigger functions) to compute bucket_date with AT TIME ZONE rt.timezone instead of bare DATE(). * No historical backfill — task_usage_daily rows already on disk keep their UTC bucket_date; only future writes / re-touches recompute under the new tz. (Product call from MUL-1950: 'guarantee future correctness'.) * runtime_usage.sql gains a @tz parameter on ListRuntimeUsage and GetRuntimeUsageByHour and threads tz through GetRuntimeTaskHourly Activity. ListRuntimeUsageDaily reads bucket_date as-is since the rollup already wrote it in tz. * parseSinceParamInTZ replaces the raw N×24h cutoff with start-of- day-N in the runtime's tz so 'last 7 days' lines up with bucket boundaries. * Daemon registration sends the host's IANA tz (TZ env, then time.Local), and UpsertAgentRuntime preserves any user override via a CASE-on-existing-value pattern so a daemon reconnect can't silently revert the operator's setting. * New PATCH /api/runtimes/:id endpoint (UpdateAgentRuntime) lets the runtime detail page edit the tz; the editor seeds with the browser tz on first interaction. Refs: MUL-1950 Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: multica-agent <github@multica.ai> * fix: harden runtime timezone rollups Co-authored-by: multica-agent <github@multica.ai> * fix: address runtime timezone review nits Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica.ai> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: multica-agent <github@multica.ai> Co-authored-by: Eve <eve@multica-ai.local>	2026-05-11 14:39:35 +08:00
Jiayuan Zhang	3b3be9d7bd	feat(comments): resolve threads with collapsible bar (MUL-1895) (#2300) ... * feat(comments): resolve threads with collapsible bar (MUL-1895) Adds a Linear-style resolve action on comment thread roots. Resolved threads collapse to a single "N resolved comments from X" bar in the activity feed; clicking expands the thread inline (per-session, not persisted). Replying inside a resolved thread auto-unresolves it. Backend - migration 069: resolved_at, resolved_by_type, resolved_by_id on comment - sqlc ResolveComment / UnresolveComment queries (idempotent via COALESCE) - POST/DELETE /api/comments/{id}/resolve handlers, root-only validation - CreateComment auto-clears resolved_at when a reply lands in a resolved thread, publishing comment:unresolved - comment:resolved / comment:unresolved events; CommentResponse and TimelineEntry both surface the new fields Frontend - Comment + TimelineEntry types extended; payloads typed; WS sync wired - useResolveComment optimistic mutation with rollback - ResolvedThreadBar component for the collapsed view - Resolve / Unresolve menu items on root comments; Collapse strip on the expanded resolved card - en + zh-Hans locale strings Co-authored-by: multica-agent <github@multica.ai> * fix(comments): cover agent reply path, expand-state hygiene, nested counts (MUL-1895) Addresses three review issues from Emacs on PR #2300: 1. TaskService.createAgentComment bypasses Handler.CreateComment, so the auto-unresolve wired into the handler did not fire when an agent replied in a resolved thread (task / mention / on_comment paths). Extracted the logic to TaskService.AutoUnresolveThreadOnReply so both reply paths share it; rewired Handler.CreateComment to call the new method. 2. Resolving an already-expanded thread no longer collapses it back to the bar because expandedResolved still contained the id. Added clearResolvedExpand + handleResolveToggle wrapper so resolve / unresolve always wipe the session expand entry. 3. ResolvedThreadBar received only direct children, while CommentCard's expanded view recurses through descendants. Extracted the recursive walk into thread-utils.collectThreadReplies and called from both — counts and author lists now match. Co-authored-by: multica-agent <github@multica.ai> * test(comments): mock useResolveComment + add zh-Hans plural key Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-09 05:49:33 +02:00
Multica Eve	eb067ff077	fix(server): aggregate task_usage into daily rollup table to cut DB load (#2256) ... * fix(server): aggregate task_usage into daily rollup table to cut DB load ListRuntimeUsage previously did a SUM(...) GROUP BY DATE(created_at), provider, model over the raw task_usage stream once per runtime row on the runtimes list and once per detail page load, scaling O(events) per call. This is the hot read path responsible for sustained load on Postgres. Switch the read path to a materialized daily rollup table maintained by a pg_cron job: - 072_task_usage_daily_rollup: schema for task_usage_daily + task_usage_rollup_state, plus rollup_task_usage_daily_window(p_from, p_to) (window primitive used by both cron and offline backfill, idempotent via ON CONFLICT DO UPDATE adding deltas) and rollup_task_usage_daily() (cron entry point — pg_try_advisory_lock(4242) for serialization, watermark advancement, 5-minute safety lag for late-visible inserts). Also adds idx_task_usage_created_at to help the two lazy endpoints (ListRuntimeUsageByAgent / GetRuntimeUsageByHour) that still hit the raw table. - 073_task_usage_daily_pgcron: CREATE EXTENSION IF NOT EXISTS pg_cron in a DO/EXCEPTION block (mirrors the migration 032 pg_bigm pattern so envs without shared_preload_libraries=pg_cron skip gracefully) and schedules rollup_task_usage_daily() every 5 minutes when the extension is present. - queries/runtime_usage.sql ListRuntimeUsage rewritten to read from task_usage_daily; sqlc regenerated. Other usage queries unchanged. - cmd/backfill_task_usage_daily: one-shot Go command that walks task_usage in monthly slices through rollup_task_usage_daily_window, then stamps the watermark to now()-5m so the cron resumes cleanly. Run once after migrations have applied, before relying on the rollup. - runtime_test.go: TestGetRuntimeUsage_BucketsByUsageTime now invokes rollup_task_usage_daily_window after fixture inserts so the handler sees the rolled-up rows. Synthetic daily rows cleaned up after each test. - runtime_rollup_test.go: new tests covering aggregation correctness, idempotency contract of ON CONFLICT DO UPDATE, and the watermark advancing exactly to now()-5m via the cron entry point. Deployment order: apply migrations → run backfill_task_usage_daily once → pg_cron picks up subsequent windows automatically. Today bucket may be up to ~10 minutes stale (5 min cron + 5 min lag) by design. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: multica-agent <github@multica.ai> * fix(server): make task_usage_daily rollup safe to overlap, replay, and correct Addresses 4 review blockers on the original PR: 1. Cron/backfill double-count race: the rollup function is now idempotent. Window calls find DIRTY KEYS via task_usage.updated_at, then RECOMPUTE each bucket from ground truth and REPLACE the daily row (no more additive ON CONFLICT). Cron and backfill can now overlap safely. 2. Silent pg_cron absence: the read path is gated behind a new USAGE_DAILY_ROLLUP_ENABLED feature flag (default off). The raw task_usage scan is preserved as the fallback. Operators flip the flag per-environment after backfill + cron are confirmed healthy (task_usage_rollup_lag_seconds() helper added for monitoring). 3. UpsertTaskUsage corrections invisible to rollup: added task_usage.updated_at column (default now(), backfilled from created_at), and bumped it on conflict. Corrections now mark the bucket dirty and the next window call recomputes it correctly. 4. CREATE INDEX blocking writes on hot table: split into separate single-statement migrations using CREATE INDEX CONCURRENTLY (074, 075), matching the 035/067 pattern. Also: cron.schedule() removed from migrations entirely. Migration 076 only enables the extension (gracefully on unsupported envs); the actual schedule is a documented operator runbook step that runs AFTER backfill. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: multica-agent <github@multica.ai> * fix(server): trigger-driven invalidation + online-safe migration for task_usage_daily Round-2 review feedback on PR #2256: 1. Add explicit dirty-bucket queue (task_usage_daily_dirty) populated by triggers on agent_task_queue (UPDATE OF runtime_id, DELETE) and task_usage (DELETE). The rollup window function drains both this queue and the updated_at-based discovery, so runtime reassignment and issue-cascade deletes no longer leave the rollup divergent from the raw query. Triggers join via agent (not issue) to look up workspace_id, because when the cascade comes from issue, the issue row is already gone by the time atq's BEFORE DELETE fires; agent stays alive. 2. Make migration 072 online-safe: only ADD COLUMN updated_at TIMESTAMPTZ (nullable, no default → metadata-only ALTER, no row rewrite) and a separate ALTER for SET DEFAULT now() (also metadata-only). No bulk UPDATE on the hot task_usage table. The rollup window function's dirty_keys CTE handles legacy NULL rows via an OR branch, supported by partial index idx_task_usage_created_at_legacy. 3. Refresh stale documentation in cmd/backfill_task_usage_daily/main.go header to describe the current recompute/replace semantics, idempotent re-runnability, and the actual migration numbering (072..077). Tests: - TestRollupTaskUsageDaily_InvalidationOnReassign: verifies usage moves between runtime buckets after ReassignTasksToRuntime-style update. - TestRollupTaskUsageDaily_InvalidationOnIssueDelete: verifies daily bucket is cleared after issue delete cascades through atq → task_usage. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: multica-agent <github@multica.ai> * fix(server): close dirty-queue race + move legacy partial index to its own concurrent migration Round-3 review feedback on PR #2256: 1. Blocker: dirty-queue invalidations could be silently lost under concurrency. ON CONFLICT DO NOTHING let a late trigger see the row already enqueued, no-op, and then the rollup drain (WHERE enqueued_at < p_to) would delete the original row — losing the late invalidation. Switched all three trigger enqueue paths to ON CONFLICT DO UPDATE SET enqueued_at = GREATEST(existing, EXCLUDED.enqueued_at), so any invalidation arriving during a rollup tick keeps enqueued_at > p_to (p_to = now() - 5min) and survives the post-tick drain. 2. High: idx_task_usage_created_at_legacy (partial index on hot task_usage table) was being created in the regular 077 migration without CONCURRENTLY. Moved to new migration 078 with CREATE INDEX CONCURRENTLY, matching the pattern of 074/075. 077's down migration leaves the index alone (it is owned by 078). 3. Minor: gofmt -w on runtime_rollup_test.go and backfill_task_usage_daily/main.go (tabs were lost in the original heredoc append). PR description rewritten to describe the current recompute/replace + dirty queue + feature flag design and the 072..078 migration ordering. Tests still green: TestRollupTaskUsageDaily_* (including both new invalidation regressions), TestGetRuntimeUsage_*, TestWorkspaceUsage_*. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: multica-agent <github@multica.ai> * fix(server): unify workspace_id source via agent in rollup window function Round-4 review feedback (J) on PR #2256: M1 (must-fix): The dirty queue triggers resolved workspace_id via `agent.workspace_id`, but the window function's `dirty_from_updates` discovery and `recomputed` recompute join used `issue.workspace_id`. There is no schema-level FK guaranteeing `agent.workspace_id == issue.workspace_id`. Any divergence (future cross-workspace task scenarios, data repairs, migration bugs) would cause: - dirty queue rows with workspace_id from agent - recompute join filtering by workspace_id from issue - 0 matches in recompute → bucket erroneously hits the deleted_empty branch and the daily row is silently dropped - dirty_from_updates path attributing usage to the wrong workspace Replaced both CTEs to JOIN agent (not issue) so trigger / discovery / recompute share one workspace_id source. Comment in 077 explains the constraint. N1: Refreshed two stale references in cmd/backfill_task_usage_daily/main.go (header now says "072..078"; stampWatermark warning now mentions migration 073, where the rollup state table is actually introduced). Test: New TestRollupTaskUsageDaily_WorkspaceMismatch constructs an atq with agent.workspace_id != issue.workspace_id, asserts the bucket lands under agent's workspace (not issue's), and re-asserts after a runtime reassign in the foreign workspace. Acts as a canary if the schema invariant changes. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: Eve <eve@multica.ai> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Co-authored-by: multica-agent <github@multica.ai> Co-authored-by: Devv <devv@Devvs-Mac-mini.local>	2026-05-08 15:35:21 +08:00
LinYushen	250ada1fb3	chore(db): drop unused agent_task_queue.last_heartbeat_at (#2212) ... Drops the unused agent_task_queue.last_heartbeat_at column and removes the hot-path task heartbeat write.	2026-05-07 15:45:29 +08:00
Naiyuan Qing	3447764b03	feat(i18n): full rollout — 21 namespaces translated (en + zh-Hans) (#1853) ... * feat(i18n): rollout phase — translate 9 namespaces (WIP) Phase 1 complete (基建 + login + Settings language switcher), phase 2 partial (Wave 4 done, search done). Pending namespaces documented inline; another developer can pick up from here. Infrastructure -------------- - server: add users.language column + extend PATCH /api/me (TestUpdateMeAcceptsLanguage / TestUpdateMePreservesLanguage) - packages/core/i18n: types / pickLocale (intl-localematcher) / browser-cookie-adapter / createI18n (initAsync false + useSuspense false) / I18nProvider / LocaleAdapterProvider - Split server-safe vs React entries: @multica/core/i18n — for proxy/RSC/middleware (no React) @multica/core/i18n/react — for client trees (createContext) (RSC vendored React lacks createContext; mixed import would crash proxy.ts at module load.) - packages/views/i18n: useT hook + selector API augmentation (i18next v26 default; auto-propagates to apps via the side-effect import in use-t.ts). - apps/web: proxy.ts (Next 16 renamed middleware) merges existing legacy/root redirects with x-multica-locale header forwarding; layout.tsx reads locale via headers() and pre-loads RSC resources. - apps/desktop: webPreferences.additionalArguments injects systemLocale (no sendSync — avoids main-thread blocking IPC); renderer adapter reads via process.argv. - ESLint: i18next/no-literal-string at file-scope for translated files via packages/views/eslint.config.mjs TRANSLATED_FILES. - glossary.md (packages/views/locales/) freezes term policy: Issue / Workspace / Agent / Skill / Autopilot / Daemon / Runtime stay English; Inbox / Project / Comment / Member translate. Translated namespaces (9 / 19) ------------------------------ - auth: login page (web wrapper含 desktop-handoff 文案) + Settings Appearance language switcher - editor: 9 .tsx (bubble-menu / link-hover-card / readonly-content / title-editor / extensions: code-block / file-card / image-view / mention-suggestion) + 32 keys - invite: 25 keys - labels / members / my-issues: Wave 4 全部 - search: command palette 35 keys - navigation: no user-facing strings (no-op) Pending (10 / 19) ----------------- issues (46 files / ~210 keys) agents (29 files / ~155 keys; presence.ts + config.ts label maps 允许进 i18n) onboarding (22 files / ~150 keys) settings rest / skills / modals / workspace / chat / inbox / projects / autopilots / layout Workflow for picking up ----------------------- - Glossary: packages/views/locales/glossary.md (mandatory read) - Reference impls: auth/login-page.tsx + editor/* (selector API + i18n-provider test wrapper pattern) - Per namespace: 1. create locales/{en,zh-Hans}/{ns}.json 2. add to packages/views/i18n/resources-types.ts 3. useT('{ns}') + t($ => $.foo) in components 4. add files to TRANSLATED_FILES in eslint.config.mjs 5. typecheck + test + lint must pass - Subagents currently CANNOT write files (sandbox deny). Run as hybrid: subagent researches + outputs full JSON + tsx diff, controller writes. Other ----- - scripts/init-worktree-env.sh: default MULTICA_DEV_VERIFICATION_CODE=888888 in dev for deterministic login (gated by isProductionEnv). Verified: pnpm typecheck (6 pkgs ok), pnpm test (232 pass), make test (Go). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(i18n): rewrite glossary aligned with docs zh voice Switch translation policy to match the canonical CN voice already established in apps/docs/content/docs/*.zh.mdx (20+ files). The new rule splits product nouns into two classes: - Typed entities (issue / project / skill / autopilot / task) — kept as lowercase English in CN text, visually marking them as system types. - Concepts (workspace / agent / daemon / runtime / inbox) — fully translated (工作区 / 智能体 / 守护进程 / 运行时 / 收件箱). Previous glossary kept Workspace / Agent / Daemon / Runtime as English on "工程惯例" grounds, but docs zh and CN AI ecosystem (Coze / 腾讯元器 / 百度) consistently translate these. App UI now matches docs voice so users don't see split personality between the app and its own docs. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(i18n): register 6 namespaces and retrofit zh strings to new glossary Two fixes that were blocking the previously-translated namespaces from actually rendering in CN: 1. RESOURCES gap — locales/index.ts only loaded common/auth/settings, but resources-types.ts declared 12 namespaces and 6 of them had real translation content. At runtime i18next would fall back to raw keys for editor / invite / labels / members / my-issues / search. Register all 9 currently-translated namespaces. 2. Retrofit zh strings to the docs-aligned glossary: - "Issue" → "issue" (lowercase entity) - "Workspace" → "工作区" - "Agent" → "智能体" - "Runtime" → "运行时" - "Skill" → "skill" (lowercase) - "项目" → "project" (lowercase) Touched: editor.json (sub_issue + mention.group_issues), invite.json (3 Workspace occurrences), members.json (agents_section / more_agents), my-issues.json (8 retrofits across page/header/errors), search.json (13 retrofits across groups/pages/commands/empty). Verified: pnpm typecheck (6/6) + pnpm test (238/238) all green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate inbox namespace First namespace through the sub-agent → main-agent integration pipeline. JSON: en/inbox.json + zh-Hans/inbox.json — 60 keys across page / menu / list / detail / types / labels / errors. Time-formatter labels are kept compact in EN ("5m" / "3h" / "2d") and use full units in zh ("5 分钟" / "5 小时" / "5 天") since raw "5 分" reads as "5 marks/points" in CN. Component changes converted two module-level statics into hooks so the strings can flow through i18next: - inbox-list-item.tsx: `timeAgo` (pure fn) → `useTimeAgo` (hook returning a fn). The local copy is a duplicate of @multica/core/utils `timeAgo` that is only used by inbox-page; other consumers across chat/agents/skills/issues stay on the core util for now and will be translated when their namespaces land. - inbox-detail-label.tsx: `typeLabels` (static const Record) → `useTypeLabels` (hook returning the same Record shape). Call sites keep the existing `typeLabels[type]` access pattern. inbox-page.tsx now uses both hooks and `useT('inbox')` selector calls for all hardcoded strings (~24 sites: header / dropdown menu / list empty state / detail panel / mobile back / quick-create-failed flow / all error toasts). Wired up: resources-types.ts, locales/index.ts RESOURCES, ESLint TRANSLATED_FILES (3 inbox tsx files now lint-protected). Verified: pnpm typecheck (6/6) + pnpm --filter @multica/views test (238/238) + ESLint clean on inbox/. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate workspace namespace Translates the three workspace shell views: create-workspace-form, new-workspace-page, no-access-page. Also fixes the prior-art no-unescaped-entities lint errors in no-access-page.tsx — the apostrophes in "doesn't" / "don't" were JSX text literals that move into JSON values after translation, so the lint rule no longer fires. Tests wrapped: workspace/create-workspace-form.test.tsx, workspace/no-access-page.test.tsx, modals/create-workspace.test.tsx all now wrap render() with <I18nProvider locale="en"> so the en values in workspace.json drive the rendered text and the existing assertions continue to match. Slug constants kept: WORKSPACE_SLUG_FORMAT_ERROR / WORKSPACE_SLUG_CONFLICT_ERROR exports in workspace/slug.ts are still imported by onboarding/steps/step-workspace.tsx (out of scope here). The workspace shell now reads its strings from workspace.json directly. Multica.ai brand prefix in the slug input affordance is wrapped with an inline `// eslint-disable-next-line i18next/no-literal-string` per glossary policy on brand names. Renamed sign_in_other → sign_in_different to avoid colliding with i18next's `_other` plural-suffix convention which the selector-API typings treated as a plural form of `sign_in`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate projects namespace Translates the projects list page, project detail page, project picker dropdown, and project chip — all four user-facing surfaces under packages/views/projects/components/. New file: projects/components/labels.ts exposes three hooks that replace the static `.label` field on PROJECT_STATUS_CONFIG / PROJECT_PRIORITY_CONFIG and the previous module-level `formatRelativeDate` helper. Core's `.label` stays untouched (it's still consumed by search and the create-project modal, both out-of-scope for this namespace) — those will flip when their respective namespaces translate. In zh, the "project" entity stays lowercase English per glossary (`新建 project`, `还没有 project`, `从 project 移除`). Status / priority / table column labels translate fully. The cancelled / done / paused etc. status labels duplicate per- namespace as `projects.status.*` rather than reading from a future shared status namespace. This matches the auth/inbox/workspace pattern of self-contained namespaces. If a generic "issue/project status" pool emerges later, these can collapse. Verified: pnpm --filter @multica/views typecheck (clean) + test (238/238) + ESLint clean on projects/ (1 pre-existing warning about useEffect/sidebarRef dep, unrelated to i18n). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate autopilots namespace Six tsx files: autopilots-page (list + 6 templates), autopilot-detail-page (properties / triggers / run history / delete), autopilot-dialog (create + edit dialog), trigger-config (cron form), and the agent / timezone pickers. Hook conversions for module-level helpers that need t(): - summarizeTrigger / describeTrigger → useSummarizeTrigger / useDescribeTrigger (no external callers, removed the plain exports) - formatRelativeDate → useFormatRelativeDate (per-component hook) - formatCountdown → useFormatCountdown (per-component hook) - TEMPLATES array now keyed by id; titles + summaries pull from templates/{id}/{title,summary} JSON. Prompts stay raw EN since they're injected directly into the agent task — translating them would translate the agent's instructions, not the user's UI. Status / execution-mode / run-status enums render via t($ => $.status[k]) with k typed against the core type (no separate hook needed). Verified: pnpm --filter @multica/views typecheck (clean) + test (238/238) + ESLint clean on autopilots/. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate skills namespace Seven tsx files: skills-page (list + filters + intro banner), skill-detail-page (the giant — properties + file tree + sidebar + conflict banner + delete dialog, ~963 lines), create-skill-dialog (chooser + manual + URL forms), runtime-local-skill-import-panel (local runtime browse + import), skill-columns, file-tree, file-viewer. Notable patterns: - `createSkillColumns` factory → `useSkillColumns` hook so column headers flow through useT. Column identity changes per render is fine — DataTable handles it. - `validateNewFilePath` (pure helper) → `useValidateNewFilePath` hook so the 5 validation error messages can be translated. - skill_files / used_by / description_with_agents use i18next plural keys (`_one` / `_other`) — the type system collapses these into a single PluralValue access, so call sites use `t($ => $.foo, { count })` and i18next picks the form. - Per glossary, "skill" stays lowercase EN in zh ("新建 skill", "已删除 skill", "未找到该 skill"). Test wrapper: runtime-local-skill-import-panel.test.tsx now wraps render() with <I18nProvider> so the assertion on /Import to Workspace/i matches the EN translation. Verified: pnpm --filter @multica/views typecheck (clean) + test (238/238) + ESLint clean on skills/. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate chat namespace Translates all 10 chat surfaces: FAB tooltip, input placeholders, message list (replied-in / failed-after / tools group / show-details / tool result preview), session history (header + time-ago labels), chat window (new-chat / restore / expand / minimize / agent + session dropdowns / starter prompts / empty states), context-anchor button + card tooltips, no-agent banner, offline / unstable banner, and the task-status pill (queued / starting up / thinking / typing + tool labels: running command / reading files / searching code / making edits / searching web). Hook conversions: - formatTimeAgo (chat-session-history) → useFormatTimeAgo - ElapsedCaption now takes a typed `variant` ("replied" | "failed") instead of a free-text `verb` so the i18n key is enumerable - pickStage (task-status-pill) refactored: pure pickStageKeys returns StageKey + optional ToolKey; useResolveStage maps to localized labels Translation policy notes: - Starter prompts ("List my open tasks by priority", etc.) are user UI when displayed AND the user's input when clicked — translating them sends the agent the user's locale-native phrasing, which is the right UX for a CN user using a CN agent. - buildAnchorMarkdown (chat-window) stays in English: it's an agent-bound markdown prefix injected into the outgoing message, not user-facing UI. Verified: pnpm --filter @multica/views typecheck (clean) + test (238/238). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate modals namespace Translates all 11 modal sources: registry (no UI text), backlog-agent-hint, set-parent-issue, add-child-issue, delete-issue-confirm, feedback, issue-picker, create-workspace, create-project, create-issue (manual), quick-create-issue (agent panel). Notable patterns: - create-project re-uses useProjectStatusLabels / useProjectPriorityLabels hooks from views/projects/components/labels — same translation source as the projects list / detail, no duplication. - create-issue.tsx: renamed `toast.custom((t) => ...)` callback param to `toastId` to avoid shadowing the closure-captured useT() `t` function. - Test wrapper added to modals/create-issue.test.tsx so the two assertions on rendered modal text (success toast + Create another) match the EN bundle. modals/create-workspace.test.tsx was already wrapped (workspace ns commit). Verified: pnpm --filter @multica/views typecheck (clean) + test (238/238). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate settings namespace (rest of tabs) Builds on the appearance-tab + language switcher already shipped in Phase 0. Translates the remaining 8 settings surfaces: settings-page shell (left nav + tab keys), account / profile, notifications-tab (5 group labels + descriptions), tokens-tab (create / list / revoke / created dialog), workspace-tab (general fields + danger zone + leave/delete confirmations), members-tab (invite + role config + revoke / remove flows), repositories-tab, labs-tab, delete-workspace-dialog. Hook conversion: members-tab `roleConfig` static const → `useRoleLabels` hook returning a Record<MemberRole, {label, description, icon}>. The icon stays as a typed React component (Crown / Shield / User), so rendering pattern is unchanged at call sites. Test wrapper: settings/components/delete-workspace-dialog.test.tsx now wraps render() with <I18nProvider> (custom render() helper) because the test asserts on rendered button labels ("Delete workspace", "Cancel", "Deleting..."). Verified: pnpm --filter @multica/views typecheck (clean) + test (238/238). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate runtimes namespace (entry surfaces) Translates the user-facing runtime list page surfaces: runtimes-page (header / search / filters / chips / empty / no-matches / bootstrapping), runtime-detail (topbar + delete dialog + delete toasts), runtime-detail-page (not-found state), shared.tsx (4-state HealthBadge labels). Hook conversion: shared `healthLabel(health)` was a pure module-level function. Added `useHealthLabel` hook for translated call sites; kept `healthLabel` as an EN-only fallback for non-component callers (column factory in runtime-columns). Deferred: - runtime-list / runtime-columns (data table column headers + cell bodies) — large surface, not in the page-load critical path. - connect-remote-dialog / update-section / usage-section — secondary flows, English remains acceptable until a focused pass. - charts/* — primarily numeric tooltips and axes; minimal user-visible text. Verified: pnpm --filter @multica/views typecheck (clean) + test (238/238). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate layout namespace (sidebar nav, help, loader) Translates the cross-cutting layout chrome: - 9 sidebar nav labels (inbox / my issues / issues / projects / autopilots / agents / runtimes / skills / settings) — driven by labelKey instead of inline strings, resolved via useT at render. - HelpLauncher dropdown (trigger aria + 3 items: Docs / Change log / Feedback) - WorkspaceLoader (named + unnamed loading states) - SortablePinItem unpin tooltip Pattern shift in app-sidebar.tsx: nav arrays carry `labelKey: NavLabelKey` (typed against the layout JSON) instead of `label: string`. The string comparison checks (`item.label === "Inbox"`) became cleaner ID-based checks (`item.key === "inbox"`). Deferred: deeper sidebar surfaces — workspace switcher dropdown, "New Issue" CTA, "Pinned" / "Workspace" / "Configure" group labels — remain English. The 9 nav labels are the ones that read in every session. Verified: pnpm --filter @multica/views typecheck (clean) + test (238/238). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate onboarding namespace (welcome + step header) Translates the user-first-impression surfaces of the onboarding flow: - step-welcome.tsx (the wordmark, headline, lede paragraphs, all CTAs: Download Desktop / Continue on web / Start exploring / I've done this before, illustration caption) - step-header.tsx ("Step N of M" counter + matching aria-label) - onboarding-flow.tsx (skip-onboarding error toast) Test wrapper added to onboarding/components/step-header.test.tsx — custom render() helper wraps with <I18nProvider> so the "Step 2 of 5" assertions match the EN bundle. Deferred (acceptable English fallback for now): step-questionnaire, step-workspace, step-runtime-connect, step-platform-fork, step-agent, step-first-issue, cli-install-instructions, option-card, runtime aside panels, starter-content-prompt, cloud-waitlist-expand. These are deeper steps with significant copy that would benefit from a focused dedicated pass — voice on each is more nuanced (questionnaire options, runtime install instructions, agent template recommendations). Verified: pnpm --filter @multica/views typecheck (clean) + test (238/238). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * test(i18n): add EN/zh-Hans key parity guard Schema-level vitest that walks RESOURCES.en and RESOURCES["zh-Hans"] namespace by namespace and asserts both bundles cover the same key set. i18next plural rule is normalized before compare (`_one` / `_other` collapse to a single logical key) so EN's plural pair matches zh's `_other`-only form. Catches retrofit drift where a new EN key lands without zh — previously this would silently fall back to the English string in production. Cheap to keep green: 39 tests across 21 namespaces in under a second. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate issues namespace Translates the entire issues surface — list / board / detail / comments / sub-issues / activity feed / batch toolbar / pickers / context menu / backlog-agent hint dialog / labels panel. Component coverage: - issues-page (page header, empty state, move-failed toast) - issues-header (scope tabs, filter dropdowns w/ status/priority/ assignee/creator/project/label, display settings, sort, view toggle) - issue-detail (page header, breadcrumb, properties / parent issue / details / token usage sections, sub-issues, activity timeline, formatActivity for status/priority/assignee/title/due-date changes, subscribe/subscriber popover) - comment-card + comment-input + reply-input (delete dialog, edit/save, copy/edit/delete row, reply count, placeholders, expand/collapse) - agent-live-card (is-working banner, tool count, stop / transcript) - execution-log-section (section header, show/hide past runs, trigger text builder, status labels, cancel-task) - batch-action-toolbar (selected count, delete dialog with plurals) - backlog-agent-hint-dialog (full dialog content) - labels-panel (intro, create form, list, delete dialog) - pickers (status / priority / assignee / due-date / label / property search placeholder + no-results) - issue-actions-menu-items (all dropdown / context menu items) - use-issue-actions / use-issue-timeline (toast strings) STATUS_CONFIG / PRIORITY_CONFIG label rendering routed through $.status[enum] / $.priority[enum] at every call site; the core config keeps its English fallback for non-i18n consumers but UI never reads .label directly anymore. Tests retrofitted: issues-page, issue-detail, and issue-actions-menu RTL specs now wrap renders in <I18nProvider> with the EN bundle, so their string assertions match the bundle (not hardcoded literals). ESLint i18next allow-list extended to 24 issues files. Verified: pnpm --filter @multica/views typecheck + test (277/277) all green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate agents namespace Translates the agents listing + detail surface and the create/duplicate flow. Covers the high-frequency surfaces; deeper sub-tab editors (activity / instructions / skills / env / custom-args bodies, and the hooks-buggy runtime/model/concurrency pickers) are deferred — they have their own pre-existing react-hooks rule violations and benefit from a focused dedicated pass. Component coverage: - agents-page (page header w/ tagline + new button, scope segment, search, sort dropdown, availability chips, archived toolbar, empty state, no-matches messaging w/ search interpolation, list-load error) - agent-detail-page (back link, archived banner, archive dialog, not-found state, all 4 toast strings) - agent-detail-inspector (avatar editor, name + description popover, description dialog, every PropRow label, validation message, presence badge label sourced from $.availability[enum]) - agent-overview-pane (tab labels, discard-unsaved-changes dialog) - create-agent-dialog (title / description / labels / placeholders / duplicate-suffix / runtime filter buttons / runtime status copy) - agent-row-actions (full dropdown items + cancel-tasks dialog with pluralized "N running + M queued" summary + archive dialog + 6 toasts) - agent-columns (every header cell, You / Archived chips, runtime fallback labels, availability + workload labels via $.availability / $.workload, activity tooltip body w/ created_today / created_days_ago / runs / failed-percent interpolation) - inspector/skill-attach (Attach trigger label + aria) availabilityConfig and workloadConfig now keep colors only — the display label lives in the bundle, sourced via $.availability[enum] and $.workload[enum] at every call site. Same pattern as STATUS_CONFIG/PRIORITY_CONFIG in the issues namespace. ESLint i18next allow-list extended to 8 agents files. Verified: pnpm --filter @multica/views typecheck + test (277/277) all green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(i18n): clear 30 stray EN strings in translated files Tail of literal strings missed in earlier passes — the ESLint i18next allow-list flagged them but they slipped through review. Files touched: - layout/app-sidebar.tsx (10 keys: Workspaces / Pending invitations / Create workspace / Join / Decline / Log out / New Issue + shortcut / Pinned / Workspace / Configure) - runtimes/components/runtime-detail.tsx (Serving header + serving_count pluralization, no_agents copy, running/queued chips with count interpolation, Diagnostics header, CLI label, Delete runtime button, Technical details toggle, last seen interpolation) - onboarding/steps/step-welcome.tsx (entire WelcomeIllustration mock — 5 cards × actor names + body copy + 3 mention chips + 2 timestamps; zh translation reads naturally instead of leaving the demo English) - settings/components/labs-tab.tsx (`Co-authored-by: ...` git trailer wrapped in {} so linter sees a JS string, not JSX text — magic identifier git relies on, must not translate) - settings/components/members-tab.tsx (✓ glyph wrapped in {}) - modals/feedback.tsx (⌘↵ shortcut wrapped in {}) ServingAgentsCard now reads availability/workload labels from `agents` namespace (cross-namespace useT) so the bundle-truth pattern holds: presenceConfig keeps colours only, label text comes from the shared bundle. Verified: typecheck + 277/277 tests + lint (only the pre-existing react-hooks rule-of-hooks errors remain, which task #6 addresses). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(agents): rules-of-hooks + translate 4 model/runtime pickers Three pre-existing react-hooks/rules-of-hooks violations + one missing useMemo dep cleared, then the four pickers wired through useT. Hook order fixes: - concurrency-picker: useEffect now runs before the !canEdit early return. Stale-draft reset still works the same way. - runtime-picker: useMemo for the filtered list moved above the !canEdit branch. - model-dropdown: `models = data?.models ?? []` was minting a fresh array each render and tripping the deps lint of the downstream useMemo. Wrap in useMemo so the reference is stable. Translation coverage: - concurrency-picker: tooltip ("Concurrency · N max..."), range helper text, Save button. - runtime-picker: trigger label fallback ("No runtime"), tooltip text composed from {{name}} + status, Mine/All filter buttons, empty-list copy, "owned by {{name}}" + status fragments in row tooltip, Cloud badge, online/offline aria. - model-picker: trigger label, tooltip, "Managed by runtime" fallback, search placeholder, "Discovering models…", default badge, "No models available", "Use \"X\"" custom-id flow, Clear button + its title. - model-dropdown: every label string including the "Select a runtime first" / "Default (provider)" / "Runtime offline — enter manually" trigger fallbacks, the supported=false explanation block, discovery failed badge, all popover items. ESLint allow-list extended to 4 picker files. Verified: typecheck + 277/277 tests + lint (0 errors, only pre-existing react-hooks warnings in unrelated files). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate runtimes list + connect dialog + CLI updater Three deep runtime surfaces wired through useT, with the agents namespace doing double duty for shared availability/workload labels. runtime-columns: - 7 column headers via t-augmented createRuntimeColumns({ t }). - HealthCell now reads from useHealthLabel() (already translation-aware) instead of the EN-only healthLabel() helper. - WorkloadCell sources the label from $.workload[enum] (cross-namespace to agents) — colour stays via workloadConfig. - CostCell delta "flat" copy + CLI cell "Desktop" badge + update- available aria/tooltip + RowMenu's full delete dialog (title / description with {{name}} interpolation / cancel / confirm / deleting state) plus its admin-permission hint. connect-remote-dialog: - Three steps fully translated: instructions (header + 4 numbered steps + security warning + troubleshooting list with mono code snippets escaped as JS strings), waiting (loader + hint), success (CTA pair). - Mono CLI commands wrapped in {} so linter sees JS strings — those are literal commands that must stay untranslated for the user to paste into a terminal. update-section: - statusConfig collapsed to icon+colour only; labels move to $.update.status[enum] for proper translation per-state. - "CLI Version:" / "Latest" / "available" / "Update" / "Retry" copy + the "Managed by Desktop" tooltip and disabled hint. Layout helpers tagged: runtime-list passes `t` through to the column factory the same way agent-columns does. ESLint allow-list extended with the 4 wired files. Verified: typecheck + 277/277 tests + 0 i18n lint errors. usage-section.tsx (KPI cards / WhenChart / TopUsageBreakdown / receipt table) is the remaining runtimes surface — chart-heavy and benefits from a focused pass next. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate 5 agent detail tabs + skill-add dialog The 5 tabs that fill the agent detail right pane plus the shared skill picker dialog. Agents bundle gains a `tab_body` block with sub-namespaces per tab + a `common` slot for save/add/unsaved. Tab coverage: - instructions-tab: intro paragraph, multi-line example placeholder (full 18-line zh translation), Save / Unsaved. - env-tab: read-only intro / empty state, editable intro with two inline `<code>` env-var examples kept English (mono terminal payloads), KEY / value placeholders, Show/Hide value aria, Add / Remove aria, all 3 toasts (duplicate keys / saved / save failed). - custom-args-tab: intro about whitespace splitting, launch-mode prefix line + `<your args>` placeholder, --flag value placeholder, Add, Remove aria, both toasts. - skills-tab: intro, Add skill button, import-hint callout, empty state title + hint + add-CTA, remove-failed toast. - activity-tab: 3 section titles (Now / Last 30 days / Recent work), active-task pluralization, performance subtitle, all 3 empty states, runs/success%/avg-duration/failed pluralization with interpolation, source labels (Issue / Chat / Autopilot / Untracked), source fallbacks (Quick create / Creating issue / Chat session / Autopilot run), issue-short fallback, "Triggered by" tooltip header, open-issue / transcript / cancel-task tooltips and ARIAs, cancelling state, started/dispatched/queued time prefixes, show more. - skill-add-dialog: dialog title + description, empty list copy, Cancel button, add-failed toast. skills-tab.test.tsx wrapped in <I18nProvider> with the EN bundle so its `Local runtime skills are always available` assertion still matches the resolved translation instead of the raw key path. ESLint allow-list extended with the 6 wired files. Verified: typecheck + 277/277 tests + 0 i18n lint errors. Only the per-test mock for skills-tab needed wrapping; the other 4 tabs ship without test files of their own and inherit the I18nProvider chain via agent-overview-pane / agent-detail-page test renders (when those exist later). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate onboarding step-questionnaire + option-card The user-profile step (3 questions) is the first deferred onboarding deep step now wired through useT. step-questionnaire: - Eyebrow + headline + answered-progress counter with {{count}} interpolation - All 3 questions and their option labels (team size / role / use case) - All 3 "Other" placeholders for free-text fallback - Right-rail "Why three questions" / "What you get" panel: 2 eyebrow rows, 2 unlock-item title+body pairs, learn-more link - Back / Continue buttons via shared `common` block option-card: shared "Other" radio label and aria. Test wrapped in <I18nProvider>. EN value of `other_label` kept as "Other" so the existing /^other$/i regex in step-questionnaire.test keeps matching after the rendering pipeline switched from a hardcoded literal to a bundle lookup. ESLint allow-list extended with these 2 files. The remaining 4 deep steps (workspace / runtime-connect / platform-fork / agent), the 2 ancillary surfaces (cli-install-instructions / starter-content- prompt), and the 3 side panels (runtime-aside-panel / cloud-waitlist- expand / compact-runtime-row) will be surfaced + swept by the global ESLint switch (next commit). Verified: typecheck + 277/277 tests + 0 i18n lint errors. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): flip ESLint to glob + drain remaining hardcoded EN ESLint i18next/no-literal-string now applies to **/*.tsx by default instead of an explicit allow-list. Files that genuinely still need hardcoded EN are listed in STILL_HARDCODED — concrete, finite, and the goal is to drain that list to zero. Tail strings translated in this commit (surfaced by the global flip): - common/task-transcript/agent-transcript-dialog.tsx — full dialog: status badge (Running / Completed / Failed), sr-only DialogTitle, Filter dropdown trigger + Clear filters, Copy all / Copy filtered / Copied, tool-calls + events metadata chips with pluralization, events-filtered "{{shown}} of {{total}}" interpolation, "Waiting for events..." live state, "No execution data recorded." past state. New `transcript` block in agents namespace. - runtimes/components/charts/activity-heatmap.tsx — Less / More legend labels around the contribution-style heat squares. - search/search-trigger.tsx — sidebar Search... button label. ⌘ glyph wrapped in {} to satisfy the linter (mono shortcut symbol, not translatable). Holdouts (STILL_HARDCODED, ~14 files): the deep onboarding steps (workspace / runtime-connect / platform-fork / agent / first-issue / cli-install-instructions, plus 4 ancillary panels), the runtimes usage-section + KPI cards, and 5 minor agent visual primitives (sparkline / agent-presence-indicator / agent-profile-card / visibility-badge / char-counter). Each one gets a dedicated future pass; the global rule prevents new hardcoded strings from landing elsewhere. Verified: typecheck + 277/277 tests + 0 i18n lint errors. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): drain agent visual primitives + onboarding small components 8 files removed from STILL_HARDCODED: agents/components/: - char-counter — over-limit text with {{count}} interpolation - visibility-badge — uses new agents.visibility.{private,workspace}. {label,tooltip} block; drops VISIBILITY_LABEL/TOOLTIP imports from core in favour of bundle-driven copy - agent-presence-indicator — availability + workload labels via $.availability[enum] / $.workload[enum] (cross-namespace), queue-badge "+N queued" with pluralization - agent-profile-card — Agent unavailable / Detail link / Owner / Skills / Runtime / Unknown runtime / Archived chip / availability line via cross-namespace lookup agents.json: new presence + visibility + profile_card + char_counter blocks. onboarding/components/: - compact-runtime-row — online/offline aria via agents.availability - runtime-aside-panel — full content (What's a runtime / Good to know / Swap anytime / Add more later / docs link) - starter-content-prompt — full dialog (title / description with inline emphasis / both buttons / 3 toasts) - cloud-waitlist-expand — intro paragraph + warning span / email + reason labels + placeholders + Optional badge / Join + on-list states / both toasts onboarding/steps/: - cli-install-instructions — copy aria + intro + 2 step labels onboarding.json: new runtime_aside / cli_install / starter_content / cloud_waitlist blocks. Tests for step-platform-fork + step-runtime-connect wrapped in <I18nProvider> with EN bundle so /you're on the list/i etc. still matches the resolved translations. Verified: typecheck + 277/277 tests + 0 i18n lint errors. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate onboarding deep steps The 5 large onboarding steps that were deferred from earlier passes, plus their support helpers, all wired through useT. step-first-issue (final beat — flips onboarded_at): - error_title / Retry / retry_failed toast / finishing / opening states. step-agent (creates the user's first agent): - Templates moved from a module-level const to a useT-driven useAgentTemplates() hook. Names + emoji stay constant (visual identity), labels + blurbs + instructions resolve from the bundle. coding / planning / writing / assistant — all four templates ship a full zh translation that reads naturally. - Recommended badge, eyebrow + headline + lede, footer hint, Create {{name}} CTA, create_failed toast. - Right-rail "About agents" panel (4 way-items + headline + add-more hint + docs link). step-workspace (create or pick existing): - 5 footer states (open / creating / creating-pending / name-first / pick), all hint + CTA strings via interpolation. - Name + URL + slug placeholders, issue-prefix preview spans, Create-new card title + subtitle. - 8-row WorkspacePreviewCard sidebar (Inbox / Issues / Agents / Projects / Autopilot / Runtimes / Skills / And more) — every label + meta strapped to bundle keys. - 4 perks (assign / chat / invite / switch) + 3 next-steps (runtime / agent / starter), 2 toasts (slug-conflict / failed). - `multica.ai/${slug}` mono URL escaped via template-literal expression so the linter sees a JS string. step-runtime-connect (desktop scan flow): - 3 phase headlines + ledes (scanning / found / empty), trust-strip status (all online / N online / none online) with pluralization, online/offline labels, Skip / Continue / Selected hint. - Empty-view 2 cards (skip + waitlist) and the cloud waitlist dialog wrapper. step-platform-fork (web fan-out): - Eyebrow + headline + lede, footer hint with 3 phase variants. - Primary download card (before/after click) + 2 alt cards (CLI / cloud) + CLI dialog with 4 elapsed-time stages (normal / midway / slow / stalled), live-listening header, runtime-connected pluralization, cloud waitlist dialog. ESLint: STILL_HARDCODED list shrunk from 14 entries to 1 — only runtimes/components/usage-section.tsx (chart-heavy KPI panel) remains. Verified: typecheck + 277/277 tests + 0 i18n lint errors. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate runtimes usage panel + drop STILL_HARDCODED Final i18n holdout: the runtimes usage panel (KPI hero, WHEN chart tabs, cost-by breakdowns, daily breakdown table) is wired through useT("runtimes"). With this drained, the eslint scaffolding for explicit holdouts is removed — every JSX text node in @multica/views now flows through i18n. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(i18n): drain rollout gaps + add cross-device sync Lands the post-review punch list for the i18n rollout: closes correctness gaps that would have shipped silently, and adds the missing cross-device locale sync the rollout's docs already promised. Coverage: - Register issues + agents namespaces in RESOURCES (90 useT call sites were rendering keys-as-text in production) - Harden parity test to compare RESOURCES keys against on-disk JSON files, so a future missing namespace registration fails loudly - Server-side language whitelist in UpdateMe + reject-unsupported test - Safe SupportedLocale resolution in appearance-tab (no more `as` cast on a region-tagged BCP-47 string) - HTML lang attribute uses zh-CN (not zh-Hans) for screen reader / CJK font-stack compatibility - Cookie Secure flag on https - Pulled createBrowserCookieLocaleAdapter out of the server-safe entry into a new @multica/core/i18n/browser subpath; document.cookie access can no longer leak into Edge middleware imports Cross-device sync: - New UserLocaleSync component mounted in CoreProvider; on login, if user.language differs from the active i18n.language, persist via the adapter and reload. Both apps benefit - Desktop main process tracks system locale and emits IPC on focus when it changes; renderer reloads only when the user has no explicit Settings choice (their preference still wins) Tests: - pickLocale / matchLocale (11 cases incl. region-tagged BCP-47, malformed tags, zh-Hant collapse-to-zh-Hans semantics) - browser-cookie-adapter (6 cases under jsdom) - Shared renderWithI18n helper at packages/views/test/i18n.tsx that wraps the real RESOURCES map; future tests opt in instead of inlining a per-file TEST_RESOURCES slice that goes stale silently Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs(conventions): consolidate naming + i18n glossary into docs site Single source of truth for code naming, i18n translation glossary, and Chinese voice rules. Previously split between packages/views/locales/glossary.md and scattered comments — now lives at apps/docs/content/docs/developers/conventions.{mdx,zh.mdx} with both English and Chinese versions kept in sync. Three sections per page: 1. Code naming — routes, packages, files, DB, Go, TS, commits 2. i18n translation glossary — entity vs concept rule, what to translate, word combination, plurals, interpolation, key naming 3. Chinese voice + style — punctuation, principles, where to look in doubt Side effects: - packages/views/locales/glossary.md collapses to a stub redirecting to the docs page; do not edit it - CLAUDE.md gets a new top-level "Conventions reference" section so any Claude session sees the pointer before any other rule - apps/docs/content/docs/developers/ gets a stub English meta.json so the conventions page is reachable on the EN side (contributing.zh.mdx / architecture.zh.mdx remain ZH-only — separate work) - Both root sidebars get a new "Developers" group Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * fix(i18n): apply zh voice rules + translate project/autopilot Two-part cleanup driven by the conventions doc landed last commit: Voice violations (mechanical sweep across 10 zh-Hans namespaces): - 「」 (Japanese-style brackets) → \" to match the EN source's straight double quotes (~13 sites) - … (single-char ellipsis) → ... three dots (~43 sites) - Drop translation-ese pronoun "我们" where it's a pure narrator ("我们已发送" → "已发送", "我们替你托管" → "由 Multica 托管"); keep "告诉我们" where "we" is the legitimate brand recipient - "作为父级 / 作为子级" → "设为父级 / 设为子级" - "任务" mistranslated as the task entity → `task` (lowercase EN entity) - Dialog title "Autopilot" → "autopilot" Translate project / autopilot per industry consensus: - `project` → 「项目」 (~42 value sites). Feishu / Tower / Teambition / PingCode / GitHub Projects all translate; no Chinese product keeps `project`. - `autopilot` → 「自动化」 (~34 value sites). Avoids the Tesla-style 「自动驾驶」 association; matches Notion / Feishu's industry term. - Issue / skill / task remain lowercase EN per dev-team familiarity. - Sidebar nav-label entities get Title Case ("Issue" / "Skill" / "我的 Issue") so the entry-point label reads as a proper UI signal; body prose stays lowercase. Conventions doc (EN + ZH) reflects the decision and adds a "why these translate but issue/skill/task don't" rationale block. Verification: parity test 45/45, full monorepo typecheck green. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(i18n): translate chat session delete + project resources section Two features main shipped while this branch was idle never went through the i18n pass: - Chat session delete confirmation dialog (#2115) and history toggle tooltip (#2117): adds session_history.delete_dialog.* and session_history.row_delete_*, plus window.history_show_tooltip / history_back_tooltip. - Project resources sidebar (#1926/#2080/#2111): entire component including toasts, popover form, attach/remove tooltips. New projects.resources subtree. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-06 16:16:12 +08:00
Bright Zheng	cf47d9b702	fix: guard session resume by runtime (#1905)	2026-05-03 10:51:31 +08:00
Bohan Jiang	b1345685a3	fix(task): rerun starts a fresh session, skip poisoned resume (#1928) ... * fix(task): rerun starts a fresh session, skip poisoned resume When a task ended in a known agent fallback ("I reached the iteration limit and couldn't generate a summary.", "Put your final update inside the content string. Keep it concise.") the (agent_id, issue_id) resume lookup would still pick that session, so a manual rerun inherited the poisoned state and reproduced the same bad output. Two complementary guards: 1. Daemon classifies poisoned terminal output and routes it through the blocked path with failure_reason set ('iteration_limit' / 'agent_fallback_message'). GetLastTaskSession excludes failed tasks with those reasons, so even comment-triggered tasks no longer resume them. Tasks that failed mid-flight (timeout, runtime_recovery, etc.) are still resumable, preserving MUL-1128's auto-retry contract. 2. Manual rerun marks the new task force_fresh_session=true. The daemon claim handler skips the resume lookup entirely when the flag is set, capturing the user-intent signal that "the prior output was bad" even when poisoned classification misses a future fallback wording. Auto-retry of orphaned mid-flight failures (MaybeRetryFailedTask → CreateRetryTask) does not take this path, so it keeps resuming. Tests: classifyPoisonedOutput unit test; integration tests assert the SQL filter excludes poisoned classifiers, RerunIssue flips the flag, and the normal enqueue path leaves it false. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): cap poisoned-output matcher to short trimmed text GPT-Boy review on MUL-1630: the previous strings.Contains match would classify any output that quoted the marker substring — including a review/analysis that simply discussed the marker itself. Real fallback messages are short single-sentence affairs, so cap the candidate at ~one paragraph and trim whitespace before matching. Adds regression tests covering a long quoting review and a marker buried in a long real conclusion; both must stay classified as completed. Co-authored-by: multica-agent <github@multica.ai> * fix(migrations): rename 065 force_fresh_session → 066 to clear collision main introduced 065_project_resources after this branch was cut, so both files shared the 065_ prefix. The readiness check (server/cmd/server/health.go → migrations.LatestVersion) takes the last entry by lexical order, which is 065_project_resources, leaving this branch's 065_force_fresh_session unguarded — a deploy that applied project_resources but not force_fresh_session would still report ready, and the next enqueue / rerun / claim would crash on "column force_fresh_session does not exist". Renaming to 066_force_fresh_session puts it strictly after project_resources so readiness blocks until it's applied. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-04-30 14:17:53 +08:00
Bohan Jiang	44608713bb	feat(projects): typed project resources + agent runtime injection (#1926) ... * feat(projects): typed project resources + agent runtime injection Adds a `project_resource` table that lets a project carry typed pointers (github_repo today, more later) and surfaces them at agent runtime. Server - migration 065: project_resource (resource_type TEXT + resource_ref JSONB) - sqlc CRUD + handler at /api/projects/{id}/resources - claim handler attaches project_id/title + resources to issue tasks Daemon - TaskContextForEnv carries project context - writes .multica/project/resources.json into workdir - adds "## Project Context" block to CLAUDE.md / AGENTS.md / GEMINI.md via type-dispatched formatter so new resource types just add a case CLI - multica project create --repo <url> attaches repos in one step - multica project resource add/list/remove Frontend - Project create modal: Repos pill (workspace repos + ad-hoc URL) - Project detail sidebar: collapsible Resources section with attach/remove Docs - New "Project Resources" chapter explaining the abstraction and exactly what code to touch when adding a new resource type Co-authored-by: multica-agent <github@multica.ai> * fix(projects): transactional resources[] on create + generic CLI ref + test fix Addresses review feedback on PR #1926: 1. CI red: TestProjectResourceLifecycle delete step called withURLParam twice, which replaced the chi route context and dropped the project id. Switched to the existing withURLParams helper from daemon_test.go. 2. POST /api/projects now accepts resources[] and attaches them in the same transaction as the project. Invalid refs roll back the whole create — no more half-attached projects on failure. Web modal + CLI `project create --repo` both use the new bundled payload. 3. CLI `project resource add` now accepts a generic --ref '<json>' flag so a new resource_type works without a CLI change. Per-type shortcuts (--url for github_repo) remain as a convenience but are no longer the only way in. Docs updated to drop the CLI from the "files you must touch" list. Adds two new server handler tests: - TestCreateProjectAttachesResources (resources[] happy path) - TestCreateProjectRollsBackOnInvalidResource (transactional rollback) Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-04-30 14:00:43 +08:00
Jiayuan Zhang	8c9c52b023	feat(inbox): add notification preferences to control inbox noise by event type (#1906) ... Users can now mute specific notification categories (assignments, status changes, comments & mentions, priority/due-date updates, agent activity) from Settings > Notifications. Muted event types are silently filtered at notification creation time — no inbox items are created for muted groups. - Add notification_preference table (migration 064) - Add GET/PUT /api/notification-preferences endpoints - Filter notifications in notifyIssueSubscribers, notifyDirect, and notifyMentionedMembers based on user preferences - Add Notifications tab in Settings with per-group toggle switches	2026-04-29 22:51:29 +02:00
Naiyuan Qing	4ad0a0b847	feat(chat): presence v4 — status pill, failure bubble, elapsed timing (#1856) ... A complete UX upgrade for chat sending → receiving → recovering. * StatusPill replaces the orphan spinner — stage-aware copy ("Reading files · 12s", "Searching the web · 14s", "Typing · 24s"), shimmer text, monotonic timer, derived effective status, > 60s warning tone, > 5min cancel button. * WS writethrough on task:queued / task:dispatch / task:cancelled so pendingTask cache stays in sync with the daemon state machine without invalidate-refetch latency. broadcastTaskDispatch now includes chat_session_id when the task is for a chat session — the existing payload only carried it on the generic task: events, leaving the pill stuck at "Queued" until completion. * Failure fallback — FailTask writes a chat_message tagged with failure_reason (mirrors the issue path's system comment, gated on retried==nil). Front-end renders an inline note ("Connection failed", with a Show details collapsible) instead of the previous black hole. * Elapsed timing — chat_message.elapsed_ms persists task.completed_at - task.created_at on success/failure rows. UI shows "Replied in 38s" / "Failed after 12s" beneath assistant bubbles. Format helper shared between StatusPill and the persisted caption so the live timer and final reading never disagree. * Optimistic burst rebalanced — pendingTask seed + created_at moved before the HTTP roundtrip so the pill appears the instant the user hits send; handleStop is fire-and-forget so cancel feels immediate (server confirmation arrives via task:cancelled WS). * Presence integration — chat avatars use ActorAvatar (status dot + hover card); OfflineBanner above the input on offline/unstable; SessionDropdown shows per-row in-flight/unread pip plus a cross-session aggregate pip on the closed trigger. * Editor blur on send so the caret stops competing with the StatusPill / streaming reply for the user's attention. * Chat panel isOpen now persists globally; defaults to OPEN for new users (storage key absence) so the feature is discoverable. Existing users' prior choice is respected. * DB: migrations 062 (failure_reason) + 063 (elapsed_ms), both ADD COLUMN NULL — fast, non-blocking, backwards compatible. * WS: task:failed chat path now invalidates chatKeys.messages — fixes a pre-existing bug where the failure bubble required a page refresh to appear. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 18:29:46 +08:00
Naiyuan Qing	f745a3bbbe	feat(agent): presence v3 + execution log + trigger summary (#1823) ... * refactor(views): migrate agent/runtime/skill lists to TanStack DataTable Replace the per-page CSS Grid + minmax(min, fr) + sticky-first-col + truncate implementation with a TanStack Table backend rendered through a Dice UI-style DataTable shell. Column widths are now px-based via column.size, so cells no longer shrink or auto-truncate as the viewport narrows; when the sum of columns exceeds the viewport, the container scrolls horizontally instead. - Add @tanstack/react-table to the catalog (8.21.3) and wire it into packages/ui (dep) and packages/views (peerDep). - packages/ui: new DataTable + DataTableColumnHeader + lib/data-table.ts (getColumnPinningStyle), adapted from Dice UI's registry. The shell renders <table> directly (skipping shadcn's <Table> wrapper) so its own outer overflow controls both axes — no nested overflow conflicts. - packages/views: each list now declares ColumnDef[] with explicit cell renderers. Row click navigates to detail via onRowClick (instead of wrapping <tr> in <a>, which is invalid HTML); kebab dropdowns stopPropagation so they don't trigger the row navigation. - Drop the previous AGENT_LIST_GRID / GRID_WITH_OWNER / ROW_GRID templates and the sticky-first-col / subgrid mechanics that came with them. agent-list-item.tsx is removed; runtime-list.tsx and skills-page.tsx are trimmed to thin wrappers. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(agent): cap description at 255 chars (db + api + ui) Symmetric enforcement across DB, server, and UI: - Migration 060: pre-flight truncate of any oversize rows, then ADD CONSTRAINT NOT VALID + VALIDATE CONSTRAINT so the new check doesn't block writes during validation. - Server handler validates utf8.RuneCountInString on Create/Update and rejects over-limit input with 400. - Front-end gets AGENT_DESCRIPTION_MAX_LENGTH in core/agents/constants (single source of truth shared by the create dialog + edit modal + test suite) and a CharCounter component that warns at 90% and errors past the cap. - Description editor moves from a 288px popover to a roomy modal. Editor body is mounted only while the dialog is open, so the local draft state is locked in at mount time and never reset by an external WS update — the React-recommended replacement for the useEffect(reset, [value]) anti-pattern. Counted in code points everywhere (rune count / spread length / char_length) so multibyte input agrees across all three layers. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(views): data-table polish across runtime + skill lists Builds on the DataTable migration in 2be0f287: - Add ColumnMeta.grow flag — declared via TanStack module augmentation in ui/lib/data-table.ts. Columns marked meta.grow skip their inline width so fixed table-layout assigns them the leftover container space (no spacer column). The Title-grows / others-fixed pattern from Linear / GitHub PR rows. - Authoritative table min-width = sum of column.size, applied to the <table> itself (fixed-layout ignores cell-level min-width per spec, so the floor has to live on the table). - Header tightens to h-8 + uppercase + tracking-wider; pinned cells switch to opaque bg + group-hover so they cover content scrolling beneath them and follow row hover state. - Toolbar slot removed from DataTable (callers wrap the toolbar themselves now — keeps DataTable single-purpose). Also: hover-card popup stops contextmenu / auxclick / dblclick from bubbling out (in addition to click). Stops the popup from triggering ancestor handlers (e.g. issue list rows) on right-click / middle-click without breaking Base UI's outside-click dismiss, which listens to pointerdown — pointerdown is deliberately NOT stopped. Runtime + skill list pages updated to use the new sizing model. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * refactor(agent): drop LastTaskState, introduce 3-state Workload Continues the presence-model rework started in #1794 / #1798. The previous LastTaskState union (running / completed / failed / cancelled / idle) carried historical outcome at the list level — a runtime-healthy agent whose last task failed showed a sticky red dot indistinguishable from a daemon-dead agent. New model: presence is two orthogonal "right-now" dimensions: AgentAvailability — runtime reachability only (online / unstable / offline). Drives the dot colour everywhere. Workload — current load (working / queued / idle). Three states, never historical. Failure / completion / cancellation are surfaced via Recent Work + Inbox, not list-level state. `queued` (= nothing running, ≥1 queued) is an honest "stuck on offline runtime" signal. To avoid amber flashes during the brief enqueue→claim race on healthy runtimes, the queued chip composes with availability: muted on online, warning amber otherwise. Activity tab cleanup that follows from the new model: - failureReasonLabel relocated from agents/presence.ts to tabs/task-failure.ts (presence no longer owns historical state). - Recent Work paginates (5 initial, +20 per "Show more"); chat-session tasks are filtered out of every Agent-scoped surface to keep "team work" separate from private chat. - Agents page drops the lastTaskFilter chip group; users find broken agents via Inbox / Recent Work, not a list-level filter. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(task): trigger summary snapshot + task:queued lifecycle event Two task-lifecycle improvements that ship together because they share the same enqueue/retry hot paths and changes interleave inside task.go: 1. trigger_summary snapshot (migration 061) New nullable column on agent_task_queue. Comment-triggered tasks snapshot the comment content; autopilot tasks snapshot the run title. Truncated to 200 runes via strings.Builder so multibyte input counts correctly without O(N²) concatenation. Snapshot survives source edits/deletes — every task row self-describes across surfaces (issue detail Execution log, agent activity tooltip, inbox) without joining back to the originating row. Retry rows inherit the parent's snapshot (CreateRetryTask SELECT) so the description stays meaningful across attempts. The UI is responsible for stacking "Retry #N" context on top. 2. task:queued WS event New protocol event covering the ∅ → queued transition. Front-end types/events.ts registers it; use-realtime-sync's task: prefix path already invalidates task caches via onAny, so old clients without this exact-match subscription still refresh correctly. Specific subscribers (sticky banner) get sub-second updates instead of waiting for daemon claim. Retry path now broadcasts task:queued (not task:dispatch) — same status transition shape as enqueue, so all "new task created" paths agree on one event type. Ordering: broadcastTaskEvent runs *before* notifyTaskAvailable so the queued event is published into the WS bus before the daemon is poked. Without this, a fast daemon could claim and emit task:dispatch over the wire before the in-process queued broadcast fan-out reached clients — race window is tiny but unsafe-by-construction. Per-agent task list (agentTasksKeys.all) and per-issue task list (["issues","tasks"]) added to the task: invalidation set so Activity tab Recent Work and the Execution log section stay fresh. Type contracts: AgentTask gains parent_task_id / attempt / trigger_comment_id (already returned by the API, just missing from TS) plus the new trigger_summary field. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * feat(issue): ExecutionLogSection — unified active+past runs panel Replaces two pieces: - the click-to-expand timeline that lived inside AgentLiveCard - the standalone TaskRunHistory below the main content with a single right-panel section that lists every agent run for the issue. Active runs sit at the top (always visible when present); past runs collapse behind a "Show past runs (N)" toggle, sorted failed → cancelled → completed within group. Active rows show the trigger summary, status + relative time, and Cancel / Transcript actions on hover (gradient backdrop fades the status text rather than hard-clipping). Past rows show the same shape minus Cancel. Retry tasks prepend "Retry #N · " to the inherited summary so they're distinguishable from their parent (which would otherwise share the exact same trigger text). Cache key registered as issueKeys.tasks(issueId); the global useRealtimeSync task: prefix path already invalidates ["issues","tasks"] on every task lifecycle event, so the section stays fresh without local WS subscriptions. AgentLiveCard slims down to a header-only "agent is working" sticky banner — keeps the at-a-glance "is anyone working on this right now" signal and the Stop / Transcript actions, drops the inline timeline that ExecutionLogSection now owns. Subscribes to both task:queued and task:dispatch so retries (which only emit queued) land in the banner without waiting for daemon claim. issue-detail mounts ExecutionLogSection in the right panel and removes the now-defunct TaskRunHistory call site. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-04-29 14:50:58 +08:00
Ayman Alkurdi	e9d04ecfc1	feat(labels): ship issue labels (closes #1191) (#1233) ... * feat(labels): add issue label CRUD + attach/detach handlers (#1191) The issue_label and issue_to_label tables were scaffolded in 001_init.up.sql but never wired to any code path. This commit ships the backend for #1191: - Migration 048: adds created_at/updated_at timestamps + workspace-scoped case-insensitive unique index on label names - sqlc queries for label CRUD + issue<->label attach/detach + batch list (ListLabelsByIssueIDs for board/list views) - HTTP handlers: /api/labels CRUD, /api/issues/{id}/labels attach/detach - Protocol events: label:{created,updated,deleted} + issue_labels:changed - Handler tests covering CRUD, duplicate-name conflict, invalid-color, attach/detach idempotency, and cross-workspace isolation * feat(cli): add label and issue label subcommands (#1191) - multica label {list,get,create,update,delete} - multica issue label {list,add,remove} Both follow existing CLI conventions (JSON/table output, flag shapes) and exercise the /api/labels endpoints shipped in the previous commit. * feat(web): add labels UI — picker with inline create + management dialog (#1191) Exposes the backend label feature to users via the existing issue-detail sidebar. - `@multica/core/types/label` — Label, CreateLabelRequest, UpdateLabelRequest, plus response envelopes - `@multica/core/api/client` — 8 methods for label CRUD and issue↔label attach/detach - `@multica/core/labels` — labelKeys, queryOptions, and mutation hooks with optimistic updates (matches the project/ module layout) - WS event type literals extended for label:{created,updated,deleted} and issue_labels:changed - `views/labels/label-chip.tsx` — colored pill; uses relative luminance (ITU-R BT.601) to pick #111827 or #f9fafb text so chips stay readable on both pastel and saturated backgrounds - `views/issues/components/pickers/label-picker.tsx` - Multi-select combobox in the issue sidebar - When 0 labels: "Add label" trigger - When 1+ labels: the chips themselves are the trigger; × on each chip detaches without opening the picker - Inline create: typing a new name + Enter creates with a hash-derived color and attaches in one motion (matches Linear/GitHub) - "Manage labels…" footer opens a dialog containing the full workspace panel — users never leave the issue context to rename/recolor/delete - `views/issues/components/labels-panel.tsx` — workspace labels manager. Single-row create form (color swatch + name + Add button). Each label row supports inline rename + recolor + delete (with confirm dialog). Color input uses the browser's native picker for full-gamut access — no preset palette clutter. - `PropRow label="Labels"` added to the issue-detail sidebar below Project Labels are issue metadata everyone uses — not admin configuration. Putting them in Settings next to destructive workspace actions misframed them; adding a top-level nav entry or a sibling tab to the Issues page added surface area that wasn't earning its keep for a feature users touch occasionally. Keeping management in a dialog launched from the picker itself keeps users in their issue context and matches how GitHub handles label editing from the label selector.	2026-04-27 14:23:42 +08:00
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>	2026-04-24 11:05:33 +08:00
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>	2026-04-23 10:35:55 +08:00
LinYushen	0b1333fb00	feat(server): orphan-task recovery + auto-retry + manual rerun (MUL-1128) (#1476) ... * feat(server): orphan-task recovery + auto-retry + manual rerun (MUL-1128) When the daemon process crashed mid-task the issue was stuck at in_progress for up to 2.5h: the in-flight task timeout was the only mechanism that ever moved the row, and the runtime heartbeat sweeper only fires after the runtime stays offline for 45s — a quick restart beats both windows. This change implements the A+B plan from the issue thread: A. lifecycle hygiene - migration 055 adds attempt / max_attempts / parent_task_id / failure_reason / last_heartbeat_at to agent_task_queue - new daemon-auth endpoint POST /runtimes/{id}/recover-orphans: daemon calls it on every register so the server fails any dispatched/running tasks the previous process left behind - new daemon-auth endpoint POST /tasks/{id}/session: persists the agent's session_id + work_dir mid-flight so a crash doesn't lose the resume pointer (claude+codex emit MessageStatus with SessionID; daemon forwards on the first one it sees) - FailAgentTask / FailStaleTasks / FailTasksForOfflineRuntimes now set failure_reason ('agent_error' / 'timeout' / 'runtime_offline') B. auto-retry with resume context - TaskService.MaybeRetryFailedTask spawns a fresh queued attempt carrying parent's session_id/work_dir when the failure reason is infrastructure-shaped (timeout, runtime_offline, runtime_recovery) and attempt < max_attempts; skips autopilot - wired into the runtime sweeper paths and TaskService.FailTask so the user transparently sees a new in_progress run instead of a stuck row - new user-auth POST /api/issues/{id}/rerun + multica issue rerun CLI for the manual escape hatch Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> * fix(server): address PR review for orphan-task recovery (MUL-1128) Three review-must-fix items on top of the A+B implementation: 1. recover-orphans now funnels through TaskService.HandleFailedTasks, the same shared post-failure pipeline used by the runtime sweeper. This guarantees task:failed events are emitted, agent status is reconciled, and issues stuck in_progress with no remaining active task are reset to todo even when no auto-retry is created (max_attempts exhausted, autopilot, non-retryable reason). 2. RerunIssue now uses CancelAgentTasksByIssueAndAgent, scoped to the issue's current assignee. The previous implementation called CancelAgentTasksByIssue, which would collateral-cancel parallel @-mention agents on the same issue. 3. GetLastTaskSession now considers both completed and failed tasks (mirroring GetLastChatTaskSession), ordering by the most recent timestamp. With UpdateAgentTaskSession pinning session_id/work_dir mid-flight, an auto-retry or manual rerun of a daemon-crash failure now actually resumes the prior conversation context instead of starting fresh — matching the stated B-branch behaviour. go build / go vet pass; the existing service and agent test suites pass. runtime_sweeper / handler integration tests require a local DB with the 055 migration (and the pre-existing 050 first_executed_at column). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>	2026-04-22 13:08:37 +08:00
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>	2026-04-21 20:32:33 +08:00
devv-eve	637bdc8eb3	feat(analytics): full PostHog pipeline + 6 funnel events (MUL-1122) (#1367) ... * feat(analytics): add PostHog client with async batch shipping Introduces server/internal/analytics, the shipping layer for the product funnel defined in docs/analytics.md. Capture is non-blocking — events are enqueued into a bounded channel and a background worker batches them to PostHog's /batch/ endpoint. A broken backend drops events rather than blocking request handlers. Local dev and self-hosted instances run a noop client until the operator sets POSTHOG_API_KEY. This is PR 1 of MUL-1122; signup and workspace_created emission land in the follow-up commit so this change is independently reviewable. * feat(server): emit signup and workspace_created analytics events Wires analytics.Client through handler.New and main, then emits the first two funnel events: - signup fires from findOrCreateUser (which now reports isNew), covering both the verification-code and Google OAuth entry points — a single emission site guarantees Google signups aren't missed. - workspace_created fires after the CreateWorkspace transaction commits, with is_first_workspace computed from a post-commit ListWorkspaces count so we can distinguish fresh-user activation from returning-user expansion. Tests use analytics.NoopClient so nothing ships from test runs. PR 1 of MUL-1122; runtime_registered and issue_executed follow in later PRs per the plan. * refactor(analytics): drop is_first_workspace from workspace_created Stamping "is this the user's first workspace?" at emit time races under concurrent CreateWorkspace requests: two transactions committing close together can both read a post-commit count greater than one and both emit false. Fixing it at the SQL layer requires a schema change we don't want in PR 1. PostHog answers the same question exactly from the event stream (funnel on "first time user does X" / cohort on $initial_event), so removing the property loses no information and makes the emit side race-free. * docs(analytics): document self-host safety defaults Spell out why self-hosted instances never ship events upstream by default (empty POSTHOG_API_KEY → noop client) and explain how operators can point at their own PostHog project without any code change. * feat(analytics): emit runtime_registered, issue_executed, team_invite_* Three server-side funnel events, all gated on first-time state transitions so retries and re-runs don't inflate the WAW buckets: - runtime_registered fires from DaemonRegister when UpsertAgentRuntime reports (xmax = 0) — i.e. the row was inserted, not updated. Heartbeats and re-registrations stay silent. - issue_executed fires from CompleteTask after an atomic UPDATE issue SET first_executed_at = now() WHERE id = $1 AND first_executed_at IS NULL flips the column for the first time. Retries, re-assignments, and comment-triggered follow-up tasks hit the WHERE clause and no-op. Carries nth_issue_for_workspace so the ≥1/≥2/≥5/≥10 buckets filter without extra queries. - team_invite_sent fires from CreateInvitation and team_invite_accepted from AcceptInvitation, closing the expansion funnel. Adds a 050 migration for issue.first_executed_at plus a partial index so the workspace-scoped executed-count query doesn't scan the never-executed tail. * feat(config): surface PostHog key via /api/config Extends AppConfig with posthog_key / posthog_host sourced from env on every request (so operators can rotate the key via secret refresh without a restart). Reading the key off the server — rather than baking it into the frontend bundle via NEXT_PUBLIC_* — means self-hosted instances inherit the blank key automatically and never ship events upstream. * feat(analytics): wire posthog-js identify + UTM capture on the client Adds @multica/core/analytics — a thin wrapper around posthog-js that owns attribution capture and identity merge. Posthog-js config comes from /api/config (not NEXT_PUBLIC_*), so self-hosted instances whose server returns an empty key automatically run the SDK inert. captureSignupSource stamps a multica_signup_source cookie with UTM params and the referrer's origin (never the full referrer — that can leak OAuth code/state in the callback URL). The backend signup event reads this cookie on new-user creation. Identity flows: - auth-initializer fires identify() right after getMe() resolves, on both cookie and token paths. A getConfig/getMe race is handled by buffering a pending identify inside the analytics module and flushing it once initAnalytics finishes. - auth store calls identify() on verifyCode / loginWithGoogle / loginWithToken and resetAnalytics() on logout so the next login merges cleanly without bleeding events. * docs(analytics): describe runtime_registered, issue_executed, invite events Fills in the schema for the remaining funnel events. Captures the design commentary that belongs next to the contract rather than in a PR description — in particular why issue_executed uses the atomic first_executed_at flip instead of counting task-terminal events, and why runtime_registered relies on xmax = 0 rather than a query-then-write. * fix(analytics): drop non-atomic nth_issue_for_workspace from issue_executed Computing the workspace's Nth-issue ordinal at emit time is not atomic under concurrent first-completions — two transactions can both run MarkIssueFirstExecuted, then both run CountExecutedIssuesInWorkspace, and both observe count=1 before either has committed, so both events go out stamped as n=1. Serialising it would mean a per-workspace advisory lock or a SERIALIZABLE-isolated tx; PostHog answers the same question exactly at query time via row_number() partitioned by workspace_id, so the emit-time property adds risk without adding information. Removes the property from analytics.IssueExecuted, deletes the unused CountExecutedIssuesInWorkspace query, and regenerates sqlc. The partial index stays — any future workspace-scoped executed-issue query will want it. * fix(analytics): wire $pageview and harden signup_source cookie payload Two frontend fixes from the PR review: - PageviewTracker, mounted under WebProviders, fires capturePageview on every Next.js App Router path / query-string change. Without this the capturePageview helper in @multica/core/analytics was never called and the acquisition funnel's / → signup step was empty. - captureSignupSource now caps each UTM / referrer value at 96 chars *before* JSON.stringify, and drops the whole cookie when the serialised payload still exceeds 512 chars. Previously the overall slice(0, 256) could leave a half-JSON string on the wire that neither the backend nor PostHog could parse. Both capturePageview and identify now buffer a single pending call when fired before initAnalytics resolves — otherwise the initial "/" pageview and same-turn login identify race the /api/config fetch and get dropped. resetAnalytics clears both buffers so a logout→login cycle stays clean. * fix(analytics): URL-decode signup_source cookie on read Go does not URL-decode Cookie.Value automatically, so the frontend's JSON-then-encodeURIComponent payload was landing in PostHog as percent-encoded garbage (%7B%22utm_source...). Unescape on read so the backend receives the original JSON string the frontend intended, and drop values that fail to decode or exceed the server-side cap — sending truncated garbage is worse than sending nothing. Oversized-cookie guard matches the frontend's SIGNUP_SOURCE_MAX_LEN. * docs(analytics): reflect nth-issue drop, $pageview wiring, cookie encoding Pulls the schema doc back in line with the code: issue_executed no longer advertises nth_issue_for_workspace (with a note about why PostHog derives it at query time instead), the frontend $pageview section names the actual PageviewTracker component that fires it, and the signup_source section documents the per-value cap / overall drop rule and the encode-on-write / decode-on-read contract. --------- Co-authored-by: Jiang Bohan <bhjiang@outlook.com>	2026-04-21 14:42:52 +08:00
Jiayuan Zhang	b291db11c2	feat(agents): add per-agent model field with provider-aware dropdown (#1399) ... Adds a first-class `model` field on agents so users can pick the LLM model from the create / settings UI instead of editing `custom_env` / `custom_args`. Each provider's dropdown is populated from the live CLI when possible (`opencode models`, `pi --list-models`, `openclaw agents list --json`, `cursor-agent --list-models`, hermes ACP `session/new` → `SessionModelState`), with a static catalog for providers that don't enumerate. Daemon resolves the runtime model as `agent.model → MULTICA_<PROVIDER>_MODEL → ""` — empty passes through so each backend's CLI picks its own default, avoiding static-guess drift. Per-provider honouring: - Claude / Codex / OpenCode / Cursor / Gemini / Pi / Copilot — CLI `--model` / thread payload. - OpenClaw — `opts.Model` is mapped to `--agent <name>` (the CLI rejects `--model`). - Hermes — `session/set_model` ACP RPC; stderr is sniffed for provider-level errors so HTTP 4xx from the configured LLM surfaces instead of "empty output"; explicit-model failures mark the task `failed`. Supporting changes: migration 050 adds `agent.model`; daemon ↔ server heartbeat piggyback carries a model-discovery request; new REST endpoints under `/api/runtimes/{id}/models`; `multica agent create --model` / `update --model`; shared `ModelDropdown` in `packages/views/agents` (searchable, creatable, provider-grouped, default-badge, runtime-supported gate).	2026-04-21 00:06:34 +08:00
Korkyzer	63800f05ff	fix(agent): add per-agent mcp_config field to restore MCP access (#1168) ... * fix(agent): add per-agent mcp_config field to restore MCP access Closes #1111 The --strict-mcp-config flag was added defensively in #592 to prevent Claude agents from inheriting MCP state from the outer Claude Code session. It was meant to be paired with --mcp-config <path> to inject a controlled set of MCPs, but that path was never implemented, which silently stripped all user-scope MCPs from spawned agents. This PR completes the original design by: - Adding a nullable mcp_config jsonb column to the agents table - Wiring mcp_config through AgentResponse, Create/Update requests - Piping it into ExecOptions.McpConfig in the daemon - Serializing to a temp file and passing --mcp-config <path> in buildClaudeArgs - Blocklisting --mcp-config in claudeBlockedArgs to prevent override via custom_args Does not touch Codex provider (tracked separately in #674). Does not implement Multica MCP auto-injection (out of scope). * fix: disambiguate JSON null vs absent for mcp_config	2026-04-18 01:35:22 +08:00
Bohan Jiang	a73336dcf8	feat(daemon): persistent UUID identity + legacy-id merge at register-time (#1220) ... * feat(daemon): persistent UUID identity + legacy-id merge at register-time daemon_id is now a stable UUID persisted to `<profile-dir>/daemon.id` on first start, replacing the hostname-derived id that drifted whenever `.local` appeared/disappeared, a system was renamed, or a profile switched — each of which used to mint a fresh `agent_runtime` row and strand agents on the old one. To migrate existing installs without operator intervention, the daemon reports every legacy id it may have registered under previously (`host`, `host` with `.local` stripped, and `host[-profile]` variants for both). At register-time the server looks up each candidate row scoped to (workspace, provider), re-points its agents and tasks onto the new UUID-keyed row, records which legacy id was subsumed in the new `legacy_daemon_id` column for audit, and deletes the stale row. Result: users running `xxx.local`-keyed runtimes today transparently land on the new UUID row on next daemon restart. The hostname-prefix `MigrateAgentsToRuntime` / `daemon_id LIKE '...-%'` compatibility shim is no longer needed and has been removed along with the handler call that invoked it. * fix(daemon): handle bidirectional .local drift and case drift in legacy merge Review on #1220 flagged two gaps in the legacy-id migration candidate set: 1. Reverse .local: LegacyDaemonIDs only added the stripped variant when the current hostname ended in `.local`. The opposite direction — DB has `foo.local`, current host is `foo` — was missed, so runtimes registered under the `.local` variant stayed orphaned after upgrade. Now both variants (`foo` and `foo.local`) are always emitted, regardless of what `os.Hostname()` currently returns, plus their `-<profile>` suffix forms. 2. Case drift: os.Hostname() has been observed returning different casings on the same machine across mDNS/reboot state. A case-sensitive `=` comparison stranded rows like `Jiayuans-MacBook-Pro.local` when the daemon later reported `jiayuans-macbook-pro.local`. FindLegacyRuntimeByDaemonID now uses `LOWER(daemon_id) = LOWER(@daemon_id)` on both sides, so casing differences merge rather than orphan. The (workspace_id, provider) prefix still bounds the scan to a tiny set of rows so the non-indexed LOWER() comparison has negligible cost. Tests: TestLegacyDaemonIDs gets the mixed-case + reverse-direction cases; daemon_test.go adds TestDaemonRegister_MergesLegacyDaemonIDRuntime_ReverseDotLocal and TestDaemonRegister_MergesLegacyDaemonIDRuntime_CaseDrift. * fix(daemon): consolidate every case-duplicate legacy runtime, not just the first Follow-up review on #1220: after switching to `LOWER(daemon_id) = LOWER(@daemon_id)`, the single-row lookup still only merged one legacy row per candidate. If a machine already had two rows in the DB that differed only in casing (e.g. `Jiayuans-MacBook-Pro.local` AND `jiayuans-macbook-pro.local` coexisting because earlier hostname drift already minted a duplicate), only one of them got consolidated and the other stayed orphaned — violating the "no duplicate runtime per machine after backfill" acceptance. - FindLegacyRuntimeByDaemonID → FindLegacyRuntimesByDaemonID (:many) - mergeLegacyRuntimes iterates every returned row and dedupes across overlapping legacy candidates so `foo` and `foo.local` both resolving to the same stored row don't double-process Test: TestDaemonRegister_MergesAllCaseDuplicateLegacyRuntimes seeds two case-duplicate rows with one agent each and confirms both rows are deleted and both agents end up on the new UUID-keyed row.	2026-04-17 15:10:38 +08:00
Bohan Jiang	a36252ca99	refactor(runtime): derive runtime usage from task_usage only (#1167) ... * refactor(runtime): derive runtime usage from task_usage only The daemon used to scan each runtime's local CLI log directory every 5 minutes (Claude Code, Codex, OpenCode, OpenClaw, Hermes) and post daily aggregates to /api/daemon/runtimes/{id}/usage. Those directories are shared with the user's own local CLI sessions, so the user's personal usage was being counted as Daemon-executed usage. Cursor and Gemini had no scanner at all, so their runtime-level aggregates were always zero. Switch GetRuntimeUsage to aggregate task_usage (already scoped to Daemon-executed tasks) via agent_task_queue.runtime_id. Single source of truth; Cursor/Gemini/Copilot get runtime usage for free; no reliance on external CLI log formats. Removes: - server/internal/daemon/usage/ (all scanners) - Daemon.usageScanLoop + providerToRuntimeMap - Client.ReportUsage - ReportRuntimeUsage handler + POST /api/daemon/runtimes/{id}/usage - UpsertRuntimeUsage / GetRuntimeUsageSummary queries - runtime_usage table (migration 046) Refs: MUL-786 * fix(runtime): bucket daily usage by task_usage.created_at, not enqueue time ListRuntimeUsage was aggregating by DATE(atq.created_at) and filtering on atq.created_at. agent_task_queue.created_at is the enqueue timestamp, which drifts from actual token-production time: a task queued at 23:58 and executed at 00:05 was attributed to yesterday; a task sitting in the queue overnight was counted on the queue day. The ?days=N cutoff also became a rolling window (now() - N) instead of a calendar-day boundary, silently clipping the morning of the earliest day returned. Switch bucket + filter to task_usage.created_at (~= task completion / usage-report time) and snap the since cutoff to start-of-day via DATE_TRUNC. Add a regression test covering both scenarios: cross-midnight task attributes to the day tokens were reported, and the earliest day's pre-cutoff rows are still included.	2026-04-16 18:54:12 +08:00
Bohan Jiang	ce447c7f06	feat(agent): add custom CLI arguments support (#986) ... * feat(agent): add custom CLI arguments support Allow users to configure custom CLI arguments per agent that get appended to the agent subprocess command at launch time. This enables use cases like specifying different models (--model o3), max turns, or other provider-specific flags without needing separate runtimes. Changes: - Add custom_args JSONB column to agent table (migration 041) - Update API handler to accept/return custom_args in create/update - Pass custom_args through claim endpoint to daemon - Append custom_args to CLI commands for all agent backends - Add ExecOptions.CustomArgs field in agent package - Add Custom Args tab in agent detail UI - Add --custom-args flag to CLI agent create/update commands Closes MUL-802 * fix(agent): filter protocol-critical flags from custom_args Add per-backend filtering of custom_args to prevent users from accidentally overriding flags that the daemon hardcodes for its communication protocol (e.g. --output-format, --input-format, --permission-mode for Claude). This follows the same pattern as custom_env's isBlockedEnvKey: we only block the small, stable set of flags that would break the daemon↔agent protocol — not every possible dangerous flag. Workspace members are trusted for everything else. Each backend defines its own blocked set: - Claude: -p, --output-format, --input-format, --permission-mode - Gemini: -p, --yolo, -o - Codex: --listen - OpenCode: --format - OpenClaw: --local, --json, --session-id, --message - Hermes: none (ACP is positional) Includes unit tests for the filtering logic. * fix(agent): address code review nits for custom_args - Replace module-level `nextArgId` counter with `crypto.randomUUID()` in custom-args-tab.tsx to avoid SSR ID conflicts - Add unit tests for custom args passthrough and blocked-arg filtering in both Claude and Gemini arg builders	2026-04-15 14:58:53 +08:00
Jiayuan Zhang	f94b0100cd	refactor(autopilot): remove broken concurrency policies and fix multiple bugs (#1048) ... Remove the concurrency_policy system (skip/queue/replace) — skip had an orphan bug that permanently blocked triggers, queue didn't actually queue, and replace didn't cancel running tasks. Every trigger now simply executes. Bug fixes: - Listener now handles in_review status (was silently ignored) - Issue deletion fails linked autopilot runs before DELETE (prevents orphans) - ComputeNextRun rejects invalid timezones instead of silent UTC fallback - dispatchCreateIssue post-commit failures now properly fail the run Reliability: - Scheduler recovers lost triggers on startup (crash recovery) - New index on autopilot_run(issue_id) for deletion lookups - Migration 043 cleans up historical orphaned/skipped/pending runs	2026-04-15 13:48:21 +08:00
Jiayuan Zhang	d88fe2608e	feat(autopilot): scheduled/triggered automations for AI agents (#1028) ... * feat(autopilot): add scheduled/triggered automation for AI agents Introduce the Autopilot feature — recurring automations that assign work to AI agents on a schedule or manual trigger. Supports two execution modes: create_issue (creates an issue for the agent to work on) and run_only (directly enqueues an agent task without issue pollution). Backend: migration (3 tables + 2 columns), sqlc queries, AutopilotService with concurrency policies (skip/queue/replace), HTTP CRUD + trigger endpoints, background cron scheduler (30s tick), event listeners for issue→run and task→run status sync. Frontend: types, API client methods, TanStack Query hooks with optimistic mutations, realtime cache invalidation, list page with create dialog, detail page with trigger management and run history, sidebar nav + routes for both web and desktop apps. * feat(autopilot): improve UX — trigger config, edit dialog, template gallery - Replace raw cron input with friendly frequency tabs (Hourly/Daily/Weekdays/Weekly/Custom), time picker, and timezone dropdown defaulting to user's local timezone - Fix Select components showing UUIDs instead of names (Base UI render function pattern) - Add Edit button on detail page opening a unified edit dialog - Remove project/concurrency/issue-title-template from create/edit (simplify for users) - Add trigger configuration inline during autopilot creation - Add template gallery on empty state (6 step-by-step workflow templates) - Rename "Description" to "Prompt" throughout UI - Inject autopilot run timestamp into issue description for agent date awareness - Treat issue status "in_review" as run completion (fixes skip on next trigger) - Make migration idempotent with IF NOT EXISTS clauses	2026-04-15 04:54:37 +08:00
Bohan Jiang	ff1d348274	feat(security): invitation acceptance flow for workspace members (#1019) ... * feat(security): replace instant member-add with invitation acceptance flow Users invited to a workspace must now explicitly accept the invitation before becoming a member. This fixes the security vulnerability where knowing someone's email was enough to auto-register their runtime to your workspace. Changes: - Add workspace_invitation table with pending/accepted/declined/expired states - Replace CreateMember with CreateInvitation (same endpoint, new behavior) - Add accept/decline/revoke/list invitation API endpoints - Add invitation WS events for real-time notification - Frontend: invitation accept/decline UI in workspace switcher - Frontend: pending invitations section in members settings tab * fix(invitation): address PR review nits - Fix invitation:revoked listener to send event to invitee user (was no-op) - Remove duplicate queryClient2 in app-sidebar.tsx, reuse existing queryClient - Add expires_at > now() filter to ListPendingInvitationsByWorkspace query	2026-04-15 00:01:18 +08:00
Naiyuan Qing	a744cd4f45	feat(chat): redesign state, header, and unread tracking ... State management - Pending task / live timeline are now Query-cache single source; Zustand mirror removed (fixes duplicate assistant render caused by the invalidate→refetch race window) - WS subscriptions moved from ChatWindow to global useRealtimeSync so pending state survives minimize and refresh - New GET /chat/sessions/:id/pending-task to recover live state on mount - Drafts persisted per-session (was per-workspace) Unread tracking - Migration 040: chat_session.unread_since (event-driven; old chats stay clean — no mass backfill) - POST /chat/sessions/:id/read clears unread; broadcasts chat:session_read so other devices sync - New GET /chat/pending-tasks aggregate for the FAB - ChatFab: brand-color impulse animation while running, brand-dot badge of unread session count - ChatWindow auto-marks read when user is viewing the session Header redesign - Two independent dropdowns: agent (avatar + name + My/Others grouping) at the input bottom-left; session (title + agent avatar) in the header - ⊕ new-chat button replaces the old + and history buttons - Session dropdown lists all sessions across agents with avatars - Empty state: 3 clickable starter prompts that send immediately - Mention link renderer falls through to default span on null — fixes @member/@agent/@all silently disappearing app-wide - User messages render through Markdown - Enter submits in chat input only (with IME guard + codeBlock skip); bubble menu hidden in chat Misc - Partial index on agent_task_queue for fast pending-task lookup - 2 new storage keys added to clearWorkspaceStorage - useMarkChatSessionRead has onError rollback - chat.* namespace logs across store, mutations, components, realtime Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-14 18:21:11 +08:00
Jiang Bohan	4165401d16	feat(agent): support custom environment variables for router/proxy mode ... Add per-agent custom_env configuration that gets injected into the agent subprocess at launch time. This enables users to configure custom API endpoints (ANTHROPIC_BASE_URL), API keys (ANTHROPIC_API_KEY), and cloud provider modes (CLAUDE_CODE_USE_BEDROCK, CLAUDE_CODE_USE_VERTEX) without requiring code changes. Changes: - Migration 040: add custom_env JSONB column to agent table - Backend: custom_env in agent CRUD API + claim endpoint - Daemon: merge custom_env into subprocess environment variables - Frontend: env var editor in agent settings (key-value pairs with visibility toggle for sensitive values) Closes #816 Related: #807, #809	2026-04-13 16:47:56 +08:00
Jiayuan Zhang	9b62485a86	feat: add pin to sidebar for issues and projects (#653) ... * feat: add pin to sidebar for issues and projects Add per-user pinning of issues and projects to the sidebar for quick access. - New `pinned_item` table with per-user, per-workspace scoping - REST API: GET/POST /api/pins, DELETE /api/pins/{type}/{id}, PUT /api/pins/reorder - Sidebar "Pinned" section between Personal and Workspace nav (hidden when empty) - Pin/unpin actions in issue and project detail dropdown menus - Optimistic mutations with WebSocket invalidation for real-time sync Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat: add drag-and-drop reordering and visible pin buttons - Sidebar pinned items now support drag-and-drop reordering via @dnd-kit - Add visible pin/unpin icon button in issue and project detail headers - Add useReorderPins mutation with optimistic updates Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix: remove drag handle and fix page refresh after reorder - Remove GripVertical drag handle — whole item is now draggable, aligning with other sidebar elements - Prevent link navigation after drag using wasDragged ref - Remove onSettled invalidation from reorder mutation to prevent unnecessary refetch after optimistic update Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-10 19:00:25 +08:00
yushen	821b6ece57	merge: resolve conflicts with main (project feature) ... Merge both chat and project types/events/routes. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-09 16:49:55 +08:00
Bohan Jiang	245beed829	feat(projects): add priority attribute to projects (#565) ... Add priority field (urgent/high/medium/low/none) to projects, matching the existing issue priority system. Includes database migration, API support for create/update/list filtering, and UI for the create dialog, project list table, and project detail page.	2026-04-09 16:31:05 +08:00
Bohan Jiang	68e2a14ba2	feat(projects): add Project entity with full-stack CRUD support (#552) ... Implements the Project concept as a higher-level grouping for issues. Hierarchy: workspace → project → issue → sub-issue. Backend: - Migration 034: project table + issue.project_id FK - sqlc queries for project CRUD - Project handler with list/get/create/update/delete - Issue handler updated to support project_id in create/update - Routes at /api/projects, WebSocket event constants Frontend (new monorepo structure): - @multica/core: Project types, API client methods, queries/mutations, status config, realtime sync - @multica/views: Projects list page, detail page (overview + issues tabs), project picker for issue detail panel - apps/web: Route pages, sidebar navigation entry All TypeScript type checks and tests pass.	2026-04-09 14:59:16 +08:00
yushen	f9a430e100	merge: resolve conflicts with main branch monorepo extraction ... Update chat feature imports to use new package paths: - @/shared/types → @multica/core/types - @/shared/api → @/platform/api - @core/* → @multica/core/* - @/features/realtime → @multica/core/realtime - @/components/ui/* → @multica/ui/components/ui/* Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-09 14:49:47 +08:00
yushen	50f9e673e8	feat(chat): add agent chat feature (full stack) ... Implement the Master Agent chat feature allowing users to chat with agents directly from a floating window, separate from the issue-based workflow. Backend: - New chat_session and chat_message tables (migration 033) - Make issue_id nullable on agent_task_queue for chat tasks - REST API: create/list/get/archive sessions, send/list messages - EnqueueChatTask in TaskService with session_id persistence - WS events: chat:message, chat:done - Daemon: chat task type with separate prompt builder - ClaimTaskByRuntime populates chat context (session, message, repos) Frontend: - ChatSession/ChatMessage types + API client methods - core/chat: TanStack Query options, mutations with optimistic updates, WS updaters - features/chat: Zustand store, ChatFab (floating button), ChatWindow with real-time streaming via task:message events - Mounted in dashboard layout (bottom-right corner) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-09 14:19:46 +08:00
LinYushen	ff27a249cc	feat(runtime): add owner tracking, filtering, and delete (#535) ... Add owner_id to agent_runtime table to track who registered each runtime. Backend: new delete endpoint with role-based permissions (owner/admin can delete any, members only their own), list filtering by owner (?owner=me), and agent dependency check before deletion. Frontend: Mine/All filter toggle in runtime list, owner display in list items and detail view, delete button with AlertDialog confirmation. Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-09 13:38:46 +08:00
Bohan Jiang	8403c97688	Merge pull request #482 from multica-ai/agent/j/674c6839 ... feat(usage): add per-task token usage tracking	2026-04-08 14:16:59 +08:00
Jiang Bohan	8a8d3ea20e	feat(usage): add per-task token usage tracking ... Extract token usage from Claude Code's stream-json output in real-time during task execution, replacing the inaccurate global JSONL log scanner. - New `task_usage` table: tracks (task_id, provider, model) level usage - Agent SDK: parse `message.usage` from assistant messages, accumulate per-model and return in Result - Daemon: convert agent usage to entries, send with CompleteTask - Server: store usage on task completion, expose workspace-level aggregation APIs (GET /api/usage/daily, GET /api/usage/summary)	2026-04-08 13:08:15 +08:00
devv-eve	7c79611309	refactor: remove agent triggers config field (#469) ... * refactor: remove agent triggers config field Remove the triggers field from agent configuration. The on_assign, on_comment, and on_mention behaviors are now always enabled (hardcoded), as decided in the Agentflow design discussion (MUL-372). Changes: - Database: migration 032 drops triggers column from agent table - Backend: remove triggers from create/update agent APIs and response - Backend: simplify trigger-checking logic to always-enabled - Frontend: remove TriggersTab UI and AgentTrigger types - Tests: remove trigger config unit tests (no longer configurable) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * refactor: also remove agent tools config field Remove the tools field from agent configuration alongside triggers. The tools field was a placeholder — stored in the DB and shown in the UI but never passed to the daemon or used at runtime. - Database: migration 032 now also drops tools column - Backend: remove tools from create/update agent APIs and response - Frontend: remove ToolsTab UI, AgentTool type, and tools tab - Update landing page copy Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(test): remove tools/triggers columns from test fixtures The test fixtures still referenced the dropped tools and triggers columns when inserting agent rows, causing CI failures. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Devv <devv@Devvs-Mac-mini.local> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-07 22:02:28 +08:00
LinYushen	09764c5f51	feat(agent): replace hard delete with archive/restore (#346) ... * feat(agent): replace hard delete with archive/restore Replace agent deletion with soft archive pattern. Archived agents are preserved in the database with all historical references intact but cannot be assigned, mentioned, or trigger tasks. Backend: - Add archived_at/archived_by columns to agent table (migration 031) - Replace DELETE /api/agents/{id} with POST /api/agents/{id}/archive - Add POST /api/agents/{id}/restore endpoint - ListAgents excludes archived by default (?include_archived=true to include) - Skip archived agents in task triggers (on_assign, on_comment, on_mention) - Block assignment to archived agents - Cancel pending tasks on archive - New events: agent:archived, agent:restored (replacing agent:deleted) Frontend: - Agent type includes archived_at/archived_by fields - Mention autocomplete and assignee picker filter out archived agents - Agent list shows archived agents with muted styling - Agent detail shows archive banner with restore button - Delete button replaced with Archive button and updated confirmation dialog - API client: archiveAgent/restoreAgent replace deleteAgent Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(agent): self-review fixes for archive feature - Fix: workspace store now fetches agents with include_archived=true so archived agents are actually visible in the frontend (the archived UI was dead code before — ListAgents excludes archived by default) - Fix: add error logging for CancelAgentTasksByAgent in ArchiveAgent - Fix: add idempotency guards — return 409 Conflict when archiving an already-archived agent or restoring a non-archived agent - Fix: revert unnecessary extra GetAgent query in ReconcileAgentStatus (archived agents won't have running tasks after CancelAgentTasksByAgent) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-04-02 17:33:52 +08:00
yushen	114d2a3acf	Merge remote-tracking branch 'origin/main' into fix/s3-cleanup-on-delete ... # Conflicts: # server/pkg/db/generated/models.go	2026-03-31 16:49:32 +08:00
yushen	79cd2a3a5d	fix(upload): link attachments to comments via client-side ID tracking ... Instead of regex-parsing markdown content to find attachment URLs (fragile), the frontend now tracks uploaded attachment IDs and sends them with the comment creation request. The backend links them by ID. Frontend: upload returns attachment ID, comment/reply inputs collect IDs during editing session, pass as attachment_ids on submit. Backend: CreateComment accepts attachment_ids, links by ID+issue scope. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-31 16:47:27 +08:00
Jiang Bohan	b8c784dda3	merge: resolve conflicts with main ... - Take main's router.go, rich-text-editor.tsx, comment-card.tsx - Remove deleted daemon_pairing.go - Keep issue mention card feature	2026-03-31 16:25:20 +08:00
Jiayuan	afdfee78b9	feat(daemon): add authentication for daemon API routes ... Issue daemon auth tokens (mdt_) on pairing session claim, bound to workspace_id + daemon_id with 1-year expiry. Add DaemonAuth middleware that validates these tokens and falls back to JWT/PAT for backward compatibility. Apply middleware to all daemon routes except pairing endpoints.	2026-03-31 16:19:02 +08:00
yushen	15f96468be	feat(upload): add attachment table for tracking uploaded files ... - Add attachment table with workspace/issue/comment associations - Upload handler creates attachment record when workspace context exists - Add GET /api/issues/{id}/attachments and DELETE /api/attachments/{id} - Frontend passes issueId context during uploads for tracking - Add Attachment type, listAttachments, deleteAttachment to API client Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-31 15:29:41 +08:00
LinYushen	961de18c97	feat(agents): reply as thread instead of top-level comment (#205) ... * feat(agents): reply as thread instead of top-level comment When an agent responds to a user comment, the reply is now nested under the triggering comment (parent_id) instead of appearing as a separate top-level comment. Also enables on_comment trigger by default for newly created agents. - Add trigger_comment_id column to agent_task_queue (migration 028) - Pass triggering comment ID through EnqueueTaskForIssue → task → createAgentComment - Include parent_id in WebSocket broadcast for agent comments - Default agent creation includes both on_assign and on_comment triggers Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(cli): add --parent flag to comment add for threaded replies The agent posts comments via the CLI, so the correct fix is giving it a --parent flag rather than wiring trigger_comment_id through the task infrastructure. The agent reads the comment list, decides which comment to reply to, and passes --parent <comment-id>. - Add --parent flag to `multica issue comment add` - Update agent runtime instructions to explain --parent usage Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(daemon): pass trigger_comment_id to agent execution context The agent now knows which comment triggered its task and gets an explicit instruction to reply to it using --parent. The trigger_comment_id flows from the DB through the claim response, daemon Task struct, and into issue_context.md where the agent sees it. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(comments): agent replies to thread root, matching frontend behavior When the triggering comment is itself a reply (has parent_id), resolve to the thread root so the agent's reply stays in the same flat thread. This matches the frontend where all replies share the top-level parent. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(cli): show parent_id and full IDs in comment list The table output now includes a PARENT column and shows full comment IDs (not truncated) so agents can see thread structure and use --parent. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(daemon): instruct agents to always use --output json Agents now see explicit guidance to use --output json for all read commands, ensuring they get structured data with full IDs and parent_id for proper threading. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * feat(daemon): differentiate comment-trigger vs assign-trigger context When triggered by a comment, the agent now gets clear instructions: - Primary goal is to read and respond to the comment - Do NOT change issue status just because you replied - Only change status if explicitly requested This prevents the agent from seeing "In Review" and stopping, since it now understands the task is to reply, not to re-evaluate the issue. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(daemon): split workflow by trigger type in CLAUDE.md/AGENTS.md The Workflow section in the agent's runtime config now shows a comment-reply workflow when triggered by a comment (read comments, find trigger, reply, don't change status) vs the full assignment workflow (set in_progress, do work, set in_review). Previously the agent always saw the assignment workflow, causing it to check the issue status, see "In Review", and stop without reading or replying to the triggering comment. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * refactor(daemon): remove duplicate workflow from issue_context.md Workflow instructions now live only in CLAUDE.md/AGENTS.md (runtime_config.go). issue_context.md keeps just the task data: issue ID, trigger type, and triggering comment ID. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(task): skip duplicate comment on completion for comment-triggered tasks When triggered by a comment, the agent posts its own reply via CLI with --parent. The task completion path was also creating a comment from the agent's stdout output, resulting in duplicates. Now only assignment-triggered tasks auto-post output as a comment. Error messages from FailTask are still posted regardless of trigger type. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>	2026-03-31 13:48:39 +08:00