~20 min · no install, no tools required
~20 min · sin instalar, 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, grades all seven GS properties (the five SAVED plus two engineering) with the failure disease named at F, 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, califica las siete propiedades GS (las cinco SAVED más dos de ingeniería) con la enfermedad de falla nombrada en F, 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.
Want to see what comes out before you spend the tokens? Read a sample report → — the ten-property scorecard, a maturity level, and the two next moves, on a real (messy) codebase.
¿Querés ver qué sale antes de gastar los tokens? Leé un reporte de muestra → — el scorecard de diez propiedades, un nivel de madurez, y los dos próximos movimientos, sobre un código real (desordenado).
The eight dimensions, in order: 1 SAVED Report Card (letter grades) · 2 Report Card Summary · 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 Boletín SAVED (notas A–F) · 2 Resumen del Boletín · 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 — SAVED REPORT CARD
──────────────────────────────────────
Grade each property A through F, like a school report card.
A = exemplary; evidence is clear and reproducible
B = solid; only minor gaps
C = present but inconsistent; intent visible, implementation incomplete
D = weak; mostly absent, only isolated signs
F = absent or severely deficient — name the failure disease
The five audit-facing properties spell SAVED. Two more, Bounded and
Composable, are the engineering layer beneath that keeps SAVED true.
Grade all seven.
For each property: grade · one-sentence finding · file:line citation ·
one specific next step to raise it by one grade.
═══ SAVED — the five an auditor can see ═══
SELF-DESCRIBING (S)
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).
F — "Empty Map": all intent lives in heads; codebase cannot explain itself.
C — some docs exist; intent must still be inferred from code.
A — spec + ADRs + architectural constitution present and current.
AUDITABLE (A)
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.
F — "Amnesia Stack": changes happened; reasons are unknowable.
C — some ADRs or meaningful commits; traceability has gaps.
A — clear ADR coverage; meaningful commits; decisions traceable.
VERIFIABLE (V)
Do tests bind specification to behavior?
Look for: test files, coverage %, whether tests describe behavior vs.
internals, integration and e2e tests alongside unit tests.
F — "Unbound Spec": no structural link between spec and running code.
C — unit tests present; minimal behavior-level coverage.
A — tests at multiple layers that verify use-case behavior.
EXECUTABLE (E)
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?
F — "Frozen Spec": specification is prose that nothing executes.
C — runnable but requires manual steps or tribal knowledge.
A — clean clone → running in one command; CI enforces it.
DEFENDED (D)
Are the rules enforced, not merely suggested?
Look for: quality gates that fail the build rather than only warn, input
validation at trust boundaries, secrets in env files not hardcoded, error
handling that does not leak internals.
F — "Open Gates": gates are advisory; a failing check can be skipped under
deadline, and the system accepts and leaks without enforcement.
C — some enforcement; trust boundary is unclear or inconsistent.
A — gates fail the build; trust boundary defined; input validated; secrets managed.
═══ ENGINEERING LAYER — what keeps SAVED true ═══
BOUNDED
Do files, functions, and modules stay within size discipline?
Look for: files over 400 lines, functions over 50 lines, modules with
multiple responsibilities.
F — "Spreading Boundary": no size discipline; modules grow unchecked.
C — most modules bounded; notable outliers exist.
A — 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.
F — "Tangled Web": changing one module triggers cascading effects.
C — some coupling present but modules are isolatable with effort.
A — clear interface boundaries; no circular deps; coupling explicit.
──────────────────────────────────────
SECTION 2 — REPORT CARD SUMMARY
──────────────────────────────────────
OVERALL GRADE — one SAVED grade, a single letter (for example B-), for the
five audit-facing properties, judged holistically (do not average to a
number), with the engineering layer noted separately. Add one line of
confidence: how much of the grade rests on evidence you verified directly
versus attestations you could not probe.
Then, in prose, bounded so two runs stay comparable:
STRENGTHS — the two or three properties the codebase can already stand behind.
WEAKNESSES — the two or three that would not survive scrutiny, each named
with its disease AND the concrete risk it creates.
PRIORITIES — the top three fixes, in order of leverage (impact over effort),
naming which are prerequisites for the others (Self-describing
and Bounded are usually first). The full ordered plan is Section 8.
BLIND SPOTS — what this audit could not verify: evidence that lives outside
the repo and was not provided (observability, CI branch
protection, IaC in another repo). This lowers stated confidence
and is never a silent F.
──────────────────────────────────────
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 — BOLETÍN SAVED
──────────────────────────────────────
Calificá cada propiedad de A a F, como un boletín escolar.
A = ejemplar; evidencia clara y reproducible
B = sólido; solo brechas menores
C = presente pero inconsistente; intención visible, implementación incompleta
D = flojo; mayormente ausente, solo señales aisladas
F = ausente o severamente deficiente — nombrá la enfermedad de falla
Las cinco propiedades que ve el auditor deletrean SAVED. Dos más, Acotado y
Componible, son la capa de ingeniería debajo que mantiene SAVED cierto.
Calificá las siete.
Para cada propiedad: nota · hallazgo en una oración · citación file:line ·
un siguiente paso específico para subirla una nota.
═══ SAVED — las cinco que ve el auditor ═══
AUTO-DESCRIPTIVO (S)
¿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).
F — "Mapa Vacío": toda la intención vive en cabezas; la base no puede
explicarse sola.
C — existen algunos docs; la intención aún debe inferirse del código.
A — spec + ADRs + constitución arquitectónica presentes y actuales.
AUDITABLE (A)
¿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.
F — "Pila Amnésica": los cambios ocurrieron; las razones son incognoscibles.
C — algunos ADRs o commits significativos; trazabilidad con brechas.
A — cobertura clara de ADRs; commits significativos; decisiones trazables.
VERIFICABLE (V)
¿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.
F — "Spec Sin Límites": sin conexión estructural entre spec y código en
ejecución.
C — pruebas unitarias presentes; cobertura de comportamiento mínima.
A — pruebas en múltiples capas que verifican comportamiento de casos de uso.
EJECUTABLE (E)
¿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?
F — "Spec Congelada": la especificación es prosa que nada ejecuta.
C — ejecutable pero requiere pasos manuales o conocimiento tribal.
A — clone limpio → corriendo en un comando; CI lo refuerza.
DEFENDIDO (D)
¿Las reglas se aplican, no solo se sugieren?
Busca: quality gates que hacen fallar el build en vez de solo advertir,
validación de input en límites de confianza, secretos en archivos de
entorno no hardcodeados, manejo de errores que no filtra internos.
F — "Puertas Abiertas": los gates son consultivos; un check que falla se
puede saltar bajo presión, y el sistema acepta y filtra sin enforcement.
C — algo de enforcement; el límite de confianza es poco claro o inconsistente.
A — los gates hacen fallar el build; límite de confianza definido; input
validado; secretos manejados.
═══ CAPA DE INGENIERÍA — lo que mantiene SAVED cierto ═══
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.
F — "Frontera Expansiva": sin disciplina de tamaño; módulos crecen sin control.
C — la mayoría de módulos acotados; existen excepciones notables.
A — 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.
F — "Red Enmarañada": cambiar un módulo desencadena efectos en cascada.
C — algo de acoplamiento presente pero módulos son aislables.
A — límites de interfaz claros; sin deps circulares; acoplamiento explícito.
──────────────────────────────────────
SECCIÓN 2 — RESUMEN DEL BOLETÍN
──────────────────────────────────────
NOTA GLOBAL — una nota SAVED, una sola letra (por ejemplo B-), para las cinco
propiedades que ve el auditor, juzgada de forma holística (no promedies a un
número), con la capa de ingeniería anotada aparte. Agregá una línea de
confianza: cuánto de la nota se apoya en evidencia que verificaste directamente
versus atestaciones que no pudiste probar.
Después, en prosa, acotado para que dos corridas queden comparables:
FORTALEZAS — las dos o tres propiedades que la base de código ya puede respaldar.
DEBILIDADES — las dos o tres que no sobrevivirían al escrutinio, cada una
nombrada con su enfermedad Y el riesgo concreto que genera.
PRIORIDADES — los tres arreglos de mayor apalancamiento, en orden (impacto
sobre esfuerzo), nombrando cuáles son prerequisito de los otros
(Auto-descriptivo y Acotado suelen ir primero). El plan completo
y ordenado es la Sección 8.
PUNTOS CIEGOS — lo que este audit no pudo verificar: evidencia que vive fuera
del repo y no fue provista (observabilidad, branch protection en
CI, IaC en otro repo). Baja la confianza declarada y nunca es
una F silenciosa.
──────────────────────────────────────
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 · SAVED Report Card
1 · Boletín SAVED
The core of the report. Each of the seven properties gets a letter grade, A through F, against concrete evidence in the code, with the failure disease named at F (Empty Map, Spreading Boundary, Tangled Web, Unbound Spec, Amnesia Stack, Open Gates, Frozen Spec). The five audit-facing ones spell SAVED — Self-describing, Auditable, Verifiable, Executable, Defended — and Bounded and Composable are the engineering layer beneath. Every grade cites file:line, so two independent runs land within one letter grade.
El núcleo del reporte. Cada una de las siete propiedades recibe una nota, de A a F, contra evidencia concreta en el código, nombrando la enfermedad de falla en F (Mapa Vacío, Frontera Expansiva, Red Enmarañada, Spec Sin Límites, Pila Amnésica, Puertas Abiertas, Spec Congelada). Las cinco que ve el auditor deletrean SAVED — Auto-descriptivo, Auditable, Verificable, Ejecutable, Defendido — y Acotado y Componible son la capa de ingeniería debajo. Cada nota cita file:line, de modo que dos corridas independientes quedan dentro de una nota.
2 · Report Card Summary
2 · Resumen del Boletín
The five SAVED properties roll up into one overall grade, a single letter the way a report card gives a final mark, with the engineering layer noted separately and a line of confidence. The report then spells it out in prose: Strengths, Weaknesses with the risk each creates, the top prioritized fixes, and the blind spots the audit could not verify. Together they set the expectation for how much remediation the project needs before it can be trusted to an unattended AI session.
Las cinco propiedades SAVED se resumen en una nota global, una sola letra como la nota final de un boletín, con la capa de ingeniería anotada aparte y una línea de confianza. El reporte lo detalla en prosa: Fortalezas, Debilidades con el riesgo que cada una genera, las prioridades de arreglo, y los puntos ciegos que el audit no pudo verificar. Juntos fijan 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 →