Learning::CapabilityOptimizer: 613 lines in the 0.2.0 release notes that Learning.create never builds and no spec has ever run #70

Hypothesis

The learning loop is built halfway. Execution history, pattern recognition, and strategy suggestions exist and are wired together by Learning.create. The half that would feed what was learned back into which capabilities an agent assembles with, which is the bet WORLD.md says to mature, is Learning::CapabilityOptimizer: 613 lines, shipped in 0.2.0, named in the 0.2.0 release notes, and never constructed, never tested, never called.

Evidence

• lib/agentic/learning/capability_optimizer.rb (613 lines, added 2025-06-01). grep -rn CapabilityOptimizer lib exe README.md docs spec returns the file itself and CHANGELOG:94 ("CapabilityOptimizer for improving capability implementations", under 0.2.0). There is no spec/agentic/learning/capability_optimizer_spec.rb; every sibling (execution_history_store, pattern_recognizer, strategy_optimizer) has one.
• Learning.create (learning.rb) builds ExecutionHistoryStore, PatternRecognizer, StrategyOptimizer and returns them as a hash. It does not build a CapabilityOptimizer, and Learning.lifecycle_hooks only records executions into the store. Nothing reads capability-level history back out.
• The class's own doc example was already annotated in the round-13 docs pass (6421a3f, 2026-07-07): "illustrative: needs a populated capability registry". That is the sound of someone noticing it does not run and documenting around it.
• Its public surface is the right shape for the gap: get_optimization_suggestions(capability_name), optimize_capability_composition(task), apply_optimization, record_execution(capability_name, version, metrics, result). optimize_capability_composition is exactly the "which capabilities should this agent have, given what worked before" question that AgentAssemblyEngine answers today from keywords (Self-assembly can't see the registry: keyword inference is a hardcoded 11-name list, and only 4 of 7 registered capabilities are on it #44, now registry-driven in Self-assembly infers capabilities from the registry, not a hardcoded list (#44) #65) with no memory.
• Related stub in the wired half: StrategyOptimizer#apply_optimizations has three # Logic to apply optimization to registry would go here comments (strategy_optimizer.rb:204,218,231) inside loops that iterate and apply nothing. The learning system suggests; it never changes anything.
• GitHub code search for Agentic::Learning::CapabilityOptimizer outside this repo: no hits.

Experiment that would validate it

1. Write the missing spec first, with no production change: construct through the documented example with a populated registry, call record_execution a few dozen times with mixed outcomes, then get_optimization_suggestions and optimize_capability_composition. If it raises or returns nothing usable, we learn that in one afternoon and the answer is deprecate.
2. If it produces something, the wiring experiment is small: Learning.create also builds a CapabilityOptimizer (one more hash key, additive), and AgentAssemblyEngine takes an optional composition_hint: from it. Measure on the existing assembly specs: does history change the selected capability set, and is the change defensible?

Cost

• Spec only: tests, no behaviour change, one session. That half is L1 and drainable on its own.
• Wire: one additive key in Learning.create plus an optional hook in assembly. Reversible.
• Deprecate: 613 lines out, one CHANGELOG line, and the 0.2.0 release note becomes a promise we withdrew.

Class: code-feature (L0) for the wiring; the spec-first step is code-refactor (L1) and can ship without this decision
Minerva's lean: Spec it this cycle, and if it runs, wire it into Learning.create and assembly; it is the only path in the gem from execution history back to capability selection, and that is the ROADMAP's bet, not a side quest.

Labels: loop:self, status:analyzed

Origin: loop:self session 2026-10-15, declared-but-never-read audit. Checked closed and deferred issues: nothing on this class. Related: #44/#65 (registry-driven inference), #46/#52 (token stats into the learning hooks), #23 C4.