sourcecode 0.1.1__tar.gz → 0.3.0__tar.gz

{sourcecode-0.1.1 → sourcecode-0.3.0}/.gitignore

@@ -13,3 +13,15 @@ build/
 .pytest_cache/
 *.pyc
 /src/*.egg-info/
+
+# Editor / IDE
+.idea/
+.vscode/
+
+# Agent / local tooling state
+.claude/
+.codex/
+
+# OS cruft
+.DS_Store
+Thumbs.db

sourcecode-0.3.0/.planning/ROADMAP.md

@@ -0,0 +1,197 @@
+# Roadmap: Sourcecode
+
+## Descripcion General
+
+Sourcecode se construye en diez fases que van desde el scaffold del proyecto hasta la publicacion y evolucion hacia un scanner de proyectos cada vez mas universal. La Fase 1 entrega una CLI funcional con escaner, seguridad y output estructurado. La Fase 2 implementa los detectores de los 8 ecosistemas principales y el pipeline de deteccion. La Fase 3 anade clasificacion de tipo de proyecto y soporte multi-stack. La Fase 4 pule, prueba sobre proyectos reales y publica en PyPI. La Fase 5 expande cobertura de stacks, ecosistemas y senales. Las Fases 6 a 10 anaden inteligencia opcional para dependencias, grafos internos, documentacion estructurada, metricas de calidad e historia operativa, manteniendo `sourcecode .` como comando base rapido.
+
+## Fases
+
+- [x] **Fase 1: Fundaciones** - CLI instalable, escaner con respeto a .gitignore, schema JSON versionado, redaccion de secretos y packaging
+- [x] **Fase 2: Deteccion Core** - AbstractDetector + detectores para 8 ecosistemas, parseo de manifiestos, deteccion de frameworks y puntos de entrada
+- [x] **Fase 3: Clasificacion y Multi-Stack** - TypeClassifier, soporte monorepo/fullstack y niveles de confianza
+- [x] **Fase 4: Pulido y Publicacion** - Tests de integracion sobre proyectos reales, documentacion, CI/CD y publicacion en PyPI
+- [x] **Fase 5: Scanner Universal** - Ampliar stacks, ecosistemas y senales de deteccion para cubrir mas tipos de proyectos reales
+- [ ] **Fase 6: Dependencias Inteligentes** - Dependencias exactas, transitivas y resolucion multi-ecosistema con `--dependencies`
+- [ ] **Fase 7: Grafos de Codigo** - Grafo de modulos, imports, llamadas y jerarquias estructurales con `--graph-modules`
+- [ ] **Fase 8: Documentacion Extraida** - Docstrings, comentarios y resúmenes de modulos consumibles por IA con `--docs`
+- [ ] **Fase 9: Metricas de Calidad** - LOC, complejidad, tests asociados y cobertura con `--full-metrics`
+- [ ] **Fase 10: Contexto Git y Operativo** - Historia git, volatilidad, CI/CD, Docker y metadata de entorno con `--git-history`
+
+## Detalles de Fases
+
+### Fase 1: Fundaciones
+**Goal**: El usuario puede instalar `sourcemap-gen` via pip, ejecutarlo en cualquier directorio y obtener un JSON/YAML valido con metadatos del proyecto, arbol de ficheros filtrado y sin secretos expuestos.
+**Depends on**: Nothing (primera fase)
+**Requirements**: CLI-01, CLI-02, CLI-03, CLI-04, CLI-05, CLI-06, SCAN-01, SCAN-02, SCAN-03, SCAN-04, SCAN-05, SEC-01, SEC-02, SEC-03, DIST-01, DIST-02, DIST-03, DIST-04, OUT-01, OUT-02, OUT-03, OUT-04
+**Status**: COMPLETE — verified 2026-04-07 (5/5 success criteria)
+**Success Criteria** (what must be TRUE):
+  1. El usuario ejecuta `sourcemap-gen` en la raiz de un proyecto y obtiene JSON valido en stdout sin configuracion previa
+  2. El usuario ejecuta `sourcemap-gen --format yaml --output mapa.yaml` y el fichero se genera con el mismo schema que el JSON
+  3. El arbol de ficheros en el output no contiene entradas de `node_modules/`, `.git/`, `__pycache__/`, `venv/` ni artefactos de build
+  4. El usuario ejecuta `sourcemap-gen --compact` y el output tiene como maximo ~500 tokens con tipo de proyecto, stack principal, puntos de entrada y arbol de primer nivel
+  5. El output nunca expone valores de ficheros `.env` ni patrones de secreto conocidos (`ghp_`, `sk-`, `AKIA`); el schema incluye `schema_version: "1.0"`
+**Plans**: 4 planes
+
+Plans:
+- [x] 01-01-PLAN.md — Scaffold Python: pyproject.toml con hatchling, src-layout, CLI Typer con todos los flags (CLI-01..06, DIST-01..04)
+- [x] 01-02-PLAN.md — Scanner de ficheros: FileScanner con pathspec/GitIgnoreSpec, exclusiones por defecto, symlinks, profundidad (SCAN-01..05)
+- [x] 01-03-PLAN.md — Schema JSON v1.0 y serializer: dataclasses AnalysisMetadata+SourceMap, to_json/to_yaml/compact_view (OUT-01..04)
+- [x] 01-04-PLAN.md — Redactor de secretos e integracion CLI: SecretRedactor, conexion scanner+schema+redactor+serializer en main() (SEC-01..03)
+
+### Fase 2: Deteccion Core
+**Goal**: La herramienta detecta el stack tecnologico y los frameworks de los 8 ecosistemas principales (Node.js, Python, Go, Rust, Java, PHP, Ruby, Dart) parseando ficheros indicadores y manifiestos, e identifica los puntos de entrada del proyecto.
+**Depends on**: Fase 1
+**Requirements**: DETECT-01, DETECT-02, DETECT-03, DETECT-04
+**Success Criteria** (what must be TRUE):
+  1. Ejecutado sobre un proyecto Next.js, el output incluye `stack: nodejs`, `frameworks: [Next.js]`, `package_manager: pnpm/npm/yarn` sin ejecutar ningun codigo del proyecto
+  2. Ejecutado sobre un proyecto FastAPI, el output incluye `stack: python`, `frameworks: [FastAPI]` inferido del `pyproject.toml` o `requirements.txt`
+  3. Ejecutado sobre un proyecto sin manifiesto formal (solo ficheros `.py` sueltos), el output incluye `stack: python` con `detection_method: heuristic` inferido por extension de fichero
+  4. El output incluye `entry_points` con al menos un punto de entrada valido para proyectos Node.js, Python, Go y Rust (inferido de manifiestos o patrones de nombre)
+**Plans**: 4 planes
+
+Plans:
+- [x] 02-01: `AbstractDetector` + orquestador — clase base con contrato `can_detect`/`detect`, `DetectionResult` con stack/confidence/frameworks/package_manager, orquestador `ProjectDetector` que ejecuta todos los detectores sobre el file index
+- [x] 02-02: Detectores Node.js y Python — `NodejsDetector` (package.json, tsconfig, lock files; frameworks via deps: react/next/express/fastapi-equivalentes), `PythonDetector` (pyproject.toml, requirements.txt, setup.py, Pipfile, uv.lock; frameworks: django/flask/fastapi/typer)
+- [x] 02-03: Detectores Go, Rust y Java — `GoDetector` (go.mod, cmd/; frameworks: gin/echo/cobra), `RustDetector` (Cargo.toml, src/main.rs vs src/lib.rs; frameworks: axum/actix/clap), `JavaDetector` (pom.xml, build.gradle; frameworks: spring-boot/quarkus/android)
+- [x] 02-04: Detectores PHP, Ruby y Dart — `PhpDetector` (composer.json, artisan; frameworks: laravel/symfony), `RubyDetector` (Gemfile, config/routes.rb; frameworks: rails/sinatra), `DartDetector` (pubspec.yaml, lib/main.dart; flutter vs dart puro); deteccion heuristica por extension como fallback universal (DETECT-03)
+**UI hint**: no
+
+### Fase 3: Clasificacion y Multi-Stack
+**Goal**: El output refleja correctamente proyectos multi-stack y monorepos, clasifica el tipo de proyecto (webapp/api/library/cli/monorepo/fullstack/unknown) e incluye niveles de confianza en cada deteccion.
+**Depends on**: Fase 2
+**Requirements**: DETECT-05, DETECT-06, DETECT-07, OUT-05
+**Success Criteria** (what must be TRUE):
+  1. Ejecutado sobre un monorepo con `pnpm-workspace.yaml` o `go.work`, el output tiene `project_type: monorepo` y lista los sub-proyectos con sus propios stacks
+  2. Ejecutado sobre un proyecto fullstack (Next.js + FastAPI en el mismo repo), el output lista ambos stacks con `primary: true/false` en lugar de reportar solo uno
+  3. Cada stack detectado incluye `confidence: high|medium|low` basado en el numero y peso de los indicadores encontrados
+  4. Ejecutado sobre un directorio sin ningun manifiesto conocido, el output es JSON valido con `detection_confidence: low` y `project_type: unknown` en lugar de error
+**Plans**: 2 planes
+
+Plans:
+- [x] 03-01: `TypeClassifier` — logica de clasificacion webapp/api/library/cli/monorepo/fullstack/unknown basada en senales (directorios pages/, routes/, components/, presencia de bin en package.json, src/lib.rs, etc.); niveles de confianza high/medium/low por numero y peso de indicadores (DETECT-06, DETECT-07)
+- [x] 03-02: Soporte monorepo y multi-stack — deteccion de senales de monorepo (pnpm-workspace.yaml, go.work, Cargo.toml [workspace], lerna.json, turbo.json); analisis recursivo limitado a profundidad 3; output estructurado con lista de workspaces y sus stacks (DETECT-05); proyectos sin manifiesto emiten output valido con confidence low (OUT-05)
+**UI hint**: no
+
+### Fase 4: Pulido y Publicacion
+**Goal**: La herramienta supera tests de integracion sobre proyectos reales de los stacks principales, tiene documentacion de usuario completa y esta publicada en PyPI como `sourcemap-gen`.
+**Depends on**: Fase 3
+**Requirements**: (ninguno nuevo — esta fase valida y publica lo construido en las fases anteriores)
+**Success Criteria** (what must be TRUE):
+  1. Los tests de integracion sobre proyectos reales (un repo Next.js, un repo FastAPI, un repo Go, un monorepo) pasan en CI sin fallos
+  2. `pip install sourcemap-gen` en Python 3.9, 3.10, 3.11 y 3.12 instala la herramienta correctamente y `sourcemap-gen --version` devuelve la version
+  3. El README explica en menos de 5 minutos de lectura como instalar, usar y que contiene el output; la documentacion del schema esta disponible en el repositorio
+  4. El repositorio tiene CI/CD con GitHub Actions que ejecuta tests en la matriz Python 3.9-3.12 y publica a PyPI automaticamente en cada tag de release
+**Status**: COMPLETE — implemented 2026-04-07; pytest green, docs and workflows added, lint/type debt remains visible in CI
+**Plans**: 3 planes
+
+Plans:
+- [x] 04-01: Tests de integracion — suite de tests contra proyectos reales como fixtures (Next.js, FastAPI, Go stdlib, monorepo pnpm); verificacion del schema completo y smoke de packaging local
+- [x] 04-02: Documentacion de usuario — README con instalacion, uso rapido, descripcion del schema y ejemplos de output; documentacion del schema JSON v1.0 en `docs/schema.md`
+- [x] 04-03: CI/CD y publicacion PyPI — GitHub Actions con matriz Python 3.9-3.12 (lint, typecheck, tests); publicacion automatizada via trusted publishing (OIDC) para TestPyPI/PyPI
+**UI hint**: no
+
+## Progreso
+
+### Fase 5: Scanner Universal
+**Goal**: La herramienta aumenta significativamente su cobertura y se comporta mas cerca de un scanner universal, detectando mas ecosistemas, manifests, build systems y senales heuristicas en proyectos reales que hoy quedan como `unknown` o parcialmente clasificados.
+**Depends on**: Fase 4
+**Requirements**: DETECT-08, DETECT-09, DETECT-10, OUT-06
+**Success Criteria** (what must be TRUE):
+  1. Ejecutado sobre proyectos de ecosistemas adicionales o tooling menos comun, la herramienta detecta correctamente el stack principal sin depender de un unico manifiesto convencional
+  2. Ejecutado sobre repos con combinaciones de manifests/build files (`Dockerfile`, `Makefile`, `Procfile`, `bun.lockb`, `poetry.lock`, `composer.lock`, `Gemfile.lock`, etc.), el output usa esas senales para elevar confianza o completar clasificacion
+  3. Ejecutado sobre proyectos mixtos o legacy con estructura irregular, la herramienta reduce de forma visible los casos `project_type: unknown` y `stacks: []`
+  4. El schema conserva compatibilidad hacia atras, pero incorpora senales mas expresivas para justificar detecciones multi-fuente
+**Status**: COMPLETE — implemented 2026-04-07; new stacks added, universal signals integrated, full suite green
+**Plans**: 4 planes
+
+Plans:
+- [x] 05-01: Base universal de senales — manifests alternativos, tooling transversal, scoring multi-fuente y deduplicacion del pipeline
+- [x] 05-02: Nuevos ecosistemas managed — detectores para .NET/C#, Elixir/Phoenix y JVM ampliado (Kotlin/Scala)
+- [x] 05-03: Ecosistemas infra/systems — Terraform, C/C++, build files y capa de tooling universal
+- [x] 05-04: Integracion universal end-to-end — fixtures adicionales, fusion heuristica final y regresion completa de CLI/suite
+**UI hint**: no
+
+### Fase 6: Dependencias Inteligentes
+**Goal**: La herramienta puede enumerar dependencias externas con versiones exactas y, cuando haya lockfiles o metadata suficiente, resolver tambien dependencias transitivas sin sacrificar la velocidad del comando base.
+**Depends on**: Fase 5
+**Requirements**: DEPS-01, DEPS-02, DEPS-03, OUT-07
+**Success Criteria** (what must be TRUE):
+  1. Ejecutado como `sourcecode . --dependencies` sobre proyectos Python, Node.js, PHP, Ruby, Rust, Go y .NET, el output lista dependencias directas con nombre, version exacta o constraint y origen del dato (`manifest`, `lockfile`, `tooling`)
+  2. Cuando existe lockfile compatible (`package-lock.json`, `pnpm-lock.yaml`, `poetry.lock`, `uv.lock`, `Gemfile.lock`, `composer.lock`, etc.), el output incluye dependencias transitivas y las relaciona con su dependencia padre o grafo de resolucion
+  3. El comando base `sourcecode .` mantiene su latencia habitual y no resuelve arboles transitivos salvo que el usuario active `--dependencies`
+  4. El schema expone dependencias de forma uniforme entre ecosistemas para que agentes IA puedan detectar incompatibilidades, duplicados o riesgos de version
+**Status**: COMPLETE — implemented 2026-04-08; dependency analysis integrated behind `--dependencies`, full suite green
+**Plans**: 4 planes
+
+Plans:
+- [x] 06-01: Base de dependencias — schema, flag `--dependencies` y analizador lazy desacoplado
+- [x] 06-02: Node.js y Python — manifests + lockfiles con deps directas, resueltas y transitivas
+- [x] 06-03: PHP, Ruby, Rust, Go y .NET — cobertura polyglot con limites explicitos donde la transitividad offline sea parcial
+- [x] 06-04: Integracion final — workspaces/monorepo, tests end-to-end y documentacion publica del contrato
+**UI hint**: no
+
+### Fase 7: Grafos de Codigo
+**Goal**: La herramienta construye una vista estructural del codigo con relaciones entre modulos, imports, llamadas y jerarquias basicas para ayudar a agentes y humanos a entender flujo y acoplamiento.
+**Depends on**: Fase 6
+**Requirements**: GRAPH-01, GRAPH-02, GRAPH-03, OUT-08
+**Success Criteria** (what must be TRUE):
+  1. Ejecutado como `sourcecode . --graph-modules`, el output incluye un grafo de imports internos entre modulos o paquetes del proyecto en al menos Python, Node.js/TypeScript, Java y Go cuando la informacion estatico-sintactica sea suficiente
+  2. El output identifica nodos clave como funciones top-level, clases o entry points y, cuando sea factible con analisis seguro, relaciones de llamada o uso entre ellos
+  3. En proyectos grandes o multi-stack, el analisis se degrada con seguridad mediante limites de profundidad/tamano en lugar de bloquearse o intentar parseo total no acotado
+  4. El schema deja claro el nivel de confianza y el metodo de construccion del grafo (`ast`, `heuristic`, `unresolved`) para que el consumidor sepa cuanto confiar en cada arista
+**Plans**: 0 planes
+**UI hint**: no
+
+### Fase 8: Documentacion Extraida
+**Goal**: La herramienta extrae documentacion util del codigo y la transforma en un resumen estructurado por modulo, clase o funcion para consumo de agentes IA y onboarding tecnico.
+**Depends on**: Fase 7
+**Requirements**: DOCS-01, DOCS-02, DOCS-03, OUT-09
+**Success Criteria** (what must be TRUE):
+  1. Ejecutado como `sourcecode . --docs`, el output incluye docstrings, comentarios de cabecera y descripciones resumidas por modulo para lenguajes soportados donde el parseo sea fiable
+  2. El output distingue entre documentacion explicita del autor y resumen inferido por la herramienta para evitar mezclar texto original con interpretaciones
+  3. Los modulos principales del proyecto incluyen un resumen compacto con proposito, simbolos destacados y relaciones con otros componentes
+  4. El schema sigue siendo consumible por maquinas y evita volcar bloques enormes de texto sin estructura ni procedencia
+**Plans**: 0 planes
+**UI hint**: no
+
+### Fase 9: Metricas de Calidad
+**Goal**: La herramienta aporta senales cuantitativas sobre complejidad, tamano, tests y cobertura para priorizar refactors, auditorias y trabajo de agentes automaticos.
+**Depends on**: Fase 8
+**Requirements**: METRICS-01, METRICS-02, METRICS-03, OUT-10
+**Success Criteria** (what must be TRUE):
+  1. Ejecutado como `sourcecode . --full-metrics`, el output incluye lineas por archivo o modulo, recuentos de simbolos y una medida de complejidad al menos para los lenguajes donde haya analisis estatico seguro
+  2. La herramienta detecta archivos o suites de tests relacionadas y asocia modulos productivos con evidencia de cobertura o ausencia de pruebas
+  3. Cuando existe metadata de cobertura (`coverage.xml`, `.coverage`, `lcov.info`, `jacoco.xml`, etc.), el output la incorpora sin ejecutar tests por defecto
+  4. El comando distingue claramente entre metricas medidas, inferidas y no disponibles para no transmitir precision falsa
+**Plans**: 0 planes
+**UI hint**: no
+
+### Fase 10: Contexto Git y Operativo
+**Goal**: La herramienta añade contexto historico y operativo del repositorio para identificar volatilidad, expertos, integraciones de despliegue y superficie de automatizacion.
+**Depends on**: Fase 9
+**Requirements**: GIT-01, OPS-01, OPS-02, OUT-11
+**Success Criteria** (what must be TRUE):
+  1. Ejecutado como `sourcecode . --git-history`, el output resume commits recientes, autores, frecuencia de cambio y archivos o modulos mas volatiles sin requerir llamadas de red
+  2. La herramienta identifica configuraciones operativas relevantes como `Dockerfile`, `docker-compose`, workflows de GitHub Actions, Terraform, Helm, Makefiles o scripts de despliegue y los agrega como metadata estructurada
+  3. Las variables de entorno o secretos solo se reportan como metadata segura (`nombre`, `origen`, `uso aproximado`) sin exponer valores sensibles
+  4. El comando base `sourcecode .` sigue centrado en estructura + stacks + workflows, mientras que el contexto historico/operativo ampliado queda detras de flags explicitamente solicitados
+**Plans**: 0 planes
+**UI hint**: no
+
+## Progreso
+
+**Orden de ejecucion:**
+Las fases se ejecutan en orden numerico: 1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9 → 10
+
+| Fase | Planes Completos | Estado | Completada |
+|------|-----------------|--------|------------|
+| 1. Fundaciones | 4/4 | Complete   | 2026-04-07 |
+| 2. Deteccion Core | 4/4 | Complete   | 2026-04-07 |
+| 3. Clasificacion y Multi-Stack | 2/2 | Complete   | 2026-04-07 |
+| 4. Pulido y Publicacion | 3/3 | Complete   | 2026-04-07 |
+| 5. Scanner Universal | 4/4 | Complete   | 2026-04-07 |
+| 6. Dependencias Inteligentes | 4/4 | Complete | 2026-04-08 |
+| 7. Grafos de Codigo | 0/0 | Not planned | - |
+| 8. Documentacion Extraida | 0/0 | Not planned | - |
+| 9. Metricas de Calidad | 0/0 | Not planned | - |
+| 10. Contexto Git y Operativo | 0/0 | Not planned | - |

{sourcecode-0.1.1 → sourcecode-0.3.0}/.planning/STATE.md

@@ -2,16 +2,16 @@
 gsd_state_version: 1.0
 milestone: v1.0
 milestone_name: milestone
-status: completed
-stopped_at: Phase 04 execution complete — pytest green; docs and workflows added
-last_updated: "2026-04-07T19:44:13.490Z"
-last_activity: 2026-04-07 -- Phase 04 completed
+status: in_progress
+stopped_at: Phase 05 execution complete; roadmap extended with future universal-analysis phases
+last_updated: "2026-04-08T10:10:00.000Z"
+last_activity: 2026-04-08 -- Phase 06 completed
 progress:
-  total_phases: 4
-  completed_phases: 4
-  total_plans: 13
-  completed_plans: 13
-  percent: 100
+  total_phases: 10
+  completed_phases: 6
+  total_plans: 21
+  completed_plans: 21
+  percent: 60
 ---
 
 # Project State
@@ -21,16 +21,16 @@ progress:
 See: .planning/PROJECT.md (updated 2026-04-07)
 
 **Core value:** Un agente IA que recibe el output de esta herramienta llega al proyecto ya informado — no necesita preguntar lo obvio ni explorar ciegamente el codigo.
-**Current focus:** Milestone complete — publication handoff
+**Current focus:** Fase 06 completada; siguiente paso natural: planificar grafos de codigo
 
 ## Current Position
 
-Phase: 04 (pulido-y-publicacion) — COMPLETE
-Plan: 3 of 3
-Status: Phase 04 complete
-Last activity: 2026-04-07 -- Phase 04 completed
+Phase: 06 (dependencias-inteligentes) — COMPLETE
+Plan: 4 of 4
+Status: Phase 06 complete
+Last activity: 2026-04-08 -- Phase 06 completed
 
-Progress: [██████████] 100%
+Progress: [██████░░░░] 60%
 
 ## Performance Metrics
 
@@ -48,18 +48,19 @@ Progress: [██████████] 100%
 | Phase 02 Deteccion Core | 4 | ~1 h | ~15 min |
 | Phase 03 Clasificacion y Multi-Stack | 2 | ~35 min | ~17.5 min |
 | Phase 04 Pulido y Publicacion | 3 | ~43 min | ~14.3 min |
+| Phase 05 Scanner Universal | 4 | ~1 h | ~15 min |
 
 **Recent Trend:**
 
-- Last 5 plans: 03-01, 03-02, 04-01, 04-02, 04-03
-- Trend: estable; pytest green en cierre de milestone, deuda de lint/type pendiente
+- Last 5 plans: 04-03, 05-01, 05-02, 05-03, 05-04
+- Trend: estable; ruff, mypy y pytest verdes tras ampliacion universal
 
 *Updated after phase verification*
-| Phase 03 P01 | 18 min | 3 tasks | 8 files |
-| Phase 03 P02 | 17 min | 3 tasks | 7 files |
-| Phase 04 P01 | 17 min | 3 tasks | 14 files |
-| Phase 04 P02 | 14 min | 2 tasks | 2 files |
 | Phase 04 P03 | 12 min | 2 tasks | 2 files |
+| Phase 05 P01 | 18 min | 2 tasks | 5 files |
+| Phase 05 P02 | 19 min | 3 tasks | 5 files |
+| Phase 05 P03 | 14 min | 3 tasks | 4 files |
+| Phase 05 P04 | 16 min | 3 tasks | 4 files |
 
 ## Accumulated Context
 
@@ -82,7 +83,18 @@ Recent decisions affecting current work:
 
 ### Pending Todos
 
-- Deuda de lint/type preexistente visible en `ruff` y `mypy`; no bloquea los tests de producto pero afectara CI hasta limpiarla.
+None.
+
+### Roadmap Evolution
+
+- Phase 5 added: Scanner universal — ampliar stacks, ecosistemas y senales de deteccion para mas tipos de proyectos.
+- Phase 6 added: Dependencias inteligentes — versiones exactas, transitivas y resolucion multi-ecosistema bajo `--dependencies`.
+- Phase 7 added: Grafos de codigo — imports, llamadas y estructura navegable bajo `--graph-modules`.
+- Phase 8 added: Documentacion extraida — docstrings, comentarios y resúmenes estructurados bajo `--docs`.
+- Phase 9 added: Metricas de calidad — LOC, complejidad, tests y cobertura bajo `--full-metrics`.
+- Phase 10 added: Contexto git y operativo — historia reciente, volatilidad, CI/CD y metadata segura bajo `--git-history`.
+- Phase 6 planned in 4 planes: base de schema/CLI, Node+Python, ecosistemas polyglot y cierre end-to-end con workspaces/docs.
+- Phase 6 completed: `--dependencies` ahora expone versiones declaradas/resueltas, transitivas conservadoras y contexto por workspace.
 
 ### Blockers/Concerns
 
@@ -93,4 +105,4 @@ None.
 Last session: 2026-04-07T19:37:00Z
 Stopped at: Phase 04 execution complete — pytest green; docs and workflows added
 Resume file: None
-Next action: Audit milestone or prepare PR/release configuration
+Next action: /gsd:plan-phase 7

sourcecode-0.3.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-01-PLAN.md

@@ -0,0 +1,146 @@
+---
+phase: 05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - src/sourcecode/detectors/parsers.py
+  - src/sourcecode/detectors/project.py
+  - src/sourcecode/classifier.py
+  - src/sourcecode/schema.py
+  - src/sourcecode/cli.py
+  - tests/test_schema.py
+  - tests/test_classifier.py
+autonomous: true
+requirements:
+  - DETECT-08
+  - DETECT-09
+  - OUT-06
+
+must_haves:
+  truths:
+    - "El pipeline puede ingerir manifests alternativos y senales multi-fuente sin romper el contrato actual"
+    - "Las nuevas evidencias se reflejan de forma trazable en `signals`"
+    - "La clasificacion no duplica stacks ni sobrestima confianza por tooling debil"
+  artifacts:
+    - path: "src/sourcecode/detectors/project.py"
+      provides: "Fusion base de senales universales y deduplicacion"
+    - path: "src/sourcecode/classifier.py"
+      provides: "Reglas de confianza actualizadas para evidencia multi-fuente"
+    - path: "tests/test_classifier.py"
+      provides: "Cobertura de scoring multi-senal"
+  key_links:
+    - from: "src/sourcecode/detectors/project.py"
+      to: "src/sourcecode/classifier.py"
+      via: "El pipeline central agrega y pondera senales antes de clasificar"
+      pattern: "signals|confidence|classify"
+---
+
+<objective>
+Preparar la base del scanner universal sin introducir todavia todos los stacks nuevos: manifests alternativos, senales compartidas y reglas de fusion para que las siguientes oleadas se apoyen en una infraestructura estable.
+
+Purpose: Evitar que la fase 5 sea solo una suma de detectores independientes y fijar una semantica comun de evidencia.
+
+Output: pipeline base ampliado, scoring ajustado y tests que cubren senales multi-fuente.
+</objective>
+
+<execution_context>
+@.codex/get-shit-done/workflows/execute-plan.md
+@.codex/get-shit-done/templates/summary.md
+</execution_context>
+
+<context>
+@.planning/ROADMAP.md
+@.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-RESEARCH.md
+@src/sourcecode/schema.py
+@src/sourcecode/classifier.py
+@src/sourcecode/detectors/project.py
+@src/sourcecode/detectors/parsers.py
+</context>
+
+<tasks>
+
+<task type="auto" tdd="true">
+  <name>Tarea 1: Inventario de manifests alternativos y senales compartidas</name>
+  <files>src/sourcecode/detectors/parsers.py, src/sourcecode/detectors/project.py, tests/test_classifier.py</files>
+
+  <behavior>
+    - lockfiles y build files pueden convertirse en evidencia reutilizable
+    - la infraestructura distingue entre manifest canonico, lockfile y tooling
+  </behavior>
+
+  <action>
+Crear tests RED para casos como:
+
+- `poetry.lock` sin `pyproject.toml`
+- `bun.lockb` junto a `package.json`
+- `Gemfile.lock` o `composer.lock` complementando manifests
+- `Dockerfile` y `Makefile` como senales auxiliares, no como stack primario
+
+Implementar helpers compartidos para leer y etiquetar estas senales sin duplicar logica en cada detector.
+  </action>
+
+  <verify>
+    <automated>.venv/bin/python -m pytest tests/test_classifier.py -q</automated>
+  </verify>
+
+  <acceptance_criteria>
+    - Existe una forma comun de representar evidencia multi-fuente
+    - Las senales auxiliares no generan stacks espurios por si solas
+  </acceptance_criteria>
+
+  <done>La base del pipeline ya entiende manifests alternativos y tooling compartido.</done>
+</task>
+
+<task type="auto" tdd="true">
+  <name>Tarea 2: Ajustar scoring y deduplicacion del pipeline</name>
+  <files>src/sourcecode/classifier.py, src/sourcecode/detectors/project.py, tests/test_classifier.py, tests/test_schema.py</files>
+
+  <behavior>
+    - un stack con manifest canonico + lockfile gana confianza frente a uno solo heuristico
+    - varias senales del mismo stack se fusionan en una sola deteccion
+    - el schema mantiene compatibilidad
+  </behavior>
+
+  <action>
+Crear tests RED para:
+
+- una deteccion Python con `pyproject.toml` + `poetry.lock`
+- una deteccion Node.js con `package.json` + `bun.lockb`
+- un repositorio con `Dockerfile` + `Makefile` pero sin lenguaje claro
+
+Implementar reglas de score y fusion que:
+
+- eleven confianza solo cuando la evidencia sea coherente;
+- deduzcan package manager si aplica;
+- sigan dejando `confidence=low` cuando la evidencia sea solo estructural.
+  </action>
+
+  <verify>
+    <automated>.venv/bin/python -m pytest tests/test_classifier.py tests/test_schema.py -q</automated>
+  </verify>
+
+  <acceptance_criteria>
+    - La confianza refleja calidad de evidencia, no solo cantidad de archivos
+    - El schema no necesita romper `1.0`
+  </acceptance_criteria>
+
+  <done>La infraestructura queda lista para recibir mas detectores sin degradar calidad.</done>
+</task>
+
+</tasks>
+
+<verification>
+## Verificacion global
+
+- `.venv/bin/python -m pytest tests/test_classifier.py tests/test_schema.py -q`
+- revisar serializacion de `signals` y `manifests` multi-fuente
+</verification>
+
+<success_criteria>
+## Success Criteria
+
+- Existe infraestructura comun para evidencia multi-fuente
+- La confianza y deduplicacion mejoran antes de anadir nuevos stacks
+</success_criteria>

sourcecode-0.3.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-01-SUMMARY.md

@@ -0,0 +1,53 @@
+---
+phase: 05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de
+plan: 01
+subsystem: detection-core
+tags: [signals, scoring, package-managers, fusion]
+requires:
+  - phase: 04-pulido-y-publicacion
+    provides: stable CLI, tests, package name sourcecode
+provides:
+  - Senales universales de tooling
+  - Fusion de signals en ProjectDetector
+  - Scoring ampliado para stacks nuevos
+affects: [detection, classification, schema]
+tech-stack:
+  added: []
+  patterns: [multi-source-evidence, tooling-signals]
+key-files:
+  created:
+    - src/sourcecode/detectors/tooling.py
+  modified:
+    - src/sourcecode/detectors/project.py
+    - src/sourcecode/classifier.py
+    - src/sourcecode/detectors/nodejs.py
+    - src/sourcecode/detectors/python.py
+key-decisions:
+  - "Las senales operativas se expresan en `signals` y no crean stacks por si solas"
+  - "Los package managers se infieren tambien por lockfiles y tooling, no solo por manifests canonicos"
+patterns-established:
+  - "ProjectDetector fusiona manifests, frameworks y signals antes de clasificar"
+requirements-completed: [DETECT-08, DETECT-09, OUT-06]
+duration: 18min
+completed: 2026-04-07
+---
+
+# Phase 05-01 Summary
+
+**Base universal de senales y fusion multi-fuente**
+
+## Accomplishments
+
+- Se creo `tooling.py` para recolectar senales universales como `Dockerfile`, `Taskfile`, `Procfile` y `Makefile`.
+- `ProjectDetector` ahora fusiona `signals` al mezclar stacks y enriquece las detecciones con contexto operativo.
+- Node.js y Python mejoraron inferencia de package manager con `bun.lockb`, `poetry.lock`, `Pipfile.lock` y `uv.lock`.
+- El clasificador aprendio extensiones y prioridades para stacks nuevos (`dotnet`, `elixir`, `kotlin`, `scala`, `terraform`, `cpp`).
+
+## Verification
+
+- `.venv/bin/ruff check src tests`
+- `.venv/bin/mypy src`
+
+## Notes
+
+- Se mantuvo `schema_version: 1.0`; toda la expresividad nueva viaja por `signals`, `manifests` y `package_manager`.