Skip to content

tasks.md

Latest commit

 

History

History
81 lines (67 loc) · 3.16 KB

tasks.md

File metadata and controls

81 lines (67 loc) · 3.16 KB
Raw

Tasks — MCP server for attune-gui

Phase 1 — Scaffold

  • 1.1 Add mcp>=0.9.0 to [project.optional-dependencies].mcp in pyproject.toml (mirror attune-help / attune-author pattern)
  • 1.2 Create sidecar/attune_gui/mcp/__init__.py and sidecar/attune_gui/mcp/server.py
  • 1.3 Add attune-gui-mcp = "attune_gui.mcp.server:main" to [project.scripts]
  • 1.4 Start server on stdio per the MCP server pattern used by sibling packages

Phase 2 — Implement core tools

For each:

  • 2.1 gui_list_specs — wrap existing routes/cowork_specs.py GET handler
  • 2.2 gui_get_spec — wrap existing per-spec read (returns content of all present phase files)
  • 2.3 gui_get_spec_status — extract **Status**: line from a phase file. Inherits a pre-existing regex bug in _STATUS_VALUE_RE that misses the common **Status:** format; tracked separately.
  • 2.4 gui_list_living_docs — wrap existing living-docs listing route
  • 2.5 gui_get_living_doc — wrap existing living-doc content read (with path-traversal guard)

Each tool:

  • Has a clear schema (input + output)
  • Has a docstring that Claude can read to decide when to invoke
  • Handles path validation (consistent with existing route protection)

Phase 3 — Optional write tool

  • 3.1 gui_set_spec_status — wrap the existing PUT route. Same validation (slug regex, phase enum, _VALID_STATUSES). Atomic write via attune_gui._fs.atomic_write. Inserts a **Status**: line if missing, otherwise substitutes via _STATUS_RE. The only write tool — additive to the five read-mostly tools.

Phase 4 — Integration test

  • 4.1 In-process parity test: gui_list_specs via AttuneGuiMCPServer.call_tool returns the same specs and specs_roots lists as GET /api/cowork/specs on the same isolated specs root. (Stdio-subprocess spawn was reinterpreted as in-process dispatch — the surface-parity guarantee is the same and the test is lighter; tracked in sidecar/tests/test_mcp_integration.py.)
  • 4.2 gui_get_spec returns disk-truth content for every phase file, and the FastAPI listing references the same most-advanced phase + status. Plus a bonus round-trip through gui_set_spec_status (Phase 3) that flips status via MCP and asserts the FastAPI listing reflects the change.

Phase 5 — Docs

  • 5.1 README section: "MCP integration" — how to configure Claude Code to use the server
  • 5.2 Example .mcp.json snippet showing attune-gui-mcp registered
  • 5.3 Cross-link with attune-ai's ops-specs-features spec (the two complement each other)

Out of scope

  • Authentication / API tokens — local stdio MCP doesn't need it
  • Streaming responses — start with one-shot tool calls only
  • Multi-root federation in MCP — Phase 1 lists local specs; cross-root listing can be a follow-up
  • Editing template content via MCP — covered by GUI editor
  • Replacing the FastAPI surface — MCP is additive, not a replacement