Preparar tu proyecto Laravel para el plugin del equipo
Hola, bienvenido. En esta lección vamos a dejar listo el proyecto helpdesk para que a partir de la siguiente podamos ir sacando piezas de él hacia el plugin. Vamos a hacer el inventario de lo que tiene, con un destino para cada pieza, a dar nombre al contrato de scripts de Composer que todos los repos del equipo van a compartir y a corregir un detalle de la configuración que copiamos del Setup y que en equipo da problemas: unos permisos que no encajan con cómo escribe Claude los comandos.
En esta lección solo decidimos dónde tiene que estar cada pieza. Moverlas lo haremos más adelante, una a una.
Seguimos donde lo dejamos en la lección anterior: en la pestaña helpdesk, la de Marta, con Sail levantado y composer qa en verde.
En esta lección solo vamos a modificar un archivo, .claude/settings.json, que es de los que copiamos de tu proyecto del Setup. Cuando una lección modifica un archivo copiado de allí, verás su estado inicial y, resaltado, lo que se añade y lo que se quita. Si tu versión de ese archivo no es exactamente igual, porque añadiste un permiso más, no pasa nada: aplica el cambio resaltado y sigue. Siempre puedes desplegar el archivo completo para comparar.
Inventario de helpdesk: lo copiado del Setup y lo creado en el curso
Antes de crear el plugin, Marta revisa lo que helpdesk tiene al salir de la lección anterior, tanto lo que copiamos del Setup como lo que escribimos en el curso, y decide dónde debe estar cada pieza, con el reparto de la lección 1:
- Lo que Claude ejecuta en su ciclo, en el plugin.
- El código que necesita el proyecto y las convenciones con su test, en el paquete.
- Lo que cambia por persona, fuera de git.
- El resto, en el repo.
El resultado es esta tabla. De momento no movemos nada: nos sirve de guía para el resto del curso.
| Pieza | Destino | Por qué |
|---|---|---|
.claude/settings.json |
Se queda | Los permisos son del repo. Más adelante llevará también el marketplace y el plugin activado |
.claude/settings.local.json |
Personal | Permisos extra de cada uno. Está fuera de git desde la lección anterior |
.claude/skills/conventional-commits/ |
Al plugin | Claude la ejecuta igual en todos los repos. Es la primera pieza que moveremos, en la siguiente lección |
.claude/skills/qa/ |
Al plugin | Igual, pero sin la key de Sonar escrita a mano |
.claude/skills/laravel-best-practices/ y pest-testing/ |
Se quedan | Las instala y las actualiza Boost, no el equipo |
.claude/agents/ |
Al plugin | Los 2 subagentes, con el modelo decidido una vez |
.claude/rules/ |
Al paquete | Son punteros a los docs, así que van con ellos |
.claude/agent-memory/ |
Se queda | Es la memoria del auditor, que llegó con la copia del Setup si la tenías. Ahora está ignorada; la versionaremos cuando los subagentes pasen al plugin |
CLAUDE.md, boost.json y .mcp.json |
Se quedan | Los genera Boost. Cuando exista el paquete, CLAUDE.md lo importará en su primera línea |
.ai/guidelines/project.md |
Se queda | Lo propio del dominio de este proyecto |
.ai/docs/ |
Al paquete | Las convenciones de código y sus docs |
app/ViewModels/ViewModel.php y tests/Architecture/ArchTest.php |
Al paquete | Código que el proyecto necesita y los tests que comprueban la convención |
pint.json, phpstan.neon y rector.php |
Al paquete | Como configuración base y stubs |
Scripts de composer.json |
Se quedan | Son lo que el plugin va a comprobar en cada repo. Los escribimos en la lección anterior |
CLAUDE.local.md y la auto memory |
Personal | Ya están fuera de git |
Fíjate en que las 2 skills de Boost se quedan aunque sean skills. Lo que decide es quién lo mantiene: Boost las reescribe cuando se actualiza, así que no tiene sentido versionarlas en un plugin del equipo.
- 02El contrato de scripts de Composer
- 03Permisos con y sin ./vendor/bin/sail
- 04Comprobar el punto de partida
