[lacasoft]

Summary

Fase 03 del plan de compatibilidad con Pi Agent: la base de dev-starter-kit para Pi ≥ 1.4.0, con el mismo enfoque que system-design-kit 1.2.0. Es una capa aditiva: sin --pi, el instalador hace exactamente lo de antes y Claude Code no cambia.

• --pi agrega:
  • .pi/settings.json, que carga las 19 skills desde .claude/skills y /status desde .claude/commands/kit/status.md, sin copias. /swarm no se carga, porque depende de los subagentes de Claude Code. Si el archivo ya existe se fusiona; si no es JSON válido, no se toca.
  • .pi/extensions/dev-starter-kit.ts, que:
    • expande los @imports de CLAUDE.md (CLAUDE.project.md y la baseline);
    • añade las reglas de .claude/rules/ sin paths:, que Claude carga siempre: las del stack en un proyecto de un solo stack y las propias del equipo;
    • pone en el contexto los avisos de inicio de sesión;
    • muestra 🧰 dev-kit en la barra de estado cuando la capa está activa.
  • El registro de la capa en el manifiesto, para que --update la recuerde, y los avisos finales: confianza del proyecto, telemetría, ripgrep/fd y que en Pi no hay subagentes.
• Helpers zero-dep: claude-imports.cjs (el mismo de system-design-kit) y claude-rules.cjs, que lee .claude/rules/ como Claude Code. La extensión .ts solo hace de puente.
• Texto:
  • Las 9 skills que nombran archivos del proyecto aclaran que sus rutas parten de la raíz.
  • swarm-orchestration y la sección 3 de la baseline dicen que los subagentes son solo de Claude Code.
  • loop-task avisa que en Pi todavía no tiene su puerta.
  • Dentro de Pi, el aviso de inicio sugiere /skill:project-context.
• CI: job pi que prueba la capa dentro de Pi 1.4.0 con su proveedor simulado, sin modelo ni API key.

Queda para la Fase 04 (próximo PR, con el bump a 3.3.0 y la sección del README):

• los guardrails de seguridad en Pi: el puente a hook-handler.cjs, las denegaciones de settings.json (~/.ssh, ~/.aws…), ask → confirmación y, sin interfaz, bloqueo, y las herramientas desconocidas.

Quedan para la 3.4.0: las reglas por carpeta en monorepo y la puerta de /loop-task.

Test plan

• npm run validate (56 comprobaciones) y node --test: 169 pruebas, más 4 de integración que se omiten sin PI_BIN.
• Con PI_BIN (Pi 1.4.0, modelo simulado): las 173 en verde.
  • Con --pi, Pi ve la baseline, la regla del stack y los avisos de inicio con sintaxis de Pi, carga las skills y no quedan líneas @.
  • /status expande el comando de .claude/commands/kit/status.md.
  • En monorepo, las reglas con paths: no entran siempre.
  • Sin --pi, Pi ve las líneas @ literales.
• Instalador: sin --pi no hay .pi/ ni registro en el manifiesto; --update recuerda --pi y respeta la extensión editada; fusión de .pi/settings.json sin duplicar; JSON inválido no se toca; --dry-run --pi no escribe nada.
• De punta a punta con un modelo real (Claude Sonnet 5.5 vía API en Pi 1.4.0, USD 0.08): /skill:project-context en un proyecto NestJS. Leyó el repo, corrió build/lint/test, escribió CLAUDE.project.md separando lo confirmado, lo inferido y lo pendiente, aplicó el overlay de NestJS y la baseline (propuso un nivel ASVS) y dejó CLAUDE.md intacto.
• CI en verde, incluido el job pi: sus 4 pruebas corrieron dentro de Pi 1.4.0, ninguna omitida.