Self-assembly infers capabilities from the registry, not a hardcoded list (#44)

[minerva-sky]

Closes #44.

AgentAssemblyEngine#infer_capabilities_from_description matched task text against a literal list of 11 names. Only 4 of the 7 built-in capabilities were on it, 7 of the 11 names were never registered, and the list said structure_extraction where the registry says structured_extraction. A capability a downstream gem registered could never be inferred by the default (non-LLM) strategy, which is the one Agentic.assemble_agent and agentic agent build ship with.

What changes

• Candidates come from the registry. The loop runs over @registry.list.each_key, which is how LlmAssistedCompositionStrategy already works. The literal array is gone.
• Matches need a word boundary. With the whole registry as the candidate set, a two-letter name must not match inside another word: db no longer fires on "feedback", ai no longer fires on "maintain". The literal, space-separated, and stem forms all require \b now.
• No duplicate selection. DefaultCompositionStrategy#select_capabilities skipped a dependency that was already selected but not a top-level requirement that an earlier dependency had already pulled in, so text_generation landed twice for "Analyze the data and generate code". Guarded.

No public signature changes. Assembled-agent output changes for descriptions that mention a registered capability, which is the point; CHANGELOG entry under Changed.

Tests

7 new examples in spec/agentic/agent_assembly_engine_spec.rb: the four descriptions from the issue select summarization, brainstorming, structured_extraction, and a spec-registered invoice_parsing; unregistered names (uml_generation, dependency_analysis) are never inferred; empty registry degrades to text_generation; word-boundary negative and positive cases; dedupe. Full suite: 1397 examples, 1 failure, the event_dispatcher_integration_spec.rb:291 timing flake that #36 addresses.

Touches the same file as #53 but different regions (that PR seeds planned capabilities above the inference call; this one changes the inference body), so they should merge in either order.

Panel

• DHH — cleared. Nits taken: each_key instead of keys.each. Verified the comment's claim that the LLM strategy reads registry.list (llm_assisted_composition_strategy.rb:23).
• Obie Fernandez — objected, then cleared on revision + rebuttal. Objection (3/3): widening from 11 fixed names to the whole registry lets free text pull in any side-effecting capability a downstream gem registers, through a substring matcher with no word boundaries. Fixed the boundary half. Rebutted the rest: selection is not execution (build_agent only calls add_capability; nothing in lib/ dispatches a capability from LLM output, a consumer calls execute_capability explicitly), and the LLM strategy and the explicit input[:capabilities] path already accept any registered name. Re-run 2/3 cleared; the dissent wants an importance floor on stem matches, which I'd take as a follow-up if a tool-calling loop ever lands.
• Vladimir Dementyev — cleared. list is an in-memory walk over under ten entries, called up to four times per analysis; not worth hoisting.
• The gem consumer — cleared. Private method, unchanged signatures, persisted agents are not re-inferred on load. Took the suggestion to file the CHANGELOG entry under Changed rather than Fixed.

🤖 Generated with Claude Code