feat: Epicode memory-augmented workflow template + MCP integration guide

[sunormesky-max]

What this PR adds

The first Clutch workflow template with persistent agent memory, powered by Epicode — a spatial AI memory operating system with 35 MCP tools.

File	Purpose
workflows/epicode-memory-pipeline.json	5-node pipeline (Research→Build→Verify→Human Gate→Review) where each agent recalls context before working and stores findings after
docs/mcp-servers/epicode.md	2-minute integration guide (account → MCP config → agent binding → L2 shared memory explained)
README.md	New "MCP Server" section linking to the guide

The problem this solves

Clutch agents start blank every session. When a workflow runs Research → Build → Review, each agent has no memory of:

• What was decided in previous runs of this workflow
• What the upstream agent in this run discovered
• Project conventions, past mistakes, architectural decisions

This PR adds memory to Clutch agents via the existing MCP client extension point (no core changes, per EXTENSIBILITY.md §4.2).

Two levels of memory

L1 — Single-agent memory (works immediately):
An agent with Epicode MCP bound will memory_recall prior context before working and memory_create to store results. Next session, it remembers.

L2 — Workflow-level shared memory (requires agent config):
When all agents in a workflow bind the same Epicode account, they share one user space:

Researcher ──memory_create("finding X")──▶ ┌──────────┐
                                           │ Epicode  │ (shared)
Builder ◀──memory_recall("finding X")──── │  Cloud   │
       └──memory_create("decided Z")──▶   └──────────┘
Reviewer ◀──memory_recall("decided Z")───╯

No manual context passing between nodes. The workflow template's instructions tell each agent when to recall/store.

How to try it

1. Sign up at epicode.cn (free, 1000 memories)
2. Settings → MCP: add server — Name: epicode, URL: https://epicode.cn/api/mcp, Header: X-API-Key: tm-your-key
3. Settings → Agents: bind epicode to your Researcher, Builder, Reviewer agents
4. Select the Memory-Augmented Pipeline workflow and run a task
5. Run the same workflow a week later — agents recall last week's work

Design decisions

• No core changes: uses only the MCP client extension point. Respects the boundary in EXTENSIBILITY.md §3 (internal implementations).
• Template is self-documenting: each agent_task.instruction explicitly tells the agent when to call memory_recall / memory_create, so the memory behavior is visible in the workflow canvas — no hidden magic.
• L1 vs L2 is honest: the template JSON demonstrates L1 by default. L2 requires users to bind the same MCP server to all agents (documented in the guide, not hardcoded — because mcpServerIds lives in agent config, not workflow JSON).
• Self-hostable: Epicode is MIT-licensed. Users who want full data locality can self-host and point to localhost:9111.

Happy to adjust based on your conventions. I also welcome feedback on whether the docs/mcp-servers/ directory pattern is the right place for this kind of guide.

[fancy1108]

Thanks for the contribution — triaged this against our Phase 1 policy (CONTRIBUTING.md) and extension boundaries (EXTENSIBILITY.md).

What this PR is

Pure extension-layer content (no orchestrator / desktop core changes):

File	Role
workflows/epicode-memory-pipeline.json	Built-in workflow template — 5-node Research→Build→Verify→Human Gate→Review, instructions tell agents to use Epicode MCP memory_recall / memory_create
docs/mcp-servers/epicode.md	Third-party MCP integration guide (SaaS epicode.cn or self-host)
README.md	Links the new doc under a new docs/mcp-servers/ section

This matches EXTENSIBILITY §4.2 (user-configured MCP client) and §4.1 (workflow JSON templates). It does not change LangGraph, Engine Router, or WS state.

Fit / concerns (maintainer view)

Pros

• Small, focused diff (~188 LOC)
• Demonstrates cross-session / cross-agent memory via MCP — a real gap users ask about (see Issue #20)
• Self-host path documented; core stays local-first

Before merge we'd want

1. Workflow validate — run against workflows/workflow.schema.json / POST /api/workflows/validate (verify node uses $CLUTCH_TASK_OUTPUT, which may not exist in runtime)
2. Agent names — template references Researcher / Builder / Reviewer; onboarding auto-provisions differ — doc should say users must create/bind these agents + Epicode MCP, or align with default agent IDs
3. Repo docs hygiene — if merged: index in docs/README.md, and user-visible template list in docs/PRODUCT_INTRO.md + CHANGELOG.md (project release gate)
4. Third-party disclaimer — README section should note Epicode is community/vendor integration, not a Clutch official service; SaaS stores data on epicode.cn (see your privacy section — users opt in via MCP config)
5. CI — please confirm green on main base (checks did not run on the PR yet)

Status

Not merging immediately — direction looks reasonable for Phase 1 (docs + template), but needs the items above. Happy to re-review after updates.

If you prefer to keep this outside the main repo, publishing the JSON + guide in the Epicode repo and linking from a Discussion also works — we can add a single neutral pointer under docs/EXTENSIBILITY.md instead of vendoring vendor docs.

Thanks again for using Clutch's MCP extension point thoughtfully.

[sunormesky-max]

Thanks for the thorough review — all five items addressed in adf32db:

1. Workflow validate — Removed the check node entirely (it referenced `` which doesn't exist in runtime). Pipeline is now Research→Build→Human Gate→Review, 4 working nodes + start/end. No shell checks — the human gate serves as the verification step.

2. Agent names — All agent_task nodes now use the default "clutch-agent" instead of Researcher/Builder/Reviewer. The doc's Step 4 explains: single default agent shares memory across steps out of the box; users who want separate system prompts per role can create agents in Settings and replace the agent names in the JSON.

3. Repo docs hygiene — Ready to index in docs/README.md / PRODUCT_INTRO.md / CHANGELOG.md on your side at merge time (happy to add if you prefer the PR to include them).

4. Third-party disclaimer — Added to both the README MCP section ("社区/第三方集成指南，非 Clutch 官方服务") and the doc header ("Community/Vendor integration — Epicode is a third-party project"). Privacy section already covers epicode.cn data storage + self-host alternative.

5. CI — This PR is docs + JSON only (no Rust/Python/TS changes), so the verify/test CI shouldn't be affected. Let me know if you'd like me to run any specific validation.

Regarding your alternative suggestion (publish in Epicode repo + link from Discussion) — I'm happy either way. If vendoring vendor docs in the main repo feels heavy, a neutral pointer in docs/EXTENSIBILITY.md + a Discussion thread works too. Your call on what fits Clutch's governance best.

[fancy1108]

Merged to dev in 095f8d4 — thanks @sunormesky-max! Content: workflows/epicode-memory-pipeline.json, docs/mcp-servers/epicode.md, README/docs index updates. (PR targeted main and had conflicts; we land extension-layer contributions on dev per CONTRIBUTING.md.)