Skip to content

Plan of Record (Ordered Execution)

Status: Superseded
Canonical Roadmap: ai-tools-stack/docs/roadmap.md

This page consolidates all proposals and PRDs into a single, ordered execution sequence. It is intentionally Go‑architecture focused: concurrency safety, context propagation, and production operational boundaries are explicit in each phase.

Principles (Go Architect Evaluation)

  • Context propagation is a contract: every long‑running or remote execution path must honor context.Context for cancellation and timeouts.
  • Concurrency safety by default: all registries and caches must be thread‑safe under concurrent reads/writes.
  • Errors are data: tool errors should be structured and preserved end‑to‑end rather than surfaced as raw panics.
  • Stable seams first: prioritize interfaces, wiring, and deterministic behaviors before adding new feature surface.

Current Baseline (already in place)

These libraries and contracts are the foundation and must remain stable:

  • toolfoundation – core types + adapters + versioning
  • tooldiscovery – registry, docs, search strategies
  • toolexec – execution, orchestration, runtime isolation
  • toolcompose – toolsets + skills
  • toolops – observability, cache, auth, resilience, health
  • toolprotocol – transport, wire, content, session, task primitives

See the canonical stack roadmap for current status and version matrix: ai-tools-stack/docs/roadmap.md

Phase 0 — Spec Alignment & Server Correctness (P1)

Goal: Ensure the MCP server edge is protocol‑correct before expanding capability.

  1. MCP spec alignment
  2. notifications/tools/list_changed
  3. pagination/cursor consistency
  4. cancellation propagation
  5. optional progress forwarding

Docs: - Proposal: MCP Spec Alignment - PRD: PRD‑180

Phase 1 — Core Exposure (MVP Foundation)

Goal: Provide CLI, configuration, transport, and provider/backends for production use.

  1. Repo scaffolding + CLI surface
  2. Configuration layer
  3. Transport layer
  4. Tool provider registry
  5. Backend registry
  6. Middleware chain

Docs: - PRDs: PRD‑110, PRD‑111, PRD‑112, PRD‑113

Phase 2 — Protocol Layer

Goal: Normalize tools into composable, protocol‑agnostic sets without changing core semantics.

  1. tooladapter → now toolfoundation/adapter
  2. toolset → now toolcompose/set

Docs: - PRD‑121 - PRD‑150

Phase 3 — Cross‑Cutting Observability & Caching

Goal: Make the system operationally measurable and resilient.

  1. toolobserve → now toolops/observe
  2. toolcache → now toolops/cache

Docs: - PRD‑160 - PRD‑161

Phase 4 — Enterprise Extensions

Goal: Enable scale, isolation, and advanced discovery without destabilizing core APIs.

  1. Multi‑tenancy core
  2. toolsemantic → now tooldiscovery/semantic

Docs: - Proposal: Multi‑Tenancy - PRD‑132

Phase 5 — Agent Skills

Goal: Higher‑level capability composition for reusable workflows.

  1. toolskill → now toolcompose/skill

Docs: - PRD‑151

Phase 6 — Runtime Expansion

Goal: Expand sandbox options and isolation strategies.

  1. toolruntime Docker backend → now toolexec/runtime

Docs: - PRD‑141

Go Architecture Review (Summary)

  • Context propagation: enforce in all public execution APIs; cancellation must be honored by toolexec/run and toolexec/runtime to avoid leaked goroutines.
  • Concurrency safety: all registries must be RW‑safe; avoid maps without guards under write paths.
  • Pagination correctness: use stable cursors and cap limits across list endpoints.
  • Error semantics: preserve tool errors as structured data; avoid panics in runtime paths.
  • Observability: add tracing hooks before multi‑tenant and semantic layers to avoid blind spots.

Reference Docs