Module Catalog

Module Catalog

Every first-party Tamp module currently shipping. The contract for each is the same: import the namespace, call a static method that returns a CommandPlan, hand it to the executor.

1.2.0 surface note — every wrapper in the table below ships both fluent s => s.Set*() configurers and object-init new() { ... } overloads. See Module shape below for the comparison.

1.6.0 surface note — Secret.Reveal() is now public, gated by the TAMP004 analyzer instead of per-satellite [InternalsVisibleTo] entries. Net-new satellites no longer require a Tamp.Core bump just to handle a service-principal secret or cert password.

Framework + global tool

Package	Wraps	Reference
Tamp.Core	The framework itself. Ships the analyzer family (TAMP001–TAMP004) bundled at analyzers/dotnet/cs/.	analyzers
Tamp.Cli	The global tool, bare-command flavor (tamp)	—
dotnet-tamp	The global tool, dotnet-verb flavor (dotnet tamp)	—

.NET toolchain

Package	Wraps	Reference
Tamp.NetCli.V8	.NET 8 SDK CLI (dotnet build / test / pack / publish / restore / clean / format) — 1.0.9+ adds solution-mode TRX auto-disambiguation	reference
Tamp.NetCli.V9	.NET 9 SDK CLI	reference
Tamp.NetCli.V10	.NET 10 SDK CLI	reference
Tamp.DotNetCoverage.V18	dotnet-coverage collector and merge	inside tamp core repo
Tamp.Coverlet.V6	Coverlet 6 config-builder — type-safe Format / Include / Exclude / UseSourceLink for dotnet test --collect "XPlat Code Coverage"	tamp-coverlet
Tamp.ReportGenerator.V5	ReportGenerator — coverage HTML / badge / markdown	tamp-reportgenerator
Tamp.EFCore.V8 / V9 / V10	EF Core dotnet ef migrations per major. V10 includes MigrationFanout for multi-target rollouts.	tamp-ef
Tamp.GitVersion.V6	GitVersion 6 — SemVer from git history	tamp-gitversion

Containers + build

Package	Wraps	Reference
Tamp.Docker.V27	Docker 27.x CLI. 0.3.0: Docker.Build routes to BuildKit (docker buildx build); pre-BuildKit builder available as Docker.LegacyBuild. tag, push, pull, full compose + buildx sub-facades.	reference
Tamp.Testcontainers.V4	Diagnostic library for testcontainers-dotnet pipelines. Probes Docker capability + sibling-container restrictions for CI gating.	tamp-testcontainers
Tamp.AdjacentContainer	Fixture-side dual-mode container acquisition — adjacent sidecar via env var, local Testcontainers spawn as fallback. Postgres / Azurite / Service Bus emulator.	tamp-adjacent-container
Tamp.AdjacentContainer.Provisioning	CI-side companion to Tamp.AdjacentContainer. Generates deterministic docker-compose.yml for sidecars + emits the env-var contract Tamp.AdjacentContainer reads. Pairs with Tamp.Docker.V27.Docker.Compose.Up/Down for lifecycle.	tamp-adjacent-container-provisioning
Tamp.Helm.V3	Helm v3 CLI — Upgrade, Template, Lint, Package, Push	tamp-helm
Tamp.Sccache	mozilla/sccache shared compile cache — transparent RUSTC_WRAPPER. Backends: local, S3, Azure Blob, GCS, Redis, memcached, GitHub Actions cache.	tamp-sccache

JavaScript / TypeScript toolchain

Package	Wraps	Reference
Tamp.Yarn.V4	Yarn Berry 4 (install, run, workspaces, npm publish)	reference
Tamp.Npm.V10	npm 10+ CLI — sibling to Tamp.Yarn.V4	tamp-npm
Tamp.Turbo.V2	Turborepo 2 (run, prune --docker, ls, info, daemon)	reference
Tamp.Vite.V5	Vite 5 (dev, build, preview, optimize) and Vitest 1 (run, watch, related, bench, typecheck)	reference
Tamp.GraphQLCodegen.V5	graphql-code-generator 5 (generate, init, --watch, --require)	reference
Tamp.Playwright.V1	Playwright 1 (test, install, codegen, show-report, merge-reports, sharding)	reference

