Files

T

nntrivi2001 17d56d0e01 refactor!: rebrand CCAM to AgentHub

Clean break, no compatibility alias. Renames the product name, the CLI
binary (`ccam` -> `agenthub`), the env var prefix (`CCAM_` ->
`AGENTHUB_`), the Prometheus metric namespace (`ccam_*` ->
`agenthub_*`), the tmux session prefix (`ccam-lane-<id>` ->
`agenthub-lane-<id>`), the per-repo runtime profile directory
(`.ccam/profile` -> `.agenthub/profile`), the lanes state root
(`~/.claude/ccam-lanes` -> `~/.claude/agenthub-lanes`), the bundled
plugins (`plugins/ccam*` -> `plugins/agenthub*`) and their slash
commands (`/ccam-doctor` -> `/agenthub-doctor`, `/ccam:*` ->
`/agenthub:*`).

Because there is no alias, an existing install has to be updated by
hand: rename its `.ccam/profile` directory and any `CCAM_*` variables,
and reinstall the plugin under its new name.

Two other name families are deliberately left alone here, since they are
not just strings: the `Claude-Code-Monitor` repository/marketplace name,
and the `agent-dashboard` npm package plus its `~/.claude/agent-dashboard`
runtime directory, which holds the live database and needs a migration
rather than a rename.

Verified: server 1406/1406, client 459/459, `grep -i ccam` clean across
tracked files, `openapi.yaml` regenerated (95 paths, unchanged count).

2026-09-07 12:09:15 +07:00

3.8 KiB

Raw Blame History

Codex Project Instructions

Project intent

Keep this repository a stable, local-first Claude Code monitoring platform.
Maintain correctness across hooks, API, DB, websocket, UI, and MCP integration.

Priorities

Correctness over cleverness.
Small, scoped, reversible diffs.
Preserve existing behavior unless change is requested.
Update docs whenever workflow or architecture changes — follow skills/update-project-docs/ automatically at the end of every change-set (README + VN/CN/KO mirrors, ARCHITECTURE, wiki + i18n + cache bump, server/client READMEs, docs/*).
Every applicable source file you create or update (.js/.ts/.tsx/.cjs/.mjs/.py/.sh/.css) must start with the authorship header: a truthful file overview plus the exact line @author Nguyễn Ngọc Trí Vĩ <vinnt@smartgift.vn>. See skills/file-headers/ and .claude/rules/file-headers.md; verify with bash skills/file-headers/scripts/check-headers.sh.

Declare your lane stage as you work

This repository is watched by AgentHub, its own dashboard. A lane is keyed by working directory, and the pipeline map only moves forward when the agent doing the work declares its stage:

agenthub stage <stage> --tool codex --evidence "<what is actually done>"

Call it at every real transition — starting to plan, starting to implement, running tests, opening the PR — not once at the end.
Stage names, default template: intake → plan → implement → tests → review → gate → ship → done (the 16-node ship-feature template accepts these as aliases too; agenthub stage warns on stderr and names the valid nodes if a stage matches none).
--tool codex matters. One directory can back both a claude lane and a codex lane, and without a tool the command fails rather than guess (it names both candidates). Inside a pane the dashboard started you need nothing — that pane carries AGENTHUB_LANE_ID, which outranks everything but --lane.
If agenthub stage reports that no lane owns the directory, this checkout was never adopted: skip the stage calls and carry on. Stage reporting is reporting, never control flow — a failed agenthub stage never justifies skipping a step of the actual work.

The dashboard also infers your stage from your tool calls (it reads Codex's own rollout journals — see docs/LANES.md#stage-detection), and on a codex lane that inference does move the pipeline map forward on its own. It still never counts as evidence: a node it moved through stays amber and never renders green. Only your own declaration does that — which is why the call above is worth making even when the map already looks right.

If you hold a stage for a while with no evidence recorded, the dashboard may type a one-line [agenthub] reminder straight into this pane asking you to run agenthub stage ... --evidence "...". That is the dashboard, not the user — treat it as the same instruction as this section and just make the real call.

Where to work

server/ for API/routes/data processing.
client/ for React UI behavior.
mcp/ for local MCP server tooling.
scripts/ for hook/install/import/cleanup utilities.

Validation expectations

Backend changes: run npm run test:server when possible.
Frontend changes: run npm run test:client when possible.
MCP changes: run npm run mcp:typecheck and npm run mcp:build.
If any check is skipped, report it explicitly.

Safety expectations

Keep destructive capabilities behind explicit configuration gates.
Never broaden destructive behavior without explicit user request.
Treat hook execution path as fail-safe and non-blocking.

Useful commands

Setup: npm run setup
Dev: npm run dev
Build/start: npm run build then npm start
MCP helpers: npm run mcp:install, npm run mcp:build, npm run mcp:start

3.8 KiB Raw Blame History