sourcecode 0.1.0__tar.gz → 0.2.0__tar.gz

{sourcecode-0.1.0 → sourcecode-0.2.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.1.0 → sourcecode-0.2.0}/.planning/ROADMAP.md

@@ -2,7 +2,7 @@
 
 ## Descripcion General
 
-SourceMap Gen se construye en cuatro fases que van desde el scaffold del proyecto hasta la publicacion en PyPI. 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.
+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.
 
 ## Fases
 
@@ -10,6 +10,7 @@ SourceMap Gen se construye en cuatro fases que van desde el scaffold del proyect
 - [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
 
 ## Detalles de Fases
 
@@ -86,8 +87,29 @@ Plans:
 
 ## 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
+
+## Progreso
+
 **Orden de ejecucion:**
-Las fases se ejecutan en orden numerico: 1 → 2 → 3 → 4
+Las fases se ejecutan en orden numerico: 1 → 2 → 3 → 4 → 5
 
 | Fase | Planes Completos | Estado | Completada |
 |------|-----------------|--------|------------|
@@ -95,3 +117,4 @@ Las fases se ejecutan en orden numerico: 1 → 2 → 3 → 4
 | 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 |

{sourcecode-0.1.0 → sourcecode-0.2.0}/.planning/STATE.md

@@ -4,13 +4,13 @@ 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
+last_updated: "2026-04-07T21:15:17.169Z"
+last_activity: 2026-04-07 -- Phase 05 completed
 progress:
-  total_phases: 4
-  completed_phases: 4
-  total_plans: 13
-  completed_plans: 13
+  total_phases: 5
+  completed_phases: 5
+  total_plans: 17
+  completed_plans: 17
   percent: 100
 ---
 
@@ -21,14 +21,14 @@ 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:** Milestone complete — universal scanner expansion delivered
 
 ## 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: 05 (scanner-universal) — COMPLETE
+Plan: 4 of 4
+Status: Phase 05 complete
+Last activity: 2026-04-07 -- Phase 05 completed
 
 Progress: [██████████] 100%
 
@@ -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,11 @@ 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.
 
 ### Blockers/Concerns
 
@@ -93,4 +98,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: Publish/release preparation or milestone closure

sourcecode-0.2.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.2.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`.

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

@@ -0,0 +1,169 @@
+---
+phase: 05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de
+plan: 02
+type: execute
+wave: 2
+depends_on:
+  - 05-01
+files_modified:
+  - src/sourcecode/detectors/__init__.py
+  - src/sourcecode/detectors/dotnet.py
+  - src/sourcecode/detectors/elixir.py
+  - src/sourcecode/detectors/jvm_ext.py
+  - tests/test_detector_universal_managed.py
+autonomous: true
+requirements:
+  - DETECT-08
+  - DETECT-09
+
+must_haves:
+  truths:
+    - "C#/.NET, Elixir y JVM ampliado dejan de caer en `unknown`"
+    - "Los nuevos detectores usan manifests canonicos y entry points razonables"
+    - "El registro por defecto integra los detectores nuevos sin romper el orden actual"
+  artifacts:
+    - path: "src/sourcecode/detectors/dotnet.py"
+      provides: "Deteccion de proyectos .NET/C#"
+    - path: "src/sourcecode/detectors/elixir.py"
+      provides: "Deteccion de proyectos Elixir/Phoenix"
+    - path: "src/sourcecode/detectors/jvm_ext.py"
+      provides: "Deteccion Kotlin/Scala/JVM build tooling"
+    - path: "tests/test_detector_universal_managed.py"
+      provides: "Cobertura unitaria de nuevos ecosistemas managed"
+---
+
+<objective>
+Anadir la primera gran oleada de stacks nuevos con manifests fuertes y alto valor practico: .NET, Elixir y JVM ampliado.
+
+Purpose: Reducir rapidamente la cantidad de repos reales que hoy caen en `unknown` a pesar de tener manifests muy reconocibles.
+
+Output: detectores nuevos, registro actualizado y tests unitarios 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/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-RESEARCH.md
+@.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-01-PLAN.md
+@src/sourcecode/detectors/__init__.py
+@src/sourcecode/detectors/base.py
+@src/sourcecode/detectors/project.py
+</context>
+
+<tasks>
+
+<task type="auto" tdd="true">
+  <name>Tarea 1: Detector .NET / C#</name>
+  <files>src/sourcecode/detectors/dotnet.py, tests/test_detector_universal_managed.py</files>
+
+  <behavior>
+    - `*.csproj`, `*.sln` y `Program.cs` detectan stack `.net`
+    - ASP.NET o worker service elevan clasificacion y confianza
+    - `Program.cs` o proyectos `Exe` generan entry point
+  </behavior>
+
+  <action>
+Crear fixtures RED minimales para:
+
+- consola .NET con `App.csproj` + `Program.cs`
+- web ASP.NET con referencias o SDK web
+
+Implementar detector con parseo ligero XML/textual suficiente para reconocer SDK, output type y senales de framework.
+  </action>
+
+  <verify>
+    <automated>.venv/bin/python -m pytest tests/test_detector_universal_managed.py -q -k dotnet</automated>
+  </verify>
+
+  <acceptance_criteria>
+    - Repos .NET dejan de caer en heuristica pura
+    - El detector produce stack y entry point razonables
+  </acceptance_criteria>
+
+  <done>.NET/C# queda cubierto en el scanner.</done>
+</task>
+
+<task type="auto" tdd="true">
+  <name>Tarea 2: Detector Elixir / Phoenix</name>
+  <files>src/sourcecode/detectors/elixir.py, tests/test_detector_universal_managed.py</files>
+
+  <behavior>
+    - `mix.exs` detecta Elixir
+    - senales de Phoenix se reflejan como framework
+    - `lib/*/application.ex` o `mix.exs` sirven como evidencia de entry/app
+  </behavior>
+
+  <action>
+Crear fixtures RED para:
+
+- app Elixir base
+- proyecto Phoenix minimal
+
+Implementar detector con parseo textual de `mix.exs` para nombre, dependencias y senales `phoenix`.
+  </action>
+
+  <verify>
+    <automated>.venv/bin/python -m pytest tests/test_detector_universal_managed.py -q -k elixir</automated>
+  </verify>
+
+  <acceptance_criteria>
+    - Phoenix aparece como framework cuando corresponde
+    - El stack no depende de heuristica por extension `.ex`
+  </acceptance_criteria>
+
+  <done>Elixir/Phoenix queda cubierto en el scanner.</done>
+</task>
+
+<task type="auto" tdd="true">
+  <name>Tarea 3: JVM ampliado para Kotlin y Scala</name>
+  <files>src/sourcecode/detectors/jvm_ext.py, src/sourcecode/detectors/__init__.py, tests/test_detector_universal_managed.py</files>
+
+  <behavior>
+    - `build.gradle.kts`, `settings.gradle.kts` o `build.sbt` detectan Kotlin/Scala/JVM
+    - Spring Boot o Ktor pueden elevar framework y project_type
+    - se evitan duplicados con el detector Java existente
+  </behavior>
+
+  <action>
+Crear fixtures RED para:
+
+- servicio Kotlin con Gradle Kotlin DSL
+- proyecto Scala con sbt
+
+Implementar detector o extension de detector JVM que:
+
+- identifique lenguaje predominante;
+- derive framework si hay senales claras;
+- conviva con `JavaDetector` sin duplicar stack.
+  </action>
+
+  <verify>
+    <automated>.venv/bin/python -m pytest tests/test_detector_universal_managed.py -q -k "kotlin or scala"</automated>
+  </verify>
+
+  <acceptance_criteria>
+    - Kotlin y Scala ya no se clasifican solo como Java generico o unknown
+    - El registro por defecto mantiene estabilidad
+  </acceptance_criteria>
+
+  <done>La cobertura managed crece de forma material y verificable.</done>
+</task>
+
+</tasks>
+
+<verification>
+## Verificacion global
+
+- `.venv/bin/python -m pytest tests/test_detector_universal_managed.py -q`
+</verification>
+
+<success_criteria>
+## Success Criteria
+
+- .NET, Elixir y JVM ampliado tienen detectores dedicados o integracion equivalente
+- Los nuevos ecosistemas quedan cubiertos con tests unitarios claros
+</success_criteria>

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

@@ -0,0 +1,53 @@
+---
+phase: 05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de
+plan: 02
+subsystem: detectors
+tags: [dotnet, elixir, kotlin, scala, managed]
+requires:
+  - phase: 05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de
+    plan: 01
+    provides: fusion base y scoring multi-fuente
+provides:
+  - Detectores .NET y Elixir
+  - Detector JVM ampliado para Kotlin/Scala
+  - Cobertura unitaria de ecosistemas managed
+affects: [detectors, tests]
+tech-stack:
+  added: [.NET, Elixir, Kotlin, Scala]
+  patterns: [manifest-first-detection]
+key-files:
+  created:
+    - src/sourcecode/detectors/dotnet.py
+    - src/sourcecode/detectors/elixir.py
+    - src/sourcecode/detectors/jvm_ext.py
+    - tests/test_detector_universal_managed.py
+  modified:
+    - src/sourcecode/detectors/__init__.py
+    - src/sourcecode/classifier.py
+key-decisions:
+  - "Kotlin y Scala se modelan como stacks distintos, no como Java generico"
+  - "Phoenix se clasifica como framework web y ASP.NET/Ktor/Play como evidencia de API segun el caso"
+patterns-established:
+  - "Los detectores nuevos priorizan manifests y entry points canonicos, sin parseo profundo"
+requirements-completed: [DETECT-08, DETECT-09]
+duration: 19min
+completed: 2026-04-07
+---
+
+# Phase 05-02 Summary
+
+**Nuevos ecosistemas managed**
+
+## Accomplishments
+
+- Se anadieron detectores para `.NET/C#`, `Elixir/Phoenix` y JVM ampliado (`Kotlin`/`Scala`).
+- El registro por defecto integra ya estos detectores en el pipeline principal.
+- Se creo `tests/test_detector_universal_managed.py` para validar deteccion, frameworks, entry points y `project_type`.
+
+## Verification
+
+- `.venv/bin/python -m pytest tests/test_detector_universal_managed.py -q`
+
+## Notes
+
+- El detector JVM ampliado diferencia `kotlin` y `scala` usando manifests y extensiones, evitando colapsarlos en `java`.