Module modules 

§2 “The Bolt-on Capability Taxonomy” (docs/composable-harness/ COMPOSABLE-HARNESS-DESIGN.md) — P3 of the composable-harness migration (design §5.2, phase P3: “A ModuleId enum (the 35 names) + resolved activation set on Config”).

ModuleId names all 35 §2 modules exactly as the table numbers them (1-35). ModuleActivation is the resolved activation set — “module activation is pure config → set, testable without the loop” (§5.3 risk 2’s mitigation): ModuleActivation::from_harness computes it from a crate::configfile::HarnessConfig alone, no crate::Agent required.

Schema-collapse note. Two of the 35 §2 rows have no independent [capabilities.<name>] table of their own in the §3.1 schema — they are represented as a field of a SIBLING module’s table instead:

• module 10 permissions.approvals is [capabilities.permissions]’s own enabled flag (the approval = "…" mode lives in the same table as modules 11-13’s parent, not a nested approvals sub-table) — ModuleId::PermissionsApprovals reads capabilities.permissions.enabled.
• module 16 mcp.server is [capabilities.mcp].serve (a bool field, not a nested table with its own enabled) — ModuleId::McpServer reads that field directly.

Every other module maps onto exactly the crate::configfile::MODULE_NAMES / crate::configfile::NESTED_MODULE_NAMES key P2 already resolves.

Structs

ModuleActivation

The resolved activation set for all 35 modules (§5.2 P3: “a resolved activation set on Config”) — pure HarnessConfig → set, no loop required (§5.3 risk 2’s testability mitigation). Also carries tools_search’s three per-tool sub-flags, since crate::tools::ToolRegistry::from_config needs them to decide which of glob/search/list_dir to register — and (P4c) tools_web’s two, for web_fetch/web_search.

Enums

ModuleId

The 35 §2 capability modules, numbered exactly as the design’s module table (§2, rows 1-35).