Rust + desktop ship chain (Microsoft Store)

End-to-end: Rust core → Tauri bundle → MSIX package → signed → Partner Center submission. Each step a typed Tamp target.

Package	Wraps	Reference
Tamp.Cargo	cargo CLI — build, test, check, clippy, fmt, run, bench, doc, update	tamp-cargo
Tamp.Tauri.V2	Tauri 2.x CLI + the load-bearing Tauri.ExternalBinPath helper for the sidecar binaries/<name>-<target-triple>[.exe] contract	tamp-tauri
Tamp.Msix	Windows MSIX toolchain (makeappx + signtool) plus Msix.SetAppxManifestVersion for 3-part-SemVer-to-4-part-MSIX normalization	tamp-msix
Tamp.MicrosoftStoreCli	Microsoft Store Developer CLI (msstore-cli) — Partner Center auth + Publish + Submission lifecycle + Flights + Rollout. Replaces the manual Partner Center web-UI submission.	tamp-msstore-cli

Azure + ADO ops

Package	Wraps	Reference
Tamp.AzureCli.V2	az 2.x — full subscription/resource/identity surface; access tokens typed as Secret	tamp-azure-cli
Tamp.Bicep	Bicep CLI (build, lint, format, version) plus az deployment group create via the unified facade	tamp-bicep
Tamp.AzureAppService	App Service slot orchestration + lifecycle (webapp deployment slot swap / list / create / delete)	tamp-azure-app-service
Tamp.Kudu	Azure App Service Kudu REST + adjacent Management API endpoints (vfs, command, config references)	tamp-kudu
Tamp.PostgresFlex	Azure Database for PostgreSQL Flexible Server admin — lifecycle, firewall, parameters	tamp-postgres-flex
Tamp.AzureFunctionsCoreTools.V4	Azure Functions Core Tools (func) 4.x — publish, log streaming, settings sync; access token typed as Secret via stdin	tamp-azure-functions-core-tools
Tamp.AzureStaticWebApps.V2	@azure/static-web-apps-cli (swa) — Azure SWA deploy CLI	tamp-azure-static-web-apps
Tamp.ServiceBus.V7 / V8	Azure Service Bus admin CRUD + topology convergence helper	tamp-servicebus
Tamp.AdoGit	PAT-injected git for Azure DevOps — bakes -c http.extraHeader=… into every fetch/push/clone	tamp-ado-git
Tamp.AdoRest.V7	Azure DevOps REST API 7.1 — typed surface for PRs, builds, service endpoints, environments, agent pools, branch policies; PAT typed as Secret	tamp-ado-rest
Tamp.AdoServiceConnection.V1	End-to-end ADO WIF (Workload Identity Federation) service connection creation — orchestrates az + ADO REST	tamp-ado-service-connection
Tamp.YouTrack	Typed YouTrack REST client. Issues create / update / search / set-state. Bearer auth via Secret-typed permanent token. Built on Tamp.Http.	tamp-youtrack

Supply-chain security

One focused tool per axis. No overlap.

Package	Wraps	Concern	Reference
Tamp.TruffleHog.V3	TruffleHog 3 (git, github, filesystem, docker; PAT typed as Secret)	leaked secrets in source / git history	reference
Tamp.CodeQL.V2	CodeQL 2 (database, github upload-results, resolve, pack, query; PAT via stdin)	code-pattern vulns (SQLi, XSS, taint)	reference
Tamp.Syft	anchore/syft — SBOM (CycloneDX / SPDX). Auto-detects 20+ ecosystems (Rust + npm + .NET + Go + Java + …)	what's inside the artifact	tamp-syft
Tamp.Grype	anchore/grype — CVE scanner. Reads Syft SBOMs. EPSS + KEV + CVSS composite 0-10 risk scoring. --fail-on severity for CI gating.	dep CVEs / vuln matching	tamp-grype
Tamp.SonarScanner.V10 / Tamp.SonarScannerCli.V6	SonarScanner for .NET 10 + the standalone CLI	code quality + coverage gating	tamp-sonar

