223 Commits

Author	SHA1	Message	Date
Bohan Jiang	384ddcbe65	fix(execenv): seed user-installed Codex skills into per-task CODEX_HOME MUL-1626 (#2519) ... * fix(execenv): seed user-installed Codex skills into per-task CODEX_HOME Codex is the only daemon runtime whose HOME is redirected — the daemon sets CODEX_HOME to a per-task isolated directory so each task gets a clean config slate without polluting ~/.codex/. Side effect: the codex CLI never sees the user's `~/.codex/skills/` and tells the user no skill was found. Other runtimes (claude / copilot / opencode / pi / cursor / kimi / kiro) don't have this issue: they leave HOME untouched and discover both user-level skills (from ~/.<runtime>/skills) and workspace-assigned skills (written to a workdir-local dotfile dir) natively. Codex is the outlier. Fix: in execenv.Prepare and execenv.Reuse, copy each subdirectory under `~/.codex/skills/` into the per-task `codex-home/skills/` before writing workspace-assigned skills. Workspace skills still win on sanitized-name conflict; user-level installer symlinks (lark-cli style) are followed so the per-task home gets real content rather than dangling links. Closes #1922 Co-authored-by: multica-agent <github@multica.ai> * fix(execenv): wipe per-task codex skills dir before each hydration Without this, the Reuse path leaves two classes of stale state behind: 1. Round 1 seeded user skill `writing/drafts/stale.md`. Round 2 reuses the same workdir with workspace skill `Writing` assigned: seed stage skips user `writing` (reserved), workspace stage writes `SKILL.md` via MkdirAll + WriteFile but never clears the directory, so the round-1 user support files surface under the workspace skill — violating "workspace fully wins on name conflict" and potentially leaking user-level files into a workspace skill view. 2. User uninstalls a skill from ~/.codex/skills between two runs. The prior copy in codex-home/skills/<name>/ lingers, so the codex CLI keeps seeing the removed skill. Fix: RemoveAll(codex-home/skills) at the start of hydrateCodexSkills, then re-seed user skills and re-write workspace skills. On Prepare this is a no-op (envRoot was already wiped); on Reuse it resets the slate. Added two regression tests covering both scenarios. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-13 16:35:03 +08:00
Multica Eve	ff27142b69	fix: treat empty output on successful completion as completed, not blocked (#2507) ... When an agent completes successfully (exit 0) but produces no text output, the daemon incorrectly classified it as 'blocked'. This is wrong — agents can legitimately complete work via tool calls (posting comments, pushing code) without emitting text output. Change the empty-output path to return status=completed so the task is correctly reported as successful. Fixes MUL-2104 Co-authored-by: yushen <ldnvnbl@gmail.com> Co-authored-by: multica-agent <github@multica.ai>	2026-05-13 12:56:17 +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	046e4b1efa	fix(execenv): switch every provider's Windows reply template to --content-file (#2411) ... Three user reports converge on the same Windows-shell encoding bug: - #2198 / #2236 — Chinese, Codex on Win11. Comments / descriptions generated by the agent arrive as `?`. - #2376 — Cyrillic, non-Codex agent ("Ops Lead") on Win11 Desktop. Title preserved (argv → CreateProcessW UTF-16), description / agent reply garbled (stdin → shell-codepage re-encoding). woodcoal's independent diagnosis on #2198 confirms the root cause: Windows PowerShell 5.1's `$OutputEncoding` defaults to ASCIIEncoding when piping to a native command, so non-ASCII bytes are silently replaced with `?` before they reach `multica.exe`. The CLI's stdin parsing is fine; the bytes are corrupted upstream, in the agent's shell layer. This PR ships the fix that supersedes the codex-only attempt in PR #2265 (which is closed in favour of this one): ## CLI Add `--content-file <path>` to `multica issue comment add` and `--description-file <path>` to `multica issue {create,update}`. The CLI reads bytes off disk via `os.ReadFile` and skips the shell entirely; UTF-8 survives end-to-end regardless of `$OutputEncoding` or `chcp`. The three input modes (`--content`, `--content-stdin`, `--content-file`) are mutually exclusive. ## Runtime config `buildMetaSkillContent`'s Available Commands section is rewritten as a neutral three-mode menu. The previous unconditional "MUST pipe via stdin" / `--description-stdin` mandate (over-spread from #1795 / #1851's Codex-multi-line fix) is gone for non-Codex providers; the strong directive now lives only in the Codex-Specific section, which branches on host: - Codex / Linux+macOS: `--content-stdin` + HEREDOC (preserves MUL-1467 fix against codex's literal `\n` habit). - Codex / Windows: `--content-file` (PowerShell ASCII pipe is the exact bug we're patching). ## Per-turn reply template `BuildCommentReplyInstructions` now takes a provider arg and branches provider × OS: - Windows + any provider → `--content-file` (the bug is shell-layer, not provider-layer; #2376 shows non-Codex agents on Windows also hit it). All providers write a UTF-8 file with their file-write tool and post via `--content-file ./reply.md`. - Linux/macOS + Codex → stdin/HEREDOC (MUL-1467 protection). - Linux/macOS + non-Codex → lightweight pre-#1795 inline `--content "..."`. The CLI server-side decodes `\n`, so escaped multi-line works; the agent retains stdin / file as escape hatches for richer formatting. `BuildPrompt` and `buildCommentPrompt` gain a `provider` arg; `daemon.runTask` already has it in scope. ## Tests - `TestResolveTextFlag` — file-source verbatim with non-ASCII (`标题 / Заголовок / 中文段落`), missing-file error, empty-file rejection, three-way mutual exclusion. - `TestInjectRuntimeConfigAvailableCommandsIsNeutral` — every non-Codex provider × {linux, darwin, windows} pins the three-mode menu present + over-spread "MUST stdin" substrings absent. - `TestInjectRuntimeConfigCodexLinuxEmphasizesStdin` + `TestInjectRuntimeConfigCodexWindowsUsesContentFile` — Codex section's per-OS branch. - `TestBuildCommentReplyInstructionsCodexLinux` + `TestBuildCommentReplyInstructionsNonCodexLinux` + `TestBuildCommentReplyInstructionsWindowsUsesContentFile` — the reply-template provider × OS matrix. - `TestInjectRuntimeConfigWindowsCommentTriggerHasNoStdin` — end-to-end AGENTS.md / CLAUDE.md on Windows has no prescriptive stdin directive, for claude / codex / opencode. `go test ./...` and `go vet ./...` clean. Closes #2198, #2236, #2376. Co-authored-by: multica-agent <github@multica.ai>	2026-05-11 17:05:45 +08:00
Bohan Jiang	fae8558263	fix(daemon): self-heal when a runtime is deleted server-side (#2404) ... Closes #2391.	2026-05-11 16:09:40 +08:00
Kagura	fb026f2607	fix(daemon): suppress git console windows on Windows (#2358) ... * fix(daemon): suppress git console windows on Windows Apply the same HideConsoleWindow pattern used for agent processes (PR #1474) to all git commands spawned by the daemon's repo-cache, execenv, and GC packages. Each exec.Command now calls util.HideConsoleWindow(cmd) which sets CREATE_NEW_CONSOLE + HideWindow so grandchildren inherit a hidden console instead of flashing visible console windows. Closes #2357 Co-Authored-By: Claude Opus 4 (1M context) <noreply@anthropic.com> * refactor: use EnsureHiddenConsole at daemon startup Replace per-site HideConsoleWindow(cmd) calls with a single EnsureHiddenConsole() invoked once at daemon startup. The daemon now owns a hidden console that every child process (git, cmd /c mklink, etc.) inherits automatically, eliminating the need for per-call SysProcAttr configuration. This also covers the previously missed exec.Command in codex_home_link_windows.go (cmd /c mklink) which never had a HideConsoleWindow call. Signed-off-by: kagura-agent <kagura.agent.ai@gmail.com> --------- Signed-off-by: kagura-agent <kagura.agent.ai@gmail.com> Co-authored-by: Claude Opus 4 (1M context) <noreply@anthropic.com>	2026-05-11 14:41: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
Bohan Jiang	39e57b870f	fix(cli): allow --mode run_only on autopilot create/update (#2360) ... * fix(cli): allow --mode run_only on autopilot create/update The autopilot run_only dispatch path is wired end-to-end (handler accepts the mode, AutopilotService.dispatchRunOnly enqueues a task with AutopilotRunID, daemon resolves workspace via autopilot_run -> autopilot in ClaimTaskByRuntime and TaskService.ResolveTaskWorkspaceID). The CLI guard was added before those fixes landed and never removed. Drop the CLI rejection on both create and update so callers can pick the same modes the API and UI already support, and remove the stale "unstable" callout from the autopilots docs. Closes multica-ai/multica#2347 Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): advertise autopilot run_only in agent runtime instructions The runtime config injected into AGENTS.md / CLAUDE.md only listed `--mode create_issue` for autopilot create and didn't expose `--mode` on update at all. So even after the CLI guard was lifted, agents reading their harness instructions would still believe create_issue was the only choice — undermining the "agents operate the same surface as humans" intent. Update both lines to advertise create_issue|run_only on create and on update, and add an InjectRuntimeConfig assertion so the runtime prompt can't drift away from the CLI surface again. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-10 14:12:34 +08:00
Bohan Jiang	15c3886302	docs(daemon): refresh stale comment for inline system prompt path (#2362) ... The inline path now carries the full runtime brief (CLI catalog, workflow steps, persona, skills, project context) rather than just identity/persona instructions, after #2353 / #2355. The pre-existing comment still described it as "identity/persona instructions inline", which would mislead future maintainers about why the inline payload is load-bearing. Also call out kiro/kimi alongside openclaw/hermes since they were added to providerNeedsInlineSystemPrompt in #2328, and document the concrete failure mode (issues stuck in todo) so the rationale is searchable. Co-authored-by: multica-agent <github@multica.ai>	2026-05-10 14:00:08 +08:00
Kagura	a6968c7485	fix(daemon): inline runtime brief for providers that need system prompt (#2355) ... InjectRuntimeConfig writes the full meta skill content (CLI catalog, workflow instructions, project context, skills) to workdir/AGENTS.md, but providers like OpenClaw, Hermes, Kiro, and Kimi read bootstrap files from their own agent workspace — not the task workdir. The inline system prompt path (providerNeedsInlineSystemPrompt) only passed the agent persona instructions, so these providers never received the runtime brief. Have InjectRuntimeConfig return the rendered content so the daemon can both write it to disk (for file-reading providers) and pass it inline (for workspace-isolated providers). This avoids double-rendering and keeps the file and inline payloads identical. Fixes #2353	2026-05-10 13:57:05 +08:00
Bohan Jiang	d713b57072	fix(daemon): add kiro and kimi to providerNeedsInlineSystemPrompt whitelist (#2328) ... Kiro and Kimi share Hermes' ACP architecture and already accept SystemPrompt prepended in front of the user prompt (kiro.go:244-247, kimi.go:256-257). Without daemon-side opt-in, ExecOptions.SystemPrompt is never set, so per-task agent identity instructions are lost in deployments that rely on inline injection (e.g. K3 Lens-style daemon → wrapper → docker compose exec acp). Co-authored-by: multica-agent <github@multica.ai>	2026-05-09 16:54:27 +08:00
Bohan Jiang	c57546159d	fix(daemon): mark provider 429 / out-of-credit agent runs as failed, not completed (#2323) ... * fix(daemon): mark provider 429 / out-of-credit runs as failed, not completed Two bugs combined to silently report failed agent runs as "Completed" in the UI when the upstream LLM returned a 4xx (e.g. HTTP 429 rate-limit / no credit on the account). 1. ACP backends (hermes, kimi, kiro) only promoted the run status to "failed" when their stderr sniffer fired AND the agent output buffer was empty. But hermes injects a synthetic agent text turn ("API call failed after 3 retries: HTTP 429...") on retry exhaustion, so the buffer was never empty in the rate-limit case and the promotion never ran. Drop the empty-output precondition: the sniffer's regex (HTTP-status markers, named error types) is specific enough to trust on its own. 2. The daemon's task-result switch only routed "blocked" through FailTask; every other status — including "cancelled", and any future status we forget to enumerate — fell through to CompleteTask. Invert it so only an explicit "completed" status reports success, and extract the switch into reportTaskResult for direct testing. Cancelled now defaults to failure_reason "cancelled" instead of being silently completed. Closes GitHub multica#1952. Co-authored-by: multica-agent <github@multica.ai> * fix(agent): only promote ACP run to failed on terminal provider error Address GPT-Boy's review on the multica#1952 fix. The previous promotion rule ("any sniffer line → fail") was too broad: the existing sniffer also captures transient per-attempt warnings ("API call failed (attempt 1/3): RateLimitError [HTTP 429]"), and those lines stay in the buffer for the rest of the run. A retry sequence whose first attempt blipped but whose third attempt succeeded would have been wrongly reported as failed. Tighten the criteria with two additional signals, both defined on the existing acpProviderErrorSniffer / output buffer: - acpTerminalErrorRe — sticky `terminal` flag set when stderr shows an exhausted/non-retryable marker (❌, [ERROR], "after N retries", Non-retryable, BadRequestError, AuthenticationError). Per-attempt warnings deliberately don't match. - acpAgentOutputTerminalRe — matches the synthetic "API call failed after N retries..." turn that hermes-style adapters inject into the agent text stream when they give up; this catches multica#1952 even if hermes' stderr only logged transient attempts. Promotion logic becomes a shared helper, promoteACPResultOnProviderError, called from hermes / kimi / kiro. Promotes when (a) terminalMessage is non-empty, (b) output contains the synthetic give-up turn, or (c) output is empty and the sniffer captured anything at all (preserves the original empty-output safety net for transient-only sequences with no real result to fall back on). Tests: - TestHermesProviderErrorSnifferTerminalVsTransient — transient attempt 1/3 alone returns terminalMessage="" but message!=""; a follow-on terminal marker flips terminal on. - TestHermesProviderErrorSnifferTerminalNonRetryable — confirms BadRequest / Authentication / Non-retryable / ❌ / [ERROR] are classified terminal even on the very first attempt. - TestHermesBackendDoesNotPromoteOnTransientRetry — fake hermes emits attempt 1/3 to stderr then a normal agent text turn and end_turn; resulting Status must stay "completed". Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-09 16:13:12 +08:00
Bohan Jiang	003dfd9b4b	feat(quick-create): add project picker that remembers last pick (#2321) ... * feat(quick-create): add project picker that remembers last pick Quick-create users targeting one project repeatedly had to restate "in project X" in every prompt. The modal now exposes a project picker beside the agent picker, persists the selection per-workspace, and pins the agent's `multica issue create` invocation to that project so the prompt text doesn't have to. The picked project also flows to the daemon as ProjectID/ProjectTitle and its github_repo resources override the workspace repo fallback — same treatment issue-bound tasks already get. Co-authored-by: multica-agent <github@multica.ai> * fix(quick-create): move project picker into property pill row Reviewer feedback: the picker felt out of place wedged next to the agent header. Move it into a property toolbar row above the footer, reusing the shared `ProjectPicker` + `PillButton` so its placement and styling line up exactly with the manual create panel. This also drops the bespoke dropdown / aria / label strings that were only needed while the picker rendered inline beside "Created by". Co-authored-by: multica-agent <github@multica.ai> * fix(quick-create): clear stale persisted project + carry across mode switch Two review-blocking bugs in PR #2321: 1. The stale-id sweep in AgentCreatePanel only fired when projects.length > 0 and only cleared local state, leaving lastProjectId pointing at a deleted project. The next open re-seeded the dead UUID and submit hit the server's `project not found` rejection. Gate on the query's `isSuccess` so we can tell "loading" apart from "loaded as empty", and clear both local state and the persisted preference when the selection isn't in the resolved list. 2. ManualCreatePanel's switchToAgent dropped the picked project from the carry payload, so flipping manual → agent silently fell back to the agent panel's own lastProjectId — potentially routing the issue to a different project than the one shown in manual mode. Forward project_id alongside prompt / agent_id, and add a regression test. Co-authored-by: multica-agent <github@multica.ai> * test(quick-create): pass new isExpanded props in stale-project tests Main got an expand button on AgentCreatePanel via #2320 while this branch was open, adding `isExpanded` / `setIsExpanded` to the panel's required props. The two new stale-project tests still passed `{ onClose }` only, which CI's typecheck (run on the main+branch merge) caught while my local run did not. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-09 16:12:12 +08:00
Bohan Jiang	3f20999597	refactor(timeline): drop server-side comment + timeline pagination (#2322) ... * refactor(timeline): drop server-side comment + timeline pagination (MUL-1929) The cursor-paginated /timeline and /comments endpoints were sized for a problem the data shape doesn't have: prod p99 is ~30 comments per issue and the all-time max is ~1.1k. Time-based pagination also splits reply threads across page boundaries (orphan replies), which the frontend was papering over with an "orphan rescue" that promoted disconnected replies to top-level — confusing UX with no real benefit. Replace both endpoints with a single full-issue fetch, capped server-side at 2000 rows as a defensive safety net (never hit in practice). Server - /api/issues/:id/timeline now returns a flat ASC TimelineEntry[] (matches the legacy desktop contract — older Multica.app builds keep working because the wrapped TimelineResponse + cursors are gone, and the raw array shape was always what they consumed). - /api/issues/:id/comments drops limit/offset; only ?since is honoured for the CLI agent-polling flow. - Drop ListCommentsBefore/After/Latest, ListActivitiesBefore/After/Latest and the timelineCursor encoding. - Replace with ListCommentsForIssue / ListCommentsSinceForIssue / ListActivitiesForIssue (capped by argument). CLI - multica issue comment list drops --limit / --offset and the X-Total-Count reporting; --since is preserved for incremental polling. Frontend - Replace useInfiniteQuery with useQuery in useIssueTimeline; drop fetchOlder/Newer, jumpToLatest, isAtLatest, newEntriesBelowCount. - Remove timeline-cache helpers (mapAllEntries / filterAllEntries / prependToLatestPage) and the TimelinePage / TimelinePageParam types. - WS event handlers update the single flat-array cache directly. - Drop the orphan-reply rescue in issue-detail — every reply's parent is now guaranteed to be in the same array. - Strip the "show older / show newer / jump to latest" buttons and their i18n strings. Co-authored-by: multica-agent <github@multica.ai> * fix(timeline): address review feedback on pagination removal Three issues caught in PR #2322 review: 1. /timeline broke for stale clients between #2128 and this PR. They send ?limit/?before/?after/?around and parse with the wrapped TimelinePageSchema; the new flat-array response was failing schema validation and falling back to an empty timeline. Restore the wrapped shape on those query params (DESC entries, null cursors, has_more_*=false), keeping the flat ASC array for bare requests. Around-mode now also fills target_index from the merged slice so legacy clients can still scroll-to-anchor without a follow-up. 2. The agent prompts in runtime_config.go and prompt.go still told agents that `multica issue comment list` accepts --limit/--offset and to use `--limit 30` on truncated output. With those flags removed in this PR, new agent runs would hit "unknown flag" or skip context. Update the prompt copy to "returns all comments, capped at 2000; --since for incremental polling". 3. useCreateComment's onSuccess was a bare append to the timeline cache with no id-dedupe, so a fast comment:created WS event firing before onSuccess produced a transient duplicate. Restore the id guard the old prependToLatestPage helper used to provide. Adds two new boundary tests: - TestListTimeline_LegacyWrappedShape_OnPaginationParams - TestListTimeline_LegacyWrappedShape_AroundFillsTargetIndex Co-authored-by: multica-agent <github@multica.ai> * test(handler): fix timeline test assertions for handler-package isolation The TestListTimeline_* assertions assumed CreateIssue would seed an "issue_created" activity_log row, but the activity listener that publishes those rows is registered in cmd/server/main.go — handler-package tests don't wire it up. CI saw 5 entries (3 comments + 2 activities) where the test expected ≥6. Drop the auto-activity assumption: assert exactly 5 entries in TestListTimeline_MergesCommentsAndActivities, and tighten TestListTimeline_EmptyIssue to assert a fully-empty timeline. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-09 16:11:58 +08:00
Bohan Jiang	6d9ebb0fdd	fix(daemon): unblock issues stuck on a poisoned-image agent session (#2314) ... * fix(daemon): treat upstream API 400 invalid_request_error as poisoned session A markdown-linked image in an issue description that the agent downloads as a tiny CDN auth-error file and Read's as a PNG poisons the conversation: the LLM API rejects the bad image with 400 invalid_request_error, the session_id is pinned mid-flight, and every follow-up task on the issue (comment-trigger, auto-retry) resumes the same poisoned conversation and hits the same 400 — the issue can no longer be executed even after the description is cleaned up. Mirror the existing fallback-output classifier on the error side: detect "API Error: ... 400 ... invalid_request_error" in the agent error string, persist failure_reason='api_invalid_request', and add it to the GetLastTaskSession exclusion list so the next task starts a fresh session that re-reads the (now-clean) description. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): unblock issues already poisoned by API 400 invalid_request_error The forward-only classifier from the previous commit only tags new failures. Issues like MUL-1918 already have multiple failed-task rows whose failure_reason is the pre-fix default 'agent_error', and GetLastTaskSession falls back to those legacy rows on the next claim — so deploying the classifier alone leaves existing poisoned issues stuck (GPT-Boy review on PR #2314). Two complementary changes: - Migration 079 backfills failure_reason='api_invalid_request' on every pre-existing 'agent_error' row whose error text matches the canonical Anthropic 400 invalid_request_error shape. Keeps observability consistent (multica issue runs / UI now report the right reason). - GetLastTaskSession adds a defensive ILIKE clause on error text. Closes the deploy-window gap where the old binary could write a new 'agent_error' row between the migration running and the new code taking over, and protects against future error-format variants the daemon classifier might miss. Plus regression tests covering the legacy + new coexistence case GPT-Boy flagged, and a guard rail asserting benign 'agent_error' failures (timeouts, tool errors) still resume their session. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-09 14:39:10 +08:00
Valentin Mihov	560e081d8f	Pass agent instructions inline to Hermes (#2283)	2026-05-09 14:23:41 +08:00
Bohan Jiang	97df9b90f5	refactor(daemon): rename repoCache interface, relax /health test timeout (#2270) ... Two follow-up nits from PR #2211 review: - Rename the package-local `repoCache` interface to `repoCacheBackend` so the field declaration `repoCache repoCacheBackend` no longer shadows its own type name. - Bump the `/health`-must-respond timeout in `TestHealthHandlerRespondsWhileTaskRepoLookupWaits` from 200ms to 1s. The regression case blocks indefinitely on the old code, so a 1s upper bound still fail-fast detects it while leaving headroom for loaded CI runners. Co-authored-by: multica-agent <github@multica.ai>	2026-05-08 17:38:06 +08:00
Bohan Jiang	61ce8a8090	feat(daemon): add disk-usage CLI to surface per-task / per-workspace footprint (#2267) ... * feat(daemon): add disk-usage CLI to surface per-task / per-workspace footprint Adds `multica daemon disk-usage [--by-workspace] [--by-task] [--top N] [--output json]`, walking the workspaces root to report task and workspace disk consumption without requiring a running daemon. Sizing reuses the GC artifact patternSet (basename-only) so the reported "artifact" footprint matches what `cleanTaskArtifacts` would actually reclaim, and the walk honors the same safety contract: never enters .git, never follows symlinks, counts only regular files. Refactors WorkspacesRoot resolution into an exported `ResolveWorkspacesRoot` so the read-only CLI picks the same root the running daemon would have. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): distinguish displayed totals from scan totals; add workspace artifact ratio - Track scan-wide TotalTaskCount / TotalWorkspaceCount on the report so `--top N` no longer leaves the table footer claiming the truncated row count is the full count. The CLI now prints a "Showing top N of M … Displayed: X. Scan total: Y" line whenever truncation happens, and keeps the bare "Total: …" footer for the un-truncated case. - Add ArtifactRatio (0..1) on WorkspaceDiskUsage and TotalArtifactRatio on the report. The workspace table renders an `ARTIFACT %` column. ratio() guards size=0 so empty workspaces report 0% instead of NaN%. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-08 17:14:52 +08:00
Qiang Zhang	f1dc3dc986	fix: keep daemon health responsive during repo lookup (#2211)	2026-05-08 16:51:36 +08:00
Bohan Jiang	823f124d67	feat(daemon): extend GC to chat / autopilot / quick-create tasks (#2260) ... * feat(daemon): extend GC to chat / autopilot / quick-create tasks Before this change the daemon's GC was strictly issue-centric: only tasks with a non-empty issue_id ever wrote .gc_meta.json, and shouldCleanTaskDir called only the issue gc-check endpoint. Chat / autopilot run / quick-create tasks fell through to the GCOrphanTTL mtime path, which mis-killed active chat sessions while leaving deleted ones around far longer than necessary. Schema: - GCMeta gains a Kind discriminator and per-kind ID fields (ChatSessionID / AutopilotRunID / TaskID). WriteGCMeta now takes a GCMeta struct so the call site classifies the task explicitly. - ReadGCMeta defaults empty Kind to GCKindIssue, so legacy on-disk meta files keep flowing through the issue path with no migration required. Server endpoints (siblings of /api/daemon/issues/{id}/gc-check, all behind requireDaemonWorkspaceAccess for the same anti-enumeration shape): - GET /api/daemon/chat-sessions/{id}/gc-check -> {status, updated_at} - GET /api/daemon/autopilot-runs/{id}/gc-check -> {status, completed_at} - GET /api/daemon/tasks/{id}/gc-check -> {status, completed_at} shouldCleanTaskDir dispatches on Kind: - chat: active is hard-skipped (no mtime fallback) so idle sessions are never reclaimed; archived + GCTTL cleans; 404 falls back to mtime to stay safe for cross-workspace tokens. - autopilot_run: terminal (completed/failed/skipped/issue_created) + GCTTL cleans; running/pending skips. Uses run.completed_at as the TTL anchor since autopilot_run has no updated_at column. - quick_create: terminal task status cleans immediately (workdir is not reused by the linked issue task, which has its own envRoot); running skips. Also drops the "skipping .gc_meta.json: issue_id is empty" warn — with the new kind dispatch, chat/autopilot/quick-create tasks now write a proper meta file instead of triggering this log. Refs: GC follow-up to PR #2077 (symptom fix) and #2115 (chat hard delete). Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): chat gc-check 404 cleans immediately, no mtime gate PR review caught that the chat 404 path was routing through orphanByMTime, which deferred reclamation to GCOrphanTTL (72h) when acceptance #3 calls for cleanup within one GC cycle (≤ 1h) after the user hard-deletes a session. Every chat_session_id we ever ask about was written by this same daemon under its current token, so the cross-workspace probe defense the issue path needs doesn't apply here. Drop the gate and clean on 404 directly. Test updates: - TestShouldCleanTaskDir_KindDispatch/chat_404 flips the locked expectation from gcActionSkip to gcActionClean. - Adds TestShouldCleanTaskDir_ChatHardDeletedFreshMtime: GCOrphanTTL set to a year so any mtime-based path is unmistakably out, and the fresh-mtime workdir still cleans on the chat-404 fast path. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-08 16:12:48 +08:00
Multica Eve	9a3a99cef8	fix: make CLI short IDs routable ... Make CLI table IDs routable across issue, autopilot, project, label, and task-run workflows. Adds scoped UUID-prefix resolution, --full-id table options, issue KEY display, safer actor/name output, and updated CLI docs/runtime prompt.	2026-05-08 14:32:03 +08:00
Matt Van Horn	6b7294aa5b	fix(daemon): use brew prefix symlink for self-restart so Linux Cellar deletion does not orphan runtimes (#2076) ... * fix(daemon): use brew prefix symlink for self-restart so Linux Cellar deletion does not orphan runtimes After brew upgrade on Linux, os.Executable() resolves /proc/self/exe to the Cellar path (e.g. .../Cellar/multica/0.2.9/bin/multica), which brew cleanup deletes. The previous IsBrewInstall() short-circuit skipped EvalSymlinks to 'preserve' the symlink, but on Linux there was nothing to preserve - the path was already resolved. Use cli.GetBrewPrefix() to resolve the stable symlink path <brewPrefix>/bin/multica for brew installs. Fall back to EvalSymlinks(os.Executable()) with a warning log when GetBrewPrefix() returns empty (brew binary missing from PATH). Introduce package-level function vars (isBrewInstall, getBrewPrefix) so the daemon test can override them without modifying the cli package. Closes #1624 * fix(daemon): harden brew-prefix fallback and document the WHY When `brew --prefix` is unavailable but the binary is under a known Cellar root, recover the prefix from cli.MatchKnownBrewPrefix and target <prefix>/bin/multica instead of falling back to the resolved Cellar path (which brew cleanup just deleted). - Extract knownBrewPrefixes + MatchKnownBrewPrefix in cli/update.go and reuse from IsBrewInstall to keep one source of truth for the install-root list. - Add a WHY comment above the brew branch in triggerRestart explaining the /proc/self/exe -> Cellar -> deleted-by-brew-cleanup chain. - Cover both fallback paths (matched / unmatched) in daemon_test.go. --------- Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>	2026-05-08 12:08:56 +08:00
Bohan Jiang	d964d37f97	Revert "fix(cli): add --content-file / --description-file for non-ASCII on Wi…" (#2252) ... This reverts commit 9650788709.	2026-05-08 12:04:03 +08:00
Bohan Jiang	9650788709	fix(cli): add --content-file / --description-file for non-ASCII on Windows (#2247) ... * fix(cli): add --content-file / --description-file for non-ASCII on Windows Windows PowerShell 5.1 (the Win11 default) and cmd.exe re-encode HEREDOC content through the active console codepage before piping it to a child process. Characters the codepage cannot represent are silently replaced with `?`, so agents on Chinese Win11 hosts emitting `--content-stdin` / `--description-stdin` HEREDOCs land all of their Chinese as `?` in the issue body and comments. The daemon log shows the original Chinese correctly because slog writes to a file directly, so the regression hides until the user opens the issue page. Add a `--content-file <path>` / `--description-file <path>` source to `resolveTextFlag`: the CLI reads the file straight off disk, preserves UTF-8 bytes verbatim, and skips the shell entirely. The runtime config injected into AGENTS.md / CLAUDE.md now surfaces this as the canonical Windows fallback when the daemon host runs on Windows; non-Windows hosts keep the existing stdin/HEREDOC guidance untouched. Closes #2198, #2236. Co-authored-by: multica-agent <github@multica.ai> * fix(execenv): route every Windows-host stdin directive at --content-file GPT-Boy on PR #2247 caught that the previous patch only inserted a Windows fallback into the Available Commands section. Two later prompt surfaces still hard-coded `--content-stdin` and overrode it for the agent: - The Codex-specific paragraph in `buildMetaSkillContent`, which always said "always use `--content-stdin` with a HEREDOC". - `BuildCommentReplyInstructions`, which is re-emitted on every turn for comment-triggered tasks (both via the AGENTS.md/CLAUDE.md workflow and the daemon's per-turn prompt) and mandated the same HEREDOC pipe. On Windows hosts we now branch both surfaces to a file-based template: the agent writes the body to a UTF-8 file with its file-write tool and posts via `--content-file <path>`. Non-Windows hosts keep the existing stdin/HEREDOC guidance untouched. Tests: - `TestBuildCommentReplyInstructionsWindowsUsesContentFile` pins the Windows / non-Windows reply-instruction text directly. - `TestInjectRuntimeConfigWindowsCommentTriggerHasNoStdin` asserts that the end-to-end CLAUDE.md / AGENTS.md surface for a comment-triggered Windows task has no remaining `--content-stdin` directive that could override the Windows fallback (covers Claude + Codex providers). Co-authored-by: multica-agent <github@multica.ai> * fix(execenv): make Windows comment block file-first, pin tests by GOOS GPT-Boy's second review on PR #2247 flagged two follow-up blockers: 1. The Windows comment/description block in `buildMetaSkillContent` was "stdin first, file caveat appended" — agents on Windows still saw "Agent-authored comments should always pipe content via stdin" / "MUST pipe via stdin" / `--description-stdin` directives before reaching the Windows fallback, so the contradicting instruction was live in the same prompt. Rewrite the entire Available Commands bullet for Windows hosts as file-first: the headline line names `--content-file`, the bulleted rules name `--content-file` / `--description-file`, and stdin only appears in anti-prescriptive "do NOT pipe via …" prose. 2. The existing non-Windows tests (TestBuildCommentReplyInstructions IncludesTriggerID, TestInjectRuntimeConfigDirectsMultiLineWritesToStdin, TestInjectRuntimeConfigCodexEmphasizesStdinForFormattedComments, TestInjectRuntimeConfigCommentTriggerUsesHelper) all depended on `runtimeGOOS` defaulting to non-Windows; they would silently fail on a Windows test runner. Pin them to `runtimeGOOS = "linux"` via save+restore and drop t.Parallel so they don't race with the GOOS-mutating Windows tests. Test additions: - TestInjectRuntimeConfigWindowsRecommendsContentFile now asserts the Windows AGENTS.md does NOT contain prescriptive stdin phrasings (`MUST pipe via stdin`, `use --description-stdin and pipe a HEREDOC`, `<<'COMMENT'`, `Agent-authored comments should always pipe content via stdin`, `always use --content-stdin`) on top of the file-first positive assertions. The ban list pins prescriptive substrings, not bare flag names, so anti-prescriptive prose like "do NOT pipe via --content-stdin" doesn't trip the ban. - TestInjectRuntimeConfigWindowsCommentTriggerHasNoStdin gets the same expanded ban list across the Available Commands, Codex paragraph, and per-turn reply template surfaces. - The non-Windows side of TestInjectRuntimeConfigWindowsRecommendsContentFile pins that the Linux stdin/HEREDOC contract is still in place, so a future refactor can't accidentally move every host to file-first. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-08 12:01:19 +08:00
Bohan Jiang	2f979ac6f0	fix(daemon): tighten quick-create prompt to drop meta-instructions and apologetic Context (#2137) ... * fix(daemon): tighten quick-create prompt to drop meta-instructions and apologetic Context The quick-create prompt was producing descriptions that: 1. Echoed routing meta-instructions ("create an issue for me", "cc @X") into the User request body, even though those phrases are handled by separate CLI flags and are not spec content. 2. Emitted a Context section to apologize for resources it could not fetch (e.g. an image attachment not piped through to the run), instead of staying silent and letting the executing agent ask the user. 3. Preserved pure conversational fillers ("对吧?", "嗯", "那个…") because the model treated removing them as forbidden paraphrasing. Updates the prompt to call out each of these as explicit non-spec material to strip before writing the description, while keeping the "high fidelity / no paraphrasing of substantive content" invariant. Adds a regression test that locks in the new rules at the substring level. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): preserve cc mention links in quick-create description Stripping "cc @Y" wholesale would have lost the mentioned member's only routing channel: `multica issue create` has no --subscriber/--cc flag, and the platform auto-subscribes members by parsing `[@Name](mention://member/<uuid>)` links from the description body. Without the mention link in the body, a cc'd member would never get subscribed or notified. Updates the prompt to: - Strip only the verbal "cc" wrapper from the User request body. - Append a trailing `CC: <mention links>` line to the description so the platform's auto-subscribe logic still picks the mentions up. - Spell out the contrast for assignee mentions, where --assignee-id is the routing channel and the body should not double-encode the mention. Also adds a substring assertion for the "Pure conversational fillers" rule that was missing from the original regression test. Co-authored-by: multica-agent <github@multica.ai> * refactor(daemon): trim quick-create prompt rules to general principles Reviewers pointed out the previous rewrite traded one prompt smell (over- permissive verbatim quoting) for another (too many specific rules and exhaustive bilingual example tables). Rewrites the description block as general principles with a single representative example each, trusting the model to generalize: - "Strip non-spec material before writing" replaces the multi-bullet list of routing-meta-instruction and conversational-filler enumerations. - "Include Context only when references were fetched and produced facts; never use it as an apology log" replaces the three "Do NOT emit a Context section to" sub-bullets. - The CC exception (the only operationally non-obvious rule, since `multica issue create` has no --subscriber flag) is kept inline as a single sentence and is still locked in by the regression test. Net: ~16 fewer lines of prompt text without losing any of the rules the test asserts. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-06 17:57:11 +08:00
Naiyuan Qing	ba147708a6	fix(timeline): cursor-paginated timeline to stop long-issue freeze (#1968) (#2128) ... * fix(timeline): cursor-paginated timeline to stop long-issue freeze (#1968) Opening an issue from Inbox with thousands of timeline entries used to hard-freeze the browser tab on a synchronous render of every comment + activity. The whole pipeline was unbounded: the API returned every row, TanStack Query cached the full array, and IssueDetail mounted N CommentCards (each running a full react-markdown + lowlight pipeline) in one frame. This swaps the timeline endpoint to keyset cursor pagination and rewires the frontend to useInfiniteQuery so a long issue costs the same as a short one on first paint. API: - GET /issues/:id/timeline now accepts ?before / ?after / ?around (mutex) + ?limit (default 50, max 100); response wraps entries with next/prev cursors and has_more flags. Cursors are opaque base64 (created_at, id). - ?around=<entry_id> anchors a window on the target so Inbox notifications pointing at an old comment never trigger the freeze. - New composite indexes on (issue_id, created_at DESC, id DESC) replace the redundant single-column ones so keyset queries are index-only scans. - /issues/:id/comments default branch now caps at 50 instead of returning every row unbounded; the unbounded ListComments / ListActivities sqlc queries are deleted. Frontend: - useIssueTimeline switches to useInfiniteQuery, exposes fetchOlder/fetchNewer/jumpToLatest + isAtLatest + newEntriesBelowCount. - WS handlers respect the at-latest invariant: comment/activity:created prepends to pages[0] only when the user is reading the live tail; otherwise it just bumps a counter so the UI offers a "Jump to latest" affordance without yanking scroll. - Optimistic mutations adapted to the InfiniteData shape via shared helpers (mapAllEntries / filterAllEntries / prependToLatestPage in core/issues/timeline-cache.ts) and use setQueriesData so all open windows of the same issue stay in sync. - IssueDetail Activity section gets a TimelineSkeleton placeholder during the brief load window plus subtle text-link load-more buttons matching the existing Subscribe affordance (no Button chrome). Top uses a divider for boundary clarity; bottom shows "Jump to latest · N new" weighted slightly heavier when there's unread state. - highlightCommentId now flows into the hook's around parameter so Inbox jumps fetch the surrounding 50 entries directly. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * chore(agent): default comment list to 50 + prompt hint about long issues The CLI's "multica issue comment list" used to default to --limit 0 (meaning "fetch every comment"), which lets an agent on a long issue fill its context window with thousands of rows. The default is now 50; agents that need older history can pass --limit or --since explicitly. The local-coding-agent prompt also gains a single-line note about this in both the comment-triggered and on-assign flows so the agent knows to scope its fetches when issue size is unknown. Autopilot run-only mode is intentionally unchanged — it has no issue context to query. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>	2026-05-06 16:27:06 +08:00
Bohan Jiang	ae985ae2a3	fix(daemon): tighten 404 task-not-found semantics — server + final guard (#2127) ... * fix(server): return 500 for transient DB errors in daemon task lookup requireDaemonTaskAccess used to turn any GetAgentTask error into 404 "task not found", including transient DB connection / pool errors. Combined with PR #2107 — which added 404+"task not found" as a daemon cancellation trigger — that means a single DB hiccup could kill an in-flight agent run. Distinguish pgx.ErrNoRows (real "task gone", 404) from other errors (transient, 500 + warn log) using the existing isNotFound helper. Tests cover both paths via the mockDB pattern already used by TestFindOrCreateUserGating. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): honor task-deleted signal in post-runTask completion guard The final pre-completion check in handleTask only looked for status == "cancelled" and ignored errors. After PR #2107 added a 404 task-deleted cancellation path to the in-flight watcher, this trailing guard fell out of sync — if the task was deleted between the watcher's last poll and runTask returning, handleTask would still try to call CompleteTask and only learn about the deletion via the 404 from that callback. Reuse shouldInterruptAgent so the same truth table (cancelled OR 404 task-not-found, but NOT transient errors) drives both polling and the final guard. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-06 16:02:59 +08:00
DimaS	b1be9ed27f	fix(daemon): cancel running agent when task is deleted server-side (#2107) ... When the server deletes a task while the daemon's agent is still running (issue removed, agent reassigned, workspace cleanup), GetTaskStatus starts returning 404 "task not found". The previous polling loop only checked for status == "cancelled" and silently swallowed the error, so the local agent kept emitting tool calls against a dead task until its own timeout fired — minutes of wasted model spend and patch_apply operations against a workdir nobody would consume. Changes: - Add isTaskNotFoundError next to isWorkspaceNotFoundError so the daemon can distinguish "task gone" 404 from "workspace gone" 404 (already handled separately) and from generic network errors. - Extract the cancellation polling goroutine in handleTask into watchTaskCancellation, plus a pure shouldInterruptAgent decision helper. The pure helper makes both signals (cancelled status and 404 task) easy to unit-test without spinning up a real backend. - Trigger interruption on the new 404 path. Transient errors (5xx, network) intentionally still don't cancel — the next poll will retry and a flaky link should not kill an in-flight agent. Tests cover the helper truth table, the existing "status cancelled" path, the new "task deleted (404)" path, and a negative case ensuring a running task is not interrupted. Co-authored-by: “646826” <“646826@gmail.com”>	2026-05-06 15:45:03 +08:00
Bohan Jiang	144661e68f	fix(daemon/execenv): refresh stale Codex auth.json across env reuse (#2126) ... `ensureSymlink` previously short-circuited whenever `dst` already existed as a regular file ("Regular file exists — don't overwrite"). On Windows that branch is reachable via the createFileLink copy fallback that fires when `os.Symlink` is unavailable, so once a per-task `codex-home/auth.json` was written as a copy it would never be refreshed by subsequent Prepare/Reuse calls. If the shared `~/.codex/auth.json` rotated (e.g. Codex Desktop refreshed the token in the background), the daemon kept handing Codex a now-revoked refresh_token, which the OAuth server rejected with `refresh_token_reused` / `token_expired`. Renaming the workspace directory was the only recovery path. Treat any non-matching dst — wrong-target symlink, broken symlink, or stale regular file — as something to delete and re-create via createFileLink, so each Prepare/Reuse mirrors the current shared source. Add a `logCodexAuthState` info log (file kind, link target, size, mtime — never contents) so operators chasing the same symptom can see at a glance whether the per-task home is tracking the shared auth or has drifted. Tests cover: stale regular-file dst is replaced, copy-fallback dst is refreshed when the shared source rotates, and a high-level prepareCodexHome regression simulating the Windows + token-rotation scenario from issue #2081. Co-authored-by: multica-agent <github@multica.ai>	2026-05-06 15:18:04 +08:00
Matt Van Horn	0dbfbfed2e	fix(daemon/execenv): refuse to write .gc_meta.json when issue_id is empty (#2077) ... A non-trivial fraction of completed task workdirs (~28% in field reports) end up with .gc_meta.json files containing issue_id: "". Empty issue_id defeats the daemon's own GC loop (gc.go:139 calls GetIssueGCCheck(meta.IssueID)) and external retention scripts that cross-reference issue status before deleting orphaned workdirs. Refuse to write the file when issueID is empty, logging a Warn so operators have a starting point for debugging the upstream race condition. Skip is preferred over a sentinel-marker file: it keeps the data invariant clean (a .gc_meta.json file always carries a valid issue_id) and matches the repo CLAUDE.md preference for not preserving dual-state behavior. WriteGCMeta now takes a *slog.Logger so it can emit the warning. The package already uses log/slog (Prepare/reuseEnv), and daemon.go:884 has taskLog in scope at the only call site. Closes #1913 Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>	2026-05-06 15:02:16 +08:00
Bohan Jiang	b08594f2f6	fix(daemon): isolate runtime poll & heartbeat schedules per runtime (#2116) ... * fix(daemon): isolate runtime poll & heartbeat schedules per runtime A daemon serving multiple workspaces ran a single round-robin poll loop and a single HTTP heartbeat loop across every registered runtime. A 30s HTTP timeout for any one runtime serialized that delay across all the others — observed in production as one workspace's runtimes wedging every other workspace's runtimes on the same daemon. This change: - Replaces the shared runtime-set channel with a multi-subscriber watcher so taskWakeupLoop, heartbeatLoop, and pollLoop can each react to runtime-set changes independently. - Splits heartbeatLoop and pollLoop into supervisor + per-runtime worker goroutines. Each runtime owns its claim cadence and its heartbeat ticker, so a slow request on one runtime no longer blocks any other. - Stagers the per-runtime heartbeat first tick by a jittered delay up to one full interval to avoid a thundering herd at startup. - Sizes the WS writer channel to scale with the runtime count (max(16, 2*N)) so a full per-runtime heartbeat batch always fits; the previous fixed 8-slot buffer dropped heartbeats whenever a daemon watched more than ~8 runtimes. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): acquire execution slot only after ClaimTask, drain pollers before taskWG Two issues from review on the previous commit: 1. Acquiring the shared task slot before ClaimTask reintroduced the very head-of-line blocking the refactor was meant to remove. With MaxConcurrentTasks=1, a slow claim on one runtime parked the only slot for the duration of the HTTP timeout (up to 30s), starving every other runtime's claim attempts. Slots are now acquired after the claim returns a task; other runtimes' pollers stay free to claim. The already-dispatched task waits for a slot under MaxConcurrentTasks bounds, which is the same backpressure shape we had before. 2. pollLoop's shutdown path called taskWG.Wait immediately after cancelling pollers, but a poller could still be between ClaimTask returning a task and taskWG.Add(1). When taskWG's counter is zero that races with Wait — undefined sync.WaitGroup misuse, sometimes panic. Added a pollerWG so the supervisor blocks until every poller goroutine has actually returned before reaching taskWG.Wait. Tests: - TestRunRuntimePollerIsolatesSlowRuntime now uses MaxConcurrentTasks=1 (was 4) so it would have failed under the old slot-before-claim path. - New TestPollLoopShutdownWaitsForPollersBeforeTaskWG drives the exact race window — claim returns a task at the same moment shutdown fires — under -race. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): acquire slot before ClaimTask so capacity-waiters never enter dispatched The previous commit moved slot acquisition AFTER ClaimTask to address a review concern about head-of-line blocking with MaxConcurrentTasks=1. That introduced a strictly worse failure mode: server-side ClaimTask flips the task to `dispatched` immediately (agent.sql:174-176), and the runtime sweeper fails any task in `dispatched` for >300s with `failed/timeout` (runtime_sweeper.go:25-28). When local execution capacity is full and the next claimed task can't acquire a slot within 5 minutes, the user sees the exact failure this issue is fixing — `dispatched_at` set, `started_at` NULL, `failure_reason=timeout`. Reverted to slot-before-claim. The trade-off is the original review concern: with MaxConcurrentTasks=1 and a slow ClaimTask, other runtimes' claims are delayed by up to client.Timeout=30s. That's a 30s polling delay, not a failure — server-side those tasks remain `queued` (no timeout in that state) until a slot frees. 30s ≪ 300s, so other runtimes' tasks cannot get sweeper-failed because of this. The pollerWG fix from the previous commit (avoiding sync.WaitGroup misuse on shutdown) is preserved. Tests: - TestRunRuntimePollerIsolatesSlowRuntime: MaxConcurrentTasks back to 4 (the pre-issue baseline) — the headroom case where slot-before- claim still gives full per-runtime isolation. - New TestRunRuntimePollerSkipsClaimWhenAtCapacity: holds the only slot and verifies the poller never calls ClaimTask while sem is empty. The previous "claim first" path would have failed this. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-06 14:13:27 +08:00
Bohan Jiang	a4fac51cf5	fix(projects): add resource_count breadcrumb instead of inlining resources (#2118) ... * fix(projects): add resource_count breadcrumb to project responses Closes #2087 `multica project get` previously returned project metadata with no signal that resources existed. Agents that fetched a project this way had no way to discover its attached resources without already knowing about `/api/projects/{id}/resources` or the on-disk `.multica/project/resources.json`. Rather than inline the full resource list into the parent payload (which conflates parent metadata with a child sub-collection and locks the resource_ref shape into the project endpoint's contract), this adds a scalar `resource_count` breadcrumb to ProjectResponse. The actual list stays at the dedicated sub-collection endpoint. Changes: - GetProjectResourceCounts :many — new batched sqlc query - ProjectResponse.ResourceCount populated in GetProject, ListProjects, SearchProjects, and the with-resources CreateProject echo - multica project get prints a stderr hint pointing at multica project resource list <id> when count > 0; the JSON on stdout stays parseable - Meta-skill (runtime_config.go) lists multica project get and multica project resource list in Available Commands so agents that read CLAUDE.md / AGENTS.md know about both paths Co-authored-by: multica-agent <github@multica.ai> * fix(projects): wire ResourceCount through Update + Create event payload Review feedback on #2118. - UpdateProject now reloads ResourceCount before responding/publishing. Previously a title- or status-only PUT served (and broadcast over WS) resource_count: 0 even when resources existed. - The with-resources CreateProject path sets resp.ResourceCount before the project:created publish, so the WS event payload matches the HTTP echo. The hand-rolled response map collapses to an embedded ProjectResponse + resources array — one source of truth for the serialized shape. - packages/core/types/project.ts: Project gains resource_count: number to keep the TS contract aligned with the server response. Tests: - TestProjectResourceCountBreadcrumb extends to assert UpdateProject preserves the breadcrumb. - TestCreateProjectWithResourcesEchoesCount asserts the create echo carries resource_count matching the attached resources. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-06 14:09:35 +08:00
Bohan Jiang	f1082b10a4	feat(cli): add --assignee-id / --to-id / --user-id for unambiguous targeting (#2114) ... * feat(cli): add --assignee-id / --to-id / --user-id for unambiguous targeting `multica issue {create,update,list}`, `issue assign`, and `issue subscriber {add,remove}` accepted only fuzzy name matching, which fails in workspaces where one user's name is a substring of another (e.g. agent "J" vs "Cursor - J" / member "Jiayuan"). #1642 added UUID acceptance through the existing flags, but there was still no explicit path that signals "this is a UUID, not a name" — important for scripts that read IDs from `multica workspace members --output json`. Adds an `-id`-suffixed counterpart for every assignee-taking flag: - `issue list` : --assignee-id - `issue create` : --assignee-id - `issue update` : --assignee-id - `issue assign` : --to-id - `issue subscriber {add,remove}` : --user-id The new flags route through `resolveAssigneeByID`, a strict resolver that requires a canonical UUID and fails with a clear error when the entity is not in the workspace (no name fallback). A shared `pickAssigneeFromFlags` helper enforces mutual exclusion between the name and id flags so a script that accidentally sets both never silently applies one over the other. Refs MUL-1254. Co-authored-by: multica-agent <github@multica.ai> * fix(cli): detect assignee flag presence via Changed, not value-emptiness `pickAssigneeFromFlags` previously branched on `flag value != ""`, so explicitly passing an empty UUID silently routed through the "no flag set" path: multica issue list --assignee-id "" # listed every issue multica issue create --assignee-id "" # created an unassigned issue multica issue subscriber add --user-id "" # subscribed the caller This is exactly the failure mode the strict-UUID flag was added to prevent — a script interpolating `--assignee-id "$MAYBE_UUID"` against a missing env var should fail loudly, not silently degrade to a different operation. Switch the picker (and the assign-command top-level guard) to use `Flags().Changed`, so an explicit empty value reaches `resolveAssigneeByID` / `resolveAssignee` and surfaces a clear "expected a canonical UUID" / "no member or agent found matching" error. Co-authored-by: multica-agent <github@multica.ai> * docs(cli): cover --assignee-id / --to-id in user docs and quick-create prompt Follow-up to the --*-id flag rollout: surface the new flags everywhere the old ones are documented so users (and agents) can discover them. - assigning-issues.{mdx,zh.mdx}: the page explicitly calls out the duplicate-name footgun ("first one listed wins, so rename before assigning") — replace that workaround with a --to-id <uuid> example - cloud-quickstart.{mdx,zh.mdx}: add a --to-id hint after the substring- match callout so first-time users learn about the strict path - internal/daemon/prompt.go (quick-create injected prompt): - default-to-self: pass --assignee-id <task.Agent.ID> instead of --assignee <name>; the picker agent's UUID is already in scope and UUID matching is unambiguous in workspaces with overlapping agent names (J / Cursor - J / Pi - J etc.) - user-named: tell the agent to prefer --assignee-id <uuid> using the user_id/id from the JSON it already fetched; --assignee <name> stays a fallback for unambiguous workspaces Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-06 13:13:36 +08:00
Ákos Seres	64c605e227	fix(execenv): write OpenCode skills to .opencode/skills/ for native discovery (#2016) ... * fix(execenv): write OpenCode skills to .opencode/skills/ for native discovery * fix(repocache): exclude OpenCode skill directory	2026-05-06 11:48:06 +08:00
Jiayuan Zhang	d492b9d7a6	Revert "feat(quick-create): add preset issue fields (#2002)" (#2042) ... This reverts commit a039c4d803.	2026-05-03 20:02:40 +02:00
Bohan Jiang	3dc3e49a47	fix(daemon): remove Co-authored-by hook when workspace setting is off (#2035) ... * fix(daemon): remove Co-authored-by hook when workspace setting is off The prepare-commit-msg hook is installed in the bare repo's shared hooks dir, so once installed it persists across worktrees. CreateWorktree only installed the hook when the setting was enabled, but never removed it — so disabling the workspace toggle had no effect on subsequent commits. Add removeCoAuthoredByHook and call it in both CreateWorktree branches when the setting is disabled. Use a marker comment in the hook script so removal only deletes hooks the daemon owns; user-installed hooks at the same path are left alone. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): recognize legacy Multica prepare-commit-msg hook on removal The first cut of removeCoAuthoredByHook only recognized hooks installed by the new code (containing the multicaHookMarker sentinel). Bare clones already on disk from previous daemon releases carry the older script without that line, so toggling the workspace setting off would have treated them as user hooks and left the trailer in place — exactly the state reported in MUL-1704. Match against a list of known daemon signatures (current marker + the legacy "Installed by the Multica daemon." comment), and add a test that seeds the verbatim legacy hook before CreateWorktree(... disabled) to keep recognition aligned with what production hosts actually have on disk. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-03 21:09:16 +08:00
ayakabot	a039c4d803	feat(quick-create): add preset issue fields (#2002) ... Fixed: #2001	2026-05-03 19:37:12 +08:00
Bohan Jiang	c4352da126	fix(daemon): drain background repo syncs before test teardown (#2026) ... TestRegisterTaskReposSurvivesWorkspaceRefresh started flaking on CI after #1988 (`feat: support repo checkout ref selection`) extended the bare-clone path to run an extra `git fetch` to backfill refs/remotes/origin/* under the new refspec layout. The race was already latent: registerTaskRepos kicks off `go syncWorkspaceRepos(...)` to clone a repo into the cache root, which in tests is `t.TempDir()`. Once the test waited on `repoCache.Lookup` to return a path it would proceed and return — but the bg goroutine was still inside `ensureRemoteTrackingLayout` running git operations on the clone dir. `t.TempDir`'s cleanup then races with those git commands and surfaces either as "directory not empty" or "fatal: cannot change to ... No such file or directory", with no hint that the failure is unrelated to the test's actual assertion. Track the background goroutine on the Daemon via a sync.WaitGroup and expose `waitBackgroundSyncs()` for tests. `newRepoReadyTestDaemon` registers a t.Cleanup that calls it, so every test that uses the helper now drains in-flight syncs before t.TempDir cleanup runs. No production-behavior change — registerTaskRepos still fires-and-forgets from the caller's perspective. Verified with `go test ./internal/daemon -run TestRegisterTaskReposSurvivesWorkspaceRefresh -count=30` (was failing within ~10 iterations before, 30 green after) and the full `go test ./internal/daemon/...` suite. Co-authored-by: multica-agent <github@multica.ai>	2026-05-03 12:24:56 +08:00
Bohan Jiang	a414a00b4a	refactor(repocache): clarify resolveBaseRef comment and cover tag refs (#2023) ... Follow-up nits from PR #1988 review: - Move the comment that documents getRemoteDefaultBranch's resolution walk into the resolveBaseRef call site description, and rephrase the "" branch so it's clear that path only fires for the default-branch case (the requested-ref path returns an explicit error before reaching it). - Add TestCreateWorktreeWithRequestedTagRef to lock in the refs/tags/<ref> candidate. The test tags the initial commit, advances the default branch past it, then asserts the worktree HEAD matches the tagged commit (so the tag must have been resolved, not the default branch). Co-authored-by: multica-agent <github@multica.ai>	2026-05-03 11:30:25 +08:00
Prince Pal	862b0509df	feat: support repo checkout ref selection (#1988)	2026-05-03 11:27:16 +08:00
Bohan Jiang	ba5b7db78e	fix(server): persist ModelListStore across replicas via Redis (#2022) ... * fix(server): persist ModelListStore across replicas via Redis The model picker uses a pending-request pattern: the frontend POSTs to create a request, the daemon pops it on its next heartbeat, runs agent.ListModels locally, and reports back. Until now the store was a plain in-memory map per Handler instance. That works for self-hosted single-instance deploys but fails in any multi-replica environment (Multica Cloud). Each replica has its own map, so: POST /runtimes/:id/models → request stored in replica A GET /runtimes/:id/models/<requestId> → polls land on B/C → 404 daemon heartbeat → only A sees PendingModelList POST .../<requestId>/result → daemon's report has to land on A Success probability ~1/N². The visible symptom is "No models available" in the picker for every provider, even those (Claude/Codex) whose catalog is statically populated end-to-end. Same shape of bug, same Redis-backed fix as multica-ai/multica#1557 did for LocalSkillListStore / LocalSkillImportStore. Reuse the operational playbook (namespaced keys, ZSET-backed pending queue, atomic ZREM+SET-running via the shared Lua script) so we don't introduce a second concurrency model for the same primitive. Changes: - Convert ModelListStore from struct to interface with context-aware methods. Add HasPending for cheap heartbeat-side probing. - InMemoryModelListStore — single-node fallback, used when REDIS_URL is unset (self-hosted dev / tests). - RedisModelListStore — multi-node implementation using the same key layout and Lua atomic claim as RedisLocalSkillListStore. - Use RunStartedAt (not UpdatedAt) as the running-timeout reference point, matching the local-skill stores so subsequent UpdatedAt bumps don't reset the running clock. - Heartbeat now uses the probe-then-pop pattern for the model queue (matching local-skills) so a slow Redis can't stall every connected daemon. Extends heartbeatMetrics + slow-log with probe_model_ms / pop_model_ms / probe_model_timed_out for parity. - Wire the Redis backend in NewRouterWithOptions when rdb != nil. - Tests for both backends. Redis tests gate on REDIS_TEST_URL so laptop runs without Redis still pass; CI provides it. Co-authored-by: multica-agent <github@multica.ai> * fix(server): persist RunStartedAt + retry model report on transient failures Two follow-ups from PR #2022 review: 1. RedisModelListStore was dropping ModelListRequest.RunStartedAt on persistence — the field is tagged json:"-" so it doesn't leak into the HTTP response, which made plain json.Marshal(req) silently discard it. Across-node readers saw RunStartedAt=nil and applyModelListTimeout's running branch became a no-op, so the 60s running-timeout escape hatch never fired. CI's TestRedisModelListStore_RunningTimeout was failing on this exact case. Fix mirrors RedisLocalSkillImportStore's envelope pattern — wrap in an internal struct that re-promotes the field. HTTP shape stays clean. Adds a no-Redis unit test that pins the round trip. 2. Daemon's handleModelList called d.client.ReportModelListResult directly and swallowed any 5xx, leaving the pending request stranded in "running" until its 60s server-side timeout — exactly the failure mode the multi-node store fix was meant to eliminate. Generalize the existing local-skill retry helper into reportRuntimeResultWithRetry (kind: model_list / local_skill_list / local_skill_import) and wire handleModelList through a new reportModelListResult helper. Renames the test-overridable var localSkillReportBackoffs → runtimeReportBackoffs to match. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-03 11:13:34 +08:00
Multica Eve	f85b7cce91	fix: make CLI update completion status reliable (#2018) ... Co-authored-by: Devv <devv@Devvs-Mac-mini.local> Co-authored-by: multica-agent <github@multica.ai>	2026-05-03 10:52:14 +08:00
Jiayuan Zhang	3df95c84b8	fix(daemon): add safe.directory=* to gitEnv to fix CI dubious ownership errors (#1980) ... * fix(daemon): add safe.directory=* to gitEnv to fix CI dubious ownership errors TestRegisterTaskReposAllowsProjectOnlyURL and TestRegisterTaskReposSurvivesWorkspaceRefresh fail on GitHub Actions CI because git clone --bare from local temp directories triggers git's safe.directory ownership check when the runner UID differs from the directory owner. Set safe.directory=* via GIT_CONFIG env vars in gitEnv() so all daemon git subprocesses trust any directory. The daemon manages its own bare caches and worktrees, so the ownership check provides no security value. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): preserve existing GIT_CONFIG_* entries in gitEnv Instead of resetting GIT_CONFIG_COUNT to 1, read the existing count from the environment and append safe.directory at the next available index. This preserves any env-scoped git config (auth, URL rewrites, extra headers) injected into the daemon process. Adds TestGitEnvPreservesExistingConfig to verify the append behavior. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-05-01 16:18:58 +02:00
Jiayuan Zhang	13fe614903	fix(daemon): optimize quick-create prompt for high-fidelity descriptions (#1969) ... The previous description rule ("stay faithful + keep it concise") caused agents to over-compress user input into vague single-sentence summaries, losing context that the executing agent needs. Key changes: - Replace "keep it concise" with structured two-section format: User request (faithful restate) + Context (verifiable external facts) - Add hard rules against information compression and semantic downgrading - Remove "one-line description" phrasing (UI supports richer input) - Strip redundant behavioral rules from issue_context.md (already covered by AGENTS.md guardrails and per-turn prompt) Co-authored-by: multica-agent <github@multica.ai>	2026-05-01 08:14:55 +02:00
Bohan Jiang	1d1dedbf6e	fix(daemon): reclaim disk on long-open issues + correct cancelled-status check (#1931) ... * fix(daemon): reclaim disk on long-open issues + correct cancelled-status check Two related fixes for GitHub #1890 (self-hosted disk space growth): - The GC's done/cancelled branch compared `status.Status` against `"canceled"` (single l), but the issue schema and the rest of the daemon use `"cancelled"` (double l). Cancelled issues therefore never matched and only fell out via the 72h orphan TTL, which itself doesn't fire because cancelled issues are still reachable. Aligning the spelling lets cancelled-issue task dirs be reclaimed on the normal TTL path. - Add a third GC mode, artifact-only cleanup, for the common case the report flagged: an issue stays open for days while many tasks complete on it, so per-task `node_modules`, `.next` and `.turbo` directories accumulate without ever becoming GC-eligible. The new branch fires when `.gc_meta.completed_at` is older than `MULTICA_GC_ARTIFACT_TTL` (default 12h), the env root is not currently in use by an active task, and the issue is still alive. It removes only directories whose basename matches `MULTICA_GC_ARTIFACT_PATTERNS` (default narrow: `node_modules,.next,.turbo`); source, `.git`, `output/`, `logs/` and the meta file are preserved so subsequent tasks can still resume the workdir. Patterns containing path separators are dropped, `.git` subtrees are never descended into, symlinked matches are not followed, and every removal target is verified to live inside the task dir. Bookkeeping: `Daemon` now tracks active env roots with a refcounted set so the GC loop never reclaims a directory that is mid-execution; `runTask` claims the predicted root early plus the prior workdir on reuse paths. The cycle log is extended with bytes reclaimed and per-pattern counts so self-hosted operators can see what was freed. Docs: extend the daemon configuration table in CLI_AND_DAEMON.md with the new GC env vars and add a Workspace garbage collection section explaining the three modes and the artifact-pattern contract. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): protect active env root from full GC removal too Address GPT-Boy's PR #1931 review: the active-root guard only fired in the artifact-cleanup branch, leaving a real race on the full-removal paths. A follow-up comment on a long-done issue dispatches a task that reuses the prior workdir, but `CreateComment` does not bump issue.updated_at — so the issue still satisfies the done+stale GCTTL window and `gcActionClean` would `RemoveAll` the directory mid-execution. The orphan-404 path is similarly exposed when a token's workspace access is in flux. Move the `isActiveEnvRoot` check to the top of `shouldCleanTaskDir` so all three delete actions (clean, orphan, artifact) skip an in-use env root in one place, and drop the now-redundant guard from the artifact branch. Add tests covering the three at-risk paths: active root + done/stale issue, active root + 404 issue past orphan TTL, active root + no-meta orphan past TTL. Also align two stale comments noted in the same review: cleanTaskArtifacts now documents that symlinks are skipped entirely (the previous note implied the link itself was removed), and GCOrphanTTL no longer claims that 404s are cleaned immediately — the implementation gates them on the same TTL. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-04-30 15:34:16 +08:00
Bohan Jiang	da5dbc6224	refactor(repos): drop unused description + tighten create-project layout (#1930) ... * refactor(repos): drop unused description + tighten create-project layout Two related changes that touch the workspace-repos surface together. 1. Remove the per-repo `description` field everywhere it was threaded. The only place it ever surfaced was a markdown table column the daemon wrote into the agent runtime config, where most rows just read "—" anyway. Agents already discover project structure by running `multica project` / `multica issue` against the CLI, so the human- readable description string carried no real value while taking up an extra Settings input row and propagating through six layers (settings UI → workspace.repos jsonb → handler RepoData → daemon RepoData → repocache.RepoInfo → execenv.RepoContextForEnv). - Settings → Repositories drops the description input; the URL field now spans the whole row. - WorkspaceRepo TS type loses `description`; backend RepoData / RepoInfo / RepoContextForEnv all collapse to URL only. - Daemon's runtime_config Repositories block changes from a `| URL | Description |` markdown table to a simple bullet list. - Tests updated; jsonb residue in existing workspaces is dropped at normalize time, so no migration needed. 2. Tighten the Create Project modal footer: pull the Status / Priority / Lead / Repos pills onto the same row as the Create Project button (Linear-style single-row footer) instead of stacking them above it, and swap the Repos pill icon from `FolderGit` to a real GitHub mark (lucide-react v1 dropped brand icons, so the mark lives inline as a small SVG component in this file). I tried promoting Repos to its own "Resources" strip above the footer to separate the resources abstraction from project metadata, but with a single pill it looked too sparse — leaving a TODO comment in the footer to revisit once we add Linear / Notion / Figma / Slack resource types. * fix(daemon test): drop residual Description field on RepoData literals * fix(repos): drop Description residue surfaced after rebase on #1929 Project-resource github_repo lift path (#1929) and registerTaskRepos both still constructed RepoData{...Description: ...} after the rebase. Two test sites in daemon_test.go and execenv_test.go also reintroduced the field. Strip them so the Description-removal change builds and tests pass with the latest main.	2026-04-30 14:55:03 +08:00
Bohan Jiang	2129aa3dee	feat(projects): project github_repo resources override workspace repos (#1929) ... * feat(projects): project github_repo resources override workspace repos When an issue's project has at least one github_repo resource, the daemon claim handler now sends only those as resp.Repos — workspace-level repos are hidden to avoid mixing two repo lists in the agent prompt. With no project github_repos (or no project), behavior is unchanged: workspace repos are surfaced as before. Lifts each project github_repo's url (and label, when present) into a RepoData entry so `multica repo checkout` and the meta-skill render the same URLs. The full structured list still ships at .multica/project/resources.json for skills that want everything. Adds TestProjectReposReplaceWorkspaceReposInMetaSkill covering the rendering side. Docs updated to spell out the new precedence. Co-authored-by: multica-agent <github@multica.ai> * fix(daemon): allow project repo URLs through the checkout allowlist When ClaimTaskByRuntime narrows resp.Repos to project github_repo URLs, the daemon receives URLs that may not exist in the workspace's GetWorkspaceRepos response. The existing checkout flow rejected those with ErrRepoNotConfigured because the allowlist (and cache) was built only from workspace-bound repos. Adds registerTaskRepos in daemon.runTask: before agent spawn, merge task.Repos into a new task-scoped allowlist (separate from the workspace-scoped one so a workspace refresh doesn't wipe project URLs) and kick off a background cache sync. ensureRepoReady now treats either allowlist as valid. Tests: - TestRegisterTaskReposAllowsProjectOnlyURL — project-only URL is checkout-able and does not trigger a workspace-repos refresh - TestRegisterTaskReposSurvivesWorkspaceRefresh — task URLs persist across refreshWorkspaceRepos - TestClaimTask_ProjectGithubReposOverrideWorkspaceRepos — claim handler returns only project repos when present, no workspace leakage - TestClaimTask_ProjectWithoutRepos_FallsBackToWorkspaceRepos — fall back to workspace repos when project has no github_repo resources Docs updated to spell out the daemon-side allowlist behavior. Co-authored-by: multica-agent <github@multica.ai> --------- Co-authored-by: multica-agent <github@multica.ai>	2026-04-30 14:37:51 +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
Prince Pal	924c69114d	feat(daemon): expose concurrent task slot env (#1889) ... * feat(daemon): expose concurrent task slot env * fix(daemon): address task slot review nits	2026-04-30 12:56:40 +08:00