Files

T

nntrivi2001 57dc91585d feat: Claude Code Monitor — lanes, pipelines and a merged workspace

Internal SmartGift build of a Claude Code monitoring dashboard.

Lanes: a durable unit of parallel agent work, one per working directory,
tracked across session restarts. Managed lanes are git worktrees the
dashboard provisions and can reset or remove behind a three-check destroy
guard and a counted preflight; adopted lanes are directories you already
own and are never destroyable.

Pipelines: a lane moves through pipeline stages. A stage the agent declares
with evidence renders green; a stage inferred from the tool-event stream
renders dashed amber and never counts as done. Detection is forward-only
within a 30-minute window, and never writes the declared stage.

Workspace: one page at /run with a lane grid, the selected lane's pipeline,
and a full Claude console behind a disclosure.

2026-07-30 14:39:03 +07:00

5.8 KiB

Raw Blame History

name, description

name	description
update-project-docs	MANDATORY for every coding agent (Claude Code, Codex, or any other) — keep this repository's documentation in sync after any change to behavior, configuration, interfaces, events, schema, or features. Use automatically (without being asked) at the end of ANY change-set that adds or alters an env var, event type, hook behavior, session/agent state transition, API route or response shape, DB schema, WebSocket message, MCP tool, CLI command, or user-facing feature — and whenever the user asks to "update the docs / README / architecture". Knows the full doc surface (README, ARCHITECTURE, server/client READMEs, docs/*) and which docs each kind of change touches.

name

description

update-project-docs

MANDATORY for every coding agent (Claude Code, Codex, or any other) — keep this repository's documentation in sync after any change to behavior, configuration, interfaces, events, schema, or features. Use automatically (without being asked) at the end of ANY change-set that adds or alters an env var, event type, hook behavior, session/agent state transition, API route or response shape, DB schema, WebSocket message, MCP tool, CLI command, or user-facing feature — and whenever the user asks to "update the docs / README / architecture". Knows the full doc surface (README, ARCHITECTURE, server/client READMEs, docs/*) and which docs each kind of change touches.

Update Project Docs

This repository keeps a large doc set and docs drift silently, because one change often belongs in several files at once. This skill encodes which docs exist, which change-types touch which docs, and how to propagate consistently. This build ships English only — the translated READMEs, the wiki and the root landing page were removed; do not recreate them.

Authoritative inventory with exact section anchors lives in references/doc-map.md — read it when deciding where a specific change lands. The repo rule .claude/rules/docs-markdown.md ("update all affected docs together") is binding.

When to update (including without being asked)

Update docs in the same change-set (PR/commit) as the code, before claiming done — do not wait for the user to ask — whenever the change is observable from outside the module:

New/changed env var → every env-var table + .env.example.
New event type (e.g. an events.event_type value) → every event-type list/table.
New/changed hook behavior or session/agent state transition → hook docs + every state-machine diagram.
New/changed API route or response shape → API docs + route tables + OpenAPI.
DB schema change (table/column/index) → database docs + ERD.
New WebSocket message type → client/server WS docs.
New MCP tool → MCP docs.
New CLI command / script / renamed file referenced in docs → command lists + onboarding guides.
New user-facing feature / page / background service → feature tables + architecture.

Do NOT auto-update for: pure internal refactors with no observable/interface/config change, test-only changes, comment/typo fixes, or work the user explicitly scoped as "no docs". When unsure whether a change is observable, check the mapping below; if it touches any row, update.

Change → docs mapping

Change type	Docs to update
Env var	`README.md` (env table), `ARCHITECTURE.md` (inline), `server/README.md`, `.env.example`
Event type	`README.md`+VN+CN (hook-event table), `ARCHITECTURE.md` (Event types line), `docs/PLUGINS.md`, + i18n, `docs/DATABASE.md` (if it enumerates types)
Hook behavior / state transition	`docs/HOOKS.md`, state-machine mermaid diagrams in `README.md`+VN+CN + `server/README.md` + `docs/DATABASE.md` + , `ARCHITECTURE.md` (hooks.js row)
API route / response	`docs/API.md`, `server/README.md` (routes), `ARCHITECTURE.md` (routes row), `server/openapi*.js` (code)
DB schema	`docs/DATABASE.md`, `ARCHITECTURE.md` (ERD/schema)
WebSocket message	`client/README.md` (Event Types), `server/README.md`,
MCP tool	`mcp/README.md`, `docs/MCP.md`
Feature / page / background service	`README.md` (feature table + data-flow list), `ARCHITECTURE.md` (module table), `server/README.md` or `client/README.md`
CLI command / script	`README.md` commands, `CLAUDE.md` / `AGENTS.md`, `INSTALL.md` / `SETUP.md`
New language	`docs/I18N.md`, `client/src/i18n/locales/<xx>/*`, `client/src/i18n/index.ts` (add to `supportedLngs` AND the `resources` map)

Procedure

Classify the change against the table above. A change can hit multiple rows (a new feature with a new env var hits both).
Write the canonical English version first — usually README.md and/or ARCHITECTURE.md. Get the wording right there; it anchors everything else.
Area READMEs / docs/: update server/README.md, client/README.md, and the relevant docs/*.md per the mapping.
Diagrams: when a state transition changes, edit every mermaid stateDiagram-v2 block that models it (they are duplicated across README, server/README and docs/DATABASE). Keep transition labels consistent.

Verify (do not skip)

Coverage: run scripts/doc-coverage.sh <new-term> [...] (e.g. the new env var / event type / identifier) and confirm every doc the mapping flags shows a HIT. The matrix is advisory — not every term belongs in every file — but a flagged doc reading 0 is a miss to fix.
Tables: markdown tables stay pipe-balanced (header column count == every row).
Mermaid: each edited block still parses (valid source --> target: label).
i18n: every new English string has a vi entry in client/src/i18n/locales/vi/.
Format/tests: run npm run format (or prettier --check on touched files); for any code touched, run the verification from CLAUDE.md (npm run test:server / test:client / mcp:typecheck).
State exactly which docs were updated and which were intentionally skipped (with reason), mirroring the repo's verification policy.

Tips

The fastest way to find where something already lives: grep -n "<existing-neighbor-term>" <doc> (e.g. grep an adjacent env var to find the env table). references/doc-map.md lists the stable anchors per file.
Parallelize translations + HTML across subagents when the change is large, but write the canonical English edit yourself first so the translations have a faithful source.
One language/area per subagent keeps edits reviewable and tables un-corrupted.

5.8 KiB Raw Blame History