CI: five pkgs Go modules (chat, database, import, launcher, tea) are built by nothing — the map/identity rot pattern, still unguarded #342

Summary

Five Go modules under pkgs/ — chat, database, import, launcher, and tea — are built by no CI workflow at all. They compile today, but a change that breaks any of them would rot silently, which is exactly what already happened to two sibling modules in this repo: pkgs/map (#338) and pkgs/identity (#340) both broke with no CI noticing, and each needed its own build workflow afterwards (map-build.yml, identity-build.yml).

Evidence (all on main 0d005a0b42cd)

• The Go modules in the repo are: pkgs/chat, pkgs/database, pkgs/graph, pkgs/identity, pkgs/import, pkgs/launcher, pkgs/map, pkgs/mcpx, pkgs/tea (each with its own go.mod).
• Workflow coverage today:
  • pkgs/mcpx — mcpx.yml / mcpx-nixbuild.yml / conformance
  • pkgs/id — id-check.yml (not a pkgs/*/go.mod module)
  • pkgs/map — map-build.yml (fix(map): upgrade keygen to v0.5.1 so pkgs/map builds again #339)
  • pkgs/identity — identity-build.yml (ci(identity): build and vet both tagged variants (sqlite, libsql) #341, tagged builds)
  • pkgs/graph — mod-tidy.yml only (tidy check; its build failure is already tracked in pkgs/graph Go build fails on sshmarshal/x/crypto symbol collision #166)
  • pkgs/chat, pkgs/database, pkgs/import, pkgs/launcher, pkgs/tea — no workflow references any of these paths (grep pkgs/ .github/workflows/ returns no hits for them), and the root nix-ci.yml only evaluates the root flake's mcpx package.
• Verified this run, with Go from each module's go.mod:
  • go build ./... and go vet ./... pass today in all five modules — they are healthy, just unguarded.
  • Each is a small single-main.go module (83–213 lines), so a build+vet job is cheap (the map-build.yml job runs in well under its 15-minute cap).
• The pkgs/identity builds only with -tags sqlite|libsql and nothing in CI says so — plain go build fails on 3 undefined symbols #340 sibling audit noted these five "build plain" — that confirmed health, but no CI coverage was filed for them.

Why it matters

This repo has now twice paid for the same gap: a module with no build CI breaks on a dependency change and nobody finds out until a later audit. The five remaining uncovered modules share the exact risk profile (charm-ecosystem dependencies, go 1.21.3 pins, no tests in any of them — find pkgs/{chat,database,import,launcher,tea} -name '*_test.go' is empty, so build+vet is the only automated signal they can get).

Acceptance criteria

• A CI workflow builds and vets all five modules (chat, database, import, launcher, tea) on changes under their pkgs/<module>/** paths, on PRs and on pushes to main — e.g. one matrix workflow mirroring map-build.yml/identity-build.yml, rather than five near-identical files.
• The workflow is green on its own PR, with one job per module so a failure names the module.
• pkgs/graph is deliberately excluded (its build failure is pkgs/graph Go build fails on sshmarshal/x/crypto symbol collision #166, already watched by mod-tidy.yml), and pkgs/map / pkgs/identity keep their existing dedicated workflows.

Suggested fix

Add .github/workflows/go-modules-build.yml: strategy.matrix.module: [chat, database, import, launcher, tea] with fail-fast: false, actions/setup-go using go-version-file: pkgs/${{ matrix.module }}/go.mod, then go build ./... and go vet ./... with working-directory: pkgs/${{ matrix.module }}. Path filters list the five module directories plus the workflow file itself.