Source control / VCS

Package	Wraps	Reference
Tamp.GitHubCli.V2	gh CLI (release, pr, issue, api, repo, auth)	tamp-gh

Foundation libraries

Package	Wraps	Reference
Tamp.Http	Foundation TampApiClient base class for HTTP-API satellite wrappers — Secret-redacted auth, JSON, error mapping. The shared substrate beneath Tamp.Kudu / Tamp.AdoRest / Tamp.MicrosoftStoreCli / Tamp.PostgresFlex.	tamp-http

NuGet listing: https://www.nuget.org/profiles/tamp · the Tamp.* prefix is reserved to the project so every package on the listing carries the verified-publisher checkmark.

Common stacks (worked examples)

Several common adopter scenarios pair specific satellites together. Pick the family that matches your project shape:

• Polyglot Microsoft Store desktop app (Rust + Node + .NET → MSIX → Store): Tamp.Cargo → Tamp.Tauri.V2 → Tamp.Msix → Tamp.MicrosoftStoreCli, optionally + Tamp.Sccache for the Rust compile cache.
• Azure-deployed .NET service: Tamp.NetCli.V10 (build) + Tamp.EFCore.V10 (migrations) + Tamp.AzureCli.V2 (auth) + Tamp.Kudu (Kudu deploy) + Tamp.AzureAppService (slot swap).
• Helm-deployed cluster app: Tamp.Docker.V27 (image) + Tamp.Helm.V3 (chart) + Tamp.GitHubCli.V2 (release).
• Compliance-aware ship: any stack + Tamp.Syft (SBOM) + Tamp.Grype (CVE gate) + Tamp.TruffleHog.V3 (secrets) + Tamp.CodeQL.V2 (SAST).

How satellites depend on Tamp.Core

Every satellite declares a Tamp.Core dependency in its .nuspec (driven by Directory.Packages.props). The dependency is a minimum, not a pin — NuGet's PackageReference semantics interpret Version="1.6.0" as >= 1.6.0, not == 1.6.0.

<!-- Inside a satellite's Directory.Packages.props: -->
<PackageVersion Include="Tamp.Core" Version="1.6.0" />

When an adopter has Tamp.Core 1.6.5 and pulls in a satellite that declared 1.6.0, NuGet resolves 1.6.5 — the satellite gets the newer Core transparently. No satellite re-publish is needed when Tamp.Core ships a minor or patch.

When does a satellite actually need to bump its Tamp.Core minimum?

Scenario	Bump?
Tamp.Core ships a patch (1.6.0 → 1.6.1)	No. Existing >= 1.6.0 dep is satisfied.
Tamp.Core ships a minor (1.6.x → 1.7.0)	No. Same reason.
Satellite wants to use new Core API (a new method, new analyzer)	Yes. Bump min to the version that introduced it.
Satellite gets tripped by a new analyzer rule	Yes, after fixing the violation.
Tamp.Core ships a major (1.x → 2.x)	Yes — breaking by SemVer. Sweep is expected.

Why this matters — and what changed in 1.6.0

Pre-1.6.0, a class of forced satellite-sweep DID exist: any satellite needing Secret.Reveal() had to be added to Tamp.Core/AssemblyInfo.cs's [InternalsVisibleTo] list, which forced a Tamp.Core minor bump and a satellite-side min-version bump. Across an onboarding wave that was a per-satellite sweep just to ship credential handling.

Tamp.Core 1.6.0 retired this via the TAMP004 analyzer. Secret.Reveal() is now public, gated by the analyzer instead of by IVT. Net-new satellites no longer require any Tamp.Core change to handle secrets — they just call Reveal() from inside their *Settings classes (the TAMP004-approved context). Satellite-sweep-per-Core-bump is the failure mode we eliminated.

NuGet range syntax (for reference)

If you want tighter intent than the default min-version semantics, NuGet supports the full SemVer range syntax:

