[Mongoose] Add Loop Tuner meta-capability recommendations

[Nickel85]

Goal

Add Loop Tuner as a future meta-capability that analyzes loop definitions and execution traces, then recommends improvements to capability workflows.

Loop Tuner should initially generate recommendations only. It must not automatically modify loop definitions, prompts, tools, state contracts, approval gates, or runtime behavior.

Roadmap Position

Loop Tuner depends on the shared Loop Runtime and Execution Traces, plus enough real capability executions to analyze. It is a future optimization capability, not an MVP requirement and not a replacement for specialized capabilities such as Njord, Overwatch, Mimir, Commerce, Tyr, or future domain agents.

This belongs after the runtime has stable traces and after capabilities have accumulated meaningful outcomes. It should inform decision learning and workflow improvement; it should not block shared memory, prompt context, provider interfaces, or the initial Loop Runtime.

Capability Role

Loop Tuner is a Mongoose meta-capability. It can inspect:

• capability definitions
• loop definitions
• execution traces
• tool usage patterns
• validation failures
• exit criteria behavior
• user approvals, rejections, and corrections
• outcome records and replay-safe summaries

It proposes improvements such as clearer prompts, better validation steps, missing tool affordances, tighter exit criteria, redundant steps, trace gaps, or candidate reusable loop patterns.

Initial Output Contract

Loop Tuner should produce recommendation-only output:

• observed issue or opportunity
• affected capability and loop definition
• supporting trace references
• proposed change
• expected benefit
• risk and required human review
• suggested follow-up issue or patch scope

Acceptance Criteria

• Defines Loop Tuner as a meta-capability that analyzes traces and loop definitions.
• Requires human review before any workflow change is applied.
• Produces recommendations rather than automatically modifying behavior.
• Can identify duplicated loop patterns across capabilities without collapsing capability identity.
• Can flag missing traces, weak exit criteria, repeated validation failures, or unnecessary tool calls.
• Requires enough execution history to avoid optimizing from one-off or low-evidence traces.
• Includes examples from one finance capability and one non-finance capability when implemented.

Non-goals

• No automatic prompt rewrites in production behavior.
• No autonomous loop mutation.
• No approval policy changes.
• No replacement of domain owners or capability-specific design judgment.
• No requirement that early Loop Runtime work include tuner behavior.

Depends On

• [Mongoose] Add shared Loop Runtime for capability execution #167 shared Loop Runtime
• [Mongoose] Add shared Execution Traces for capability runs #168 shared Execution Traces
• [Mongoose] Define shared agent memory provider contract #164 shared agent memory provider contract