Between 2026-07 and 2026-09 most of what used to be GTB's own pkg/ packages
moved out into standalone modules under gitlab.com/phpboyscout/go/. Each one
is small, framework-free and independently versioned: a project can take one
of them on its own, without taking any of GTB. Collectively they are the
phpboyscout Go toolkit (go.phpboyscout.uk).
GTB is one consumer of the toolkit, an opinionated assembly of it: the Props
container, the command tree, the config-key schemas, the doctor checks, and
the generator that scaffolds a new tool from it. The toolkit modules
themselves carry no dependency on GTB. This page is the orientation for
someone new to the estate; the component pages under
Components do not assume you have read it.
Every toolkit module follows the same three-part shape:
Module path: gitlab.com/phpboyscout/go/<name>, a bare, lower-case
name with no pkg or lib prefix.
Documentation microsite: https://<name>.go.phpboyscout.uk, built with
the same zensical tooling as this
site and deployed via GitLab Pages. Not every module has one: a
provider submodule (a forge, a chat backend, a signing backend) is
documented on its parent module's site instead, under a providers or
backends reference page, so a reader is not sent hunting across a dozen
near-identical microsites for one paragraph.
Mocks: a published mocks subpackage (gitlab.com/phpboyscout/go/<name>/mocks),
not a <name>mock package alongside the code. A consumer imports it under
an alias (configmocks "gitlab.com/phpboyscout/go/config/mocks" is the
pattern GTB's own tests use) rather than generating its own.
The direction of dependency is one-way. A toolkit module never imports
gitlab.com/phpboyscout/go-tool-base, so none of them carry the framework,
Cobra, or any GTB-specific type into a project that uses them standalone.
Where GTB still has a pkg/ package for something a module now owns, that
package is a thin adapter: it maps GTB's config store, Props and
logger onto the module's own constructors, and owns only what is GTB's to
own, a config-key schema, a doctor check, a link-kind blank import, a
generator template. A GTB page is never the authority on a module's API;
every component page that wires one links out to
the module's own docs for that. See the
migration guides for the individual
cut-overs, each one a clean repoint with no compatibility shim.
The tables below list every gitlab.com/phpboyscout/go/* module go.mod and
cli/go.mod require directly, as of 2026-09-18. A provider submodule (forge, chat, signing backend) is
documented on its parent's microsite rather than its own, and so is a
companion module such as config-afero or signing-aws-kms; where a
microsite is not yet serving, the link goes to its pkg.go.dev reference
instead and that gap is called out.
Feature gating as values rather than process state: a Registry declared at init, an immutable Snapshot, a resolved Set, and an Evaluator seam for dynamic flags
The core props/setup build on: which built-in commands, forges and link-kind features a binary carries
Storage-mode abstraction for user-supplied secrets: env-var reference, OS keychain, or literal, with a pluggable backend and an auditable keychain opt-out
The setup wizard's storage-mode selector, pkg/vcs's and pkg/chat's credential resolution, and the credentials.no-literal doctor check
OpenPGP/WKD release signing and verification: a backend registry, trust-set and key-resolver primitives, and OpenPGP packet assembly from any crypto.Signer
gtb sign / gtb keys, and Phase 2 self-update signature verification in pkg/setup
One Go interface over GitHub, GitLab, Gitea, Codeberg, Bitbucket and a plain-HTTP download source, each provider's SDK kept behind its own module boundary
Release discovery and the credential chain behind self-update and pkg/setup's auth flows; pkg/vcs is the config-key adapter over it
The per-provider SDKs (Claude; OpenAI and OpenAI-compatible; Gemini and Vertex; AWS Bedrock's Converse API; Azure OpenAI)
Blank-imported by the binary that ships each provider (cli/cmd/gtb/providers.go links every one); a generated tool links only what its manifest selects
Shared transport middleware and resilience: logging, OpenTelemetry, circuit breaking, rate limiting, retry, for both HTTP and gRPC, server and client
The middleware chain GTB's servers and clients compose from; RateLimitConfigFromConfig/CircuitBreakerConfigFromConfig are the two GTB config adapters left over it
Several toolkit modules exist that GTB does not currently depend on (a
YubiKey signing backend, a GCP KMS backend, standalone TUI components, and
others). For the full, current list of published modules, see
phpboyscout.uk/projects rather than this
page: a project list maintained in one place is less likely to drift than a
second copy of it here.