You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Problem — The fork registers a widget-authoring tool natively in its tool
registry; the harness-neutral MCP tool floor does not carry an equivalent.
Every non-fork harness therefore lacks the widget-authoring affordance, and
the fork's registry change is one of only two load-bearing deltas blocking
its retirement.
Approach — Port the tool into the MCP floor as a harness-neutral tool
with the same name, schema, and semantics the fork exposes; the server-side
helper and the UI sentinel seam are already ported — only the tool shell is
missing.
Scope — in: the MCP tool (schema, execution path calling the existing
server helper, tests) · out: the fork's registry change itself (retires with
the fork), any UI changes.
Assumptions — The fork's tool definition (its registration and its
prompt file) is the reference; the MCP floor's existing 17-tool pattern is
the vehicle.
Acceptance Criteria
The tool appears in the MCP floor's tool list with the fork-equivalent name and schema.
A tool call drives the existing server-side widget helper end-to-end (the widget appears in the dashboard inventory).
The MCP floor's parity test covers the tool (count and bijective-name assertions updated).
The tool's prompt/description text is carried from the fork (its prompt file), not rewritten.
Testing Decisions
Extend the MCP floor's existing test suites (the core tests + the parity
test); no new suites.
Key Decisions
Bare-name convention per the floor's existing rule (the host namespaces the product view).
The tool executes against the extension-host service's widget endpoints, not the harness server.
Constraints & Invariants
Worktree off fresh origin/main; the shared checkout's branch is never moved.
The floor stays harness-neutral: no fork-specific imports.
Prior Art
The fork's tool registration + prompt file (read via the remote branch origin/local/amicode).
The MCP floor's core tools module and its parity test.
The extension service's widget server helper (already ported).
Source
Part of the re-base leg — campaign ledger sessions/session-20260827-harness-agnostic.md, loop 28b.
Important
Problem — The fork registers a widget-authoring tool natively in its tool
registry; the harness-neutral MCP tool floor does not carry an equivalent.
Every non-fork harness therefore lacks the widget-authoring affordance, and
the fork's registry change is one of only two load-bearing deltas blocking
its retirement.
Approach — Port the tool into the MCP floor as a harness-neutral tool
with the same name, schema, and semantics the fork exposes; the server-side
helper and the UI sentinel seam are already ported — only the tool shell is
missing.
Scope — in: the MCP tool (schema, execution path calling the existing
server helper, tests) · out: the fork's registry change itself (retires with
the fork), any UI changes.
Assumptions — The fork's tool definition (its registration and its
prompt file) is the reference; the MCP floor's existing 17-tool pattern is
the vehicle.
Acceptance Criteria
Testing Decisions
Extend the MCP floor's existing test suites (the core tests + the parity
test); no new suites.
Key Decisions
Constraints & Invariants
Prior Art
Source
Part of the re-base leg — campaign ledger
sessions/session-20260827-harness-agnostic.md, loop 28b.