Architectural Traits Blind Scorecard — 51 Go Projects#

Reduced from 5 chunk outputs (X22a-1 through X22a-5-arch-traits). No re-scoring performed. Chunks are authoritative for their assigned projects.

Rubric#

Scorecard#

Evidence#

P01-kubernetes#

P01-kubernetes / T1 (score 2): report:P01-kubernetes–interfaces.md: dominant style is 2–4 method interfaces (runtime.Object 2, FilterPlugin 2, ScorePlugin 2); broader legacy interfaces (storage.Interface 13, SharedInformer 15) acknowledged as accumulation points P01-kubernetes / T2 (score 1): report:P01-kubernetes–patterns.md: 827 func init() calls populating the Scheme global mutable registry; explicitly described as “a deliberate trade-off for API extensibility” P01-kubernetes / T3 (score 3): report:P01-kubernetes–architecture.md: “No dependency injection framework is used. Wiring is manual: each New(config) function receives all its dependencies explicitly”; CreateServerChain assembles server chain at startup P01-kubernetes / T4 (score 3): report:P01-kubernetes–patterns.md: 16,784 context.Context parameters; 1,013 context.WithCancel/WithTimeout/WithDeadline calls; external effects flow through injected parameters throughout P01-kubernetes / T5 (score 1): report:P01-kubernetes–structure.md: monolithic pkg/ tree mixes domain logic with I/O; staging module extraction helps public packages but main codebase has no explicit pure-logic boundary P01-kubernetes / T6 (score 1): report:P01-kubernetes–interfaces.md: 2,498 interface definitions; “every major collaboration point is abstracted behind an interface”; type assertions used pervasively for capability discovery P01-kubernetes / T7 (score 3): report:P01-kubernetes–api-surface.md: 20+ independently published staging modules (client-go, apimachinery, apiserver, component-base); sample-controller as reference integrator; dedicated staging pipeline with semantic versioning P01-kubernetes / T8 (score 2): report:P01-kubernetes–structure.md: custom import-boss tool enforces layering via .import-restrictions files rather than Go’s internal/; staging sub-modules published independently; non-standard but effective

P02-moby#

P02-moby / T1 (score 1): report:P02-moby–interfaces.md: ImageService has 35 methods, ContainerAPIClient 30; “Large (10+ methods)” interfaces appear at critical seams; some narrow marker interfaces in errdefs but insufficient to offset P02-moby / T2 (score 2): report:P02-moby–patterns.md: Registry pattern for layers/volumes/plugins uses init-time self-registration; no widespread init() side effects beyond plugin registry; constructor-based wiring for Daemon struct P02-moby / T3 (score 3): report:P02-moby–architecture.md: daemonCLI.start() ~400 lines of sequential manual wiring; no DI framework; explicit bootstrap without abstraction P02-moby / T4 (score 3): report:P02-moby–patterns.md: 2,267 context.Context function parameter occurrences; rate limiting via golang.org/x/time/rate; external effects flow through parameters throughout P02-moby / T5 (score 1): report:P02-moby–architecture.md: Daemon is a large layered monolith; api/ is pure types only but daemon/ mixes logic and I/O heavily; no functional core isolation P02-moby / T6 (score 2): report:P02-moby–interfaces.md: handler packages define consumer-side Backend interfaces (ISP pattern); but ImageService, libcontainerd.Client, driverapi.Driver are pervasive complex interfaces; mixed P02-moby / T7 (score 2): report:P02-moby–api-surface.md: github.com/moby/moby/client published as independent module with functional options; api/ as type-only module; well-defined but narrower ecosystem than k8s P02-moby / T8 (score 2): report:P02-moby–structure.md: daemon/internal/ with ~45 private packages; non-standard sub-directory internal/ enforcement; dual storage path (graphdriver/snapshotter) indicates some boundary tension

P03-etcd#

P03-etcd / T1 (score 3): report:P03-etcd–interfaces.md: UberApplier 1 method, Watchable 1, Wait 3, Raft 4; narrow consumer-side interfaces dominate at nearly all seams; AuthStore (~30 methods) is internal-only exception P03-etcd / T2 (score 3): report:P03-etcd–patterns.md: manual constructor wiring in bootstrap.go; no DI framework; no package-level mutable state or problematic init() blocks observed P03-etcd / T3 (score 3): report:P03-etcd–architecture.md: embed.StartEtcd() and bootstrap() form explicit named composition root; bootstrappedServer struct carries all deps; dependency order is explicit and observable P03-etcd / T4 (score 2): report:P03-etcd–patterns.md: 1,490 context.Context usages as first argument; context-based timeouts for linearizable reads; some ambient Raft timing clock usage remains in raft internals P03-etcd / T5 (score 3): report:P03-etcd–architecture.md: go.etcd.io/raft/v3 is a pure state machine with no I/O; apply layer handles effects; storage and MVCC layers are algorithmic; clear shell/core separation P03-etcd / T6 (score 3): report:P03-etcd–interfaces.md: decorators (applierV3) and storage subsystems (mvcc.store) are concrete structs; interfaces only at external seams (rafthttp.Transporter, Queryable, Appendable) P03-etcd / T7 (score 2): report:P03-etcd–api-surface.md: embed.Config and embed.StartEtcd() provide clear embedding surface; client/v3 has functional options; solid but infrastructure-centric rather than library-oriented P03-etcd / T8 (score 3): report:P03-etcd–structure.md: 13-module Go workspace enforces boundaries via module separation rather than internal/; clean dependency hierarchy (root → api → server → client) with no circular imports

P04-prometheus#

P04-prometheus / T1 (score 2): report:P04-prometheus–interfaces.md: bimodal — Discoverer 1 method, Queryable 1 method, Storage 8 with embedding are excellent; rules.Rule 15+ methods is an outlier; ~60% under 8 methods P04-prometheus / T2 (score 1): report:P04-prometheus–patterns.md: service discovery plugins call discovery.RegisterConfig() in init() at startup; global registry built from init-time side effects; consistent pattern across all SD providers P04-prometheus / T3 (score 3): report:P04-prometheus–architecture.md: main.go ~1700 lines with explicit sequential dependency order (readyStorage → remoteStorage → fanout → discovery managers → scrape manager → engine → rules manager → web handler); no framework P04-prometheus / T4 (score 2): report:P04-prometheus–patterns.md: 732 context.Context usages as first arg; deadline-based scrape timeouts; ambient cloud SDK calls in discovery layer (AWS/Azure/GCP) limit score P04-prometheus / T5 (score 2): report:P04-prometheus–dependencies.md: PromQL parser uses stdlib only; TSDB is algorithmic; storage layer couples query engine to concrete backends with some I/O interleaving in scrape/discovery P04-prometheus / T6 (score 2): report:P04-prometheus–interfaces.md: consumer-defined interfaces (TargetRetriever, RulesRetriever) show good ISP inside web/api; scrape, discovery, fanout subsystems are concrete; flat structure weakens overall discipline P04-prometheus / T7 (score 1): report:P04-prometheus–api-surface.md: promql.Engine, tsdb.DB, storage interfaces are public; no dedicated builder patterns or test helpers package; minimal embedding affordances; config via structs P04-prometheus / T8 (score 1): report:P04-prometheus–structure.md: domain-driven flat layout with no pkg/; minimal internal/; packages depend on concrete types from peers; no strict layering or visibility enforcement

P05-grafana#

P05-grafana / T1 (score 2): report:P05-grafana–interfaces.md: infrastructure interfaces exemplary (BackgroundService 1, CacheStorage 3, Bus 2, PluginSource 3); domain service interfaces broad (DashboardService ~20 methods); two tiers co-exist P05-grafana / T2 (score 3): report:P05-grafana–architecture.md: Wire DI eliminates globals; setting.Cfg and all dependencies are explicit constructor parameters; no ambient init() side effects beyond bounded startup sequence in Server.Init() P05-grafana / T3 (score 3): report:P05-grafana–architecture.md: pkg/server/wire_gen.go is a 1939-line generated composition root; Wire validates full dependency graph at compile time; constructors are the only way to obtain dependencies P05-grafana / T4 (score 2): report:P05-grafana–patterns.md: context pervasive (14,694 usages); rates parameterized via golang.org/x/time/rate and workqueue limiters; some legacy ambient patterns expected in large codebase P05-grafana / T5 (score 3): report:P05-grafana–architecture.md: clear layering — pkg/infra/ has no domain imports, pkg/services/ implements business logic, pkg/api/ is the HTTP shell; pure packages explicitly avoid IO imports P05-grafana / T6 (score 3): report:P05-grafana–interfaces.md: concrete internal service implementations throughout; interfaces at plugin system (gRPC), infrastructure (CacheStorage, DB) boundaries; Wire-validated explicit dependencies prevent accidental abstraction P05-grafana / T7 (score 2): report:P05-grafana–api-surface.md: plugin SDK, apimachinery, apiserver documented as external-facing; Wire providers are public; no dedicated pkg/test pattern; formal integrator surface not explicitly documented P05-grafana / T8 (score 2): report:P05-grafana–structure.md: go.work manages 35+ modules; individual packages have internal/ subdirs; layering enforced by Wire compile-time validation; some public imports of internal services remain possible

P06-hugo#

P06-hugo / T1 (score 2): report:P06-hugo–interfaces.md: most interfaces narrow (Identity 1, Converter 1–2, Template 2, SignalRebuilder 1); two large facades (page.Page ~50, config.AllProvider ~45) are intentional system-boundary aggregates P06-hugo / T2 (score 2): report:P06-hugo–architecture.md: Deps is passed explicitly (not a global singleton); init side effects concentrated in Deps.Init(); no package-level mutable state but Deps is a god-object with centralized lifecycle P06-hugo / T3 (score 2): report:P06-hugo–architecture.md: hugoBuilder.newHugoSites() constructs Deps with all providers explicitly; no DI framework; composition is explicit but Deps container is not a clearly named “root” P06-hugo / T4 (score 2): report:P06-hugo–patterns.md: context pervasive (448 uses); file I/O through hugofs abstraction; time mockable via bep/clocks; effects flow through Deps parameter rather than individual function args P06-hugo / T5 (score 2): report:P06-hugo–architecture.md: identity package deliberately minimal (no domain imports); converters (markup/converter) are pure logic; page.Page implementation mixes domain+I/O; no strict enforcement P06-hugo / T6 (score 2): report:P06-hugo–interfaces.md: goldmarkConverter and filecache.Caches are concrete; interfaces at extension points (Converter, Provider) and domain boundaries (page.Page); afero wrapping introduces extra abstraction layers P06-hugo / T7 (score 1): report:P06-hugo–api-surface.md: Template API rich (~30 namespaces, ~400 functions); hugolib explicitly flagged as unstable API; no dedicated pkg/test pattern; no integrator builder surface documented P06-hugo / T8 (score 1): report:P06-hugo–structure.md: root-level packages dominate; internal/ minimal (WASM/JS only); no import cycle prevention mechanism visible; circular import avoidance via convention not enforcement

P07-traefik#

P07-traefik / T1 (score 2): report:P07-traefik–interfaces.md: hand-authored interfaces predominantly 1–3 methods (Provider 2, tcp.Handler 1, udp.Handler 1, ProxyBuilder 2, ServiceBuilder 1); metrics.Registry ~20 methods is a service-boundary exception P07-traefik / T2 (score 2): report:P07-traefik–patterns.md: manual constructor injection throughout; setupServer() is the composition root; global state limited to observability registration; no heavy init() side effects for core logic P07-traefik / T3 (score 3): report:P07-traefik–architecture.md: setupServer() ~220 lines in cmd/traefik/traefik.go is the explicit, obvious composition root; all components manually constructed and passed; no DI framework P07-traefik / T4 (score 1): report:P07-traefik–patterns.md: channel-based event bus provides some parameterization; no systematic evidence of injecting time/RNG/IO as seams; ambient call patterns persist for ACME/TLS operations P07-traefik / T5 (score 2): report:P07-traefik–structure.md: protocol layers (muxer/http, tcp, udp) separated from application logic; middleware packages isolated per-concern; separation present in most subsystems but not explicitly enforced P07-traefik / T6 (score 2): report:P07-traefik–interfaces.md: Provider and ProxyBuilder interfaces at external/replaceable boundaries; serviceManager used locally; good ISP discipline; some internal interfaces for flexibility without reaching mock-everything P07-traefik / T7 (score 2): report:P07-traefik–api-surface.md: REST API, CLI (healthcheck/version), 30+ middleware catalog, plugin system (yaegi/WASM); good surface but no dedicated pkg/test or formal integrator builder API P07-traefik / T8 (score 1): report:P07-traefik–structure.md: pkg/ packages are openly importable without internal/ discipline; only cmd/internal/gen uses internal/; layering described as “generally one direction” but not Go-enforced

P08-caddy#

