lang

package
v0.1.158 Latest Latest
Warning

This package is not in the latest version of its module.

 Go to latest Published: May 2, 2026 License: MIT Imports: 9 Imported by: 0

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 17 typed RPCs that every language agent implements (ListSymbols, Test, Lint, FindReferences, 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 (Tool[ListSymbols] = "lang.list_symbols", 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

View Source 
const (
	// LSP / analysis
	ToolListSymbols    = "lang.list_symbols"
	ToolGetDiagnostics = "lang.get_diagnostics"
	ToolGoToDefinition = "lang.go_to_definition"
	ToolFindReferences = "lang.find_references"
	ToolRenameSymbol   = "lang.rename_symbol"
	ToolGetHoverInfo   = "lang.get_hover_info"
	ToolGetCompletions = "lang.get_completions"

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

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

	// Project-level analysis
	ToolGetProjectInfo = "lang.get_project_info"
	ToolGetCallGraph   = "lang.get_call_graph"

	// 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 source of truth. The bidirectional bridge (NewToolboxFromTooling, ToolingFromToolbox) reads them; renaming one here automatically renames it on both sides.

Variables

View Source 
var AllTools = []string{
	ToolListSymbols, ToolGetDiagnostics, ToolGoToDefinition,
	ToolFindReferences, ToolRenameSymbol, ToolGetHoverInfo,
	ToolGetCompletions, ToolFix, ToolApplyEdit,
	ToolListDependencies, ToolAddDependency, ToolRemoveDependency,
	ToolGetProjectInfo, ToolGetCallGraph,
	ToolBuild, ToolTest, ToolLint,
}

AllTools is the full conventional tool list every language plugin must expose. Test fixtures use it to assert no tool was dropped on the bridge.

Functions

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.ListSymbols(ctx, req) routes to CallTool("lang.list_symbols", 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 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 (*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) Identity 

func (b *ToolboxFromTooling) Identity(_ context.Context, _ *toolboxv0.IdentityRequest) (*toolboxv0.IdentityResponse, error)

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.

Source Files

View all Source files

Directories

Path Synopsis
cmd
fake-lang-toolbox command
Command fake-lang-toolbox is a TEST-ONLY language plugin used by the round-trip integration test in core/toolbox/lang.
 Command fake-lang-toolbox is a TEST-ONLY language plugin used by the round-trip integration test in core/toolbox/lang.

Jump to

Keyboard shortcuts

? : This menu
/ : Search site
f or F : Jump to
y or Y : Canonical URL
go.dev uses cookies from Google to deliver and enhance the quality of its services and to analyze traffic. Learn more.