`ClaudeTranslator` implementa el trait `IntentTranslator` igual que el `MockTranslator`, así que el `Orchestrator` no cambia: se traduce una intención NL a un `.swm` válido vía `/v1/messages`. Diseño: - Síncrono (ureq + rustls), consistente con `AgentClient`. Tokio entraría sólo si el resto del crate lo pidiera. - Trait `HttpClient` inyectable ⇒ tests sin red contra una fake que captura el request y devuelve un body pre-armado. - Modelo por defecto: `claude-opus-4-8` (Opus 4.8, el más capaz al día de hoy). Adaptive thinking + `effort=high` por defecto. Override por env (`HAMMER_LLM_MODEL`, `HAMMER_LLM_EFFORT`, `HAMMER_LLM_BASE_URL`). - System prompt documenta el shape exacto del `.swm` (4 variantes de mutación) y obliga JSON puro. Parseamos con `serde_json::from_str:: <Swm>` + `verify_schema()` como gate adicional. Manejamos `refusal`, error envelopes de la API y code-fence markdown. Activación: - Sin feature: el módulo declara los tipos pero `ClaudeTranslator::new` está bajo cfg. El binario compila sin red. - Con `--features llm-claude`: trae `ureq` con rustls, y la CLI activa `hammer ai --llm`. CLI: - `hammer ai` gana `--llm` (mutuamente excluyente con `--catalog`). Refactor de `run_ai` en helpers `run_with_mock_translator` / `run_with_llm_translator` para mantener legible el dispatch. - Sin la feature, `--llm` falla con un mensaje claro pidiendo recompilar. Tests (7 unit): happy path con verificación de URL/headers/body, unwrap de markdown, `refusal`, error envelope, SWM mal formado, verify_schema, helpers de strip_code_fence.
Documentación de diseño de hammer
Estos documentos son la fuente de verdad del diseño. El código los implementa; cuando haya discrepancia, o se corrige el código o se actualiza el SDD con un commit que explique por qué.
Software Design Documents (SDD)
| # | Documento | Qué cubre |
|---|---|---|
| 00 | Visión y filosofía | Por qué existe, qué problema resuelve, la actitud de ingeniería |
| 01 | Arquitectura general | El modelo de dos mundos, componentes, flujo de datos |
| 02 | El laboratorio de build | Sandbox, zig cc, recetas, CAS, grafo de dependencias |
| 03 | Hidratación y store | Store content-addressed, hardlinks a FHS, patchelf, rollback |
| 04 | Overlay de experimentación | overlayfs en caliente, try/commit/discard |
| 05 | Diario de mutaciones | fanotify, log append-only, config-sin-ser-declarativa |
| 06 | Formato .swm |
Manifiesto de mutación compartible, esquema, firma |
| 07 | Bus de init y de agente | /run/init.control, /run/agent.sock, protocolo |
| 08 | Integración de la IA | El bucle agéntico, seguridad, intención → .swm |
| 09 | Modelo de confianza | Reproducibilidad, verificar-no-confiar, log de transparencia |
| 10 | Roadmap | Fases, MVP, primer entregable |
Architecture Decision Records (ADR)
Decisiones tomadas, con su contexto y consecuencias. Ver adr/.