Files
pad/cmd
xarmian de8679f535 chore(mcp): bump ToolSurfaceVersion 0.3 → 0.4; document v0.4 envelope (TASK-1418) (#544)
* chore(mcp): bump ToolSurfaceVersion 0.3 → 0.4; document v0.4 envelope (TASK-1418)

Final PR of PLAN-1410. The contractual announcement that the v0.4
bootstrap shape is stable.

## What

1. internal/mcp/version.go — ToolSurfaceVersion: "0.3" → "0.4".

   The godoc on the constant gains a full v0.4 changelog entry
   enumerating each shape change shipped by PLAN-1410's six
   bootstrap PRs:

     - BootstrapCollection projection (TASK-1412): drops id,
       workspace_id, created_at, updated_at, settings; schema as
       a nested JSON object.
     - BootstrapRole projection (TASK-1423): drops id,
       workspace_id, tools, created_at, updated_at.
     - Convention slug dropped (TASK-1413).
     - Top-level recent_activity duplicate removed (TASK-1413).
     - BootstrapDashboard wrapper caps five sub-arrays (TASK-1413
       + TASK-1422): attention, recent_activity, active_items,
       active_plans, by_role at 5 entries each, parallel
       *_overflow_count fields. suggested_next deliberately
       excluded — already capped to 3 upstream.
     - Schema label omitted when label == TitleCase(key) (TASK-1424).

   Plus an explicit compatibility note: all v0.4 changes are
   additive or subtractive (no field renames); clients that read
   the preserved field names keep working unchanged.

2. CLAUDE.md updates:

   - "## MCP server" header: v0.3 catalog → v0.4 catalog, with a
     one-paragraph summary of what v0.4 shipped.
   - "Surface:" Tools bullet: v0.3 → v0.4, with a note that the
     tool/action surface is unchanged — only the bootstrap JSON
     these tools return has been trimmed.
   - "Stability contract": ToolSurfaceVersion (currently "0.4"),
     comprehensive single-paragraph description of the v0.4
     envelope, cumulative size reduction (40% live / 54% fixture),
     and explicit additive/subtractive note.

## Why the strategy worked

PLAN-1410's "version bump last" strategy paid off:

- Each individual shape PR (TASK-1412/1413/1422/1423/1424) was
  reviewable in isolation against a stable v0.3 contract.
- The six skill-side PRs (TASK-1414/1415/1416) had no MCP-shape
  impact and didn't need any version bump consideration.
- v0.4 is now announced as a single comprehensive contract change,
  not five separate version bumps — easier for downstream MCP
  consumers (Claude Desktop, Cursor, future Pad Cloud remote MCP)
  to reason about.

## Verification

  - `make check` — golangci-lint 0 issues, all Go tests pass
    (including the version-tracking tests in catalog_meta_test.go
    that auto-pin to whatever ToolSurfaceVersion is set to),
    govulncheck clean, web build clean.
  - MCP handshake (verified via `pad mcp serve` + an initialize
    JSON-RPC request) advertises
    capabilities.experimental.padToolSurface.version = "0.4".
    padCmdhelp.version stays at "0.1" as expected.

## Post-merge follow-ups

After this lands:

  - Update PLAN-1410's Result section with a "v0.4 announced" line
    and the final post-everything measurement (taken against
    docapp after `make install`).
  - Flip PLAN-1410 status from `active` → `completed`.

These are pad-item operations, not git changes.

Parent: PLAN-1410. Closes the plan.

* fix(mcp): update stale v0.3 references after ToolSurfaceVersion bump (TASK-1418 follow-up)

Address Codex P2 + P3 findings on PR #544: bumping
ToolSurfaceVersion in version.go left four runtime/user-facing
docs still claiming v0.3:

  P2 — runtime MCP docs:
    - internal/mcp/instructions.md   "## Tool surface (v0.3)" → v0.4
    - internal/mcp/catalog_meta.go   "v0.3 server-introspection tool" → "(v0.4 catalog)"
    - internal/mcp/catalog_meta.go   padMetaToolDescription twice:
      * "the v0.3 tool catalog" → "the v0.4 tool catalog"
      * "v0.3 catalog dump" → "v0.4 catalog dump"
    - internal/mcp/catalog_meta.go   actionMetaToolSurface godoc:
      "v0.3 catalog" → "catalog" (de-versioned; the comment is
      about scope, not version)

  P3 — public README:
    - README.md  "Tool catalog (v0.3)" → "Tool catalog (v0.4)"
    - README.md  "tool_surface_version: '0.3'" → "'0.4'" with a
      pointer to PLAN-1410's bootstrap-trim summary and
      version.go's full v0.4 changelog.

Without these, agents reading the initialize-instructions blob or
pad_meta's tool description (both of which are part of the
runtime MCP surface, not just internal docs) would see v0.3 while
the handshake / pad_meta.action: version returned v0.4 — the
exact "contradictory metadata depending on what you read" failure
mode Codex flagged.

Same skill-↔-code sync pattern that has been a running theme
through PLAN-1410's review loops. The cluster of stale references
is a classic side effect of a version bump landing late in a
plan — the version constant is one string, but downstream prose
that names it lives in multiple places.

Verified no remaining "v0.3" claims that imply currency — `grep -rn
"v0\.3\|tool_surface_version" --include="*.{go,md}"` returns only
historical-context mentions in changelog godocs (correct) and the
runtime constant readback (correctly returns "0.4" now).

Parent: PLAN-1410 / TASK-1418.

* fix(mcp): correct schema-type-change disclosure + stale cmdhelp-walker description (TASK-1418 follow-up)

Address Codex round 2 P3 findings on PR #544:

## P3 — `cmd/pad/mcp.go` still described the retired leaf walker

The `pad mcp serve` command's Long description said "every leaf
command becomes an MCP tool, except the curated allow-list
exclusions" — that was true under v0.1 but the cmdhelp leaf
walker was retired in TASK-981 (PLAN-969's v0.2 rollout). The
v0.2/v0.3/v0.4 surface has always been the hand-curated catalog
of eight resource × action tools + pad_set_workspace.

Updated the Long description to:

  - Name the v0.4 catalog explicitly.
  - List the eight resource × action tools.
  - Note that cmdhelp v0.1 still drives per-command arg schemas
    at dispatch time (so it's not gone, just no longer drives
    tool naming/count).
  - Reference TASK-981 for the cutover.

## P3 — "additive/subtractive only" was misleading

The compatibility note in `version.go` and `CLAUDE.md` claimed
all v0.4 changes were additive or subtractive. That glossed over
one breaking change in TASK-1412: `collections[].schema` went
from a JSON-encoded string ("schema":"{\"fields\":...}") to a
nested JSON object ("schema":{"fields":...}). For any v0.3
consumer that read schema as a string and JSON.parse()'d it
themselves, that's a TYPE change, not a no-op.

Updated both godoc and CLAUDE.md to explicitly call this out
as the one breaking change, separately from the additive/
subtractive bucket. Better for downstream MCP consumers to see
the truth than to discover it via runtime failure.

The remaining v0.4 changes ARE additive (overflow counts on
BootstrapDashboard) or subtractive (dropped fields with named
canonical alternatives) — those parts of the original note
are accurate and kept.

Honesty about compatibility is more valuable than a tidy
narrative. Surfaced explicitly in the godoc + the public
contract doc; PLAN-1410's Result section was already honest
about the field-level deltas.

Parent: PLAN-1410 / TASK-1418.
2026-05-13 18:02:34 -04:00
..