Skip to content

Commit 6880dbe

Browse files
committed
docs(cleanup): Remove project-phase references and trim gotchas
- Remove "Phase 2" from agent-workflow title, intro, and inline execution section - Delete implementation order section (P2.1-P2.12 dependency chain) - Remove "(Phase 2)" annotations from CLAUDE.md architecture and tech stack - Trim gotchas.md from 132 to 55 lines, keeping only genuine contributor gotchas - Drop agent-workflow duplicates, standard boilerplate, and obvious items
1 parent 98dc587 commit 6880dbe

3 files changed

Lines changed: 15 additions & 106 deletions

File tree

CLAUDE.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -20,7 +20,7 @@ Read these when working on the relevant area:
2020
| Document | Contents |
2121
| -------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
2222
| [`docs/architecture.md`](docs/architecture.md) | Component responsibilities, data flow, git repo scope, file layout. Read when modifying service layer, store, git, or lock interactions. |
23-
| [`docs/agent-workflow.md`](docs/agent-workflow.md) | Phase 2 orchestration model, skill files, slash commands, workflow steps, blocker recovery, implementation order. Read when working on MCP, skills, or agent coordination. |
23+
| [`docs/agent-workflow.md`](docs/agent-workflow.md) | Agent orchestration model, skill files, slash commands, workflow steps, blocker recovery. Read when working on MCP, skills, or agent coordination. |
2424
| [`docs/data-model.md`](docs/data-model.md) | Domain rules (full detail), card file format, Go type definitions, board config format. Read when modifying card parsing, state machine, or API validation. |
2525
| [`docs/api-reference.md`](docs/api-reference.md) | REST endpoints, agent identification, error format, response codes. Read when modifying or consuming API handlers. |
2626
| [`docs/gotchas.md`](docs/gotchas.md) | YAML parsing, go-git, SSE, MCP, Vite, stdlib quirks. Skim before your first commit in a session. |
@@ -37,7 +37,7 @@ internal/gitops/ → GitManager (commit, pull, push via go-git)
3737
internal/lock/ → agent claim/release/heartbeat + timeout checker
3838
internal/service/ → CardService: orchestrates store, git, lock, events, state machine
3939
internal/api/ → REST API handlers (stdlib http.ServeMux) + SSE endpoint
40-
internal/mcp/ → MCP server: tools + prompts (Phase 2)
40+
internal/mcp/ → MCP server: tools + prompts
4141
internal/runner/ → webhook client for contextmatrix-runner
4242
internal/events/ → in-process pub/sub event bus
4343
internal/config/ → global config loading
@@ -59,7 +59,7 @@ details.
5959
- **go-yaml v3** — YAML frontmatter (`gopkg.in/yaml.v3`)
6060
- **goldmark** — markdown rendering for preview (`github.com/yuin/goldmark`)
6161
- **Go MCP SDK** — MCP server via Streamable HTTP
62-
(`github.com/modelcontextprotocol/go-sdk`) (Phase 2)
62+
(`github.com/modelcontextprotocol/go-sdk`)
6363
- **React 19 + TypeScript** — frontend
6464
- **Vite** — frontend build
6565
- **Tailwind CSS** — styling

docs/agent-workflow.md

Lines changed: 12 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,6 @@
1-
# Phase 2: Agent Orchestration Architecture
1+
# Agent Orchestration Architecture
22

3-
This section describes the agreed design for how AI agents coordinate work
4-
through ContextMatrix in Phase 2.
3+
This document describes how AI agents coordinate work through ContextMatrix.
54

65
## Orchestration model
76

@@ -85,16 +84,16 @@ multi-turn flow because sub-agents cannot relay back-and-forth user messages
8584
through the `Agent` tool.
8685

8786
**Server-side inline execution for model-matched skills:** `review-task` and
88-
`create-plan` (Phase 1 only) support **inline execution** when the
89-
orchestrator's model matches the skill's required model. This is controlled by
90-
the `get_skill` tool: when the orchestrator passes its model family as
91-
`caller_model` and it matches the skill model, `get_skill` returns the content
92-
wrapped in a lifecycle-enforcing inline preamble and sets `inline: true` in the
93-
response. The delegation wrapper instructs the orchestrator to execute inline
94-
when `inline` is true, or delegate as usual when false. This saves the overhead
95-
of spawning a sub-agent on the same model the orchestrator is already running.
96-
When `caller_model` is absent (backward compatibility), `inline` is always false
97-
and behavior is identical to the standard delegation flow.
87+
`create-plan` support **inline execution** when the orchestrator's model matches
88+
the skill's required model. This is controlled by the `get_skill` tool: when the
89+
orchestrator passes its model family as `caller_model` and it matches the skill
90+
model, `get_skill` returns the content wrapped in a lifecycle-enforcing inline
91+
preamble and sets `inline: true` in the response. The delegation wrapper
92+
instructs the orchestrator to execute inline when `inline` is true, or delegate
93+
as usual when false. This saves the overhead of spawning a sub-agent on the same
94+
model the orchestrator is already running. When `caller_model` is absent,
95+
`inline` is always false and behavior is identical to the standard delegation
96+
flow.
9897