Syntax	Means	npm equivalent
Version="1.6.0"	>= 1.6.0 (NuGet default)	^1.6.0 (close enough)
Version="[1.6.0]"	exactly 1.6.0	1.6.0
Version="[1.6.0,2.0.0)"	any 1.x >= 1.6.0	^1.6.0 precisely
Version="1.6.*"	floating — picks highest 1.6.x at restore	~1.6.0
Version="1.*"	floating — picks highest 1.x at restore	^1.0.0

Tamp's first-party satellites stay on the bare 1.6.0 form. It's already min-version semantics, and tighter pinning is an adopter choice (build script reproducibility) rather than something the satellite should impose.

Naming convention

Tamp.{ToolFamily}{.V{Major}}?

The .V{Major} suffix is present only when the wrapped tool's CLI surface breaks across majors. Recorded in ADR 0002 — Package naming convention.

Pattern	Example	Why
Pinned	Tamp.NetCli.V10	dotnet CLI breaks across majors; consumers on .NET 10 stay on V10 indefinitely
Pinned	Tamp.Docker.V27	Docker majors break wrapper code
Pinned	Tamp.Yarn.V4	Berry 4 broke from classic Yarn; future Berry 5 would be a sibling package
Pinned	Tamp.Vite.V5	Vite 6 reworked the build pipeline → new major → sibling package
Unpinned	Tamp.Kubectl (planned)	kubectl is deliberately backward-compatible

Decision rule: does the new tool major break wrapper code? If yes → new package. If no → keep the existing package and branch on the tool's reported version inside the wrapper.

Module shape (what you'll see in every wrapper)

using Tamp.NetCli.V10;       // namespace = package name

// Single static class per module, named after the tool.
DotNet.Build(...)
DotNet.Pack(...)
Docker.Login(...)
Docker.Push(...)

Each verb takes an Action<TSettings> configurer or an already-populated settings instance, and returns a CommandPlan (1.2.0+ — object-init overloads fanned out across every first-party wrapper):

// fluent — chains read top-to-bottom
var plan = DotNet.Build(s => s
    .SetConfiguration(Configuration.Release)
    .SetNoRestore(true)
    .SetVerbosity(DotNetVerbosity.Minimal));

// object-init — flatter, integrates with target-typed new()
var plan = DotNet.Build(new()
{
    Configuration = Configuration.Release,
    NoRestore = true,
    Verbosity = DotNetVerbosity.Minimal,
});

// either way:
// plan.Executable == "dotnet"
// plan.Arguments  == ["build", "--configuration", "Release", "--no-restore", "--verbosity", "minimal"]

Both styles produce byte-identical CommandPlans. Settings classes are mutable while the configurer runs, then frozen into the returned CommandPlan. The runner takes care of dispatch.

When a wrapper takes a Secret

Wrappers handling sensitive values (passwords, tokens) accept the typed Secret parameter and emit the secret via stdin where the wrapped tool supports it:

Docker.Login(s => s
    .SetServer("registry.example.com")
    .SetUsername("ci")
    .SetPassword(RegistryPassword));   // Secret type, not string
// produces:
//   docker login --username ci --password-stdin registry.example.com
//   stdin: <password value>
//
// the password value is never on the command line, never in the
// process table, and is automatically registered with the executor's
// redaction table.

Building your own module

A first-party-shaped module is roughly:

1. New csproj Tamp.<Family>{.V<N>} referencing Tamp.Core.
2. Per-verb settings record (mutable, fluent setters).
3. Common base if the tool has shared knobs (verbosity, working directory).
4. Static class with one method per verb, returning CommandPlan.
5. Tests: argument shape, edge cases, secret handling.

Tamp.Docker.V27 is the worked example for a from-scratch module; Tamp.NetCli.V10 is the worked example with a shared base across multiple verbs.

Schema-driven codegen for wrappers is on the roadmap (deferred ADR 0013) and will eliminate hand-authoring most of this; for now it's small enough to write by hand.

Where next

• Tamp.NetCli — full reference for the .NET SDK wrapper
• Tamp.Docker — full reference for the Docker wrapper
• Build Script Authoring — how to consume modules from a build script