Migration: adapters are registered by the tool's main¶

Until this change, pkg/chat/providers.go blank-imported the three chat provider modules and pkg/setup/providers.go the four forge adapters, so every tool built on the framework linked all seven whether it used them or not. A bare root command weighed 81 MB statically linked; without them it weighs 34 MB (spec 0194).

Both files now register nothing. The framework still registers forge/direct, the plain download source that ships inside the forge module.

What to do¶

Add a file to the tool's main package that blank-imports the modules it uses. For a tool that talks to Claude and releases on GitHub:

package main

import (
    _ "gitlab.com/phpboyscout/go/chat-anthropic" // claude, claude-local
    _ "gitlab.com/phpboyscout/go/forge-github"
)

Then go get each module and go mod tidy. The modules are no longer indirect requirements of the framework, so the versions are the tool's own to choose.

Which module registers which name:

chat.ProviderModule and forge.ModuleFor return the same tables at runtime, and the error hints quote them.

A tool generated by gtb is not affected: gtb generate project and gtb regenerate project emit these imports from the manifest into cmd/<name>/chat.go and cmd/<name>/forge.go (spec 0194 D4 to D7; see the generate reference). A project generated before this change keeps working, because the framework version it pins still carries the imports; regenerating it under the new gtb writes the two files, and records every provider the framework could configure in the manifest's chat: block so the project states its own choice from then on.

The gtb CLI moved to cli/¶

gitlab.com/phpboyscout/go-tool-base/cli is a nested module carrying the binary, the generator and the e2e suite. Two consequences for anyone building from source:

• go install gitlab.com/phpboyscout/go-tool-base/cli/cmd/gtb@latest (the path gained cli/). The generated go.mod's tool block names the new path.
• In a checkout, ./... reaches only the framework module: use go test ./... ./cli/..., or the justfile recipes, which already do.

The framework module's own requirements dropped from 266 to 200 lines; the generator's dependencies (dave/dst, dave/jennifer, godog) went with the CLI.

Revision: chat providers no longer need the ai feature¶

The first cut tied chat.providers to the ai feature: the list was recorded and cmd/<name>/chat.go rendered only with ai enabled, and --chat-providers was ignored without it. A tool that drives go/chat from its own code and chooses its provider under its own key had no way to declare its providers except by enabling ai, and then inherited the ai config section, the init ai wizard and a doctor warning about ai.provider, a key it never reads (#94). They are two things:

• chat.providers is the wiring: which go/chat provider modules the binary links. It stands on its own and drives chat.go whether or not ai is on. --chat-providers defaults to none and is honoured without ai.
• The ai feature switches GTB's AI-based features: the ai config section and ai.provider, init ai, docs ask, the chat defaults bundle and the doctor check. It needs at least one linked provider; with no list given it links the default set, as before.

What changes for an existing project:

• docs ask is now registered only with ai enabled. A tool with docs and without ai loses a subcommand that could not have constructed a client.
• gtb disable ai keeps chat.providers and chat.go, and says so; run gtb unset chat.providers to drop the modules.
• doctor on a tool without ai lists the providers it links instead of skipping, and never warns about ai.provider.
• The wizard always offers a Chat providers page; the AI defaults (default provider and model) are on their own page under ai. Nothing is ticked unless ai was selected on the flags.