P08-caddy / T1 (score 3): report:P08-caddy–interfaces.md: vast majority of interfaces 1–2 methods (Module 1, App 2, Provisioner 1, Validator 1, MiddlewareHandler 1, Adapter 1); textbook ISP compliance throughout P08-caddy / T2 (score 1): report:P08-caddy–patterns.md: entire extensibility model driven by init() side effects; 112 init functions and 136 RegisterModule calls populating global module registry before main(); architecture.md confirms “global modules map built before main()” P08-caddy / T3 (score 3): report:P08-caddy–architecture.md: provisionContext() + ctx.LoadModule() form clear composition root; cmd/caddy/main.go deliberately minimal (43 lines); manual context-passing enables explicit wiring; no DI framework P08-caddy / T4 (score 1): report:P08-caddy–patterns.md: modules receive caddy.Context in Provision(); context-passing provides flexibility but no systematic evidence of parameterizing time/RNG/IO as injected seams P08-caddy / T5 (score 1): report:P08-caddy–architecture.md: caddyconfig/caddyfile is a pure parser; modules are inherently effectful by design; no functional core / IO shell separation enforced at package level P08-caddy / T6 (score 2): report:P08-caddy–interfaces.md: interfaces ubiquitous by design (Module, Provisioner, MiddlewareHandler at every extension point); 125 compile-time interface satisfaction checks; pragmatic for plugin model but not concrete-first internally P08-caddy / T7 (score 3): report:P08-caddy–api-surface.md: dedicated public integrator surface — Module interface, lifecycle hooks (Provisioner/Validator/CleanerUpper), plugin registration pattern, xcaddy build tool; cmd/caddy/main.go is a deliberate copy-paste template for custom builds P08-caddy / T8 (score 3): report:P08-caddy–structure.md: strict layering (root → caddyconfig → modules); modules/internal/ for sub-tree visibility; root package is stable public boundary; intentional use of Go visibility rules at sub-tree granularity

P09-cockroach#

P09-cockroach / T1 (score 2): report:P09-cockroach–interfaces.md: kv.Sender is 1 method; Processor and Resumer are narrow (1–5); but batcheval.EvalContext ~35 methods and storage.Engine ~30 methods at critical internal seams; mixed across layer depth P09-cockroach / T2 (score 1): report:P09-cockroach–patterns.md: ~15 CCL feature hooks injected via init() function variables at package level; CCL builds mutate package-level function vars to add enterprise features; more than “one or two” init() side effects P09-cockroach / T3 (score 3): report:P09-cockroach–architecture.md: NewServer() in pkg/server/server.go is ~1200 lines of explicit construction; numbered dependency order (1–13 steps); no DI framework; manual injection throughout P09-cockroach / T4 (score 3): report:P09-cockroach–patterns.md: context propagation in 26,543 usages; every function that does I/O or RPC accepts context.Context as first parameter; I/O through Engine/Reader/Writer interfaces; HLC for temporal concerns P09-cockroach / T5 (score 2): report:P09-cockroach–architecture.md: strict bottom-up layering with pkg/raft as pure algorithm module; SQL optimizer (pkg/sql/opt) is cost-based logic; most packages mix logic and I/O at their level; no explicit IO prohibition in logic packages P09-cockroach / T6 (score 1): report:P09-cockroach–interfaces.md: 1,481 interface definitions; every internal component implements multiple interfaces (Sender, TxnSender, Reader, Writer, Processor); architecture described as having near-universal interface abstraction at internal seams P09-cockroach / T8 (score 2): report:P09-cockroach–structure.md: clear functional domain layering and CCL separation via blank imports; no top-level internal/ directory; pkg/ is a domain monolith; layering enforced by design and documentation but not Go conventions

P10-fyne#

