refactor: consolidate first-class tools — colocate compile-time and runtime code per tool

[jamesadevine]

Summary

First-class tools (tools: front matter) currently have their implementation scattered across three directories with inconsistent organization. This makes it hard to understand where a tool's code lives and adds friction when adding new tools.

Current layout

src/
├── compile/extensions/    ← compile-time (CompilerExtension impls)
│   ├── azure_devops.rs    ←── tools.azure-devops compile-time
│   ├── cache_memory.rs    ←── tools.cache-memory compile-time
│   ├── lean.rs            ←── runtimes.lean compile-time
│   ├── github.rs          ←── always-on (GitHub MCP)
│   └── safe_outputs.rs    ←── always-on (SafeOutputs MCP)
│
├── tools/                 ← Stage 3 runtime for tools
│   ├── mod.rs
│   └── cache_memory.rs    ←── tools.cache-memory Stage 3 execution
│
├── safeoutputs/           ← Stage 3 runtime for safe outputs
│   ├── create_pr.rs
│   ├── create_work_item.rs
│   └── ... (14 tools)
│
└── runtimes/              ← (empty now — lean moved to extensions/)
    ├── mod.rs
    └── lean.rs            ←── dead code? lean is in extensions/

Problems

1. Cache memory is split — compile-time in compile/extensions/cache_memory.rs, runtime in tools/cache_memory.rs. You need to know both exist.

2. src/tools/ is misleading — it only contains cache_memory. The name suggests it's the home for all tools, but azure-devops (a tool) has no runtime here, and safe outputs (also tools) live in safeoutputs/.

3. src/runtimes/lean.rs may be dead — lean was moved to compile/extensions/lean.rs as a CompilerExtension. Is the old runtimes/ module still used?

4. No organizational symmetry — a tool configured under tools: could have code in compile/extensions/, tools/, or both. There's no single directory you can look at.

Proposed organization

Consolidate each first-class tool into a single module that owns both its compile-time and runtime behavior:

src/
├── tools/
│   ├── mod.rs                ← re-exports, collect_extensions()
│   ├── cache_memory/
│   │   ├── mod.rs
│   │   ├── extension.rs      ← CompilerExtension impl
│   │   └── execute.rs        ← Stage 3 runtime (validate/copy)
│   ├── azure_devops/
│   │   ├── mod.rs
│   │   └── extension.rs      ← CompilerExtension impl
│   └── ...future tools
│
├── runtimes/                  ← language environment extensions
│   ├── mod.rs
│   └── lean/
│       ├── mod.rs
│       └── extension.rs       ← CompilerExtension impl
│
├── compile/extensions/
│   ├── mod.rs                 ← CompilerExtension trait, Extension enum, infra-only extensions
│   ├── github.rs              ← always-on (not a user-configured tool)
│   └── safe_outputs.rs        ← always-on (not a user-configured tool)
│
├── safeoutputs/               ← unchanged (safe output MCP tools)

Principles

• Tools (tools: front matter) live in src/tools/<name>/ — one directory per tool, containing both compile-time and runtime code
• Runtimes (runtimes: front matter) live in src/runtimes/<name>/
• Infrastructure extensions (GitHub, SafeOutputs) that are always-on and not user-configured stay in compile/extensions/
• Safe outputs (safe-outputs: front matter) stay in src/safeoutputs/ — they're MCP tools with a different lifecycle (Stage 1 NDJSON → Stage 3 execution)

Work items

1. Consolidate cache-memory — move compile/extensions/cache_memory.rs and tools/cache_memory.rs into tools/cache_memory/
2. Consolidate azure-devops — move compile/extensions/azure_devops.rs into tools/azure_devops/
3. Consolidate lean — move compile/extensions/lean.rs into runtimes/lean/, remove old runtimes/lean.rs if dead
4. Update compile/extensions/mod.rs — import tool/runtime extensions from their new homes, keep Extension enum and collect_extensions() here
5. Clean up src/runtimes/ — verify runtimes/lean.rs is dead code and remove if so
6. Update AGENTS.md — reflect new directory structure

[jamesadevine]

Also, let's document this methodology in agents.md