sourcecode 0.2.0__tar.gz → 0.3.0__tar.gz

{sourcecode-0.2.0 → sourcecode-0.3.0}/.planning/ROADMAP.md

@@ -1,8 +1,8 @@
-# Roadmap: SourceMap Gen
+# Roadmap: Sourcecode
 
 ## Descripcion General
 
-SourceMap Gen se construye en cinco fases que van desde el scaffold del proyecto hasta la publicacion y expansion 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 para acercar la herramienta a un escaner universal.
+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
 
@@ -11,6 +11,11 @@ SourceMap Gen se construye en cinco fases que van desde el scaffold del proyecto
 - [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
 
@@ -106,10 +111,77 @@ Plans:
 - [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
+Las fases se ejecutan en orden numerico: 1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9 → 10
 
 | Fase | Planes Completos | Estado | Completada |
 |------|-----------------|--------|------------|
@@ -118,3 +190,8 @@ Las fases se ejecutan en orden numerico: 1 → 2 → 3 → 4 → 5
 | 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.2.0 → 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-07T21:15:17.169Z"
-last_activity: 2026-04-07 -- Phase 05 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: 5
-  completed_phases: 5
-  total_plans: 17
-  completed_plans: 17
-  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 — universal scanner expansion delivered
+**Current focus:** Fase 06 completada; siguiente paso natural: planificar grafos de codigo
 
 ## Current Position
 
-Phase: 05 (scanner-universal) — COMPLETE
+Phase: 06 (dependencias-inteligentes) — COMPLETE
 Plan: 4 of 4
-Status: Phase 05 complete
-Last activity: 2026-04-07 -- Phase 05 completed
+Status: Phase 06 complete
+Last activity: 2026-04-08 -- Phase 06 completed
 
-Progress: [██████████] 100%
+Progress: [██████░░░░] 60%
 
 ## Performance Metrics
 
@@ -88,6 +88,13 @@ 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
 
@@ -98,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: Publish/release preparation or milestone closure
+Next action: /gsd:plan-phase 7

sourcecode-0.3.0/.planning/phases/06-dependencias-inteligentes/06-01-PLAN.md

@@ -0,0 +1,140 @@
+---
+phase: 06-dependencias-inteligentes
+plan: 01
+type: execute
+wave: 1
+depends_on: []
+files_modified:
+  - src/sourcecode/cli.py
+  - src/sourcecode/schema.py
+  - src/sourcecode/dependency_analyzer.py
+  - src/sourcecode/serializer.py
+  - tests/test_dependency_schema.py
+  - tests/test_cli.py
+autonomous: true
+requirements:
+  - DEPS-01
+  - OUT-07
+
+must_haves:
+  truths:
+    - "La CLI expone `--dependencies` sin encarecer `sourcecode .` por defecto"
+    - "El schema de dependencias es uniforme y compatible hacia atras"
+    - "Existe un analizador desacoplado y lazy para resolucion futura por ecosistema"
+  artifacts:
+    - path: "src/sourcecode/schema.py"
+      provides: "Modelo publico para dependencias y metadata asociada"
+    - path: "src/sourcecode/cli.py"
+      provides: "Flag `--dependencies` e invocacion lazy del analizador"
+    - path: "src/sourcecode/dependency_analyzer.py"
+      provides: "Punto de entrada comun para resolucion por ecosistema"
+    - path: "tests/test_dependency_schema.py"
+      provides: "Cobertura del contrato de salida y defaults"
+---
+
+<objective>
+Preparar la base de la fase 6: contrato de datos, flag CLI y esqueleto de analisis de dependencias sin implementar todavia toda la logica por ecosistema.
+
+Purpose: Crear una infraestructura estable para que las siguientes olas anadan resolutores concretos sin tocar repetidamente el contrato publico.
+
+Output: schema ampliado, CLI opt-in y clase/orquestador base para dependencias.
+</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/06-dependencias-inteligentes/06-RESEARCH.md
+@src/sourcecode/cli.py
+@src/sourcecode/schema.py
+@src/sourcecode/serializer.py
+</context>
+
+<tasks>
+
+<task type="auto" tdd="true">
+  <name>Tarea 1: Extender schema con dependencias y resumen</name>
+  <files>src/sourcecode/schema.py, tests/test_dependency_schema.py</files>
+
+  <behavior>
+    - el output puede incluir dependencias sin romper consumidores actuales
+    - cada dependencia expresa origen, alcance y version declarada/resuelta
+    - el schema diferencia entre "sin datos" y "analisis no solicitado"
+  </behavior>
+
+  <action>
+Crear tests RED para:
+
+- serializacion de una dependencia directa con `declared_version`
+- serializacion de una dependencia transitiva con `resolved_version` y `parent`
+- `SourceMap` sin `--dependencies` sigue siendo valido y compacto
+
+Implementar dataclasses o tipos equivalentes para modelar:
+
+- dependencia individual
+- resumen/agregados del analisis
+- campos opcionales en `SourceMap`
+  </action>
+
+  <verify>
+    <automated>.venv/bin/python -m pytest tests/test_dependency_schema.py -q</automated>
+  </verify>
+
+  <acceptance_criteria>
+    - El contrato de dependencias es consistente y extensible
+    - El schema actual sigue funcionando cuando no se pide analisis de dependencias
+  </acceptance_criteria>
+
+  <done>El modelo de datos de dependencias queda fijado.</done>
+</task>
+
+<task type="auto" tdd="true">
+  <name>Tarea 2: Anadir flag CLI y analizador lazy</name>
+  <files>src/sourcecode/cli.py, src/sourcecode/dependency_analyzer.py, tests/test_cli.py</files>
+
+  <behavior>
+    - `sourcecode . --dependencies` activa analisis detallado
+    - `sourcecode .` no hace trabajo extra ni rellena dependencias por defecto
+    - la integracion es transparente con JSON/YAML y workspaces futuros
+  </behavior>
+
+  <action>
+Crear tests RED para:
+
+- `--dependencies` activa el analizador
+- sin flag, el analizador no se invoca
+- el output sigue siendo valido en JSON y YAML
+
+Implementar el esqueleto de `DependencyAnalyzer` y conectarlo desde la CLI de forma lazy.
+  </action>
+
+  <verify>
+    <automated>.venv/bin/python -m pytest tests/test_cli.py tests/test_dependency_schema.py -q</automated>
+  </verify>
+
+  <acceptance_criteria>
+    - El coste extra queda detras del flag
+    - La base del pipeline de dependencias queda lista para ecosistemas concretos
+  </acceptance_criteria>
+
+  <done>La CLI ya tiene la puerta de entrada para dependencia inteligente.</done>
+</task>
+
+</tasks>
+
+<verification>
+## Verificacion global
+
+- `.venv/bin/python -m pytest tests/test_dependency_schema.py tests/test_cli.py -q`
+- validar que `sourcecode .` sin flag no serializa bloque pesado de dependencias
+</verification>
+
+<success_criteria>
+## Success Criteria
+
+- Existe un contrato estable para dependencias
+- `--dependencies` queda integrado como opcion opt-in y lazy
+</success_criteria>

sourcecode-0.3.0/.planning/phases/06-dependencias-inteligentes/06-01-SUMMARY.md

@@ -0,0 +1,52 @@
+---
+phase: 06-dependencias-inteligentes
+plan: 01
+subsystem: api
+tags: [dependencies, schema, cli, lazy-loading]
+requires:
+  - phase: 05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de
+    provides: scanner multi-stack, workspaces, schema estable
+provides:
+  - Modelo publico de dependencias
+  - Flag CLI `--dependencies`
+  - DependencyAnalyzer base
+affects: [schema, cli, output]
+tech-stack:
+  added: []
+  patterns: [lazy-analysis, backward-compatible-schema]
+key-files:
+  created:
+    - src/sourcecode/dependency_analyzer.py
+    - tests/test_dependency_schema.py
+  modified:
+    - src/sourcecode/schema.py
+    - src/sourcecode/cli.py
+    - tests/test_cli.py
+key-decisions:
+  - "El analisis de dependencias queda detras de `--dependencies` para no encarecer `sourcecode .`"
+  - "El schema diferencia entre `declared_version` y `resolved_version`"
+patterns-established:
+  - "Bloques opcionales del schema activados por flags sin romper compatibilidad"
+requirements-completed: [DEPS-01, OUT-07]
+duration: 15min
+completed: 2026-04-08
+---
+
+# Phase 06-01 Summary
+
+**Base de dependencias: schema, CLI y analizador lazy**
+
+## Accomplishments
+
+- Se añadieron `DependencyRecord` y `DependencySummary` al schema publico.
+- La CLI incorpora `--dependencies` y solo ejecuta el analizador cuando el usuario lo pide.
+- Se creo `DependencyAnalyzer` como punto de entrada desacoplado para los resolutores por ecosistema.
+- Quedo cubierta la compatibilidad hacia atras con tests del schema y de la ayuda del CLI.
+
+## Verification
+
+- `.venv/bin/python -m pytest tests/test_dependency_schema.py tests/test_cli.py -q`
+
+## Notes
+
+- `--compact` sigue sin incluir dependencias para preservar rapidez y salida breve.

sourcecode-0.3.0/.planning/phases/06-dependencias-inteligentes/06-02-PLAN.md

@@ -0,0 +1,135 @@
+---
+phase: 06-dependencias-inteligentes
+plan: 02
+type: execute
+wave: 2
+depends_on:
+  - 06-01
+files_modified:
+  - src/sourcecode/dependency_analyzer.py
+  - src/sourcecode/detectors/parsers.py
+  - tests/test_dependency_analyzer_node_python.py
+  - tests/test_integration_dependencies.py
+autonomous: true
+requirements:
+  - DEPS-01
+  - DEPS-02
+  - DEPS-03
+
+must_haves:
+  truths:
+    - "Node.js y Python exponen dependencias directas con versiones y origen"
+    - "Cuando existe lockfile compatible, se reportan versiones resueltas y transitivas"
+    - "La fusion manifest+lockfile evita duplicados y preserva trazabilidad"
+  artifacts:
+    - path: "src/sourcecode/dependency_analyzer.py"
+      provides: "Resolucion inicial por ecosistema para Node.js y Python"
+    - path: "tests/test_dependency_analyzer_node_python.py"
+      provides: "Cobertura unitaria de manifests y lockfiles principales"
+    - path: "tests/test_integration_dependencies.py"
+      provides: "Smoke e integracion CLI para ambos ecosistemas"
+---
+
+<objective>
+Implementar la primera oleada fuerte del analizador sobre los dos ecosistemas mas frecuentes del proyecto: Node.js y Python.
+
+Purpose: Cubrir cuanto antes el grueso del valor practico de `--dependencies` con lockfiles comunes y soporte real de transitivas.
+
+Output: parsing de manifests/lockfiles Node y Python, merge uniforme y tests dedicados.
+</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/06-dependencias-inteligentes/06-RESEARCH.md
+@.planning/phases/06-dependencias-inteligentes/06-01-PLAN.md
+@src/sourcecode/dependency_analyzer.py
+@src/sourcecode/detectors/parsers.py
+@src/sourcecode/detectors/nodejs.py
+@src/sourcecode/detectors/python.py
+</context>
+
+<tasks>
+
+<task type="auto" tdd="true">
+  <name>Tarea 1: Resolver dependencias Node.js</name>
+  <files>src/sourcecode/dependency_analyzer.py, tests/test_dependency_analyzer_node_python.py, tests/test_integration_dependencies.py</files>
+
+  <behavior>
+    - `package.json` aporta dependencias directas por scope
+    - `package-lock.json` o `pnpm-lock.yaml` aportan versiones exactas y transitivas
+    - el merge final relaciona dependencias declaradas con resueltas
+  </behavior>
+
+  <action>
+Crear fixtures/tests RED para:
+
+- proyecto npm con `package.json` + `package-lock.json`
+- proyecto pnpm con `package.json` + `pnpm-lock.yaml`
+- caso sin lockfile donde solo hay `declared_version`
+
+Implementar resolucion Node.js con scopes (`dependencies`, `devDependencies`, `peerDependencies`, `optionalDependencies`) y linking de transitivas cuando sea razonable.
+  </action>
+
+  <verify>
+    <automated>.venv/bin/python -m pytest tests/test_dependency_analyzer_node_python.py -q -k node</automated>
+  </verify>
+
+  <acceptance_criteria>
+    - Node.js devuelve deps directas y transitivas segun la evidencia disponible
+    - El origen del dato queda explicitado por dependencia
+  </acceptance_criteria>
+
+  <done>Node.js queda cubierto con valor real para agentes IA.</done>
+</task>
+
+<task type="auto" tdd="true">
+  <name>Tarea 2: Resolver dependencias Python</name>
+  <files>src/sourcecode/dependency_analyzer.py, src/sourcecode/detectors/parsers.py, tests/test_dependency_analyzer_node_python.py, tests/test_integration_dependencies.py</files>
+
+  <behavior>
+    - `pyproject.toml`, `requirements*.txt` y equivalentes aportan deps directas
+    - `poetry.lock`, `uv.lock` o `Pipfile.lock` aportan resolucion exacta y transitivas cuando el formato lo permita
+    - extras y grupos no rompen el modelo comun
+  </behavior>
+
+  <action>
+Crear fixtures/tests RED para:
+
+- `pyproject.toml` + `poetry.lock`
+- `pyproject.toml` + `uv.lock`
+- `requirements.txt` sin lockfile
+
+Implementar parsing y merge con version declarada/resuelta, scopes razonables y senales de limitacion cuando el lockfile no cubra toda la info.
+  </action>
+
+  <verify>
+    <automated>.venv/bin/python -m pytest tests/test_dependency_analyzer_node_python.py -q -k python</automated>
+  </verify>
+
+  <acceptance_criteria>
+    - Python deja de reportar solo nombres sueltos y pasa a exponer versiones/origen
+    - El contrato es uniforme respecto a Node.js
+  </acceptance_criteria>
+
+  <done>Python queda cubierto con dependencias detalladas y lockfiles utiles.</done>
+</task>
+
+</tasks>
+
+<verification>
+## Verificacion global
+
+- `.venv/bin/python -m pytest tests/test_dependency_analyzer_node_python.py tests/test_integration_dependencies.py -q`
+</verification>
+
+<success_criteria>
+## Success Criteria
+
+- Node.js y Python cubren dependencias exactas y transitivas cuando procede
+- El merge de manifests y lockfiles es trazable y consistente
+</success_criteria>

sourcecode-0.3.0/.planning/phases/06-dependencias-inteligentes/06-02-SUMMARY.md

@@ -0,0 +1,47 @@
+---
+phase: 06-dependencias-inteligentes
+plan: 02
+subsystem: dependencies
+tags: [nodejs, python, lockfiles, transitive]
+requires:
+  - phase: 06-dependencias-inteligentes
+    provides: schema de dependencias y CLI lazy
+provides:
+  - Resolucion Node.js por package-lock y pnpm-lock
+  - Resolucion Python por pyproject, poetry.lock, uv.lock y Pipfile.lock
+affects: [dependencies, output]
+tech-stack:
+  added: []
+  patterns: [manifest-lockfile-merge, conservative-transitive-resolution]
+key-files:
+  created:
+    - tests/test_dependency_analyzer_node_python.py
+    - tests/test_integration_dependencies.py
+  modified:
+    - src/sourcecode/dependency_analyzer.py
+key-decisions:
+  - "Las versiones resueltas del lockfile prevalecen sobre el constraint declarado"
+  - "Las transitivas solo se emiten cuando el lockfile ofrece informacion util y segura"
+requirements-completed: [DEPS-01, DEPS-02, DEPS-03]
+duration: 22min
+completed: 2026-04-08
+---
+
+# Phase 06-02 Summary
+
+**Node.js y Python con versiones exactas y transitivas**
+
+## Accomplishments
+
+- Node.js ahora fusiona `package.json` con `package-lock.json` o `pnpm-lock.yaml`.
+- Python ahora combina `pyproject.toml`/`requirements*.txt` con `poetry.lock`, `uv.lock` y `Pipfile.lock`.
+- El output distingue dependencias directas y transitivas y conserva `parent` cuando puede resolverse.
+- Se añadieron tests unitarios e integración CLI para ambos ecosistemas.
+
+## Verification
+
+- `.venv/bin/python -m pytest tests/test_dependency_analyzer_node_python.py tests/test_integration_dependencies.py -q`
+
+## Notes
+
+- El merge manifest+lockfile conserva ambas capas: constraint declarado y version resuelta.