refactor: decouple task lifecycle from issue status (#151 )

* refactor: decouple task lifecycle from issue status, add daemon health server

- Remove automatic issue status changes from StartTask (in_progress),
  CompleteTask (in_review), and FailTask (blocked) in task service.
  Issue status is now fully managed by the agent via `multica issue status`.
- Update agent prompt and meta skill to instruct agents to manage issue
  status themselves (in_progress → done/in_review/blocked).
- Add daemon health HTTP server on 127.0.0.1:19514 with /health endpoint
  exposing pid, uptime, agents, and workspaces. Fail fast if port is taken
  (another daemon already running).
- Update `multica status` to check both server and daemon health.
- Add Save button to repos section in workspace settings UI.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* refactor(daemon): simplify prompt, fix runtime config path, improve task error logging

- Slim down BuildPrompt to a minimal hint; detailed workflow now lives in CLAUDE.md/AGENTS.md
- Write CLAUDE.md to workDir root instead of .claude/CLAUDE.md
- Fix git-exclude pattern (.claude → CLAUDE.md)
- Decouple task queue reconciliation from issue status changes (agents manage status via CLI)
- Add diagnostic logging when CompleteTask/FailTask fail due to unexpected task state

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

* fix(task): use task_completed/task_failed inbox notification types

FailTask was sending "agent_blocked" which conflates agent crash with
issue-level blocked status. Align notification types with the new
decoupled model: task_completed and task_failed. Update frontend types
and labels accordingly.

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-27 18:30:21 +08:00

2.4 KiB

Raw Blame History

Repository Guidelines

Project Structure & Module Organization

apps/web/ contains the Next.js 16 frontend: routes live in app/, reusable UI in components/, feature code in features/, test utilities in test/, and static assets in public/. server/ contains the Go backend: entry points are in cmd/{server,multica,migrate}, application logic lives in internal/, migrations are in migrations/, and SQL lives under pkg/db/queries/ with generated sqlc output in pkg/db/generated/. e2e/ holds Playwright coverage. scripts/ and the root Makefile drive local setup and verification.

Build, Test, and Development Commands

Use make setup for first-time setup: it installs dependencies, ensures PostgreSQL is running, and applies migrations. Use make start to run backend and frontend together with .env or .env.worktree. For single-surface work, use pnpm dev:web for the frontend and make dev for the Go server. Run pnpm test for Vitest, make test for Go tests, and make check for the full pipeline: typecheck, frontend unit tests, Go tests, then Playwright. After changing SQL in server/pkg/db/queries/*.sql, run make sqlc.

Coding Style & Naming Conventions

TypeScript in apps/web uses 2-space indentation, double quotes, and semicolons. Prefer PascalCase for React components, camelCase for hooks and helpers, and colocated test files such as page.test.tsx. Go code should stay gofmt-clean and use domain-oriented filenames like issue.go or cmd_issue.go. Do not hand-edit generated code in server/pkg/db/generated/.

Testing Guidelines

Frontend unit tests use Vitest with Testing Library and shared setup from apps/web/test/. End-to-end tests live in e2e/*.spec.ts; make check will start missing services automatically, while direct Playwright runs expect the app to already be running. Backend tests use Go’s standard *_test.go pattern. Add or update tests whenever you change handlers, CLI commands, daemon behavior, or SQL-backed flows.

Commit & Pull Request Guidelines

Recent history follows conventional commits with scopes, for example feat(web): ..., fix(cli): ..., refactor(daemon): ..., test(cli): ..., and docs: .... Keep PRs focused and include a short description, linked issue or PR number when relevant, screenshots for UI work, and notes for migrations, env changes, or CLI surface changes. Before opening a PR, run make check or the relevant frontend/backend subset.

2.4 KiB Raw Blame History Unescape Escape