6d2a0b45d2
* 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>
16 lines
2.4 KiB
Markdown
16 lines
2.4 KiB
Markdown
# 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.
|