9998
```
10099
skills/
@@ -482,17 +481,3 @@ needed for MCP tools.
482481
If `Edit` or `Write` is not in the target project's allowlist, execution agents
483482
will report `TASK_BLOCKED` with an actionable error message explaining what
484483
permissions are needed. The user must update the project's permissions config.
485-
486-
## Implementation order
487-
488-
The Phase 2 dependency chain for the agent orchestration workflow is:
489-
490-
```
491-
P2.1 (MCP tools — extended set)
492-
P2.2 (MCP transport + prompts) ◄── P2.1
493-
P2.4 (dependency enforcement) ◄── P2.1
494-
P2.10 (skill files) ◄── P2.2
495-
P2.8 (token tracking) ◄── P2.1
496-
P2.12 (dashboard) ◄── P2.8
497-
P2.9 (orchestrator — headless mode only, deferred)
498-
```

docs/gotchas.md

Lines changed: 0 additions & 76 deletions
Original file line numberDiff line numberDiff line change
@@ -3,10 +3,6 @@
33
- **YAML frontmatter parsing:** use `bytes.SplitN(content, []byte("---"), 3)` to
44
split. Element 0 is empty (before first `---`), element 1 is YAML, element 2
55
is body. Handle `\r\n` line endings.
6-
- **`next_id` atomicity:** since the server is single-process, a mutex on
7-
`ProjectConfig` is sufficient. Multi-instance would need file locking.
8-
- **`go-git` performance:** fine for ContextMatrix boards (small files, <10k
9-
cards). If it becomes an issue, shell out to `git` binary.
106
- **Deferred git commits (`git_deferred_commit`):** When
117
`git_deferred_commit: true` in `config.yaml`, agent mutations (heartbeats, log
128
entries, intermediate updates) are batched and committed in a single flush at
@@ -18,8 +14,6 @@
1814
API — the PUT/PATCH handlers set `ImmediateCommit: true` when
1915
`card.AssignedAgent == ""`, triggering an immediate commit. MCP tool callers
2016
(agents) never set this flag, so their commits continue to defer normally.
21-
- **SSE headers:** `Content-Type: text/event-stream`, `Cache-Control: no-cache`,
22-
`Connection: keep-alive`. Must call `Flusher.Flush()` after each event.
2317
- **SSE and MCP streaming vs. `WriteTimeout`:** Go's `http.Server.WriteTimeout`
2418
is an absolute deadline measured from when request headers are read — it is
2519
NOT reset by intermediate writes (keepalive comments, partial event data, etc.).
@@ -47,85 +41,15 @@
4741
in both `App.tsx` (top-level) and `ProjectShell.tsx` (nested project routes).
4842
If you add a new `Routes` subtree, add its own catch-all or users will see a
4943
blank screen instead of the 404 page.
50-
- **Tailwind purge:** `content` in `tailwind.config.js` must include
51-
`./src/**/*.tsx` or classes get stripped.
52-
- **Activity log bloat:** capped at 50 entries in frontmatter. Older entries are
53-
only in git history. If an agent writes very frequently, entries may be lost
54-
between git commits — this is acceptable.
55-
- **Vite proxy:** `vite.config.ts` must proxy `/api` to `http://localhost:8080`
56-
during dev. Without this, frontend can't reach the backend.
5744
- **stdlib URL params:** use `r.PathValue("project")` (Go 1.22+). Route patterns
5845
use `{project}` syntax:
5946
`mux.HandleFunc("GET /api/projects/{project}", handler)`.
6047
- **`time.Duration` in YAML:** `time.Duration` doesn't unmarshal from strings
6148
like `"30m"` with `gopkg.in/yaml.v3`. Either use a custom type with
6249
`UnmarshalYAML`, or store as string in config and parse with
6350
`time.ParseDuration()` at load time.
64-
- **MCP Streamable HTTP transport:** `POST /mcp` handles all MCP traffic.
65-
Responses are either plain JSON (for non-streaming operations) or
66-
`text/event-stream` (for streaming tool results). Registered on the same
67-
`http.ServeMux` as the REST API — no separate server or port needed.
68-
- **MCP auth:** support an optional bearer token (`mcp.auth_token` in
69-
`config.yaml`). When set, the `/mcp` endpoint requires
70-
`Authorization: Bearer <token>`. Essential for container deployments exposed
71-
beyond localhost.
72-
- **MCP prompts + card context:** most prompt handlers return delegation
73-
wrappers (not raw skill content); interview skills (`create-task`,
74-
`init-project`) return raw content for inline execution. The `get_skill` tool
75-
fetches card context at execution time, calling the service layer in-process.
76-
The MCP handler and HTTP API share the same `CardService` instance. The
77-
`## Agent Configuration` section is stripped from all skill content delivered
78-
via `get_skill` and prompt handlers — the required model is returned as a
79-
separate `model` field.
80-
- **Sub-agent death during idle user-approval wait:** Claude Code can kill a
81-
sub-agent between turns if the conversation goes quiet (e.g., while waiting
82-
for the user to read and approve a plan). The fix is to never have a sub-agent
83-
wait for user input — instead, the sub-agent should write its output to the
84-
card body and return immediately, and let the always-alive main agent (CC)
85-
handle the user interaction. All skills that previously had this problem have
86-
been fixed:
87-
- `create-plan`: Phase 1 drafts and writes the plan then returns
88-
`PLAN_DRAFTED`; CC presents the plan to the user and collects approval;
89-
Phase 2 creates subtasks from the already-approved plan.
90-
- `review-task`: The review sub-agent writes `## Review Findings` to the card
91-
body and returns `REVIEW_FINDINGS` immediately; CC presents findings to the
92-
user and collects the approve/reject decision directly.
93-
- `document-task`: The doc sub-agent writes files to disk and returns
94-
`DOCS_WRITTEN` immediately — no user approval gate before writing, since
95-
docs are built from already-reviewed code; CC presents the summary after.
96-
- `create-task` and `init-project`: These interview skills now run inline in
97-
CC (no sub-agent at all) — see the "Interview skills run inline" entry
98-
below. Any new skill that must get user approval before continuing should
99-
follow the same split-phase pattern: sub-agent writes output to card body
100-
and returns a structured result immediately; CC handles the user
101-
interaction.
102-
- **Interview skills (create-task, init-project) run inline:** These skills
103-
require multi-turn back-and-forth conversations with the user (gathering
104-
requirements, confirming config). Delegating them to a sub-agent breaks this
105-
because the `Agent` tool does not support relaying multiple user turns back
106-
into the sub-agent. Their prompt handlers return the raw skill content (with
107-
`## Agent Configuration` stripped) rather than a delegation wrapper, so the
108-
main agent executes them directly in its own context. **Never delegate
109-
`create-task` or `init-project` to a sub-agent.**
110-
- **Execute-task agents never spawn review:** The `execute-task` skill
111-
explicitly instructs agents to ignore any `next_step` field returned by
112-
`complete_task` (e.g., when the parent card transitions to `review`). The
113-
lifecycle continuation (spawning review sub-agents) was removed from
114-
execute-task agents because it caused nested agent chains with unpredictable
115-
lifetimes. The orchestrator (main CC) is solely responsible for detecting that
116-
the parent entered `review` and spawning the review sub-agent.
11751
- **`/healthz` requests are not logged:** the HTTP logging middleware skips
11852
`slog.Info` for `GET /healthz` to prevent k8s liveness/readiness probe traffic
11953
from spamming logs. The endpoint still responds normally — only the log line
12054
is suppressed. If you expect to see probe traffic in logs for debugging, hit
12155
any other path or check the endpoint directly with `curl`.
122-
- **Health-check polling interval:** the monitoring loop in `create-plan.md`
123-
polls every 1 minute (not 2-3 min). Shorter intervals mean stalled agents are
124-
detected and respawned faster, reducing idle time for the user.
125-
- **Agents must never use curl:** `CLAUDE.md` mentions `curl` for "Manual
126-
verification for API tasks" — that applies to human developers checking API
127-
handler code, NOT to agents interacting with the board. Agents must use MCP
128-
tools exclusively (`claim_card`, `heartbeat`, `update_card`, `complete_task`,
129-
etc.). Using curl bypasses claim tracking, heartbeats, and the event bus,
130-
leaving cards orphaned. This rule is enforced in the `workflowPreamble`
131-
prepended to every skill prompt.

0 commit comments

Comments
 (0)