lang

Documentation

Overview

Package lang defines the conventional language toolbox: the stable set of tool names every language plugin (python, go, rust, ...) exposes through the unified Toolbox contract.

Why this package exists: the Tooling proto service has typed RPCs that every language agent implements (Test, Lint, dependency management, project metadata, edits, etc.). Going forward, every callable codefly surface speaks the Toolbox contract. To preserve Mind's typed ergonomics WITHOUT keeping two parallel proto contracts, this package provides:

• Stable convention names (ToolTest = "lang.test", etc.)
• A bridge in both directions: NewToolboxFromTooling — wrap an existing Tooling impl as a Toolbox. Lets language agents migrate by adding one line to PluginRegistration; the Tooling impl stays unchanged. ToolingFromToolbox — wrap a Toolbox client as a typed ToolingClient. Lets Mind keep its existing call sites.

Both bridges round-trip via protojson + structpb, so the typed proto messages travel intact. The wire is unified (Toolbox); the Go API surfaces remain typed at the boundaries that need them.

Migration shape:

• Phase B (this work): Tooling impls stay; agents register both Tooling and a NewToolboxFromTooling-wrapped Toolbox. Mind can opt into the Toolbox surface (via ToolingFromToolbox) per consumer site.
• Phase α (follow-up): Language agents move directly to a Toolbox impl using these tool names; the Tooling proto + generated code are deleted. NewToolboxFromTooling becomes obsolete; the typed ToolingFromToolbox wrapper survives as Mind's stable interface.

Index

• Constants
• func ToolNames() []string
• func ToolingFromToolbox(c toolboxv0.ToolboxClient) toolingv0.ToolingClient
• type ToolboxFromTooling
  • func NewEditToolboxFromTooling(name, version string, t toolingv0.ToolingServer) *ToolboxFromTooling
  • func NewSourceToolboxFromTooling(name, version string, t toolingv0.ToolingServer) *ToolboxFromTooling
  • func NewToolboxFromTooling(name, version string, t toolingv0.ToolingServer) *ToolboxFromTooling
  • func NewValidationToolboxFromTooling(name, version string, t toolingv0.ToolingServer) *ToolboxFromTooling
  • func (b *ToolboxFromTooling) CallTool(ctx context.Context, req *toolboxv0.CallToolRequest) (*toolboxv0.CallToolResponse, error)
  • func (b *ToolboxFromTooling) Tools() []*registry.ToolDefinition

Constants

const (
	// Modification
	ToolFix       = "lang.fix"
	ToolApplyEdit = "lang.apply_edit"

	// Dependencies
	ToolListDependencies = "lang.list_dependencies"
	ToolAddDependency    = "lang.add_dependency"
	ToolRemoveDependency = "lang.remove_dependency"

	// Project metadata
	ToolGetProjectInfo = "lang.get_project_info"

	// Dev validation (delegates to Runtime)
	ToolBuild = "lang.build"
	ToolTest  = "lang.test"
	ToolLint  = "lang.lint"
)

Conventional tool names every language plugin exposes through the Toolbox contract. The naming rule is `lang.<verb>` in snake_case — `lang` because the convention applies to ANY language plugin (python, go, rust, …), and snake_case to match the Toolbox convention used by other tool sets (`git.status`, `docker.list_containers`).

These constants are the stable names used by the bidirectional bridge (NewToolboxFromTooling, ToolingFromToolbox). The exported catalog is derived from the bridge spec table, so callers should use ToolNames() when they need the complete set.

Functions

func ToolNames

func ToolNames() []string

ToolNames returns the conventional lang.* names derived from the same specs used to register toolbox definitions.

func ToolingFromToolbox

func ToolingFromToolbox(c toolboxv0.ToolboxClient) toolingv0.ToolingClient

ToolingFromToolbox wraps a Toolbox client and presents the typed ToolingClient interface. Mind's existing call sites continue working: client.Test(ctx, req) routes to CallTool("lang.test", req) under the hood.

Returns toolingv0.ToolingClient so Mind can drop this in as a type-compatible replacement for a real ToolingClient over the Tooling RPC. When Phase α deletes the Tooling proto, this wrapper stays — Mind keeps its typed interface; the underlying contract just stops being a separate proto.

Types

type ToolboxFromTooling

type ToolboxFromTooling struct {
	*registry.Base
	// contains filtered or unexported fields
}

ToolboxFromTooling implements toolboxv0.ToolboxServer over a Tooling impl. Exported so callers can compose it into a PluginRegistration directly.

Embeds *registry.Base for ListTools/ListToolSummaries/DescribeTool; CallTool is overridden because the bridge dispatches per-name to typed Tooling RPCs (different shape than the Handler-per-tool pattern the capability toolboxes use). The Tools() definitions here therefore omit Handler — Base.CallTool would be shadowed anyway.

func NewEditToolboxFromTooling

func NewEditToolboxFromTooling(name, version string, t toolingv0.ToolingServer) *ToolboxFromTooling

NewEditToolboxFromTooling is the language-neutral subset for a plugin that supports structured editing and metadata but has no language-aware fixer.

func NewSourceToolboxFromTooling

func NewSourceToolboxFromTooling(name, version string, t toolingv0.ToolingServer) *ToolboxFromTooling

NewSourceToolboxFromTooling exposes only the source-authoring operations implemented by code.SourceTooling. This keeps ListTools honest for small language plugins that format and edit source but do not own dependency or validation behavior yet.

func NewToolboxFromTooling

func NewToolboxFromTooling(name, version string, t toolingv0.ToolingServer) *ToolboxFromTooling

NewToolboxFromTooling adapts an existing Tooling server into a Toolbox server. The result implements toolboxv0.ToolboxServer; its Identity / ListTools / CallTool route to the underlying Tooling RPCs via the conventional names in names.go.

Used by language agents that have a working Tooling impl and want to expose the unified contract WITHOUT rewriting their server. One line change in main.go:

agents.Serve(agents.PluginRegistration{
    ...,
    Tooling: tooling,                   // unchanged
    Toolbox: lang.NewToolboxFromTooling("python", "0.0.1", tooling),  // new
})

Mind sees the same typed responses whether it calls Tooling directly or goes through the Toolbox via ToolingFromToolbox — the bridge round-trips the typed proto messages intact.

func NewValidationToolboxFromTooling

func NewValidationToolboxFromTooling(name, version string, t toolingv0.ToolingServer) *ToolboxFromTooling

NewValidationToolboxFromTooling exposes source authoring plus build, test, and lint for language plugins that do not implement dependency mutation.

func (*ToolboxFromTooling) CallTool

func (b *ToolboxFromTooling) CallTool(ctx context.Context, req *toolboxv0.CallToolRequest) (*toolboxv0.CallToolResponse, error)

CallTool dispatches by conventional name. The argument Struct is converted to the typed proto request via protojson; the response is converted back to a Struct and wrapped in a Content block.

func (*ToolboxFromTooling) Tools

func (b *ToolboxFromTooling) Tools() []*registry.ToolDefinition

Tools projects the conventional lang.* surface into the registry's ToolDefinition shape — same source-of-truth pattern the capability toolboxes use. Bridge-specific note: the inner Tooling proto's typed RPCs have stable schemas, but here we surface them generically (anyObjectSchema) since the typed shape is enforced by the Mind-side wrapper at protojson encode time.

Handler is left nil — CallTool is overridden below to dispatch per-name into the inner Tooling server's typed RPCs.