P10-fyne / T1 (score 3): report:P10-fyne–interfaces.md: behavior interfaces median 2 methods (Tappable 1, Draggable 2, Focusable 4, DoubleTappable 1); all behavior interfaces 1–4 methods; App (17) and Canvas (20) are explicit facade exceptions P10-fyne / T2 (score 3): report:P10-fyne–patterns.md: single app singleton stored in atomic.Pointer[fyne.App]; no package-level mutable state beyond this; no init() side effects; described as “zero application-wide globals except the app singleton” P10-fyne / T3 (score 3): report:P10-fyne–architecture.md: explicit sequence app.New() → NewWithID() → NewGLDriver() → newAppWithDriver() in app/app.go; no DI framework; build tags select driver at compile time; fully traceable P10-fyne / T4 (score 1): report:P10-fyne–patterns.md: only 5 context.Context references in entire repo; deliberate omission — fyne.Do() marshals work to UI thread as the cancellation model; idiomatic for GUI but scores low on rubric P10-fyne / T5 (score 1): report:P10-fyne–architecture.md: software painter uses only stdlib image/*; but no explicit pure-logic/IO separation at package level; internal/ is 32 packages mixing all concerns vertically by rendering layer P10-fyne / T6 (score 2): report:P10-fyne–interfaces.md: internal collaborators fyneApp, glCanvas, gLDriver are concrete structs; interfaces at driver/painter boundaries; root package is interface-only but internal implementations are concrete, not mock-heavy P10-fyne / T7 (score 3): report:P10-fyne–api-surface.md: 63+ exported widget constructors (NewButton, NewEntry, etc.), container layouts, dialogs, data binding, storage API, driver extensions, test helpers; primary library designed for integrators P10-fyne / T8 (score 3): report:P10-fyne–structure.md: root package is interface-only (no concrete implementations exported); entire rendering stack in internal/ making it refactorable without API breakage; feature packages public; textbook visibility discipline

P11-minio#

P11-minio / T1 (score 1): report:P11-minio–interfaces.md: bimodal — ObjectLayer (~40 methods) and StorageAPI (~35) dominate; narrow interfaces (WarmBackend 5, event.Target 6, RWLocker 4) exist but are secondary; provider-defined large interfaces characterize the public boundary P11-minio / T3 (score 1): report:P11-minio–architecture.md: serverMain() has a single bootstrapTrace()-ordered init sequence, but all wiring flows into global* vars rather than explicit constructor parameters — the “root” creates globals, not an explicit graph P11-minio / T4 (score 1): report:P11-minio–patterns.md: context used throughout (1714 occurrences) for cancellation; no evidence of injected clock interface or parameterized randomness/IO; rate limiting via x/time/rate is narrow and ambient P11-minio / T5 (score 1): report:P11-minio–structure.md: 34 internal/ sub-packages ring the single cmd/ god package (~453 Go files all in package cmd); utility packages (bpool, cachevalue) are pure, but business logic is thoroughly mixed with IO in the dominant cmd package P11-minio / T6 (score 2): report:P11-minio–architecture.md: ObjectLayer is the single seam replacing the storage hierarchy; internal grid RPC and background workers use concrete types throughout; the narrow use of interfaces at real replacement points (ObjectLayer, event.Target) reflects correct boundary discipline P11-minio / T7 (score 1): report:P11-minio–api-surface.md: server-binary only with no exported Go library API; external SDK lives in the separate github.com/minio/pkg repo; extension is via compiled-in event targets and Object Lambda, not an importable package P11-minio / T8 (score 1): report:P11-minio–structure.md: internal/ wraps 34 sub-packages correctly, but the dominant cmd/ is a single 453-file god package with no visibility enforcement; no sub-package discipline within the most import-heavy portion of the codebase

P12-consul#

P12-consul / T1 (score 2): report:P12-consul–interfaces.md: modal size 1–3 methods; 20 single-method proxycfg Notify interfaces; consumer-defined pattern throughout; outlier Authorizer (~35 methods) is a legitimately wide protocol contract P12-consul / T2 (score 1): report:P12-consul–architecture.md: BaseDeps struct for explicit DI; but api-surface.md notes HTTP routes registered via init() in agent/http_register.go; some package-level sentinels; not pervasive but present P12-consul / T3 (score 2): report:P12-consul–architecture.md: BaseDeps is an explicit manual DI root passed through Server/Client constructors; wiring is discoverable and greppable; no framework, no service locator P12-consul / T4 (score 1): report:P12-consul–patterns.md: shutdownCh + context coexistence noted as an in-progress migration; no explicit clock injection or parameterized IO described; context used for request scope but not the primary lifecycle signal P12-consul / T5 (score 1): report:P12-consul–structure.md: agent/structs/ is a god package for shared domain types — business logic and IO are entangled at the center; domain-driven layout at top level is correct but structs package prevents true core/IO separation P12-consul / T6 (score 2): report:P12-consul–interfaces.md: ca.Provider (9 methods with ISP sub-interfaces), storage.Backend (6), Reconciler (1) — interfaces at real replacement boundaries; internal coordinator/delegate uses concrete types P12-consul / T7 (score 2): report:P12-consul–structure.md: api/ sub-module is a public Go client library; sdk/ sub-module as reusable primitives; proto-public/ as stable external proto contracts — three distinct public-facing layers P12-consul / T8 (score 2): report:P12-consul–structure.md: 5 sub-modules (api/, sdk/, proto-public/, envoyextensions/, troubleshoot/); internal/ for v2 architecture; domain-driven root layout with intentional visibility separation

P13-vault#

P13-vault / T1 (score 2): report:P13-vault–interfaces.md: SDK provides narrow clean interfaces (physical.Backend 4, logical.Storage 4, physical.HABackend 2); optional capability extension via type assertions rather than wider interfaces; Core has legitimately wide SecurityBarrier (~25) as protocol contract P13-vault / T2 (score 1): report:P13-vault–patterns.md: factory maps in CoreConfig (functions, not instances) keep globals lean; sync.Once guards (72 uses) for lazy singletons; some package-level vars for CA state; limited but present P13-vault / T3 (score 2): report:P13-vault–architecture.md: CoreConfig struct carries factory maps (not instances) — explicit DI container; plugins never imported directly; radix-tree router as the dispatch mechanism; composition root is clearly vault.NewCore(CoreConfig{…}) P13-vault / T4 (score 1): report:P13-vault–patterns.md: ShutdownCh chan struct{} pattern throughout; helper/fairshare/ worker pool with explicit context; no documented clock injection interface; api/auth/ uses functional options but not time parameterization P13-vault / T5 (score 2): report:P13-vault–structure.md: sdk/ and api/ as separate Go modules with clean boundaries; physical/ backends separated from core logic; sdk/logical.Backend as a pure plugin contract that carries no IO dependencies itself P13-vault / T6 (score 2): report:P13-vault–architecture.md: plugins never imported directly into CoreConfig — only factory functions; sdk/logical.Backend is the universal plugin contract at the real external boundary; internal vault/ package uses concrete collaborators P13-vault / T7 (score 3): report:P13-vault–structure.md: three Go modules (root, sdk/, api/); api/ is an independent library used by all Vault clients; sdk/ provides the stable plugin development kit for third-party secrets engines and auth methods — textbook multi-module library design P13-vault / T8 (score 2): report:P13-vault–structure.md: internal/ used throughout; Enterprise/CE split via _stubs_oss.go build stubs; three distinct modules with explicit visibility; internalshared/ as a cross-module seam

P14-terraform#

P14-terraform / T1 (score 2): report:P14-terraform–interfaces.md: GraphNodeExecutable (1 method), GraphTransformer (1) alongside providers.Interface (~35), EvalContext (~30); statemgr.Full is exemplary interface composition (5 interfaces composed); bimodal but consumer-defined throughout P14-terraform / T2 (score 2): report:P14-terraform–architecture.md: all-internal architecture with zero exported packages; factory map registry for backends; no package singletons visible in reports; ContextOpts DI container; cleaner than most projects in this chunk P14-terraform / T3 (score 2): report:P14-terraform–architecture.md: ContextOpts as explicit DI container; each operation builds a fresh DAG; composition root in main.go is thin but explicit; no service locator P14-terraform / T4 (score 1): report:P14-terraform–patterns.md: atomic stop flag used instead of context cancellation for stopping operations; no documented clock injection or parameterized IO beyond context; consistent with the graph/batch model P14-terraform / T5 (score 1): report:P14-terraform–architecture.md: DAG logic in internal/dag is pure; providers run as subprocesses (zero in-process IO mixing); internal/promising/ uses generics for pure promise combinators; limited to specific packages P14-terraform / T6 (score 2): report:P14-terraform–architecture.md: providers.Interface only at the subprocess boundary (all providers are out-of-process gRPC); internal graph transformers use concrete types; EvalContext wraps the internal pipeline but is a necessary abstraction for the walk P14-terraform / T7 (score 1): report:P14-terraform–structure.md: zero exported packages (all internal/); rpcapi provides gRPC automation interface; no importable library; downstream tools consume via CLI or gRPC protocol, not Go packages P14-terraform / T8 (score 3): report:P14-terraform–structure.md: all internal/, 9 remote-state backends as separate Go modules, clean layering with no import cycles reported; tfplugin5/tfplugin6 dual protocol separation; textbook package boundary discipline

P15-nomad#

P15-nomad / T1 (score 2): report:P15-nomad–interfaces.md: Scheduler (1 method), FeasibleIterator/RankIterator (2 each), admissionController (1) are consumer-defined narrow interfaces; StateDB (30+) and DriverPlugin (15) are broader protocol contracts at real external boundaries P15-nomad / T2 (score 1): report:P15-nomad–patterns.md: init() subprocess dispatch trick in main.go for task drivers; shutdownCh + context coexistence; limited internal/ enforcement; not pervasive but present P15-nomad / T3 (score 2): report:P15-nomad–patterns.md: manual DI via constructor functions; Server and Client constructed with explicit dependency parameters; no service locator; greppable wiring P15-nomad / T4 (score 1): report:P15-nomad–patterns.md: shutdownCh + context coexistence (incomplete migration); blocking query/watch semantics via go-memdb; no explicit clock injection described; context present but not the primary mechanism P15-nomad / T5 (score 1): report:P15-nomad–structure.md: scheduler/ isolated with no server imports (clear separation); but nomad/structs/ as monolithic domain model entangles domain types with the rest; partial functional core isolation P15-nomad / T6 (score 2): report:P15-nomad–interfaces.md: CQRS-style boundary — read from State, write via Planner; Scheduler interface at the scheduling seam; internal server/client use concrete types for collaboration P15-nomad / T7 (score 2): report:P15-nomad–structure.md: api/ is a separate Go module providing the public Go client library; used by third-party tooling to interact with Nomad clusters P15-nomad / T8 (score 2): report:P15-nomad–structure.md: domain-driven layout at root level; scheduler/ cleanly isolated; api/ as separate module; only internal/testing/ for internal enforcement — less strict than ideal but intentional structure

P16-dapr#

P16-dapr / T1 (score 2): report:P16-dapr–interfaces.md: leaf/transport interfaces are small (http.API 2 methods, wfengine.Interface 5, channel.AppChannel 5); core subsystem interfaces are broader (actors.Interface 12, security.Handler 16 with //nolint:interfacebloat); deliberate ISP split between subsystem and leaf boundaries P16-dapr / T2 (score 1): report:P16-dapr–patterns.md: component registration via init() blank imports with build-tag-controlled flavors (allcomponents.go vs stablecomponents.go); DefaultRegistry singletons per building block type; contained but present P16-dapr / T3 (score 2): report:P16-dapr–architecture.md: DaprRuntime struct as composition root; newDaprRuntime() wires all subsystems with Options structs; concurrency.RunnerCloserManager manages structured goroutine lifecycle; explicit and greppable P16-dapr / T4 (score 1): report:P16-dapr–patterns.md: context propagation pervasive (4702 context.Context references); context.WithCancelCause in newer subsystems; no documented clock injection or parameterized randomness P16-dapr / T5 (score 1): report:P16-dapr–structure.md: compstore is a leaf package (no deps) — closest to pure; pkg/api/universal/ as shared semantic layer is not pure (calls IO); no systematic functional core/IO separation P16-dapr / T6 (score 2): report:P16-dapr–interfaces.md: channel.AppChannel (app protocol selection), hotreload/loader.Interface (disk vs operator), resiliency.Provider — interfaces at real deployment-mode and replacement boundaries; internal Options struct wiring is concrete P16-dapr / T7 (score 1): report:P16-dapr–api-surface.md: sidecar binary with no importable Go library; extension via pluggable component gRPC protocol (any language can implement); no pkg/action-style embeddable library P16-dapr / T8 (score 2): report:P16-dapr–structure.md: standard Go layout (cmd/ + pkg/); pkg/internal/ for non-export; co-located fake/ and mock/ sub-packages; clean per-service isolation (pkg/placement, pkg/sentry only depended on by their cmd/)

P17-k3s#

P17-k3s / T1 (score 1): report:P17-k3s–interfaces.md: Executor (17 methods) and Driver (14) dominate the interface landscape; smaller Cluster (3) and store.ReadCloser (3) exist but are exceptions; provider-defined large interfaces characterize the primary abstractions P17-k3s / T2 (score 1): report:P17-k3s–patterns.md: executor singleton as package-level var; init() registration via blank import in main.go; managed.RegisterDriver() appends to a package-level slice; contained but structural P17-k3s / T3 (score 1): report:P17-k3s–patterns.md: executor.Set() is the injection point but it writes to a package-level global var — a service locator pattern rather than true constructor injection; large config structs pass deps through the call stack but the central executor is a global P17-k3s / T4 (score 1): report:P17-k3s–patterns.md: functional options WithCACertificate, WithTimeout for HTTP client configuration; context cancellation via signals.SetupSignalContext(); no documented clock injection for time-dependent operations P17-k3s / T5 (score 1): report:P17-k3s–structure.md: pkg/configfilearg/ is a pure preprocessing step; no pure-logic packages beyond that; executor implementation imports upstream Kubernetes app.Run() entry points directly — IO is deeply embedded P17-k3s / T6 (score 2): report:P17-k3s–architecture.md: Executor interface is a deliberate seam isolating k3s orchestration from upstream k8s code; most internal wiring uses concrete large config structs (Control, Node); correct placement of the one major interface P17-k3s / T7 (score 1): report:P17-k3s–api-surface.md: StartupHookArgs/StartupHook and RouterFunc as extension points for downstream builds (RKE2); Executor interface as compile-time seam; no versioned public library API P17-k3s / T8 (score 1): report:P17-k3s–structure.md: no internal/ directory — all packages under pkg/ are technically importable; no import cycle enforcement; package visibility entirely implicit; unusual for a project of this size

P18-helm#

P18-helm / T1 (score 2): report:P18-helm–interfaces.md: PostRenderer (1 method), Getter (1), RESTClientGetter (3) are exemplary minimal interfaces; driver.Driver explicitly decomposed into Creator/Updator/Deletor/Queryor role interfaces; kube.Interface (10) is broad but documented as intentionally wide P18-helm / T2 (score 2): report:P18-helm–architecture.md: no package singletons; cobra.OnInitialize defers storage driver init until command execution; no Viper; no global registries; ConfigurationOption for customization — cleanest T2 in this chunk outside Terraform P18-helm / T3 (score 2): report:P18-helm–architecture.md: Configuration struct as DI container; cobra.OnInitialize deferred init pattern; NewInstall(cfg), NewUpgrade(cfg) constructors receive Configuration explicitly — clear, greppable composition root P18-helm / T4 (score 1): report:P18-helm–patterns.md: sync.Once lazy init for Kubernetes client (lazyClient); With functional options pervasive; no clock injection interface documented; context propagated through action layer P18-helm / T5 (score 2): report:P18-helm–architecture.md: pkg/engine renders Go templates with sprig — pure function, no IO dependency; pkg/storage/driver/memory is a pure in-process store; clear separation of rendering logic from Kubernetes apply logic P18-helm / T6 (score 2): report:P18-helm–interfaces.md: kube.Interface for cluster operation swappability (enables full test suite without a cluster); driver.Driver for storage backend selection; internal rendering and coalescing logic uses concrete types throughout P18-helm / T7 (score 3): report:P18-helm–architecture.md: pkg/action explicitly documented as “a library for calling top-level Helm actions”; imported by Flux, Argo CD, and other ecosystem tools; ConfigurationOption and With* functional options provide stable extension points — textbook embeddable library P18-helm / T8 (score 2): report:P18-helm–architecture.md: internal/ used for plugin runtime and logging; pkg/ exports only intentional surfaces; clean layering (cmd → action → kube/storage/engine); no import cycles reported

P19-istio#

P19-istio / T1 (score 2): report:P19-istio–interfaces.md: XdsResourceGenerator (1 method!) is near-perfect ISP; XdsDeltaResourceGenerator embeds and extends it cleanly; ConfigStore (7), XDSUpdater (6); Collection[T] small generic interface — strong ISP in the xDS layer, slightly wider in the model layer P19-istio / T2 (score 1): report:P19-istio–patterns.md: feature flags registered at init() time via pkg/env.Register*Var() in pkg/features/ packages; xDS generator map populated during InitGenerators(); limited but structural P19-istio / T3 (score 2): report:P19-istio–architecture.md: bootstrap.Server as composition root with a 24-step explicitly ordered init sequence; server.Instance.AddStartFunc() component runner; manual wiring — no DI framework, no service locator P19-istio / T4 (score 1): report:P19-istio–patterns.md: stop-channel lifecycle dominates (538 <-chan struct{} occurrences) over context (341); no documented clock injection; atomic.Value for readiness state; stop channels are ambient lifecycle signals, not parameterized time P19-istio / T5 (score 2): report:P19-istio–patterns.md: PushContext is built as an immutable snapshot per push cycle — generators read it without locks, effectively a pure-read data structure; krt.Collection[T] framework provides declarative reactive transforms as functional pipelines over Kubernetes data P19-istio / T6 (score 2): report:P19-istio–interfaces.md: XdsResourceGenerator plugin map at the xDS extensibility boundary; ConfigStore/ConfigStoreController for backend selection; ServiceDiscovery aggregate for registry multiplexing; internal generator implementations use concrete PushContext snapshots P19-istio / T7 (score 1): report:P19-istio–architecture.md: control plane binary (pilot-discovery); pkg/kube/krt and pkg/kube/kclient are internally used packages; no versioned public library API; not designed for external import P19-istio / T8 (score 2): report:P19-istio–architecture.md: 263 interface definitions in pilot/pkg/model; clean package layering (krt → kclient → model → xds → bootstrap); modular per-concern packages; no import cycles in the core path reported

P20-argo-cd#

P20-argo-cd / T1 (score 2): report:P20-argo-cd–interfaces.md: AppStateManager (3 methods!), Generator (3 methods) are exemplary; ClusterCache (14) and ArgoDB (~40) are wide but cover complete domain contracts; mix of narrow purpose-built and wider repository-style interfaces P20-argo-cd / T2 (score 1): report:P20-argo-cd–patterns.md: 76 init() functions (majority in generated protobuf/Kubernetes client code); non-generated uses register Prometheus metrics at startup; Kubernetes-standard pattern, tolerable but not clean P20-argo-cd / T3 (score 2): report:P20-argo-cd–architecture.md: ArgoCDServerOpts struct as “composition root manifest”; manual wiring in cobra.Command.Run for each service; all dependencies injected at the constructor boundary — explicit and auditable P20-argo-cd / T4 (score 1): report:P20-argo-cd–patterns.md: context propagation pervasive (4094 occurrences); context.WithTimeout used at all I/O boundaries; no documented clock injection; context is the deadline mechanism, not parameterized time P20-argo-cd / T5 (score 1): report:P20-argo-cd–architecture.md: gitops-engine/pkg/diff and pkg/health contain pure diff/health logic (Lua + built-in rules); but these are embedded as a sub-module, not distinctly separated packages; partial isolation rather than systematic P20-argo-cd / T6 (score 2): report:P20-argo-cd–interfaces.md: AppStateManager, LiveStateCache, Kubectl, ResourceTracking at real testability/replacement boundaries; ClusterCache from gitops-engine at the cluster-backend boundary; internal controller uses concrete types for reconcile loop wiring P20-argo-cd / T7 (score 1): report:P20-argo-cd–architecture.md: single binary, multiple personas; no importable Go library; CMP sidecar gRPC protocol and Generator interface enable community extensions; no versioned library API P20-argo-cd / T8 (score 2): report:P20-argo-cd–architecture.md: gitops-engine as embedded sub-module with its own import path; per-service package separation (controller/, server/, reposerver/, applicationset/); some internal/ usage; generally clean boundaries

P21-tekton-pipeline#

P21-tekton-pipeline / T1 (score 3): report:P21-tekton-pipeline–interfaces.md: Requester (1 method), Waiter/Runner/PostWriter (1 each), ResolvedResource (3), dag.Task (2), dag.Tasks (1) — overwhelmingly single-method or narrow; consumer-defined throughout; optional capabilities (TimedResolution, ConfigWatcher) split correctly as ISP sub-interfaces P21-tekton-pipeline / T2 (score 1): report:P21-tekton-pipeline–architecture.md: Knative context-based injection — clients extracted via kubeclient.Get(ctx), taskruninformer.Get(ctx) — is a service-locator pattern through context; init() in generated Kubernetes client code; structurally present even if not pervasive in hand-written code P21-tekton-pipeline / T3 (score 2): report:P21-tekton-pipeline–architecture.md: sharedmain.MainWithConfig as composition root; factory functions taskrun.NewController(opts, clock), pipelinerun.NewController(opts, clock) per controller; explicit, discoverable wiring point; Knative framework provides the runner P21-tekton-pipeline / T4 (score 2): report:P21-tekton-pipeline–interfaces.md: Waiter, Runner, PostWriter are explicit IO abstractions injected into Entrypointer — each wraps a single IO concern (polling semaphore files, executing a subprocess, writing a result file); parameterized IO at the step-execution boundary is textbook T4 applied narrowly but correctly P21-tekton-pipeline / T5 (score 2): report:P21-tekton-pipeline–architecture.md: pkg/reconciler/pipeline/dag has zero Kubernetes dependencies — pure DAG logic tested without any cluster API; pkg/substitution is a pure parameter interpolation package; clear functional core within the reconciler layer P21-tekton-pipeline / T6 (score 2): report:P21-tekton-pipeline–interfaces.md: Resolver interface at the remote source extensibility boundary; Requester at the CRD protocol boundary; SPIRE interfaces (ControllerAPIClient, EntrypointerAPIClient) at the security subsystem boundary; internal DAG and substitution logic uses concrete types P21-tekton-pipeline / T7 (score 1): report:P21-tekton-pipeline–architecture.md: Kubernetes operator binary; Resolver interface is a plugin extension point for community resolvers; no versioned importable library; RunObject/TaskObject interfaces enable CustomRun extensibility but require CRD implementation P21-tekton-pipeline / T8 (score 2): report:P21-tekton-pipeline–architecture.md: Knative-style package layout with explicit pkg/ boundaries; pkg/remoteresolution and legacy pkg/resolution coexist (migration in progress); internal/computeresources for hidden computation; generally disciplined but dual-framework coexistence creates some noise

P22-go#

P22-go / T1 (score 3): report:P22-go–interfaces.md: 1,201 interfaces; dominant 1-method form (io.Reader, io.Writer, io.Closer, fs.FS, Actor); ir.Node=22 methods is justified internal-only; textbook ISP across stdlib P22-go / T2 (score 1): report:P22-go–patterns.md: init()-based command registration in cmd/go (build, test, vet, etc.); runtime package is inherently global state; pprof registers via init()/blank-import side effect P22-go / T3 (score 1): report:P22-go–architecture.md: go tool wires subcommands via init() and package-level command registries; compiler and runtime have no single explicit composition root; wiring scattered across init() calls P22-go / T4 (score 1): report:P22-go–patterns.md: os.Stdin/Stdout ambient throughout the go tool; time.Now() called directly in compiler; testing.TB provides injection in tests only, not in production code paths P22-go / T5 (score 2): report:P22-go–structure.md: compiler front-end (parsing, type-checking) are pure transformations with no I/O; math/, sort/, strings/ stdlib packages are pure; go tool and runtime are inherently I/O-bound P22-go / T6 (score 2): report:P22-go–interfaces.md: stdlib uses 1-method interfaces (io.Reader, io.Writer) at all external boundaries; ir.Node=22 is wide but internal-only; runtime internals use concrete types for hot paths P22-go / T7 (score 3): report:P22-go–api-surface.md: stdlib is the canonical public helper API: io, sync, testing, fmt, encoding, math; api/go1.N.txt formally tracks the public surface; 50+ stdlib packages with integrator affordances P22-go / T8 (score 3): report:P22-go–structure.md: strict internal/ layering enforced by go build tooling itself; no import cycles (test enforced by src/internal/dag); dual module split (std vs cmd); custom src/ layout with clear subsystem boundaries

P23-gin#

P23-gin / T1 (score 2): report:P23-gin–interfaces.md: Binding=2, Render=2, HTMLRender=1 are narrow; IRoutes=15 and ResponseWriter=10+4-embedded are intentionally wide capability declarations that dominate the interface catalog P23-gin / T2 (score 1): report:P23-gin–patterns.md: build-tag init() selects JSON backend (sonic/jsoniter/go_json/default); mutable package-level binding.Validator; global atomic ginMode; these exist in production paths P23-gin / T3 (score 2): report:P23-gin–architecture.md: gin.New() constructor with OptionFunc pattern is a real composition root; but global ginMode and package-level binding.Validator are ambient state alongside it P23-gin / T4 (score 1): report:P23-gin–patterns.md: no explicit time injection; context.Context has exactly 1 occurrence in tests; request/response I/O is ambient via net/http; no injection point for testing without real HTTP P23-gin / T5 (score 2): report:P23-gin–structure.md: binding/ and render/ have format-conversion logic that is partially pure; hot request path (context.go, gin.go) mixes I/O with routing and handler dispatch P23-gin / T6 (score 2): report:P23-gin–interfaces.md: Binding/Render/HTMLRender interfaces at extension boundaries (appropriate); radix tree router (tree.go) is deliberately concrete and non-pluggable for performance predictability P23-gin / T7 (score 2): report:P23-gin–api-surface.md: WrapF/WrapH adapters for stdlib http.HandlerFunc; H map alias; build-tag JSON backend selection; OptionFunc construction-time configuration P23-gin / T8 (score 2): report:P23-gin–structure.md: flat root with public sub-packages (binding/, render/, codec/json/); internal/ contains only bytesconv and fs (two packages); sub-packages have clear single concerns

P24-echo#

P24-echo / T1 (score 3): report:P24-echo–interfaces.md: 7 of 10 non-trivial interfaces have 1 method; Router=4; average ~1.6 methods/interface across the catalog; v5 removed the wide Context interface and made it concrete P24-echo / T2 (score 2): report:P24-echo–patterns.md: NewWithConfig() is the primary constructor with explicit Config struct; no init() registrations observed; sync.Pool for Context is package-level but not a singleton or registry P24-echo / T3 (score 3): report:P24-echo–architecture.md: Echo struct is the explicit composition root; Config holds all swappable slots (Binder, Renderer, Logger, IPExtractor, Router); NewWithConfig() is the discoverable wiring entry point P24-echo / T4 (score 1): report:P24-echo–patterns.md: no explicit time or filesystem injection; signal.NotifyContext for graceful shutdown uses ambient OS signals; no IO injection point separate from net/http P24-echo / T5 (score 1): report:P24-echo–structure.md: framework is inherently I/O-bound (HTTP request/response pipeline); middleware/ handler logic is interleaved with I/O; no isolated pure-logic packages identified P24-echo / T6 (score 2): report:P24-echo–interfaces.md: Binder, Renderer, Logger, Router interfaces at replaceable boundaries; v5 concrete Context eliminates the former 100-method interface; middleware dependencies are concrete P24-echo / T7 (score 2): report:P24-echo–api-surface.md: echotest/ as first-class public testing utility in the library; Config struct for middleware construction; middleware/ as sibling package with clean handler signatures P24-echo / T8 (score 2): report:P24-echo–structure.md: flat structure with clear sibling packages (middleware/, echotest/); no internal/; root-package-as-framework is appropriate for the scope; no import cycles

P25-fiber#

P25-fiber / T1 (score 1): report:P25-fiber–interfaces.md: Ctx interface generated by ifacemaker has 100+ methods — the primary user-facing abstraction is extremely wide; Storage=9, Views=2, StructValidator=1 are narrow but secondary P25-fiber / T2 (score 2): report:P25-fiber–patterns.md: sync.Pool in 15+ locations (package-level performance pattern); no significant init() registration or process-wide singletons; code generation is build-time only P25-fiber / T3 (score 2): report:P25-fiber–architecture.md: New() constructor with Config struct; but three distinct execution paths (regular, custom Ctx, custom pool) mean no single unambiguous composition root P25-fiber / T4 (score 1): report:P25-fiber–patterns.md: fasthttp-based with no explicit time or filesystem injection identified in architecture or patterns reports P25-fiber / T5 (score 2): report:P25-fiber–structure.md: 30 middleware packages are self-contained with no cross-dependencies; internal/memory and internal/storage hold pure data structures; core Ctx handling is I/O-bound P25-fiber / T6 (score 2): report:P25-fiber–interfaces.md: Storage, Views, StructValidator=1 interfaces at external/replaceable boundaries; fasthttp types used concretely in internal hot paths; Adaptor package bridges stdlib handlers P25-fiber / T7 (score 3): report:P25-fiber–api-surface.md: 30 middleware packages as self-contained integrator affordances (each a separate importable package); generic pool/state helpers; rich fiber.App configuration API; Adaptor for stdlib compat P25-fiber / T8 (score 2): report:P25-fiber–structure.md: root as core; 30 middleware as self-contained packages; internal/ for memory/storage/tlstest; no import cycles identified; middleware isolation is a structural strength

P26-buffalo#

P26-buffalo / T1 (score 2): report:P26-buffalo–interfaces.md: render.Renderer=2 (excellent ISP), servers.Server=3, worker.Worker=6 are bounded; but Context=17 is wide and permeates the framework core P26-buffalo / T2 (score 2): report:P26-buffalo–patterns.md: sync.OnceValue for plugin singleton; no init() registration observed; Options struct approach for all major configuration decisions P26-buffalo / T3 (score 2): report:P26-buffalo–architecture.md: Options struct passed to New() makes dependencies explicit; adapters (render, servers, worker, binding, plugins) are named and swappable; no single wiring function unifying all of them P26-buffalo / T4 (score 1): report:P26-buffalo–patterns.md: reflection-based middleware identity detection is fragile; no explicit time, filesystem, or clock injection identified in the architecture P26-buffalo / T5 (score 2): report:P26-buffalo–structure.md: render/ is a standalone importable package with pure format-conversion logic; ports-and-adapters structure isolates some concerns; app struct core mixes I/O with dispatch P26-buffalo / T6 (score 1): report:P26-buffalo–interfaces.md: Context=17 is a massive interface used throughout internal routing; reflection-based middleware skip is fragile with closures; render.Renderer=2 is good at its boundary but is the exception P26-buffalo / T7 (score 2): report:P26-buffalo–api-surface.md: render/ as a standalone importable library; Resource interface for RESTful scaffolding; compile-time assertions for all server adapters P26-buffalo / T8 (score 2): report:P26-buffalo–structure.md: root-package library with clear ports-and-adapters separation; internal/ for private utilities; render/ standalone; no import cycles

P27-beego#

P27-beego / T4 (score 1): report:P27-beego–interfaces.md: Configer interface is injectable as a slot; but global BeeApp and BConfig are ambient; no explicit time/clock or I/O injection at construction P27-beego / T5 (score 2): report:P27-beego–structure.md: async logging via channel-based pipeline is isolated; ORM decorator cache uses pure caching logic; but reflection-based controller routing tightly couples I/O with dispatch P27-beego / T6 (score 1): report:P27-beego–interfaces.md: ControllerInterface=16 is a wide interface used in core dispatch; reflection-based routing is not interface-driven; backend interfaces (Cache, Configer) are appropriate at those boundaries P27-beego / T7 (score 3): report:P27-beego–api-surface.md: massive feature set across four domains (ORM, cache, task scheduling, session, admin HTTP, beego.Run()); rich integrator affordance is the project’s dominant characteristic P27-beego / T8 (score 2): report:P27-beego–structure.md: four-domain split (core/client/server/task); one subdir per backend universally; mock packages co-located; only client/orm/internal/ uses internal/ mechanism; no import cycles

P28-gorm#

P28-gorm / T1 (score 3): report:P28-gorm–interfaces.md: clause.Expression=1, all callback hooks are 1-method; ConnPool=4, logger.Interface=5 are narrow; Dialector=8 is wide but justified (external DB-engine boundary with 8 distinct responsibilities) P28-gorm / T2 (score 2): report:P28-gorm–patterns.md: sync.Map for schema cache is package-level but not init()-registered; copy-on-write DB avoids shared mutable per-request state; no init() registrations identified P28-gorm / T3 (score 3): report:P28-gorm–architecture.md: Open(dialector, config) is the single composition root; dialector, callbacks, logger, and ConnPool all wired there; DB copy-on-write propagates the wired config to all derived sessions P28-gorm / T4 (score 2): report:P28-gorm–interfaces.md: Dialector and ConnPool injected as interfaces at Open(); logger.Interface injectable via gorm.Config; time.Now() usage not explicitly parameterized P28-gorm / T5 (score 3): report:P28-gorm–structure.md: clause/ is a pure SQL AST package with no I/O; schema/ is a pure reflection cache; callbacks/ are pure transformation pipeline steps; error accumulation on DB.Error is logic-only P28-gorm / T6 (score 2): report:P28-gorm–interfaces.md: Dialector=8 and ConnPool=4 interfaces at external DB boundaries (appropriate); clause.Expression=1 at AST boundary; schema/ and internal callback logic use concrete types P28-gorm / T7 (score 2): report:P28-gorm–api-surface.md: G[T] generic API for type-safe query results; functional options for gorm.Config; callback pipeline is expressive but requires domain knowledge to extend correctly P28-gorm / T8 (score 3): report:P28-gorm–structure.md: flat library root with single-concern sub-packages (callbacks/, clause/, schema/, logger/, migrator/); internal/ for LRU cache and stmt_store; no import cycles

P29-sqlc#

P29-sqlc / T1 (score 3): report:P29-sqlc–interfaces.md: ast.Node=1, Parser=3, Analyzer=4 — all consumer-defined and narrow; CachedAnalyzer is a 1-method decorator; ext.Handler is the plugin boundary over grpc.ClientConnInterface P29-sqlc / T2 (score 2): report:P29-sqlc–patterns.md: no init() registration; standard Go layout with no ambient singletons; all plugin invocation via protobuf RPC; errgroup concurrency is explicit in code P29-sqlc / T3 (score 3): report:P29-sqlc–architecture.md: parse → catalog → type-resolve → IR → codegen pipeline stages are explicit; pkg/cli is the sole public surface; errgroup fan-out with GOMAXPROCS bound is discoverable in internal/ P29-sqlc / T4 (score 1): report:P29-sqlc–patterns.md: compiler reads SQL files directly from disk; no explicit filesystem abstraction or time injection; GOMAXPROCS-bounded fan-out is explicit but concurrency is not parameterized P29-sqlc / T5 (score 3): report:P29-sqlc–architecture.md: parse → catalog → IR pipeline stages are pure transformations (input SQL → output IR); protobuf plugin boundary cleanly separates codegen I/O; each stage maps input to output without side effects P29-sqlc / T6 (score 2): report:P29-sqlc–interfaces.md: Parser and Analyzer interfaces at replaceable boundaries (PostgreSQL vs MySQL backends); concrete types for internal catalog, IR nodes, and AST; only external plugin boundary uses interfaces P29-sqlc / T7 (score 2): report:P29-sqlc–api-surface.md: protobuf plugin boundary enables external code generators; pkg/cli as the sole public surface; but depth of compiler internals limits casual integrator affordance P29-sqlc / T8 (score 3): report:P29-sqlc–structure.md: textbook cmd/internal/pkg layout; all logic in internal/; pkg/cli as sole public surface; clean compiler-style layering with no import cycles

P30-viper#

P30-viper / T1 (score 3): report:P30-viper–interfaces.md: Encoder=1, Decoder=1, FlagValueSet=1 (VisitAll), Finder=1, StringReplacer=1 — all 1-method; Codec embeds Encoder+Decoder; FlagValue=4 is the widest and still bounded; ISP textbook P30-viper / T2 (score 1): report:P30-viper–patterns.md: package-level singleton initialized in init(); every global function (Get, Set, ReadInConfig) delegates to singleton; remote/ self-registers via init() on blank import P30-viper / T3 (score 2): report:P30-viper–architecture.md: NewWithOptions() with Option interface is a clean, dependency-explicit composition root; but the global singleton (GetViper()) coexists and is the primary documented usage path P30-viper / T4 (score 2): report:P30-viper–patterns.md: afero.Fs injected via WithFinder/SetFs (not ambient os.FS); io.Reader/io.Writer accepted for ReadConfig/WriteConfigTo; slog.Logger injected via WithLogger option P30-viper / T5 (score 2): report:P30-viper–structure.md: internal/encoding/* codecs are pure format-conversion packages (no I/O); internal/features holds pure bool constants; viper.go mixes waterfall key-lookup logic with filesystem I/O P30-viper / T6 (score 2): report:P30-viper–interfaces.md: afero.Fs interface at filesystem boundary (replaceable for testing); codec interfaces at format boundary; waterfall lookup algorithm (deep() function) uses concrete Go map traversal P30-viper / T7 (score 2): report:P30-viper–api-surface.md: Sub() for scoped instances; FlagValue/FlagValueSet decouple from pflag; io.Reader/Writer for ReadConfig/WriteConfigTo; DefaultCodecRegistry.RegisterCodec for format extension P30-viper / T8 (score 3): report:P30-viper–structure.md: internal/encoding/* for codec implementations; internal/features for build-tag flags; internal/testutil for shared test helpers; remote/ as a separate Go module; no import cycles

P31-cobra#

P31-cobra / T1 (score 3): report:P31-cobra–interfaces.md: one named interface (SliceValue=1 method, consumer-defined for pflag detection); all other contracts are function types (PositionalArgs, CompletionFunc) or stdlib io.Reader/io.Writer — minimal by design P31-cobra / T2 (score 1): report:P31-cobra–patterns.md: package-level globals: EnablePrefixMatching, EnableCommandSorting, EnableCaseInsensitive, EnableTraverseRunHooks; flagCompletionFunctions map (RWMutex-guarded); initializers/finalizers slices P31-cobra / T3 (score 2): report:P31-cobra–architecture.md: consumers wire the command tree via &cobra.Command{…} struct literal + AddCommand() — explicit; Execute() is the single entry point; but lazy injection of help/__complete/completion subcommands in ExecuteC() is not visible at construction P31-cobra / T4 (score 3): report:P31-cobra–patterns.md: SetIn/SetOut/SetErr explicitly inject io.Reader/io.Writer; parent-chain fallback propagates streams to all descendants automatically; ExecuteContext threads context.Context; no ambient I/O in production code P31-cobra / T5 (score 2): report:P31-cobra–structure.md: args.go validators are pure functions (no I/O); flag_groups.go validation is pure; doc/ is a pure tree-traversal package; completion generation and command execution are I/O-bound P31-cobra / T6 (score 3): report:P31-cobra–interfaces.md: one named interface (SliceValue=1) used only for type-detection in completion; pflag.FlagSet is concrete; lifecycle hooks are function fields (Run, PreRun, PostRun) not interface methods; io.Writer only at I/O boundary P31-cobra / T7 (score 3): report:P31-cobra–api-surface.md: MatchAll validator combinator; completion generators (GenBashCompletionV2, GenFishCompletion, GenZshCompletion); SetIn/SetOut/SetErr for test injection; doc/ for docgen; AddTemplateFunc for help customization P31-cobra / T8 (score 2): report:P31-cobra–structure.md: no internal/ by deliberate choice (stable library; all symbols intentionally public); doc/ as a clean one-way dependency subpackage; platform files via filename build constraints; no import cycles

P32-fzf#

P32-fzf / T2 (score 2): report:P32-fzf–patterns.md: manual DI in Run(); no DI framework; EventBox is constructed and passed explicitly; no init() side effects for core wiring P32-fzf / T3 (score 3): report:P32-fzf–architecture.md: Run() in src/core.go is a textbook composition root — explicitly wires EventBox, ChunkList, Reader, Matcher, Terminal, and HTTP Server into a single goroutine-coordinator; single function, all deps assembled P32-fzf / T4 (score 1): report:P32-fzf–patterns.md: custom EventBox for inter-goroutine signaling (no context.Context used); Algo function type as a value parameter isolates variant logic; IO not injected via interface seams P32-fzf / T5 (score 2): report:P32-fzf–structure.md: algo sub-package contains pure search algorithms (FuzzyMatchV1/V2, ExactMatch); Algo type as first-class function value cleanly isolates algorithm variants from the event-driven coordinator P32-fzf / T6 (score 3): report:P32-fzf–architecture.md: ALL internal collaborators are concrete structs (Reader, Matcher, Terminal, Server, ChunkList, EventBox, Slab); Run() wires concrete types directly; interfaces appear only at the TUI backend boundary P32-fzf / T7 (score 1): report:P32-fzf–api-surface.md: exported constructors exist but with no stability guarantee; CLI-only primary interface (custom 177-flag parser); optional minimalist HTTP REST server; no designed embedding surface P32-fzf / T8 (score 1): report:P32-fzf–structure.md: entire application lives in flat src/ (package fzf); no internal/ directory; only 4 sub-packages (algo, tui, util, protector); no meaningful package boundary enforcement

P33-gh#

P33-gh / T1 (score 2): report:P33-gh–interfaces.md: bimodal — per-command consumer-defined iprompter interfaces are 2–4 methods (narrow); service-boundary aggregates Config (17 methods), AuthConfig (13 methods), Prompter (10 methods) are present but justified at stable system seams P33-gh / T2 (score 2): report:P33-gh–patterns.md: manual DI via cmdutil.Factory struct; universal runF injection pattern across 35+ commands; no DI framework; no package-level globals for core logic P33-gh / T3 (score 3): report:P33-gh–architecture.md: factory.New() via lazy closures forms the explicit composition root in internal/ghcmd; all 35+ commands receive every dependency through the Factory; bootstrap sequence is traceable and single-origin P33-gh / T4 (score 2): report:P33-gh–patterns.md: IOStreams (stdin/stdout/stderr) explicitly injected through cmdutil.Factory (IO as parameter); 554 context.Context usages propagate cancellation and deadlines throughout the command pipeline P33-gh / T5 (score 2): report:P33-gh–interfaces.md: per-command local iprompter interfaces narrow each command’s dependency footprint; pkg/cmd/ isolates commands as self-contained units with no cross-command coupling P33-gh / T6 (score 1): report:P33-gh–patterns.md: cmdutil.Factory is a concrete carrier struct; however moq-generated mocks, per-command consumer interfaces, and AuthConfig internal test methods indicate interface-heavy internal collaboration P33-gh / T7 (score 2): report:P33-gh–structure.md: pkg/httpmock and pkg/iostreams are public packages explicitly provided for extension authors writing tests; formal extension system via ExtensionManager.Dispatch() with a public Extension interface P33-gh / T8 (score 3): report:P33-gh–structure.md: standard cmd/internal/pkg layout with internal/ enforcing private packages; pkg/cmd/ is unconventional but deliberate and documented; module boundaries clearly enforced by Go compiler

P34-gitea#

P34-gitea / T1 (score 1): report:P34-gitea–interfaces.md: auth.Method (2 methods, good ISP), indexer interfaces 3–4 methods; notify.Notifier (40+ methods, explicit ISP violation); optional auth source capabilities via type assertion; wide interface at notification seam P34-gitea / T3 (score 1): report:P34-gitea–architecture.md: 24-step explicit InitWebInstalled() sequence shows awareness of ordering; but the sequence wires into global singletons rather than explicit constructor parameters, making it a bootstrap chain not a composition root P34-gitea / T5 (score 1): report:P34-gitea–architecture.md: 4-tier strict layering (modules→models→services→routers) separates concerns by convention; global coupling via setting.* and singletons means layers communicate through ambient state rather than pure function parameters P34-gitea / T6 (score 1): report:P34-gitea–structure.md: strict 4-tier layering passes concrete model types across tiers; but singleton managers and global config dominate; concrete models are present but global state prevents clean concrete-first collaboration P34-gitea / T7 (score 1): report:P34-gitea–structure.md: no pkg/ or explicitly designed public API; single binary with urfave/cli; no embedding surface; no designed integrator helpers P34-gitea / T8 (score 1): report:P34-gitea–structure.md: no internal/ directory at all (by design); 4-tier convention (modules/, models/, services/, routers/) maintained by project convention alone; no mechanical boundary enforcement

P35-gogs#

P35-gogs / T1 (score 2): report:P35-gogs–interfaces.md: consumer-defined narrow interfaces present: context.Store (6 methods), lfsx.Storager (3 methods with compile-time assertion), auth.Provider (5 methods); database.Engine (12 methods) is a legacy wrapping artifact P35-gogs / T3 (score 1): report:P35-gogs–architecture.md: route registration centralized in cmd/gogs/web.go (~700 lines); partially explicit wiring point but global state is accessed directly from handlers without injection P35-gogs / T5 (score 1): report:P35-gogs–structure.md: x-suffix utility packages (iox, strx, osx, urlx) provide some separation of pure utilities from I/O code; thin service layer exists but mixes logic with global state access P35-gogs / T6 (score 2): report:P35-gogs–patterns.md: database.Handle is a concrete struct used as the sole DB collaborator; internal collaboration via concrete model types throughout; no mock-friendly interface abstraction for the data layer P35-gogs / T7 (score 1): report:P35-gogs–structure.md: no designed public library surface; x-suffix packages (iox, strx) serve internal utilities only; no pkg/ or embedding affordances P35-gogs / T8 (score 2): report:P35-gogs–structure.md: cmd/internal layout; x-suffix naming convention provides clear scope signaling; internal/database dominates (61 source files); clear package naming discipline despite no internal/ enforcement

P36-drone#

P36-drone / T1 (score 2): report:P36-drone–interfaces.md: authn.Authenticator (1 method), authz.Authorizer (2 methods), router.Interface (3 methods) are textbook minimal; git.Interface (~50 methods) is a deliberate facade; store interfaces ~20–30 methods each (domain-appropriate width) P36-drone / T2 (score 2): report:P36-drone–architecture.md: Google Wire generates explicit constructors in wire_gen.go with no global state; no package-level mutable state; init() for proxy factory self-registration is contained to a reflect.Type registry P36-drone / T3 (score 3): report:P36-drone–architecture.md: wire.Build() with ~120 WireSets in a single call; wire_gen.go is a compile-time verified composition root that encodes the full dependency graph; any wiring error is a compile error P36-drone / T4 (score 1): report:P36-drone–architecture.md: Wire-injected dependencies provide DI for services and stores; context threading via Wire; no explicit clock abstraction or IO injection beyond constructor parameters P36-drone / T5 (score 2): report:P36-drone–architecture.md: store interfaces separate domain from persistence; service layer over store layer; Redis as event bus cleanly separates event I/O from business logic P36-drone / T7 (score 2): report:P36-drone–structure.md: registry/ as a separate Go module via replace directive; events system with Go generics (cache.Cache[K,V], ReaderFactory[R]); shared pkg/ packages for auth, nathole, transport P36-drone / T8 (score 1): report:P36-drone–structure.md: no internal/ directory; convention-based layering in app/ (handler→controller→service→store); separation maintained by convention, not compiler enforcement

P37-buildkite-agent#

P37-buildkite-agent / T1 (score 2): report:P37-buildkite-agent–interfaces.md: all narrow and consumer-defined — core.APIClient (7 methods, exactly what core needs), jobProcess (6 methods), logger.Logger (9 methods), tracetools.Span (3 methods), logger.Printer (1 method); no wide interfaces observed P37-buildkite-agent / T2 (score 2): report:P37-buildkite-agent–architecture.md: manual DI in agent_start.go; explicit AgentPool→AgentWorker→JobRunner constructor chain; no DI framework; no problematic init() side effects or package-level globals for core logic P37-buildkite-agent / T3 (score 3): report:P37-buildkite-agent–architecture.md: agent_start.go is the explicit composition root; sequential manual constructor chain (AgentPool→AgentWorker→JobRunner); all dependencies passed explicitly; no framework P37-buildkite-agent / T4 (score 1): report:P37-buildkite-agent–interfaces.md: consumer-defined interfaces facilitate injection of all major collaborators; two-process design (agent + bootstrap subprocess) separates concerns at process boundary; no explicit clock injection observed P37-buildkite-agent / T5 (score 2): report:P37-buildkite-agent–architecture.md: two-process design cleanly separates agent lifecycle management from job execution; internal/job.Executor handles bootstrap phases as a distinct concern; clean process-level separation P37-buildkite-agent / T6 (score 2): report:P37-buildkite-agent–architecture.md: AgentPool, AgentWorker, JobRunner are concrete structs used as internal collaborators; Kubernetes variant achieved via jobProcess interface swap at the external seam — concrete-first internally, interface at extension points P37-buildkite-agent / T7 (score 1): report:P37-buildkite-agent–structure.md: core/ package explicitly marked as an unstable public library; otherwise minimal designed public API surface P37-buildkite-agent / T8 (score 2): report:P37-buildkite-agent–structure.md: internal/ enforces private packages; clicommand/ separate from agent/; core/ explicitly scoped as public-but-unstable; clear package boundary discipline

P38-restic#

P38-restic / T1 (score 3): report:P38-restic–interfaces.md: BlobSaver/BlobSaverAsync (1–2 methods); Unwrapper (1 method) with generic AsBackend[B] for type-safe introspection; Layout (5 methods); compile-time assertions throughout; generics for FileType constraints; textbook ISP application P38-restic / T2 (score 2): report:P38-restic–architecture.md: backend registry uses init() blank imports for self-registration only — write-once immutable registry that does not affect test isolation; manual DI throughout; internal/restic imports nothing internal P38-restic / T3 (score 2): report:P38-restic–architecture.md: global.OpenRepository / global.wrapBackend assembles the full backend decorator stack, repository, cache, and index explicitly; clear single wiring function but named “global” rather than a canonical composition root file P38-restic / T4 (score 1): report:P38-restic–architecture.md: Backend interface injection provides a complete IO abstraction (no raw filesystem or network calls above repository layer); context threading present; no explicit clock injection observed P38-restic / T5 (score 3): report:P38-restic–architecture.md: internal/restic imports NO other internal packages — pure domain types and interfaces with zero I/O; internal/crypto is stdlib-only; textbook functional core / IO shell separation enforced by the package dependency graph P38-restic / T6 (score 2): report:P38-restic–architecture.md: backend decorator stack is a concrete struct chain — sema.Backend wraps logger.Backend wraps retry.Backend wraps storage driver; cross-cutting concerns implemented as concrete wrapping types, not additional interfaces P38-restic / T8 (score 3): report:P38-restic–architecture.md: strict enforced layering cmd→global/ui→archiver/restorer→repository→backend→restic; all under internal/; internal/restic at foundation with zero internal imports makes cycles impossible; build-tag-gated optional features (FUSE, debug, self-update)

P39-syncthing#

P39-syncthing / T1 (score 2): report:P39-syncthing–interfaces.md: wide central hubs (model.Model ~30 methods, config.Wrapper ~25 methods, fs.Filesystem ~22 methods); narrow at component seams (config.Committer 2 methods, events.Logger 2+suture, discover.Finder 4 methods, events.Subscription 4 methods) P39-syncthing / T2 (score 2): report:P39-syncthing–architecture.md: all major components behind interfaces with concrete structs unexported; manual DI in lib/syncthing.App.startup(); no DI framework; no package-level globals for core logic P39-syncthing / T3 (score 2): report:P39-syncthing–architecture.md: lib/syncthing.App.startup() is the explicit assembly point; lateAddressLister resolves circular dependency via deferred injection; lib/syncthing as a dedicated assembly package is an explicit architectural concept P39-syncthing / T4 (score 1): report:P39-syncthing–architecture.md: strong context threading via suture supervisor library; config.Wrapper injected at all component seams; no explicit clock injection identified P39-syncthing / T5 (score 2): report:P39-syncthing–structure.md: lib/ holds ~40 public packages with clear domain separation; suture supervisor tree cleanly separates lifecycle management from business logic; 5-tier layering enforced by structure P39-syncthing / T6 (score 1): report:P39-syncthing–architecture.md: all major components’ concrete structs are unexported; ALL cross-component communication is through interfaces; contradicts concrete-first internal collaboration P39-syncthing / T7 (score 3): report:P39-syncthing–structure.md: lib/ (not pkg/) explicitly designed for embedding; lib/syncthing is a dedicated embeddable assembly package; ~40 public packages with stable interfaces; syncthing is intentionally consumable as a library P39-syncthing / T8 (score 2): report:P39-syncthing–structure.md: lib/ + internal/ layout; 5-tier layering (primitives→domain utilities→protocol/network→application core→assembly); clear domain separation across tiers

P40-rclone#

P40-rclone / T1 (score 3): report:P40-rclone–interfaces.md: fs.Fs (5 methods for all 70+ backends); ~25 single-method optional capability interfaces in fs/features.go; march.Marcher (3 methods); compile-time var _ fs.Fs assertions widespread; textbook ISP with optional-capability pattern P40-rclone / T3 (score 1): report:P40-rclone–architecture.md: no explicit composition root; rclone.go is 15 lines that triggers init() chains via blank imports; fs instances created lazily via cache.Get(ctx, remote) on demand; composition is via side effects, not an explicit wiring function P40-rclone / T4 (score 2): report:P40-rclone–architecture.md: fs.Fs interface is the IO injection mechanism — all 70+ backends implement it and are injected via the registry; fs.AddConfig(ctx, ci) / fs.GetConfig(ctx) for per-operation config DI; 3,557 context.Context usages throughout P40-rclone / T5 (score 2): report:P40-rclone–architecture.md: fs/march is pure two-tree walking logic; sync pipeline (checkers→copiers) has clean stage separation via typed channel pipes; Features struct separates capability declaration from implementation P40-rclone / T7 (score 3): report:P40-rclone–structure.md: lib/ (rest, oauthutil, pacer, dircache, http, encoder — all shared utilities for backends); librclone/ C shared library; fstest/fstests/ generic backend conformance test suite reusable by all backends; textbook helper surface P40-rclone / T8 (score 2): report:P40-rclone–structure.md: clear unidirectional layers (cmd→fs→lib, backend→fs→lib, vfs→fs→lib); no internal/ directory but strict layering maintained by convention; no cross-direction imports observed

P41-frp#

P41-frp / T1 (score 2): report:P41-frp–interfaces.md: Connector (3 methods), MessageSender (1 method), client/proxy.Proxy (4 methods), Visitor (3 methods), client/plugin.Plugin (3 methods); server/proxy.Proxy at 11 methods is the outlier (“fat interface syndrome driven by embedding-based pseudo-inheritance”) P41-frp / T2 (score 1): report:P41-frp–patterns.md: init() self-registration for proxy factories (global reflect.Type→factory map) and client plugins (global string→creator map); primary DI via constructor parameters and ServiceOptions is clean; init() registries are present but bounded P41-frp / T3 (score 2): report:P41-frp–architecture.md: server.NewService(v1.ServerConfig) and client.NewService(ServiceOptions{…}) are explicit wiring functions; ResourceController acts as a dependency bundle; two symmetric named composition roots (one per binary) P41-frp / T4 (score 1): report:P41-frp–patterns.md: 114 context.Context occurrences with exemplary propagation; rate.Limiter explicitly injected via BaseProxy for bandwidth; lastPong heartbeat timestamp uses atomic.Value (not an injected clock) P41-frp / T5 (score 2): report:P41-frp–architecture.md: pkg/msg is pure wire protocol types (stdlib only, no I/O); pkg/config/v1 is pure typed config structs; client/control.go and server/service.go mix I/O and logic as expected for network coordination code P41-frp / T6 (score 1): report:P41-frp–patterns.md: BaseProxy concrete struct embedded for shared behavior (work-conn wrapping, encryption, rate limiting); but Connector, MessageTransporter, Proxy, Visitor are all interfaces — broader interface use than external-boundary-only P41-frp / T7 (score 2): report:P41-frp–structure.md: pkg/sdk/client (Go SDK for frps admin REST API); pkg/virtual (VirtualClient for in-process frp tunnels); pkg/vnet (WireGuard L3 overlay); pkg/util/ (extensive network, limit, vhost, wait, log utilities) P41-frp / T8 (score 2): report:P41-frp–structure.md: clear functional decomposition — client/ and server/ have no cross-imports; cmd/→client/|server/→pkg/ dependency direction; pkg/msg as explicit shared protocol boundary; no internal/ directory

P42-headscale#

P42-headscale / T1 (score 2): report:P42-headscale–interfaces.md: AutoApprover(3m), AuthProvider(4m), nodeConnection(5m) are narrow; ControlServer(31m) and TailscaleClient(35m) are god interfaces P42-headscale / T2 (score 1): report:P42-headscale–patterns.md: promauto.NewCounterVec called at package level via promauto init() side effects; architecturally central P42-headscale / T3 (score 3): report:P42-headscale–architecture.md: NewHeadscale() documented as explicit composition root; manual DI; all deps passed via constructor P42-headscale / T4 (score 1): report:P42-headscale–patterns.md: 347 context.Context uses but no clock injection; time.Now() ambient P42-headscale / T5 (score 2): report:P42-headscale–architecture.md: layered monolith; some domain separation but no pure-logic packages isolated from IO P42-headscale / T6 (score 1): report:P42-headscale–interfaces.md: ControlServer(31m) and TailscaleClient(35m) suggest broad interface use beyond just external seams P42-headscale / T7 (score 1): report:P42-headscale–api-surface.md: gRPC/REST/CLI API only; no dedicated embedding API or test helper packages P42-headscale / T8 (score 1): report:P42-headscale–structure.md: no internal/; hscontrol/ is main package; layered by convention only

P43-tailscale#

P43-tailscale / T1 (score 3): report:P43-tailscale–interfaces.md: consumer-side interface definitions confirmed: ipnLocalBackend defined in ssh/ consuming ipnlocal; Observer(1m), StateStore(2m), Extension(3m) are narrow; pattern explicitly used P43-tailscale / T2 (score 1): report:P43-tailscale–patterns.md: feature.Hook registers in init() for optional subsystem feature registration; architecturally central P43-tailscale / T3 (score 2): report:P43-tailscale–architecture.md: tsd.System is explicit DI container; explicit wiring partially undermined by init()-based feature.Hook registrations P43-tailscale / T4 (score 2): report:P43-tailscale–patterns.md: logger.Logf injected as func parameter (DI via function type); context pervasive; no clock injection P43-tailscale / T5 (score 2): report:P43-tailscale–interfaces.md: net/dns.OSConfigurator(4m) at OS boundary; some pure packages; mixed overall at this scale P43-tailscale / T6 (score 1): report:P43-tailscale–patterns.md: feature.Hook adds implicit indirection between internal subsystems; some interface-everywhere patterns P43-tailscale / T7 (score 3): report:P43-tailscale–api-surface.md: tsnet library is rich public embedding API; dedicated client/local library surface; textbook integrator-facing design P43-tailscale / T8 (score 1): report:P43-tailscale–structure.md: minimal internal/; flat public namespace; feature/ build flags

P44-wireguard-go#

P44-wireguard-go / T1 (score 3): report:P44-wireguard-go–interfaces.md: only 5 interfaces total; BindSocketToInterface(2m) and PeekLookAtSocketFd(2m) are capability extension interfaces; “minimum necessary abstraction” is stated philosophy P44-wireguard-go / T2 (score 3): report:P44-wireguard-go–patterns.md: no init() side effects documented; no package-level singletons; 5 direct deps; no promauto/registry patterns P44-wireguard-go / T3 (score 3): report:P44-wireguard-go–architecture.md: NewDevice(tun tun.Device, bind conn.Bind, logger *Logger); textbook 3-parameter composition root; nothing hidden P44-wireguard-go / T4 (score 2): report:P44-wireguard-go–patterns.md: tun.Device and conn.Bind are injected IO interfaces; //go:linkname fastrandn is ambient randomness (not injected); no clock injection P44-wireguard-go / T5 (score 3): report:P44-wireguard-go–structure.md: ratelimiter/, replay/, tai64n/ packages have zero intra-project deps; purely algorithmic; no IO P44-wireguard-go / T6 (score 3): report:P44-wireguard-go–architecture.md: no interfaces between client→Sublist→Account within server package; interfaces only at tun.Device and conn.Bind IO seams P44-wireguard-go / T7 (score 2): report:P44-wireguard-go–api-surface.md: tun/tuntest and conn/bindtest provide in-memory test doubles; clear embedding story; no dedicated examples package P44-wireguard-go / T8 (score 2): report:P44-wireguard-go–structure.md: no internal/ (deliberate: library-first); clean package layout device/tun/conn/ratelimiter; no import cycles

P45-delve#

P45-delve / T1 (score 2): report:P45-delve–interfaces.md: MemoryReader(1m), LocationSpec(1m), service.Server(2m) are narrow; service.Client(~50m) is a god interface; Thread(10m) and Registers(8m) are wider P45-delve / T2 (score 2): report:P45-delve–patterns.md: sync.Once for CPU feature detection is justified one-time init; no architectural init() side effects; vendor/ present but unrelated P45-delve / T3 (score 3): report:P45-delve–architecture.md: execute() is the documented composition root; manual Config struct wiring; 4-layer system CLI→Service→Debugger→Proc all wired explicitly P45-delve / T4 (score 1): report:P45-delve–patterns.md: ~10 context.Context uses (minimal, intentional for debugger domain); no clock or IO injection P45-delve / T5 (score 3): report:P45-delve–structure.md: pkg/dwarf and pkg/proc have no service layer deps; service/ imports from pkg/ but not vice versa; clean directional layering P45-delve / T6 (score 2): report:P45-delve–interfaces.md: ProcessInternal extends Process via interface; some excess interface use; mostly appropriate P45-delve / T7 (score 1): report:P45-delve–api-surface.md: JSON-RPC 2.0 + DAP; embeddable in principle but no dedicated embedding/test API P45-delve / T8 (score 3): report:P45-delve–structure.md: Standard Go Layout cmd/pkg; service/ layer distinct from pkg/; clean pkg/dwarf, pkg/proc, pkg/proc/amd64 decomposition

P46-air#

P46-air / T1 (score 3): report:P46-air–interfaces.md: only 2 project-owned interfaces: exiter(1m) for test seam, Streamer(5m) for I/O; no unnecessary interfaces P46-air / T2 (score 3): report:P46-air–patterns.md: no init() side effects; single Engine struct owns all state; atomic.Bool for state; no package singletons P46-air / T3 (score 3): report:P46-air–architecture.md: Engine struct created in main.go; all deps via struct fields; clear single wiring point P46-air / T4 (score 1): report:P46-air–patterns.md: zero context.Context usage; custom channels for cancellation; FileWatcher interface exists but no clock injection P46-air / T5 (score 1): report:P46-air–structure.md: flat single runner/ package; logic and IO mixed in same package; no pure-logic isolation P46-air / T6 (score 3): report:P46-air–interfaces.md: only exiter(1m) and Streamer(5m); all other internal collaborators are concrete structs P46-air / T7 (score 1): report:P46-air–api-surface.md: application binary only; no public library or embedding API P46-air / T8 (score 1): report:P46-air–structure.md: no internal/; flat root-level main.go + runner/ package; minimal boundary discipline

P47-pop#

P47-pop / T1 (score 3): report:P47-pop–interfaces.md: 11 single-method lifecycle callbacks (BeforeSaveable, AfterCreateable, etc.); TableNameAble(1m), PaginationParams(1m); textbook optional extension interfaces P47-pop / T2 (score 1): report:P47-pop–patterns.md: dialect factories registered via init() in each dialect_*.go; global Connections map; var Debug bool; var ConfigName string P47-pop / T3 (score 1): report:P47-pop–patterns.md: NewConnection() exists but init()-based dialect auto-registration distributes composition; global Connections map populated by LoadConfigFile() P47-pop / T4 (score 1): report:P47-pop–patterns.md: time used for created_at/updated_at (likely time.Now() internal); no clock injection; context propagation via contextStore but not injected P47-pop / T5 (score 1): report:P47-pop–structure.md: root package is dense hub (72 .go files); sub-packages (columns/, slices/) are somewhat pure but root mixes IO and domain logic P47-pop / T6 (score 1): report:P47-pop–interfaces.md: dialect(~21m) and store(18m) are wide internal interfaces; core collaboration is interface-based internally P47-pop / T7 (score 2): report:P47-pop–api-surface.md: well-documented fluent Connection/Query API; public columns/, slices/, associations/ packages; genny/ for scaffolding P47-pop / T8 (score 1): report:P47-pop–structure.md: internal/defaults and internal/randx are minimal; root package has 72 files; no strong boundary discipline

P48-pocketbase#

P48-pocketbase / T1 (score 2): report:P48-pocketbase–interfaces.md: Mailer(1m), RecordProxy(2m), Resolver(1m), optional extensions MaxBodySizeCalculator/SetterFinder(1m each) are narrow; core.App(~150m) is the acknowledged god interface P48-pocketbase / T2 (score 1): report:P48-pocketbase–patterns.md: core.SystemMigrations.Register() in init(); Fields registry populated via optional init() registration; architecturally central P48-pocketbase / T3 (score 3): report:P48-pocketbase–architecture.md: examples/base/main.go is canonical composition root; pocketbase.New() wires all components; core.App passed explicitly to every subsystem P48-pocketbase / T4 (score 2): report:P48-pocketbase–interfaces.md: Mailer and blob.Driver interfaces mean IO is injectable; 197 context.Context uses; no clock injection P48-pocketbase / T5 (score 2): report:P48-pocketbase–structure.md: tools/ sub-packages (hook, store, types, tokenizer, search) are pure utilities; core/ mixes DB and domain logic P48-pocketbase / T6 (score 1): report:P48-pocketbase–patterns.md: core.App(~150m) passed as the single dependency everywhere; every package depends on the fat interface rather than concrete types P48-pocketbase / T7 (score 3): report:P48-pocketbase–api-surface.md: examples/base as canonical library reference; tests/ fixtures; hook-based plugin system; rich Go embedding story P48-pocketbase / T8 (score 2): report:P48-pocketbase–structure.md: no internal/ (deliberate for embeddability); clear core/apis/forms/plugins layering; tools/ as utility library; good discipline

P49-nats-server#

P49-nats-server / T1 (score 2): report:P49-nats-server–interfaces.md: Authentication(1m), DeleteBlock(2m), WAL(12m) are narrow; RaftNode(53m) and StreamStore(44m) are justified-wide system ports; bimodal distribution P49-nats-server / T2 (score 3): report:P49-nats-server–patterns.md: no init() side effects; CONTRIBUTING.md explicitly discourages new deps; Server struct owns all state; no package singletons P49-nats-server / T3 (score 3): report:P49-nats-server–architecture.md: NewServer(opts *Options) is the explicit composition root; ~300-line function; all state visible in Server struct fields P49-nats-server / T4 (score 2): report:P49-nats-server–dependencies.md: internal/fastrand avoids global mutex; Logger is injectable interface; no clock injection P49-nats-server / T5 (score 3): report:P49-nats-server–structure.md: server/stree, server/avl, server/gsl, server/ats, server/thw are pure data-structure/algorithm packages; conf/ is pure parser; no IO in these packages P49-nats-server / T6 (score 3): report:P49-nats-server–architecture.md: deliberate: no interface indirection between client/Sublist/Account on hot paths; interfaces only for StreamStore/ConsumerStore/RaftNode at behavioral-substitution seams P49-nats-server / T7 (score 2): report:P49-nats-server–api-surface.md: server package exported for embedding; NewServer/InProcessConn/HTTPHandler; test/ black-box package; functional but not elaborate P49-nats-server / T8 (score 3): report:P49-nats-server–structure.md: internal/ for OCSP/LDAP/fastrand (security primitives); server/ sub-packages for algorithms; clear OS-portability via build tags in pse/ and sysmem/

P50-temporal#

P50-temporal / T1 (score 3): report:P50-temporal–interfaces.md: dynamicconfig.Client(1m), Authorizer(1m), ClaimMapper(1m), hsm.Environment(2m), StateMachineDefinition(4m) are narrow and consumer-defined; architectural migration from MutableState(80m) to narrow HSM interfaces is ongoing P50-temporal / T2 (score 2): report:P50-temporal–architecture.md: fx DI removes need for init() globals; hsm.Registry registration via fx.Invoke not init(); 2,555-file codebase makes certainty partial P50-temporal / T3 (score 3): report:P50-temporal–architecture.md: temporal/fx.go TopLevelModule + fx.New() is explicit; nested fx.App per service; everything wired via providers; file:temporal/fx.go P50-temporal / T4 (score 3): report:P50-temporal–patterns.md: goro.AdaptivePool backed by injectable clock.TimeSource; 8,416 context.Context references; common/clock package; textbook time injection P50-temporal / T5 (score 3): report:P50-temporal–patterns.md: common/tasks, common/goro, common/backoff, common/collection are pure logic; service/history/hsm has pure state machine logic separated from IO P50-temporal / T6 (score 1): report:P50-temporal–architecture.md: fx DI means every component is declared as interface in fx.In structs; internal collaborators are interface-typed by framework convention P50-temporal / T7 (score 3): report:P50-temporal–api-surface.md: temporal/ package for embedding; temporaltest/ for test servers; WithAuthorizer/WithDynamicConfigClient functional options; textbook integrator API P50-temporal / T8 (score 2): report:P50-temporal–structure.md: no internal/ (deliberate for embeddability); 60+ packages under service/history/api/ (one per RPC handler); clear layering; good discipline

P51-crush#

P51-crush / T1 (score 2): report:P51-crush–interfaces.md: PublisherT and SubscriberT are textbook narrow generics; MessageItem hierarchy (Identifiable 1m, Animatable 2m, Expandable 1m) is narrow; Workspace(~41m) is acknowledged facade P51-crush / T2 (score 3): report:P51-crush–architecture.md: all code under internal/; no init() side effects; App struct owns all state; no package singletons documented P51-crush / T3 (score 3): report:P51-crush–architecture.md: setupWorkspace() + app.New() is explicit composition root; manual DI throughout; all deps wired via constructor injection P51-crush / T4 (score 2): report:P51-crush–patterns.md: 584 context.Context uses; proper ticker/ctx.Done() patterns for cancellation; no explicit clock injection; IO is cancellable P51-crush / T5 (score 2): report:P51-crush–structure.md: internal/csync (pure generics), internal/pubsub (pure generics), internal/stringext, internal/filepathext are pure; agent loop is inherently IO-heavy P51-crush / T6 (score 2): report:P51-crush–interfaces.md: domain service interfaces (session.Service, message.Service) exist mainly for testability; coordinator receives them as constructor params; reasonable internal use P51-crush / T7 (score 1): report:P51-crush–structure.md: everything under internal/; no public library surface; REST API over Unix socket exists but is not a Go library P51-crush / T8 (score 3): report:P51-crush–structure.md: aggressive internal/ usage for all ~50 packages; no accidental public API; textbook package visibility discipline for an application binary

Score Distribution Summary#

Top composites: P03-etcd (22), P44-wireguard-go (21), P49-nats-server (21), P05-grafana (20), P28-gorm (20), P50-temporal (20).

Bottom composites: P34-gitea (6), P11-minio (8), P27-beego (9), P17-k3s (9), P35-gogs (9).

T3 (composition root) is the strongest trait — mode 3, only 1 project scoring 0. T4 (injected effects) is the weakest — mode 1, only 3 projects scoring 3. T2 and T4 together are the structural predictors of testability most worth examining in the synthesis pass.

Per-Trait Commentary#

T1 — Narrow consumer-side interfaces#

T1 is one of the strongest traits in the corpus: 17 of 51 projects score 3 and only 2 score 0, with a mode of 2. The canonical exemplars at score 3 span the full spectrum of Go OSS — the standard library itself (P22-go) with io.Reader/io.Writer, infrastructure tools (P03-etcd, P38-restic, P40-rclone), HTTP frameworks (P24-echo post-v5 refactor), and micro-focused libraries (P30-viper’s 1-method codec interfaces, P31-cobra’s function-type-over-interface approach). rclone is particularly notable for combining a 5-method fs.Fs core with ~25 single-method optional capability interfaces — a “narrow spine, optional extensions” pattern that enables 70+ backend implementations without widening the core contract.

The two 0-scoring projects are instructive contrasts. Beego (P27) has wide interfaces throughout its four-domain framework by design; every consumer-facing abstraction is a service facade. fzf (P32) scores 0 for the opposite reason: it uses no narrow interfaces at all — only two wide TUI backend interfaces for rendering. Both are valid design choices for their domains, but neither practices consumer-side narrowness. The bimodal projects (score 2) typically have narrow interfaces in most subsystems but retain wide facades at explicit system boundaries — Kubernetes, CockroachDB, Grafana, Syncthing all follow this pattern. This is arguably correct ISP applied at scale: a boundary-crossing contract may legitimately have many methods while individual collaboration seams stay narrow.

T2 — No globals / no init() side effects / no package singletons#

T2 is the most polarized trait. The 0-scoring projects (P11-minio, P27-beego, P34-gitea, P35-gogs, P40-rclone) share a defining pattern: init()-driven plugin or backend self-registration that populates global state before main() runs — minio’s globalIAMSys/globalObjectAPI cluster, gitea’s 196 init() functions and GetManager() singletons, rclone’s fs.Registry populated by every backend. These are not oversights; they are architectural commitments to init()-based extensibility. The 7 projects scoring 3 (P03-etcd, P05-grafana, P10-fyne, P44-wireguard-go, P46-air, P49-nats-server, P51-crush) are architecturally diverse but share the absence of any registry or registration pattern driven by side effects.

The modal score is 1–2, confirming that some degree of init() usage is nearly universal in Go OSS: Prometheus registers its SD plugins via init(), Kubernetes populates the global Scheme via 827 init() calls, Cobra has package-level behavior flags, viper exposes a global singleton. Most projects treat init() as an acceptable price for the extensibility it enables. The T2=3 projects demonstrate that extensibility does not require init() — but avoiding it requires deliberate architectural decisions made early. Projects that started as embedded libraries (wireguard-go, fyne) or that were built recently with clean-architecture goals (crush, air) find it easier to maintain the discipline than projects that grew large before the discipline was established.

T3 — Explicit composition root#

T3 is the strongest single trait in the corpus: 24 of 51 projects score 3, and all but 8 projects score at least 2. Only P27-beego scores 0 (global BeeApp singleton operated by beego.Run()). The 7 projects scoring 1 (P11-minio, P17-k3s, P22-go, P34-gitea, P35-gogs, P40-rclone, P47-pop) each combine a partial wiring sequence with global state that undermines the explicit root — serverMain() flows into globals rather than constructors, executor.Set() writes to a package-level var, Go’s tool wires via init() registries.

The range of composition-root implementations is striking: wireguard-go’s 3-parameter NewDevice() is the smallest composition root in the corpus; cockroach’s NewServer() at ~1200 lines and Grafana’s generated wire_gen.go at 1939 lines are the largest. Drone uses Google Wire to make the root a compile-time artifact rather than runtime code. fzf’s Run() function explicitly wires 6 concrete collaborators in a single function that is also the goroutine coordinator. These all score 3 because the explicit wiring point is discoverable — a developer can grep for it and trace all dependencies from one place. This trait is well-understood and broadly practiced; the failures tend to be historical artifacts (init()-based registration predating the project’s current scale) rather than deliberate anti-patterns.

T4 — Time / IO / randomness as parameters#

T4 is the weakest trait in the corpus. The modal score is 1 (32 of 51 projects), with only 5 projects scoring 3. Two projects score 0 (P34-gitea, P35-gogs) where even context propagation is absent. The 5 projects scoring 3 are P01-kubernetes, P02-moby, P09-cockroach, P31-cobra, and P50-temporal. These five share a specific pattern: each explicitly parameterizes multiple external effect types, not just context. Temporal has a common/clock package with an injectable TimeSource; cobra uses SetIn/SetOut/SetErr to inject all three standard streams; kubernetes and moby thread effects through constructor parameters at scale; cockroach uses HLC and injects IO through Engine/Reader/Writer interfaces.

The root cause of the corpus-wide weakness is that context.Context normalizes deadline/cancellation injection but leaves clock, filesystem, and randomness ambient. Most projects inject context (scoring them at 1 rather than 0) but don’t extend the discipline to other effect types. The projects that do — typically by having a single team member who cares about hermetic testing — achieve noticeably better test isolation. This trait is the synthesis pass’s highest-value input: T4 scores are the best structural predictor of testability without reading any testing report.

T5 — Functional core / pure-logic isolation#

T5 has a moderate mode of 2, with 9 projects scoring 3 and 15 scoring 1. The 3-scoring projects (P03-etcd, P05-grafana, P28-gorm, P29-sqlc, P38-restic, P44-wireguard-go, P45-delve, P49-nats-server, P50-temporal) share a key structural property: they have at least one subsystem where the package dependency graph mechanically prevents IO imports. Etcd’s raft/v3 module imports no network code; restic’s internal/restic imports nothing internal; wireguard-go’s ratelimiter/replay/tai64n packages have zero intra-project dependencies; sqlc’s parse→catalog→IR pipeline produces outputs from inputs without side effects; temporal’s common/* packages are pure domain logic.

The 15 projects scoring 1 share the inverse property: the domain logic lives in a package that also owns IO (minio’s 453-file cmd package, gitea’s global setting.* pattern, caddy’s inherently effectful module design, fyne’s vertically-organized rendering layers). HTTP frameworks (echo, caddy, traefik partial) and GUI frameworks (fyne) naturally score 1 here because their core abstraction — handling a request or rendering a frame — is inherently an IO operation. Scoring 1 in T5 is not a failure for these projects; it reflects domain constraints. The synthesis pass should account for this domain confound when correlating T5 with testability.

T6 — Concrete internal collaborators#

T6 is intentionally contrarian and produces the most interesting distribution: 7 projects score 3, 2 score 0, and the mode is 2. The 3-scoring projects split philosophically: wireguard-go, nats-server, air, and fzf score 3 because performance or simplicity is the driver — they explicitly avoid interface indirection on hot paths. Etcd, grafana (via Wire), and cobra score 3 through different reasoning — etcd’s concrete decorators, Grafana’s Wire-validated concrete service implementations, cobra’s function-field approach to lifecycle hooks.

The 2 projects scoring 0 are drone (Wire generates interface-typed dependencies everywhere) and rclone (fs.Fs/fs.Object/fs.DirEntry are the primary abstractions throughout). These are not pathological mock-everything architectures; they are systems where interface ubiquity is architecturally motivated. The 13 projects scoring 1 include kubernetes (2,498 interface definitions, type-assertion capability discovery), cockroach (1,481 interface definitions at internal seams), and syncthing (all concrete structs unexported, all cross-component communication through interfaces). The synthesis pass will be most interesting for this trait: T6=1 projects that nonetheless test well are the strongest counter-argument to “you need concrete collaborators for good testability.”

T7 — Public helper / builder API surface#

T7 is the most application-type-dependent trait: the two 0-scoring projects (P09-cockroach, P38-restic) are deliberately library-free application binaries. A score of 0 here reflects a principled design decision rather than an oversight. The 14 projects scoring 3 span library-first designs (P22-go stdlib, P10-fyne widget library, P13-vault SDK, P18-helm pkg/action, P25-fiber middleware packages, P43-tailscale tsnet, P50-temporal temporaltest/) and application binaries that chose to expose embeddable surfaces (P08-caddy’s xcaddy model, P31-cobra’s test injection helpers, P27-beego’s four-domain affordances, P39-syncthing’s lib/ design, P48-pocketbase’s examples/base pattern).

The modal score of 2 indicates that most mature OSS projects export at least a functional-options API or a client module, even when not primarily designed as libraries. The 1-scoring cluster includes infrastructure operators (istio, argo-cd, tekton-pipeline, dapr) that are binary applications for Kubernetes clusters rather than importable libraries — their T7=1 is correct and expected. The interesting T7 insight for the book is the correlation between explicit T7 investment and ecosystem adoption: vault’s SDK, helm’s pkg/action, and kubernetes’ staging modules are all direct contributors to those projects’ ecosystem breadth.

T8 — Package boundary discipline#

T8 has the strongest floor in the corpus: no project scores 0. This reflects the Go compiler’s assistance — even projects with flat layouts avoid import cycles by default. The 13 projects scoring 3 split between compiler-tooling-style projects (P22-go, P28-gorm, P29-sqlc, P45-delve) that use textbook cmd/internal/pkg layouts, and systems projects (P03-etcd, P08-caddy, P10-fyne, P14-terraform, P49-nats-server, P51-crush) that enforce visibility via aggressive internal/ usage. Restic (P38) and gh (P33) also score 3: restic’s enforced layering (all under internal/ with internal/restic importing nothing) and gh’s standard layout with documented reasoning for pkg/cmd/ unconventionality.

The 11 projects scoring 1 (P04-prometheus, P06-hugo, P07-traefik, P11-minio, P17-k3s, P32-fzf, P34-gitea, P42-headscale, P43-tailscale, P46-air, P47-pop) share flat or convention-only layouts without internal/ enforcement. This is not uniformly bad — cobra deliberately exposes all symbols publicly as a stable library, fzf’s flat src/ reflects its small scope, and tailscale’s flat namespace is a size-management challenge rather than a design philosophy. Modal score is 2: clear internal/ discipline with mostly clean layering. The synthesis pass should note that T8 is the least informative testability predictor since it primarily measures structural visibility rather than the seam quality that testability requires.

Confidence Note#

Composite verification: All 51 composites re-summed T1..T8 from chunk values. No discrepancies found.

Project coverage: All 51 rows present exactly once. P10 is fyne (P10-influxdb excluded per corpus rules — InfluxDB 3 is a Rust rewrite). No duplicates or omissions.

Hardest-to-assign scores (cross-chunk):

• T4 (modal=1) versus T4=0: Every chunk flagged T4 as the hardest borderline call. Projects with context propagation but no other injected effects score 1. Projects with zero context and zero effect injection (gitea, gogs) score 0. The 1/0 boundary should be treated as uncertain for ~8 projects.

• T5 (1 vs 2 for partial-pure projects): consul, nomad, dapr, argo-cd, k3s, and headscale all have one or two pure utility packages but no systematic functional-core discipline. All scored 1. A reader emphasizing the pure packages over the dominant IO-mixed pattern might score these 2. Uncertainty is ±1 for these projects.

• T6 for Wire-driven projects (drone, temporal): P36-drone scores 0 (Wire interfaces throughout, contradicting concrete-first) and P50-temporal scores 1 (fx framework mandates interface-typed dependencies). Both scores follow the rubric literally. A reader who views “Wire/fx forces this style” as a domain confound rather than an architectural signal might score these higher. Flagged per rubric instruction.

• P05-grafana T6=3: Grafana domain service interfaces (~20 methods each) introduce some abstraction at non-external boundaries. Wire-validated explicit dependencies and concrete internal implementations support the 3, but domain-service interfaces are a borderline case. Alternative reading: score 2.

• P09-cockroach T7=0: CockroachDB is a deployed binary application. The 0 is correct but will look like a gap in cross-project scatter plots. Synthesis pass should annotate this explicitly.

• P38-restic T7=0: Same situation — principled no-library design decision, not a gap.

• Chunk 2 T6 cluster (score 2 for all 11 projects, P11-P21): Every infrastructure/operator project in chunk 2 scored 2 on T6. This uniformity is genuine: all practice “interfaces at real boundaries, concrete internals” to the same degree. The synthesis pass should verify whether this cluster correlates with the testability scores of this cohort.

• T4 scores for domain-constrained projects: fyne (T4=1) deliberately avoids context threading because GUI main-thread constraints demand a different model. delve (T4=1) uses minimal context because debuggers attach synchronously. Both scores are accurate per rubric but architecturally misleading if read as “poor design.” The synthesis pass should account for domain constraints when interpreting T4 correlation with testability.

Chunk confidence summary:

• Chunk 1 (P01-P10): high confidence; 7 non-testing reports per project read
• Chunk 2 (P11-P21): medium-high confidence; T4=1 across 9 of 11 projects is likely accurate but low-information
• Chunk 3 (P22-P31): medium-high confidence; P27-beego T5=2 is the most uncertain call
• Chunk 4 (P32-P41): high confidence; borderline calls documented in chunk confidence note
• Chunk 5 (P42-P51): high confidence; wireguard-go and nats-server are the highest-confidence 3-scores in the corpus