Workshop · 30 min · no tools required
Taller · 30 min · sin herramientas
GS Audit Report
Reporte de Auditoría GS
Paste the template below into any AI assistant — Claude Code, Cursor, Copilot — pointed at the project root. No install, no CLI. This prompt now mirrors the full pragmaworks CLI report — all eight dimensions: the AI reads the codebase, scores all seven GS properties with disease names at score 0, identifies which structural disciplines apply, maps the test pyramid, checks documentation health, reviews security & logging, reads the git history for team habits, and produces a prioritized remediation plan as markdown. Nothing is changed in this pass.
Pega la plantilla de abajo en cualquier asistente de IA — Claude Code, Cursor, Copilot — apuntado a la raíz del proyecto. Sin instalar, sin CLI. Este prompt ahora espeja el reporte completo del CLI de pragmaworks — las ocho dimensiones: la IA lee la base de código, puntúa las siete propiedades GS con nombres de enfermedades en puntaje 0, identifica qué disciplinas estructurales aplican, mapea la pirámide de pruebas, verifica la salud de la documentación, revisa seguridad y logging, lee el historial de git para hábitos de equipo, y produce un plan de remediación priorizado como markdown. No se cambia nada en esta pasada.
The eight dimensions, in order: 1 GS Property Scorecard (0–14) · 2 Total Score & Band · 3 Structural Disciplines · 4 Test Pyramid · 5 Documentation Health · 6 Security & Logging · 7 Team Habits (Git History) · 8 Remediation Plan. Dimensions 1–6 read the code; dimension 7 reads the git history, so the project must be a git repository for that section to run.
Las ocho dimensiones, en orden: 1 Scorecard de Propiedades GS (0–14) · 2 Puntaje Total y Banda · 3 Disciplinas Estructurales · 4 Pirámide de Pruebas · 5 Salud de Documentación · 6 Seguridad y Logging · 7 Hábitos de Equipo (Historial Git) · 8 Plan de Remediación. Las dimensiones 1–6 leen el código; la dimensión 7 lee el historial de git, por lo que el proyecto debe ser un repositorio git para que esa sección corra.
01
Paste the template. Edit the bracketed lines to match your project if needed. The rest runs without customization.
Pega la plantilla. Edita las líneas entre corchetes para que coincidan con tu proyecto si es necesario. El resto corre sin personalización.
Paste this — GS Audit ReportPega esto — Reporte de Auditoría GSYou are about to produce a GS Audit Report for this codebase. Read the
code, tests, documentation, CI config, and the last 200 commits of git
log. Write the report to reports/gs-audit-[YYYY-MM-DD].md. Do not modify
any application code in this session.
──────────────────────────────────────
SECTION 1 — GS PROPERTY SCORECARD (0–14)
──────────────────────────────────────
Score each property 0, 1, or 2.
0 = absent or severely deficient
1 = intent present, implementation incomplete
2 = solid — evidence is clear and reproducible
For each property: score · one-sentence finding · file:line citation ·
one specific next step to raise it by 1.
SELF-DESCRIBING
Does the codebase explain its own intent without the original author present?
Look for: SPEC.md or equivalent, ADRs, README that states purpose not just
setup, architectural constitution (CLAUDE.md / AGENTS.md / .cursor/rules).
Score 0 — "Empty Map": all intent lives in heads; codebase cannot
explain itself.
Score 1 — some docs exist; intent must still be inferred from code.
Score 2 — spec + ADRs + architectural constitution present and current.
BOUNDED
Do files, functions, and modules stay within size discipline?
Look for: files over 400 lines, functions over 50 lines, modules with
multiple responsibilities.
Score 0 — "Spreading Boundary": no size discipline; modules grow
unchecked.
Score 1 — most modules bounded; notable outliers exist.
Score 2 — explicit size limits configured or documented; consistently
respected.
COMPOSABLE
Do pieces compose without hidden coupling?
Look for: circular dependencies, wide import fan-out (one file imports from
3+ layers), direct cross-module writes, feature flags that span modules.
Score 0 — "Tangled Web": changing one module triggers cascading effects.
Score 1 — some coupling present but modules are isolatable with effort.
Score 2 — clear interface boundaries; no circular deps; coupling explicit.
VERIFIABLE
Do tests bind specification to behavior?
Look for: test files, coverage %, whether tests describe behavior vs.
internals, integration and e2e tests alongside unit tests.
Score 0 — "Unbound Spec": no structural link between spec and running
code.
Score 1 — unit tests present; minimal behavior-level coverage.
Score 2 — tests at multiple layers that verify use-case behavior.
AUDITABLE
Can decisions and changes be traced back to why they happened?
Look for: commit message quality, ADRs present and current, changelog, PR
descriptions with context.
Score 0 — "Amnesia Stack": changes happened; reasons are unknowable.
Score 1 — some ADRs or meaningful commits; traceability has gaps.
Score 2 — clear ADR coverage; meaningful commits; decisions traceable.
DEFENDED
Is the security and error-handling baseline in place?
Look for: input validation at trust boundaries, secrets in env files not
hardcoded, error handling that does not leak internals, what is logged at
the trust boundary.
Score 0 — "Open Gates": system accepts and leaks without enforcement.
Score 1 — some validation; trust boundary is unclear or inconsistent.
Score 2 — trust boundary defined; input validated; secrets managed.
EXECUTABLE
Do the use cases actually run? Is the spec operationally alive?
Look for: can you run the project from a clean clone? Does CI run? Are
there scripts that build, test, and start the project without tribal
knowledge?
Score 0 — "Frozen Spec": specification is prose that nothing executes.
Score 1 — runnable but requires manual steps or tribal knowledge.
Score 2 — clean clone → running in one command; CI enforces it.
──────────────────────────────────────
SECTION 2 — TOTAL SCORE AND BAND
──────────────────────────────────────
Total = sum of 7 scores (0–14).
0–4 Critical — foundational properties absent; start with oracle
tests + Self-describing before anything else
5–8 Developing — partial discipline; one focused sprint can move
3–4 properties
9–11 Functional — solid base; targeted improvement per weak property
12–14 Strong — publish the approach; document what is working as
methodology
State: total score · band · one sentence on the single highest-leverage
property to improve first and why.
──────────────────────────────────────
SECTION 3 — STRUCTURAL DISCIPLINES
──────────────────────────────────────
For each discipline: Implemented / Partial / Not applicable — one citation.
For "not applicable": one sentence on why it does not fit this codebase.
SOLID (the five principles) ·
Hexagonal / Clean Architecture (ports & adapters; dependency rule) ·
Convention over Configuration / Screaming Architecture ·
Type-Driven Design (illegal states unrepresentable; Result/Either error types) ·
Design by Contract (preconditions, postconditions, invariants) ·
DDD — ubiquitous language · CQRS · TDD · BDD ·
Clean Code (intentional naming, small functions) ·
Immutability / functional core, imperative shell ·
GoF design patterns (named in the spec) ·
Conventional + atomic commits · ADRs ·
Doc-first cascade (sentinel → spec → ADR → code) — GS-specific
──────────────────────────────────────
SECTION 4 — TEST PYRAMID
──────────────────────────────────────
Count test files by layer: unit · integration · e2e. State the ratio.
Identify the most under-served layer. Flag any test that mocks all
dependencies without a corresponding behavior-level test — label these
"test theater."
──────────────────────────────────────
SECTION 5 — DOCUMENTATION HEALTH
──────────────────────────────────────
Use git log --follow -- <file> to find last-touched date for each doc.
Flag: any doc not updated in 90+ days where the code beneath it changed.
List: missing docs (README with purpose, SPEC, ADR for major decisions,
CHANGELOG).
──────────────────────────────────────
SECTION 6 — SECURITY & LOGGING
──────────────────────────────────────
Review and report:
- Authentication: which routes are protected, which are public, any gaps.
- Authorization: are roles/permissions enforced at the boundary, or assumed?
- Input validation: is all external input validated at the trust boundary? Cite files.
- Secrets: any hardcoded credentials, keys, or tokens in code or logs? (flag each)
- Logging hygiene: are errors logged with enough context? Any PII or secrets leaked into logs?
- Dependency risk: known-vulnerable or unmaintained dependencies (note if a lockfile audit is possible).
Rate each: OK / Gap / Critical. List every Critical with file:line.
──────────────────────────────────────
SECTION 7 — TEAM HABITS (read the last 200 commits with git log)
──────────────────────────────────────
Analyze and report:
- PR / review density: what fraction of changes went through review vs. direct commits?
- Commit-size distribution: median and tail. Flag giant commits (>400 lines) — they hide intent.
- AI-introduced bug rate: commits that were reverted or hot-fixed within a short window — estimate the rate.
- Regression coverage: when bugs were fixed, was a test added in the same or adjacent commit?
- Collaboration graph / bus factor: how many files have effectively one author? Where is the knowledge concentrated?
- Co-change coupling: which files change together most often? (this also reveals where module boundaries are wrong)
Report the numbers plus the single biggest risk the history reveals.
──────────────────────────────────────
SECTION 8 — REMEDIATION PLAN
──────────────────────────────────────
10–15 items in priority order:
1. Oracle tests first — before any structural change
2. Lowest-scoring properties first
3. Within a property: smallest effort, biggest score lift
Format each item:
[N] [S/M/L] [property affected]
What: one sentence describing the change
Why now: one sentence on ordering rationale
──────────────────────────────────────
Cite files and line numbers liberally. Do not apply any change in this
pass. This report is the contract for the remediation session that
follows.Vas a producir un Reporte de Auditoría GS para esta base de código. Lee
el código, pruebas, documentación, config de CI, y los últimos 200 commits
de git log. Escribe el reporte en reports/gs-audit-[YYYY-MM-DD].md. No
modifiques ningún código de la aplicación en esta sesión.
──────────────────────────────────────
SECCIÓN 1 — SCORECARD DE PROPIEDADES GS (0–14)
──────────────────────────────────────
Puntúa cada propiedad 0, 1, o 2.
0 = ausente o severamente deficiente
1 = intención presente, implementación incompleta
2 = sólido — evidencia clara y reproducible
Para cada propiedad: puntaje · hallazgo en una oración · citación file:line ·
un siguiente paso específico para subirlo 1 punto.
AUTO-DESCRIPTIVO
¿La base de código explica su propia intención sin que el autor original
esté presente?
Busca: SPEC.md o equivalente, ADRs, README que explique propósito no solo
setup, constitución arquitectónica (CLAUDE.md / AGENTS.md / .cursor/rules).
Puntaje 0 — "Mapa Vacío": toda la intención vive en cabezas; la base
no puede explicarse sola.
Puntaje 1 — existen algunos docs; la intención aún debe inferirse del
código.
Puntaje 2 — spec + ADRs + constitución arquitectónica presentes y
actuales.
ACOTADO
¿Los archivos, funciones y módulos se mantienen dentro de la disciplina
de tamaño?
Busca: archivos de más de 400 líneas, funciones de más de 50 líneas,
módulos con múltiples responsabilidades.
Puntaje 0 — "Límite Expandido": sin disciplina de tamaño; módulos
crecen sin control.
Puntaje 1 — la mayoría de módulos acotados; existen excepciones notables.
Puntaje 2 — límites de tamaño explícitos configurados o documentados;
respetados consistentemente.
COMPONIBLE
¿Las piezas componen sin acoplamiento oculto?
Busca: dependencias circulares, import fan-out amplio (un archivo importa
de 3+ capas), escrituras directas entre módulos, feature flags que cruzan
módulos.
Puntaje 0 — "Red Enredada": cambiar un módulo desencadena efectos en
cascada.
Puntaje 1 — algo de acoplamiento presente pero módulos son aislables.
Puntaje 2 — límites de interfaz claros; sin deps circulares.
VERIFICABLE
¿Las pruebas conectan la especificación al comportamiento?
Busca: archivos de pruebas, % de cobertura, si las pruebas describen
comportamiento vs. internos, pruebas de integración y e2e.
Puntaje 0 — "Spec Desvinculada": sin conexión estructural entre spec
y código en ejecución.
Puntaje 1 — pruebas unitarias presentes; cobertura de comportamiento mínima.
Puntaje 2 — pruebas en múltiples capas que verifican comportamiento
de casos de uso.
AUDITABLE
¿Se pueden rastrear decisiones y cambios hasta por qué ocurrieron?
Busca: calidad de mensajes de commit, ADRs presentes y actuales,
changelog, descripciones de PR con contexto.
Puntaje 0 — "Pila de Amnesia": los cambios ocurrieron; las razones son
incognoscibles.
Puntaje 1 — algunos ADRs o commits significativos; trazabilidad con brechas.
Puntaje 2 — cobertura clara de ADRs; commits significativos; decisiones
trazables.
DEFENDIDO
¿Está en marcha el baseline de seguridad y manejo de errores?
Busca: validación de input en límites de confianza, secretos en archivos
de entorno no hardcodeados, manejo de errores que no filtra internos.
Puntaje 0 — "Puertas Abiertas": el sistema acepta y filtra sin
enforcement.
Puntaje 1 — algo de validación; el límite de confianza es poco claro.
Puntaje 2 — límite de confianza definido; input validado; secretos
manejados.
EJECUTABLE
¿Los casos de uso realmente corren? ¿Está viva la spec operacionalmente?
Busca: ¿puedes correr el proyecto desde un clone limpio? ¿Corre CI? ¿Hay
scripts que construyen, prueban, e inician el proyecto sin conocimiento
tribal?
Puntaje 0 — "Spec Congelada": la especificación es prosa que nada
ejecuta.
Puntaje 1 — ejecutable pero requiere pasos manuales o conocimiento
tribal.
Puntaje 2 — clone limpio → corriendo en un comando; CI lo refuerza.
──────────────────────────────────────
SECCIÓN 2 — PUNTAJE TOTAL Y BANDA
──────────────────────────────────────
Total = suma de 7 puntajes (0–14).
0–4 Crítico — propiedades fundamentales ausentes; empezar con oracle
tests + Auto-descriptivo antes que cualquier otra cosa
5–8 En desarrollo — disciplina parcial; un sprint enfocado puede mover
3–4 propiedades
9–11 Funcional — base sólida; mejora dirigida por propiedad débil
12–14 Sólido — publica el enfoque; documenta lo que funciona como
metodología
Indica: puntaje total · banda · una oración sobre la propiedad de mayor
apalancamiento para mejorar primero y por qué.
──────────────────────────────────────
SECCIÓN 3 — DISCIPLINAS ESTRUCTURALES
──────────────────────────────────────
Para cada disciplina: Implementada / Parcial / No aplica — una citación.
Para "no aplica": una oración de por qué no encaja en esta base.
Principios SOLID · TDD · BDD · DDD (lenguaje ubicuo) ·
Hexagonal / ports-and-adapters · Capas / clean architecture ·
CQRS · Conventional commits · ADRs (Registros de Decisiones) ·
Cascada doc-first (sentinel → spec → ADR → código) ·
Naming intencional (firmas como especificaciones)
──────────────────────────────────────
SECCIÓN 4 — PIRÁMIDE DE PRUEBAS
──────────────────────────────────────
Cuenta archivos de prueba por capa: unit · integration · e2e. Indica el
ratio. Identifica la capa más sub-servida. Flagea cualquier prueba que
mockea todas las dependencias sin una prueba de nivel de comportamiento
correspondiente — etiquétalas "teatro de pruebas".
──────────────────────────────────────
SECCIÓN 5 — SALUD DE DOCUMENTACIÓN
──────────────────────────────────────
Usa git log --follow -- <archivo> para encontrar la última fecha de
modificación de cada doc. Flagea: cualquier doc no actualizado en 90+
días donde el código debajo cambió. Lista: docs faltantes (README con
propósito, SPEC, ADR para decisiones mayores, CHANGELOG).
──────────────────────────────────────
SECCIÓN 6 — SEGURIDAD Y LOGGING
──────────────────────────────────────
Revisa y reporta:
- Autenticación: qué rutas están protegidas, cuáles son públicas, cualquier brecha.
- Autorización: ¿se imponen roles/permisos en el límite, o se asumen?
- Validación de input: ¿todo input externo se valida en el límite de confianza? Cita archivos.
- Secretos: ¿credenciales, claves o tokens hardcodeados en código o logs? (flagea cada uno)
- Higiene de logging: ¿se loguean los errores con suficiente contexto? ¿Se filtra PII o secretos a los logs?
- Riesgo de dependencias: dependencias con vulnerabilidades conocidas o sin mantenimiento (nota si es posible una auditoría de lockfile).
Califica cada uno: OK / Brecha / Crítico. Lista cada Crítico con file:line.
──────────────────────────────────────
SECCIÓN 7 — HÁBITOS DE EQUIPO (lee los últimos 200 commits con git log)
──────────────────────────────────────
Analiza y reporta:
- Densidad de PR / revisión: ¿qué fracción de los cambios pasó por revisión vs. commits directos?
- Distribución de tamaño de commits: mediana y cola. Flagea commits gigantes (>400 líneas) — ocultan la intención.
- Tasa de bugs introducidos por IA: commits revertidos o hot-fixeados en una ventana corta — estima la tasa.
- Cobertura de regresión: cuando se arreglaron bugs, ¿se agregó un test en el mismo commit o uno adyacente?
- Grafo de colaboración / bus factor: ¿cuántos archivos tienen efectivamente un solo autor? ¿Dónde se concentra el conocimiento?
- Acoplamiento por co-cambio: ¿qué archivos cambian juntos más seguido? (esto también revela dónde están mal los límites de módulo)
Reporta los números más el mayor riesgo único que revela el historial.
──────────────────────────────────────
SECCIÓN 8 — PLAN DE REMEDIACIÓN
──────────────────────────────────────
10–15 items en orden de prioridad:
1. Oracle tests primero — antes de cualquier cambio estructural
2. Propiedades con puntaje más bajo primero
3. Dentro de una propiedad: menor esfuerzo, mayor lift de puntaje
Formato por item:
[N] [S/M/L] [propiedad afectada]
Qué: una oración describiendo el cambio
Por qué ahora: una oración sobre la racionalidad de orden
──────────────────────────────────────
Cita archivos y números de línea liberalmente. No apliques ningún cambio
en esta pasada. Este reporte es el contrato para la sesión de remediación
que sigue.
What each dimension reports
Qué reporta cada dimensión
The eight dimensions of the full CLI report
Las ocho dimensiones del reporte completo del CLI
1 · GS Property Scorecard (0–14)
1 · Tarjeta de Puntaje GS (0–14)
The core of the report. Each of the seven properties — Self-describing, Bounded, Composable, Verifiable, Auditable, Defended, Executable — is scored 0, 1, or 2 against concrete evidence in the code, with the failure disease named at each 0 (Empty Map, Spreading Boundary, Tangled Web, Unbound Spec, Amnesia Stack, Open Gates, Frozen Spec). Every score cites file:line, so two independent runs land within ±1 point.
El núcleo del reporte. Cada una de las siete propiedades — Auto-descriptiva, Acotada, Componible, Verificable, Auditable, Defendida, Ejecutable — se puntúa 0, 1 o 2 contra evidencia concreta en el código, nombrando la enfermedad de falla en cada 0 (Mapa Vacío, Límite Difuso, Telaraña, Spec sin Anclaje, Pila de Amnesia, Puertas Abiertas, Spec Congelada). Cada puntaje cita file:line, de modo que dos corridas independientes quedan dentro de ±1 punto.
2 · Total Score & Band
2 · Puntaje Total y Banda
The seven scores sum to 0–14 and place the codebase in a band: 0–4 Critical · 5–8 Developing · 9–11 Functional · 12–14 Strong. The band sets the expectation for how much remediation the project needs before it can be trusted to an unattended AI session.
Los siete puntajes suman 0–14 y ubican la base de código en una banda: 0–4 Crítico · 5–8 En desarrollo · 9–11 Funcional · 12–14 Sólido. La banda fija la expectativa de cuánta remediación necesita el proyecto antes de poder confiarlo a una sesión de IA sin supervisión.
3 · Structural Disciplines
3 · Disciplinas Estructurales
A checklist of the engineering disciplines present, partial, or absent: SOLID, hexagonal / clean architecture (ports & adapters), convention over configuration / screaming architecture, type-driven design, design by contract, DDD (ubiquitous language), CQRS, TDD, BDD, clean code (intentional naming, small functions), immutability / functional core, GoF design patterns, conventional + atomic commits, ADRs, and the doc-first cascade. These are the same disciplines that give the AI reader its mechanical advantage — see Temper.
Una checklist de las disciplinas de ingeniería presentes, parciales o ausentes: SOLID, arquitectura hexagonal / limpia (puertos y adaptadores), convención sobre configuración / screaming architecture, type-driven design, design by contract, DDD (lenguaje ubicuo), CQRS, TDD, BDD, clean code (naming intencional, funciones pequeñas), inmutabilidad / núcleo funcional, patrones de diseño GoF, commits convencionales + atómicos, ADRs y la cascada doc-first. Son las mismas disciplinas que le dan al lector IA su ventaja mecánica — ver Temper.
4 · Test Pyramid
4 · Pirámide de Pruebas
The ratio of unit, integration, and end-to-end tests, and whether the shape is healthy or inverted. Flags test theater — suites that mock every dependency and never exercise real behavior, which pass green while the system breaks.
La proporción de tests unitarios, de integración y end-to-end, y si la forma es sana o está invertida. Flagea el teatro de tests — suites que mockean toda dependencia y nunca ejercitan comportamiento real, que pasan en verde mientras el sistema se rompe.
5 · Documentation Health
5 · Salud de la Documentación
The last-touched date of each doc against the code beneath it, flagging stale documentation where the code moved on without the spec. Stale docs are worse than none — they feed the AI reader confident, wrong context.
La fecha de última modificación de cada doc contra el código debajo, flageando documentación desactualizada donde el código avanzó sin la spec. Los docs desactualizados son peores que ninguno — le dan al lector IA contexto seguro y equivocado.
6 · Security & Logging
6 · Seguridad y Logging
A focused security read of the trust boundary. The AI reports authentication coverage (which routes are protected, which are public, where the gaps are), whether authorization is enforced at the boundary or merely assumed, and whether all external input is validated where it enters. It flags every hardcoded credential, key, or token found in code or logs; checks logging hygiene for missing context and for PII or secrets leaking into log output; and notes dependency risk, including whether a lockfile audit is possible. Each item is rated OK / Gap / Critical, and every Critical is listed with a file:line citation.
Una lectura de seguridad enfocada en el límite de confianza. La IA reporta la cobertura de autenticación (qué rutas están protegidas, cuáles son públicas, dónde están las brechas), si la autorización se impone en el límite o solo se asume, y si todo input externo se valida donde entra. Flagea cada credencial, clave o token hardcodeado en código o logs; verifica la higiene de logging por falta de contexto y por PII o secretos filtrándose a la salida de logs; y nota el riesgo de dependencias, incluyendo si es posible una auditoría de lockfile. Cada ítem se califica OK / Brecha / Crítico, y cada Crítico se lista con una citación file:line.
7 · Team Habits — Git History
7 · Hábitos de Equipo — Historial Git
The only dimension that reads the project's git history rather than its code, so it needs an actual git repository to run. Over the last 200 commits the AI estimates PR / review density (reviewed changes vs. direct commits), the commit-size distribution with its median and tail (flagging giant commits over 400 lines that hide intent), and the AI-introduced bug rate inferred from reverts and quick hot-fixes. It checks whether bug fixes shipped with a regression test in the same or an adjacent commit, maps the collaboration graph and bus factor (how many files have effectively one author, where knowledge is concentrated), and surfaces co-change coupling — the files that change together most often, which also reveals where module boundaries are drawn wrong. It closes with the numbers plus the single biggest risk the history reveals.
La única dimensión que lee el historial de git del proyecto en lugar de su código, por lo que necesita un repositorio git real para correr. Sobre los últimos 200 commits la IA estima la densidad de PR / revisión (cambios revisados vs. commits directos), la distribución de tamaño de commits con su mediana y cola (flageando commits gigantes de más de 400 líneas que ocultan la intención), y la tasa de bugs introducidos por IA inferida de reverts y hot-fixes rápidos. Verifica si los arreglos de bugs vinieron con un test de regresión en el mismo commit o uno adyacente, mapea el grafo de colaboración y el bus factor (cuántos archivos tienen efectivamente un solo autor, dónde se concentra el conocimiento), y revela el acoplamiento por co-cambio — los archivos que cambian juntos más seguido, lo que también muestra dónde están mal trazados los límites de módulo. Cierra con los números más el mayor riesgo único que revela el historial.
8 · Remediation Plan
8 · Plan de Remediación
The report closes with a prioritized plan: 10–15 items in order — oracle tests first, then the lowest-scoring properties, then the smallest-effort / biggest-lift fixes. Each item names the property it raises, the effort (S / M / L), and why it matters now. This plan is the contract for the remediation session that follows — see Anneal.
El reporte cierra con un plan priorizado: 10–15 ítems en orden — oracle tests primero, luego las propiedades de menor puntaje, luego los arreglos de menor esfuerzo / mayor impacto. Cada ítem nombra la propiedad que sube, el esfuerzo (S / M / L), y por qué importa ahora. Este plan es el contrato para la sesión de remediación que sigue — ver Anneal.
This template is the no-tools version of the full audit. The brownfield journey shows the tool-assisted version that also runs CI, generates HTML + PDF output, and works at team scale.
Esta plantilla es la versión sin herramientas de la auditoría completa. El camino brownfield muestra la versión asistida por herramientas que también corre CI, genera HTML + PDF, y funciona a escala de equipo.
Want a guided audit run?
¿Quieres una corrida de auditoría guiada?
Email me directly. If you want a live walkthrough with the full PragmaWorks toolchain, or a Concierge engagement where we handle the remediation end-to-end, just ask.
Escríbeme directamente. Si quieres un walkthrough en vivo con el stack completo de PragmaWorks, o un engagement de Concierge donde manejamos la remediación end-to-end, solo pídelo.
juan@pragmaworks.dev →