sourcecode 0.5.0__tar.gz → 0.6.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- {sourcecode-0.5.0 → sourcecode-0.6.0}/.gitignore +8 -2
- {sourcecode-0.5.0 → sourcecode-0.6.0}/PKG-INFO +1 -1
- {sourcecode-0.5.0 → sourcecode-0.6.0}/docs/schema.md +2 -2
- {sourcecode-0.5.0 → sourcecode-0.6.0}/pyproject.toml +1 -1
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/__init__.py +1 -1
- sourcecode-0.5.0/.github/workflows/ci.yml +0 -42
- sourcecode-0.5.0/.github/workflows/release.yml +0 -101
- sourcecode-0.5.0/.planning/PROJECT.md +0 -79
- sourcecode-0.5.0/.planning/REQUIREMENTS.md +0 -111
- sourcecode-0.5.0/.planning/ROADMAP.md +0 -204
- sourcecode-0.5.0/.planning/STATE.md +0 -110
- sourcecode-0.5.0/.planning/config.json +0 -42
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-01-PLAN.md +0 -475
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-01-SUMMARY.md +0 -151
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-02-PLAN.md +0 -521
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-02-SUMMARY.md +0 -149
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-03-PLAN.md +0 -468
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-03-SUMMARY.md +0 -216
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-04-PLAN.md +0 -771
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-04-SUMMARY.md +0 -202
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-CONTEXT.md +0 -77
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-DISCUSSION-LOG.md +0 -29
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-RESEARCH.md +0 -652
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-REVIEW.md +0 -222
- sourcecode-0.5.0/.planning/phases/01-fundaciones/01-VERIFICATION.md +0 -134
- sourcecode-0.5.0/.planning/phases/02-deteccion-core/02-01-PLAN.md +0 -225
- sourcecode-0.5.0/.planning/phases/02-deteccion-core/02-01-SUMMARY.md +0 -88
- sourcecode-0.5.0/.planning/phases/02-deteccion-core/02-02-PLAN.md +0 -206
- sourcecode-0.5.0/.planning/phases/02-deteccion-core/02-02-SUMMARY.md +0 -84
- sourcecode-0.5.0/.planning/phases/02-deteccion-core/02-03-PLAN.md +0 -196
- sourcecode-0.5.0/.planning/phases/02-deteccion-core/02-03-SUMMARY.md +0 -84
- sourcecode-0.5.0/.planning/phases/02-deteccion-core/02-04-PLAN.md +0 -222
- sourcecode-0.5.0/.planning/phases/02-deteccion-core/02-04-SUMMARY.md +0 -110
- sourcecode-0.5.0/.planning/phases/02-deteccion-core/02-RESEARCH.md +0 -256
- sourcecode-0.5.0/.planning/phases/03-clasificacion-y-multi-stack/03-01-PLAN.md +0 -214
- sourcecode-0.5.0/.planning/phases/03-clasificacion-y-multi-stack/03-01-SUMMARY.md +0 -101
- sourcecode-0.5.0/.planning/phases/03-clasificacion-y-multi-stack/03-02-PLAN.md +0 -220
- sourcecode-0.5.0/.planning/phases/03-clasificacion-y-multi-stack/03-02-SUMMARY.md +0 -108
- sourcecode-0.5.0/.planning/phases/03-clasificacion-y-multi-stack/03-RESEARCH.md +0 -191
- sourcecode-0.5.0/.planning/phases/04-pulido-y-publicacion/04-01-PLAN.md +0 -186
- sourcecode-0.5.0/.planning/phases/04-pulido-y-publicacion/04-01-SUMMARY.md +0 -58
- sourcecode-0.5.0/.planning/phases/04-pulido-y-publicacion/04-02-PLAN.md +0 -138
- sourcecode-0.5.0/.planning/phases/04-pulido-y-publicacion/04-02-SUMMARY.md +0 -48
- sourcecode-0.5.0/.planning/phases/04-pulido-y-publicacion/04-03-PLAN.md +0 -141
- sourcecode-0.5.0/.planning/phases/04-pulido-y-publicacion/04-03-SUMMARY.md +0 -53
- sourcecode-0.5.0/.planning/phases/04-pulido-y-publicacion/04-RESEARCH.md +0 -153
- sourcecode-0.5.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/.gitkeep +0 -0
- sourcecode-0.5.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-01-PLAN.md +0 -146
- sourcecode-0.5.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-01-SUMMARY.md +0 -53
- sourcecode-0.5.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-02-PLAN.md +0 -169
- sourcecode-0.5.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-02-SUMMARY.md +0 -53
- sourcecode-0.5.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-03-PLAN.md +0 -164
- sourcecode-0.5.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-03-SUMMARY.md +0 -51
- sourcecode-0.5.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-04-PLAN.md +0 -183
- sourcecode-0.5.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-04-SUMMARY.md +0 -57
- sourcecode-0.5.0/.planning/phases/05-scanner-universal-ampliar-stacks-ecosistemas-y-senales-de-de/05-RESEARCH.md +0 -165
- sourcecode-0.5.0/.planning/phases/06-dependencias-inteligentes/.gitkeep +0 -0
- sourcecode-0.5.0/.planning/phases/06-dependencias-inteligentes/06-01-PLAN.md +0 -140
- sourcecode-0.5.0/.planning/phases/06-dependencias-inteligentes/06-01-SUMMARY.md +0 -52
- sourcecode-0.5.0/.planning/phases/06-dependencias-inteligentes/06-02-PLAN.md +0 -135
- sourcecode-0.5.0/.planning/phases/06-dependencias-inteligentes/06-02-SUMMARY.md +0 -47
- sourcecode-0.5.0/.planning/phases/06-dependencias-inteligentes/06-03-PLAN.md +0 -132
- sourcecode-0.5.0/.planning/phases/06-dependencias-inteligentes/06-03-SUMMARY.md +0 -46
- sourcecode-0.5.0/.planning/phases/06-dependencias-inteligentes/06-04-PLAN.md +0 -143
- sourcecode-0.5.0/.planning/phases/06-dependencias-inteligentes/06-04-SUMMARY.md +0 -51
- sourcecode-0.5.0/.planning/phases/06-dependencias-inteligentes/06-RESEARCH.md +0 -171
- sourcecode-0.5.0/.planning/phases/07-grafos-de-codigo/.gitkeep +0 -0
- sourcecode-0.5.0/.planning/phases/07-grafos-de-codigo/07-01-PLAN.md +0 -141
- sourcecode-0.5.0/.planning/phases/07-grafos-de-codigo/07-01-SUMMARY.md +0 -52
- sourcecode-0.5.0/.planning/phases/07-grafos-de-codigo/07-02-PLAN.md +0 -134
- sourcecode-0.5.0/.planning/phases/07-grafos-de-codigo/07-02-SUMMARY.md +0 -48
- sourcecode-0.5.0/.planning/phases/07-grafos-de-codigo/07-03-PLAN.md +0 -131
- sourcecode-0.5.0/.planning/phases/07-grafos-de-codigo/07-03-SUMMARY.md +0 -46
- sourcecode-0.5.0/.planning/phases/07-grafos-de-codigo/07-04-PLAN.md +0 -143
- sourcecode-0.5.0/.planning/phases/07-grafos-de-codigo/07-04-SUMMARY.md +0 -50
- sourcecode-0.5.0/.planning/phases/07-grafos-de-codigo/07-RESEARCH.md +0 -165
- sourcecode-0.5.0/.planning/phases/08-documentacion-extraida/.gitkeep +0 -0
- sourcecode-0.5.0/.planning/phases/09-metricas-de-calidad/.gitkeep +0 -0
- sourcecode-0.5.0/.planning/phases/10-contexto-git-y-operativo/.gitkeep +0 -0
- sourcecode-0.5.0/.planning/research/ARCHITECTURE.md +0 -631
- sourcecode-0.5.0/.planning/research/FEATURES.md +0 -543
- sourcecode-0.5.0/.planning/research/PITFALLS.md +0 -341
- sourcecode-0.5.0/.planning/research/STACK.md +0 -436
- {sourcecode-0.5.0 → sourcecode-0.6.0}/.ruff.toml +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/README.md +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/classifier.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/cli.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/dependency_analyzer.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/__init__.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/base.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/dart.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/dotnet.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/elixir.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/go.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/heuristic.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/java.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/jvm_ext.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/nodejs.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/parsers.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/php.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/project.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/python.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/ruby.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/rust.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/systems.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/terraform.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/detectors/tooling.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/graph_analyzer.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/redactor.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/scanner.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/schema.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/serializer.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/tree_utils.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/src/sourcecode/workspace.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/__init__.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/conftest.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/fastapi_app/pyproject.toml +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/fastapi_app/src/main.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/go_service/cmd/api/main.go +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/go_service/go.mod +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/nextjs_app/app/page.tsx +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/nextjs_app/package.json +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/nextjs_app/pnpm-lock.yaml +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/pnpm_monorepo/apps/web/app/page.tsx +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/pnpm_monorepo/apps/web/package.json +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/pnpm_monorepo/packages/api/main.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/pnpm_monorepo/packages/api/pyproject.toml +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/fixtures/pnpm_monorepo/pnpm-workspace.yaml +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_classifier.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_cli.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_dependency_analyzer_node_python.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_dependency_analyzer_polyglot.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_dependency_schema.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_detector_go_rust_java.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_detector_nodejs.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_detector_php_ruby_dart.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_detector_python.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_detector_universal_managed.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_detector_universal_systems.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_detectors_base.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_graph_analyzer_polyglot.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_graph_analyzer_python_node.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_graph_schema.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_integration.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_integration_dependencies.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_integration_detection.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_integration_graph_modules.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_integration_multistack.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_integration_universal.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_packaging.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_real_projects.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_redactor.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_scanner.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_schema.py +0 -0
- {sourcecode-0.5.0 → sourcecode-0.6.0}/tests/test_workspace_analyzer.py +0 -0
|
@@ -1,3 +1,4 @@
|
|
|
1
|
+
# Python cache and build artifacts
|
|
1
2
|
__pycache__/
|
|
2
3
|
*.pyc
|
|
3
4
|
*.pyo
|
|
@@ -11,8 +12,7 @@ build/
|
|
|
11
12
|
.mypy_cache/
|
|
12
13
|
.ruff_cache/
|
|
13
14
|
.pytest_cache/
|
|
14
|
-
|
|
15
|
-
/src/*.egg-info/
|
|
15
|
+
src/*.egg-info/
|
|
16
16
|
|
|
17
17
|
# Editor / IDE
|
|
18
18
|
.idea/
|
|
@@ -22,6 +22,12 @@ build/
|
|
|
22
22
|
.claude/
|
|
23
23
|
.codex/
|
|
24
24
|
|
|
25
|
+
# Environment / secrets
|
|
26
|
+
*.env
|
|
27
|
+
*.secret.json
|
|
28
|
+
|
|
25
29
|
# OS cruft
|
|
26
30
|
.DS_Store
|
|
27
31
|
Thumbs.db
|
|
32
|
+
|
|
33
|
+
.planning
|
|
@@ -35,7 +35,7 @@ Campos:
|
|
|
35
35
|
{
|
|
36
36
|
"schema_version": "1.0",
|
|
37
37
|
"generated_at": "2026-04-07T19:41:05.686277+00:00",
|
|
38
|
-
"sourcecode_version": "0.
|
|
38
|
+
"sourcecode_version": "0.6.0",
|
|
39
39
|
"analyzed_path": "/abs/path/to/project"
|
|
40
40
|
}
|
|
41
41
|
```
|
|
@@ -336,7 +336,7 @@ Ejemplo real de salida para un monorepo con web Node.js y API Python:
|
|
|
336
336
|
"metadata": {
|
|
337
337
|
"schema_version": "1.0",
|
|
338
338
|
"generated_at": "2026-04-07T19:41:05.686277+00:00",
|
|
339
|
-
"sourcecode_version": "0.
|
|
339
|
+
"sourcecode_version": "0.6.0",
|
|
340
340
|
"analyzed_path": "/abs/path/to/project"
|
|
341
341
|
},
|
|
342
342
|
"file_tree": {
|
|
@@ -1,42 +0,0 @@
|
|
|
1
|
-
name: CI
|
|
2
|
-
|
|
3
|
-
on:
|
|
4
|
-
push:
|
|
5
|
-
branches:
|
|
6
|
-
- main
|
|
7
|
-
pull_request:
|
|
8
|
-
|
|
9
|
-
jobs:
|
|
10
|
-
test:
|
|
11
|
-
runs-on: ubuntu-latest
|
|
12
|
-
strategy:
|
|
13
|
-
fail-fast: false
|
|
14
|
-
matrix:
|
|
15
|
-
python-version: ["3.9", "3.10", "3.11", "3.12"]
|
|
16
|
-
|
|
17
|
-
steps:
|
|
18
|
-
- name: Checkout
|
|
19
|
-
uses: actions/checkout@v4
|
|
20
|
-
|
|
21
|
-
- name: Set up Python
|
|
22
|
-
uses: actions/setup-python@v5
|
|
23
|
-
with:
|
|
24
|
-
python-version: ${{ matrix.python-version }}
|
|
25
|
-
|
|
26
|
-
- name: Upgrade pip
|
|
27
|
-
run: python -m pip install --upgrade pip
|
|
28
|
-
|
|
29
|
-
- name: Install project and dev dependencies
|
|
30
|
-
run: python -m pip install -e ".[dev]"
|
|
31
|
-
|
|
32
|
-
- name: Ruff
|
|
33
|
-
run: ruff check src tests
|
|
34
|
-
|
|
35
|
-
- name: Mypy
|
|
36
|
-
run: mypy src
|
|
37
|
-
|
|
38
|
-
- name: Pytest
|
|
39
|
-
run: pytest -q
|
|
40
|
-
|
|
41
|
-
- name: Smoke test console script
|
|
42
|
-
run: sourcecode --version
|
|
@@ -1,101 +0,0 @@
|
|
|
1
|
-
name: Release
|
|
2
|
-
|
|
3
|
-
on:
|
|
4
|
-
workflow_dispatch:
|
|
5
|
-
inputs:
|
|
6
|
-
target:
|
|
7
|
-
description: "Repositorio de publicacion"
|
|
8
|
-
required: true
|
|
9
|
-
default: "testpypi"
|
|
10
|
-
type: choice
|
|
11
|
-
options:
|
|
12
|
-
- testpypi
|
|
13
|
-
- pypi
|
|
14
|
-
release:
|
|
15
|
-
types:
|
|
16
|
-
- published
|
|
17
|
-
|
|
18
|
-
permissions:
|
|
19
|
-
contents: read
|
|
20
|
-
id-token: write
|
|
21
|
-
|
|
22
|
-
jobs:
|
|
23
|
-
build:
|
|
24
|
-
runs-on: ubuntu-latest
|
|
25
|
-
|
|
26
|
-
steps:
|
|
27
|
-
- name: Checkout
|
|
28
|
-
uses: actions/checkout@v4
|
|
29
|
-
|
|
30
|
-
- name: Set up Python
|
|
31
|
-
uses: actions/setup-python@v5
|
|
32
|
-
with:
|
|
33
|
-
python-version: "3.12"
|
|
34
|
-
|
|
35
|
-
- name: Upgrade pip
|
|
36
|
-
run: python -m pip install --upgrade pip
|
|
37
|
-
|
|
38
|
-
- name: Install build tooling
|
|
39
|
-
run: python -m pip install build
|
|
40
|
-
|
|
41
|
-
- name: Build sdist and wheel
|
|
42
|
-
run: python -m build
|
|
43
|
-
|
|
44
|
-
- name: Smoke test built wheel
|
|
45
|
-
run: |
|
|
46
|
-
python -m venv .venv-smoke
|
|
47
|
-
.venv-smoke/bin/python -m pip install --upgrade pip
|
|
48
|
-
.venv-smoke/bin/python -m pip install dist/*.whl
|
|
49
|
-
.venv-smoke/bin/sourcecode --version
|
|
50
|
-
|
|
51
|
-
- name: Upload distribution artifacts
|
|
52
|
-
uses: actions/upload-artifact@v4
|
|
53
|
-
with:
|
|
54
|
-
name: python-dist
|
|
55
|
-
path: dist/
|
|
56
|
-
|
|
57
|
-
publish-testpypi:
|
|
58
|
-
needs: build
|
|
59
|
-
runs-on: ubuntu-latest
|
|
60
|
-
if: >-
|
|
61
|
-
${{
|
|
62
|
-
github.event_name == 'workflow_dispatch' && github.event.inputs.target == 'testpypi'
|
|
63
|
-
|| github.event_name == 'release' && github.event.release.prerelease
|
|
64
|
-
}}
|
|
65
|
-
environment:
|
|
66
|
-
name: testpypi
|
|
67
|
-
url: https://test.pypi.org/p/sourcecode
|
|
68
|
-
|
|
69
|
-
steps:
|
|
70
|
-
- name: Download distribution artifacts
|
|
71
|
-
uses: actions/download-artifact@v4
|
|
72
|
-
with:
|
|
73
|
-
name: python-dist
|
|
74
|
-
path: dist/
|
|
75
|
-
|
|
76
|
-
- name: Publish to TestPyPI with trusted publishing
|
|
77
|
-
uses: pypa/gh-action-pypi-publish@release/v1
|
|
78
|
-
with:
|
|
79
|
-
repository-url: https://test.pypi.org/legacy/
|
|
80
|
-
|
|
81
|
-
publish-pypi:
|
|
82
|
-
needs: build
|
|
83
|
-
runs-on: ubuntu-latest
|
|
84
|
-
if: >-
|
|
85
|
-
${{
|
|
86
|
-
github.event_name == 'workflow_dispatch' && github.event.inputs.target == 'pypi'
|
|
87
|
-
|| github.event_name == 'release' && !github.event.release.prerelease
|
|
88
|
-
}}
|
|
89
|
-
environment:
|
|
90
|
-
name: pypi
|
|
91
|
-
url: https://pypi.org/p/sourcecode
|
|
92
|
-
|
|
93
|
-
steps:
|
|
94
|
-
- name: Download distribution artifacts
|
|
95
|
-
uses: actions/download-artifact@v4
|
|
96
|
-
with:
|
|
97
|
-
name: python-dist
|
|
98
|
-
path: dist/
|
|
99
|
-
|
|
100
|
-
- name: Publish to PyPI with trusted publishing
|
|
101
|
-
uses: pypa/gh-action-pypi-publish@release/v1
|
|
@@ -1,79 +0,0 @@
|
|
|
1
|
-
# SourceMap Gen
|
|
2
|
-
|
|
3
|
-
## Qué es esto
|
|
4
|
-
|
|
5
|
-
Herramienta CLI de Python (instalable via pip) que analiza cualquier proyecto de software desde su directorio raíz y genera ficheros JSON/YAML con contexto estructurado del proyecto: árbol de archivos, stack tecnológico, arquitectura inferida (cliente/servidor/monorepo), módulos principales, puntos de entrada y APIs expuestas. El output está diseñado para ser inyectado como contexto inicial en agentes IA de desarrollo.
|
|
6
|
-
|
|
7
|
-
## Valor Core
|
|
8
|
-
|
|
9
|
-
Un agente IA que recibe el output de esta herramienta llega al proyecto ya informado — no necesita preguntar lo obvio ni explorar ciegamente el código.
|
|
10
|
-
|
|
11
|
-
## Requisitos
|
|
12
|
-
|
|
13
|
-
### Validados
|
|
14
|
-
|
|
15
|
-
(Ninguno aún — pendiente de publicar para validar)
|
|
16
|
-
|
|
17
|
-
### Activos
|
|
18
|
-
|
|
19
|
-
- [ ] CLI instalable via `pip install` y ejecutable con un solo comando en la raíz del proyecto
|
|
20
|
-
- [ ] Detección automática del stack tecnológico (lenguajes, frameworks, gestores de dependencias)
|
|
21
|
-
- [ ] Generación de árbol de archivos filtrado (excluyendo node_modules, .git, build artifacts, etc.)
|
|
22
|
-
- [ ] Inferencia de arquitectura: cliente, servidor, fullstack, monorepo, librería
|
|
23
|
-
- [ ] Análisis profundo de ficheros clave para extraer: módulos principales, puntos de entrada, APIs expuestas
|
|
24
|
-
- [ ] Output en formato JSON y/o YAML machine-readable
|
|
25
|
-
- [ ] Funciona sobre proyectos reales de cualquier stack sin configuración previa
|
|
26
|
-
|
|
27
|
-
### Fuera de Alcance
|
|
28
|
-
|
|
29
|
-
- Interfaz web o GUI — herramienta de línea de comandos únicamente
|
|
30
|
-
- Análisis de rendimiento o métricas de código — el foco es contexto estructural, no calidad
|
|
31
|
-
- Integración directa con IDEs en v1 — primero CLI, luego extensiones
|
|
32
|
-
- Servidor MCP en v1 — posible en versión futura una vez validada la herramienta
|
|
33
|
-
|
|
34
|
-
## Contexto
|
|
35
|
-
|
|
36
|
-
El problema que resuelve: los agentes IA que asisten en desarrollo pierden tiempo (y tokens) explorando la estructura del proyecto haciendo preguntas básicas que deberían conocer de antemano. Esta herramienta genera ese "mapa mental" del proyecto de forma automática y en formato que los agentes pueden consumir directamente.
|
|
37
|
-
|
|
38
|
-
El output tiene dos usos principales:
|
|
39
|
-
1. **Inyección al inicio de sesión**: el desarrollador pasa el fichero generado como contexto al agente antes de empezar a trabajar
|
|
40
|
-
2. **Consulta bajo demanda**: el agente puede invocar la herramienta cuando necesita entender una parte del proyecto
|
|
41
|
-
|
|
42
|
-
La herramienta debe funcionar correctamente sobre proyectos reales desde el día 1, con soporte universal y detección especializada para los stacks más comunes (Node.js, Python, Go, Java, Rust).
|
|
43
|
-
|
|
44
|
-
## Restricciones
|
|
45
|
-
|
|
46
|
-
- **Lenguaje**: Python — la herramienta en sí está escrita en Python
|
|
47
|
-
- **Distribución**: pip — instalable como paquete estándar de Python
|
|
48
|
-
- **Sin dependencias pesadas**: debe poder instalarse y ejecutarse sin entornos complejos
|
|
49
|
-
- **Rendimiento**: el análisis no debe tardar más de unos segundos en proyectos de tamaño normal
|
|
50
|
-
- **Stack agnóstico**: no puede depender de herramientas del stack analizado para funcionar
|
|
51
|
-
|
|
52
|
-
## Decisiones Clave
|
|
53
|
-
|
|
54
|
-
| Decisión | Justificación | Estado |
|
|
55
|
-
|----------|---------------|--------|
|
|
56
|
-
| Output JSON/YAML (no Markdown) | Machine-readable para consumo directo por agentes | — Pendiente |
|
|
57
|
-
| Análisis profundo de ficheros clave | Un árbol de archivos solo no es suficiente para que el agente entienda la arquitectura | — Pendiente |
|
|
58
|
-
| CLI pip en v1 (no MCP server) | Validar el valor primero con el formato más simple | — Pendiente |
|
|
59
|
-
| Detección universal desde v1 | Los proyectos reales no son solo Node o solo Python | — Pendiente |
|
|
60
|
-
|
|
61
|
-
## Evolución
|
|
62
|
-
|
|
63
|
-
Este documento evoluciona en cada transición de fase y al cerrar hitos.
|
|
64
|
-
|
|
65
|
-
**Tras cada fase** (via `/gsd-transition`):
|
|
66
|
-
1. ¿Requisitos invalidados? → Mover a Fuera de Alcance con motivo
|
|
67
|
-
2. ¿Requisitos validados? → Mover a Validados con referencia de fase
|
|
68
|
-
3. ¿Nuevos requisitos emergidos? → Añadir a Activos
|
|
69
|
-
4. ¿Decisiones que registrar? → Añadir a Decisiones Clave
|
|
70
|
-
5. ¿"Qué es esto" sigue siendo preciso? → Actualizar si ha derivado
|
|
71
|
-
|
|
72
|
-
**Tras cada hito** (via `/gsd-complete-milestone`):
|
|
73
|
-
1. Revisión completa de todas las secciones
|
|
74
|
-
2. Check del Valor Core — ¿sigue siendo la prioridad correcta?
|
|
75
|
-
3. Auditoría de Fuera de Alcance — ¿los motivos siguen siendo válidos?
|
|
76
|
-
4. Actualizar Contexto con el estado actual
|
|
77
|
-
|
|
78
|
-
---
|
|
79
|
-
*Última actualización: 2026-04-07 tras inicialización*
|
|
@@ -1,111 +0,0 @@
|
|
|
1
|
-
# Requisitos: SourceMap Gen
|
|
2
|
-
|
|
3
|
-
**Definido:** 2026-04-07
|
|
4
|
-
**Valor Core:** Un agente IA que recibe el output de esta herramienta llega al proyecto ya informado — no necesita preguntar lo obvio ni explorar ciegamente el código.
|
|
5
|
-
|
|
6
|
-
## Requisitos v1
|
|
7
|
-
|
|
8
|
-
Requisitos para la publicación inicial. Cada uno mapea a fases del roadmap.
|
|
9
|
-
|
|
10
|
-
### CLI
|
|
11
|
-
|
|
12
|
-
- [ ] **CLI-01**: El usuario puede ejecutar `sourcemap-gen` en la raíz de cualquier proyecto sin argumentos y obtener output
|
|
13
|
-
- [ ] **CLI-02**: El usuario puede especificar directorio objetivo con `sourcemap-gen [ruta]`
|
|
14
|
-
- [ ] **CLI-03**: El usuario puede elegir formato de salida con `--format json|yaml` (por defecto: json)
|
|
15
|
-
- [ ] **CLI-04**: El usuario puede especificar fichero de salida con `--output [fichero]` (por defecto: stdout)
|
|
16
|
-
- [ ] **CLI-05**: El usuario puede activar el modo compacto con `--compact` para output reducido (~500 tokens)
|
|
17
|
-
- [ ] **CLI-06**: La herramienta muestra versión con `--version` y ayuda con `--help`
|
|
18
|
-
|
|
19
|
-
### Escáner
|
|
20
|
-
|
|
21
|
-
- [x] **SCAN-01**: La herramienta traversa el árbol de directorios respetando las reglas de `.gitignore` del proyecto analizado
|
|
22
|
-
- [x] **SCAN-02**: La herramienta excluye directorios de dependencias por defecto: `node_modules`, `__pycache__`, `.git`, `vendor`, `venv`, `.venv`, `dist`, `build`, `target`
|
|
23
|
-
- [x] **SCAN-03**: La herramienta no sigue symlinks (protección frente a bucles infinitos)
|
|
24
|
-
- [x] **SCAN-04**: La herramienta limita la profundidad de búsqueda de manifiestos a nivel raíz (profundidad 0-1) para evitar falsos positivos
|
|
25
|
-
- [x] **SCAN-05**: El árbol de ficheros resultante se limita a una profundidad configurable (por defecto: 4 niveles)
|
|
26
|
-
|
|
27
|
-
### Detección de Stack
|
|
28
|
-
|
|
29
|
-
- [ ] **DETECT-01**: La herramienta detecta el stack tecnológico mediante ficheros indicadores (no ejecutando código del proyecto)
|
|
30
|
-
- [ ] **DETECT-02**: La herramienta detecta con soporte completo: Node.js, Python, Go, Rust, Java, PHP, Ruby, Dart/Flutter
|
|
31
|
-
- [ ] **DETECT-03**: La herramienta detecta lenguajes por extensión de fichero para proyectos sin manifiesto formal
|
|
32
|
-
- [ ] **DETECT-04**: La herramienta identifica el framework principal dentro de cada stack (Express, FastAPI, Django, Gin, etc.) parseando los manifiestos de dependencias
|
|
33
|
-
- [ ] **DETECT-05**: El output refleja múltiples stacks cuando el proyecto es multi-stack o monorepo
|
|
34
|
-
- [ ] **DETECT-06**: La herramienta infiere el tipo de proyecto: `webapp`, `api`, `library`, `cli`, `monorepo`, `fullstack`, `unknown`
|
|
35
|
-
- [ ] **DETECT-07**: Cada detección incluye un nivel de confianza: `high`, `medium`, `low`
|
|
36
|
-
|
|
37
|
-
### Output
|
|
38
|
-
|
|
39
|
-
- [ ] **OUT-01**: El output JSON sigue un schema versionado (`schema_version: "1.0"`) estable y documentado
|
|
40
|
-
- [ ] **OUT-02**: El output incluye: metadatos del análisis, árbol de ficheros filtrado, stacks detectados, frameworks, tipo de proyecto, puntos de entrada detectados
|
|
41
|
-
- [ ] **OUT-03**: El output está disponible en JSON (canónico) y YAML (alias con el mismo schema)
|
|
42
|
-
- [ ] **OUT-04**: El modo `--compact` emite solo: tipo de proyecto, stacks principales, puntos de entrada y árbol de primer nivel (~500 tokens)
|
|
43
|
-
- [ ] **OUT-05**: Los proyectos sin manifiesto emiten output válido con `detection_confidence: low` en lugar de error
|
|
44
|
-
|
|
45
|
-
### Seguridad
|
|
46
|
-
|
|
47
|
-
- [x] **SEC-01**: La herramienta redacta por defecto valores que coincidan con patrones de secretos conocidos (tokens GitHub `ghp_`, claves OpenAI `sk-`, AWS keys `AKIA`, etc.) en cualquier campo de texto del output
|
|
48
|
-
- [x] **SEC-02**: Los ficheros `.env` y `*.secret` se excluyen del análisis de contenido por defecto
|
|
49
|
-
- [x] **SEC-03**: La redacción de secretos está activa por defecto y requiere `--no-redact` para desactivarla
|
|
50
|
-
|
|
51
|
-
### Distribución
|
|
52
|
-
|
|
53
|
-
- [ ] **DIST-01**: La herramienta es instalable con `pip install sourcemap-gen` en Python 3.9+
|
|
54
|
-
- [ ] **DIST-02**: El paquete usa `pyproject.toml` con `hatchling` como build backend
|
|
55
|
-
- [ ] **DIST-03**: La herramienta no requiere dependencias del stack analizado para funcionar
|
|
56
|
-
- [ ] **DIST-04**: El paquete incluye tests de integración ejecutables con `pytest`
|
|
57
|
-
|
|
58
|
-
## Requisitos v2
|
|
59
|
-
|
|
60
|
-
Diferidos a versión futura. Reconocidos pero fuera del roadmap actual.
|
|
61
|
-
|
|
62
|
-
### Extensibilidad
|
|
63
|
-
|
|
64
|
-
- **EXT-01**: Sistema de plugins via entry points de setuptools (`[project.entry-points."sourcemap_gen.detectors"]`)
|
|
65
|
-
- **EXT-02**: Fichero `.sourcemapignore` para reglas de exclusión personalizadas por proyecto
|
|
66
|
-
- **EXT-03**: Detector de stack instalable como paquete pip separado sin modificar el núcleo
|
|
67
|
-
|
|
68
|
-
### Análisis Profundo
|
|
69
|
-
|
|
70
|
-
- **DEEP-01**: Extracción de endpoints REST por framework (decoradores FastAPI/Flask, routes Express, config/routes.rb Rails)
|
|
71
|
-
- **DEEP-02**: Análisis de imports para identificar módulos más referenciados (estilo RepoMap de Aider)
|
|
72
|
-
- **DEEP-03**: Flag `--deep` que activa análisis de contenido de ficheros clave con `magika` para detección por contenido
|
|
73
|
-
|
|
74
|
-
### Integración
|
|
75
|
-
|
|
76
|
-
- **INT-01**: Servidor MCP para que agentes IA invoquen la herramienta directamente
|
|
77
|
-
- **INT-02**: Flag `--git-metadata` para incluir rama actual, último commit, autores principales
|
|
78
|
-
|
|
79
|
-
## Fuera de Alcance
|
|
80
|
-
|
|
81
|
-
| Funcionalidad | Motivo |
|
|
82
|
-
|---------------|--------|
|
|
83
|
-
| Interfaz web o GUI | Herramienta de línea de comandos por diseño; GUI añade complejidad sin valor para el caso de uso principal |
|
|
84
|
-
| Integración con IDEs en v1 | Web-first (CLI), extensiones IDE en versiones futuras |
|
|
85
|
-
| Análisis de rendimiento o calidad de código | El foco es contexto estructural para agentes IA, no métricas de calidad |
|
|
86
|
-
| Detección basada en ML/modelos | Rules-based es más fiable, predecible y sin dependencias pesadas |
|
|
87
|
-
| Ejecución de código del proyecto analizado | Riesgo de seguridad inaceptable; toda detección debe ser estática |
|
|
88
|
-
| Output en Markdown (para consumo humano) | El output JSON/YAML ya es el formato óptimo; Markdown puede generarse encima si se necesita |
|
|
89
|
-
|
|
90
|
-
## Trazabilidad
|
|
91
|
-
|
|
92
|
-
Actualizada durante la creación del roadmap.
|
|
93
|
-
|
|
94
|
-
| Requisito | Fase | Estado |
|
|
95
|
-
|-----------|------|--------|
|
|
96
|
-
| CLI-01 a CLI-06 | Fase 1 | Pendiente |
|
|
97
|
-
| SCAN-01 a SCAN-05 | Fase 1 | Pendiente |
|
|
98
|
-
| SEC-01 a SEC-03 | Fase 1 | Pendiente |
|
|
99
|
-
| DIST-01 a DIST-04 | Fase 1 | Pendiente |
|
|
100
|
-
| OUT-01 a OUT-05 | Fase 1-2 | Pendiente |
|
|
101
|
-
| DETECT-01 a DETECT-04 | Fase 2 | Pendiente |
|
|
102
|
-
| DETECT-05 a DETECT-07 | Fase 3 | Pendiente |
|
|
103
|
-
|
|
104
|
-
**Cobertura:**
|
|
105
|
-
- Requisitos v1: 27 total
|
|
106
|
-
- Mapeados a fases: 27
|
|
107
|
-
- Sin mapear: 0 ✓
|
|
108
|
-
|
|
109
|
-
---
|
|
110
|
-
*Requisitos definidos: 2026-04-07*
|
|
111
|
-
*Última actualización: 2026-04-07 tras definición inicial*
|
|
@@ -1,204 +0,0 @@
|
|
|
1
|
-
# Roadmap: Sourcecode
|
|
2
|
-
|
|
3
|
-
## Descripcion General
|
|
4
|
-
|
|
5
|
-
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.
|
|
6
|
-
|
|
7
|
-
## Fases
|
|
8
|
-
|
|
9
|
-
- [x] **Fase 1: Fundaciones** - CLI instalable, escaner con respeto a .gitignore, schema JSON versionado, redaccion de secretos y packaging
|
|
10
|
-
- [x] **Fase 2: Deteccion Core** - AbstractDetector + detectores para 8 ecosistemas, parseo de manifiestos, deteccion de frameworks y puntos de entrada
|
|
11
|
-
- [x] **Fase 3: Clasificacion y Multi-Stack** - TypeClassifier, soporte monorepo/fullstack y niveles de confianza
|
|
12
|
-
- [x] **Fase 4: Pulido y Publicacion** - Tests de integracion sobre proyectos reales, documentacion, CI/CD y publicacion en PyPI
|
|
13
|
-
- [x] **Fase 5: Scanner Universal** - Ampliar stacks, ecosistemas y senales de deteccion para cubrir mas tipos de proyectos reales
|
|
14
|
-
- [x] **Fase 6: Dependencias Inteligentes** - Dependencias exactas, transitivas y resolucion multi-ecosistema con `--dependencies`
|
|
15
|
-
- [x] **Fase 7: Grafos de Codigo** - Grafo de modulos, imports, llamadas y jerarquias estructurales con `--graph-modules`
|
|
16
|
-
- [ ] **Fase 8: Documentacion Extraida** - Docstrings, comentarios y resúmenes de modulos consumibles por IA con `--docs`
|
|
17
|
-
- [ ] **Fase 9: Metricas de Calidad** - LOC, complejidad, tests asociados y cobertura con `--full-metrics`
|
|
18
|
-
- [ ] **Fase 10: Contexto Git y Operativo** - Historia git, volatilidad, CI/CD, Docker y metadata de entorno con `--git-history`
|
|
19
|
-
|
|
20
|
-
## Detalles de Fases
|
|
21
|
-
|
|
22
|
-
### Fase 1: Fundaciones
|
|
23
|
-
**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.
|
|
24
|
-
**Depends on**: Nothing (primera fase)
|
|
25
|
-
**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
|
|
26
|
-
**Status**: COMPLETE — verified 2026-04-07 (5/5 success criteria)
|
|
27
|
-
**Success Criteria** (what must be TRUE):
|
|
28
|
-
1. El usuario ejecuta `sourcemap-gen` en la raiz de un proyecto y obtiene JSON valido en stdout sin configuracion previa
|
|
29
|
-
2. El usuario ejecuta `sourcemap-gen --format yaml --output mapa.yaml` y el fichero se genera con el mismo schema que el JSON
|
|
30
|
-
3. El arbol de ficheros en el output no contiene entradas de `node_modules/`, `.git/`, `__pycache__/`, `venv/` ni artefactos de build
|
|
31
|
-
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
|
|
32
|
-
5. El output nunca expone valores de ficheros `.env` ni patrones de secreto conocidos (`ghp_`, `sk-`, `AKIA`); el schema incluye `schema_version: "1.0"`
|
|
33
|
-
**Plans**: 4 planes
|
|
34
|
-
|
|
35
|
-
Plans:
|
|
36
|
-
- [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)
|
|
37
|
-
- [x] 01-02-PLAN.md — Scanner de ficheros: FileScanner con pathspec/GitIgnoreSpec, exclusiones por defecto, symlinks, profundidad (SCAN-01..05)
|
|
38
|
-
- [x] 01-03-PLAN.md — Schema JSON v1.0 y serializer: dataclasses AnalysisMetadata+SourceMap, to_json/to_yaml/compact_view (OUT-01..04)
|
|
39
|
-
- [x] 01-04-PLAN.md — Redactor de secretos e integracion CLI: SecretRedactor, conexion scanner+schema+redactor+serializer en main() (SEC-01..03)
|
|
40
|
-
|
|
41
|
-
### Fase 2: Deteccion Core
|
|
42
|
-
**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.
|
|
43
|
-
**Depends on**: Fase 1
|
|
44
|
-
**Requirements**: DETECT-01, DETECT-02, DETECT-03, DETECT-04
|
|
45
|
-
**Success Criteria** (what must be TRUE):
|
|
46
|
-
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
|
|
47
|
-
2. Ejecutado sobre un proyecto FastAPI, el output incluye `stack: python`, `frameworks: [FastAPI]` inferido del `pyproject.toml` o `requirements.txt`
|
|
48
|
-
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
|
|
49
|
-
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)
|
|
50
|
-
**Plans**: 4 planes
|
|
51
|
-
|
|
52
|
-
Plans:
|
|
53
|
-
- [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
|
|
54
|
-
- [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)
|
|
55
|
-
- [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)
|
|
56
|
-
- [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)
|
|
57
|
-
**UI hint**: no
|
|
58
|
-
|
|
59
|
-
### Fase 3: Clasificacion y Multi-Stack
|
|
60
|
-
**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.
|
|
61
|
-
**Depends on**: Fase 2
|
|
62
|
-
**Requirements**: DETECT-05, DETECT-06, DETECT-07, OUT-05
|
|
63
|
-
**Success Criteria** (what must be TRUE):
|
|
64
|
-
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
|
|
65
|
-
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
|
|
66
|
-
3. Cada stack detectado incluye `confidence: high|medium|low` basado en el numero y peso de los indicadores encontrados
|
|
67
|
-
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
|
|
68
|
-
**Plans**: 2 planes
|
|
69
|
-
|
|
70
|
-
Plans:
|
|
71
|
-
- [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)
|
|
72
|
-
- [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)
|
|
73
|
-
**UI hint**: no
|
|
74
|
-
|
|
75
|
-
### Fase 4: Pulido y Publicacion
|
|
76
|
-
**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`.
|
|
77
|
-
**Depends on**: Fase 3
|
|
78
|
-
**Requirements**: (ninguno nuevo — esta fase valida y publica lo construido en las fases anteriores)
|
|
79
|
-
**Success Criteria** (what must be TRUE):
|
|
80
|
-
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
|
|
81
|
-
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
|
|
82
|
-
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
|
|
83
|
-
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
|
|
84
|
-
**Status**: COMPLETE — implemented 2026-04-07; pytest green, docs and workflows added, lint/type debt remains visible in CI
|
|
85
|
-
**Plans**: 3 planes
|
|
86
|
-
|
|
87
|
-
Plans:
|
|
88
|
-
- [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
|
|
89
|
-
- [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`
|
|
90
|
-
- [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
|
|
91
|
-
**UI hint**: no
|
|
92
|
-
|
|
93
|
-
## Progreso
|
|
94
|
-
|
|
95
|
-
### Fase 5: Scanner Universal
|
|
96
|
-
**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.
|
|
97
|
-
**Depends on**: Fase 4
|
|
98
|
-
**Requirements**: DETECT-08, DETECT-09, DETECT-10, OUT-06
|
|
99
|
-
**Success Criteria** (what must be TRUE):
|
|
100
|
-
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
|
|
101
|
-
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
|
|
102
|
-
3. Ejecutado sobre proyectos mixtos o legacy con estructura irregular, la herramienta reduce de forma visible los casos `project_type: unknown` y `stacks: []`
|
|
103
|
-
4. El schema conserva compatibilidad hacia atras, pero incorpora senales mas expresivas para justificar detecciones multi-fuente
|
|
104
|
-
**Status**: COMPLETE — implemented 2026-04-07; new stacks added, universal signals integrated, full suite green
|
|
105
|
-
**Plans**: 4 planes
|
|
106
|
-
|
|
107
|
-
Plans:
|
|
108
|
-
- [x] 05-01: Base universal de senales — manifests alternativos, tooling transversal, scoring multi-fuente y deduplicacion del pipeline
|
|
109
|
-
- [x] 05-02: Nuevos ecosistemas managed — detectores para .NET/C#, Elixir/Phoenix y JVM ampliado (Kotlin/Scala)
|
|
110
|
-
- [x] 05-03: Ecosistemas infra/systems — Terraform, C/C++, build files y capa de tooling universal
|
|
111
|
-
- [x] 05-04: Integracion universal end-to-end — fixtures adicionales, fusion heuristica final y regresion completa de CLI/suite
|
|
112
|
-
**UI hint**: no
|
|
113
|
-
|
|
114
|
-
### Fase 6: Dependencias Inteligentes
|
|
115
|
-
**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.
|
|
116
|
-
**Depends on**: Fase 5
|
|
117
|
-
**Requirements**: DEPS-01, DEPS-02, DEPS-03, OUT-07
|
|
118
|
-
**Success Criteria** (what must be TRUE):
|
|
119
|
-
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`)
|
|
120
|
-
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
|
|
121
|
-
3. El comando base `sourcecode .` mantiene su latencia habitual y no resuelve arboles transitivos salvo que el usuario active `--dependencies`
|
|
122
|
-
4. El schema expone dependencias de forma uniforme entre ecosistemas para que agentes IA puedan detectar incompatibilidades, duplicados o riesgos de version
|
|
123
|
-
**Status**: COMPLETE — implemented 2026-04-08; dependency analysis integrated behind `--dependencies`, full suite green
|
|
124
|
-
**Plans**: 4 planes
|
|
125
|
-
|
|
126
|
-
Plans:
|
|
127
|
-
- [x] 06-01: Base de dependencias — schema, flag `--dependencies` y analizador lazy desacoplado
|
|
128
|
-
- [x] 06-02: Node.js y Python — manifests + lockfiles con deps directas, resueltas y transitivas
|
|
129
|
-
- [x] 06-03: PHP, Ruby, Rust, Go y .NET — cobertura polyglot con limites explicitos donde la transitividad offline sea parcial
|
|
130
|
-
- [x] 06-04: Integracion final — workspaces/monorepo, tests end-to-end y documentacion publica del contrato
|
|
131
|
-
**UI hint**: no
|
|
132
|
-
|
|
133
|
-
### Fase 7: Grafos de Codigo
|
|
134
|
-
**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.
|
|
135
|
-
**Depends on**: Fase 6
|
|
136
|
-
**Requirements**: GRAPH-01, GRAPH-02, GRAPH-03, OUT-08
|
|
137
|
-
**Success Criteria** (what must be TRUE):
|
|
138
|
-
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
|
|
139
|
-
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
|
|
140
|
-
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
|
|
141
|
-
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
|
|
142
|
-
**Status**: COMPLETE — implemented 2026-04-08; module graph integrated behind `--graph-modules`, full suite green
|
|
143
|
-
**Plans**: 4 planes
|
|
144
|
-
|
|
145
|
-
Plans:
|
|
146
|
-
- [x] 07-01: Base del grafo — schema, flag `--graph-modules` y analizador lazy desacoplado
|
|
147
|
-
- [x] 07-02: Python y Node.js/TypeScript — imports internos, nodos de modulo y degradacion segura
|
|
148
|
-
- [x] 07-03: Relaciones estructurales y soporte polyglot — llamadas simples, jerarquias basicas y soporte inicial Go/JVM
|
|
149
|
-
- [x] 07-04: Integracion final — workspaces, limites de analisis, tests end-to-end y documentacion publica del contrato
|
|
150
|
-
**UI hint**: no
|
|
151
|
-
|
|
152
|
-
### Fase 8: Documentacion Extraida
|
|
153
|
-
**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.
|
|
154
|
-
**Depends on**: Fase 7
|
|
155
|
-
**Requirements**: DOCS-01, DOCS-02, DOCS-03, OUT-09
|
|
156
|
-
**Success Criteria** (what must be TRUE):
|
|
157
|
-
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
|
|
158
|
-
2. El output distingue entre documentacion explicita del autor y resumen inferido por la herramienta para evitar mezclar texto original con interpretaciones
|
|
159
|
-
3. Los modulos principales del proyecto incluyen un resumen compacto con proposito, simbolos destacados y relaciones con otros componentes
|
|
160
|
-
4. El schema sigue siendo consumible por maquinas y evita volcar bloques enormes de texto sin estructura ni procedencia
|
|
161
|
-
**Plans**: 0 planes
|
|
162
|
-
**UI hint**: no
|
|
163
|
-
|
|
164
|
-
### Fase 9: Metricas de Calidad
|
|
165
|
-
**Goal**: La herramienta aporta senales cuantitativas sobre complejidad, tamano, tests y cobertura para priorizar refactors, auditorias y trabajo de agentes automaticos.
|
|
166
|
-
**Depends on**: Fase 8
|
|
167
|
-
**Requirements**: METRICS-01, METRICS-02, METRICS-03, OUT-10
|
|
168
|
-
**Success Criteria** (what must be TRUE):
|
|
169
|
-
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
|
|
170
|
-
2. La herramienta detecta archivos o suites de tests relacionadas y asocia modulos productivos con evidencia de cobertura o ausencia de pruebas
|
|
171
|
-
3. Cuando existe metadata de cobertura (`coverage.xml`, `.coverage`, `lcov.info`, `jacoco.xml`, etc.), el output la incorpora sin ejecutar tests por defecto
|
|
172
|
-
4. El comando distingue claramente entre metricas medidas, inferidas y no disponibles para no transmitir precision falsa
|
|
173
|
-
**Plans**: 0 planes
|
|
174
|
-
**UI hint**: no
|
|
175
|
-
|
|
176
|
-
### Fase 10: Contexto Git y Operativo
|
|
177
|
-
**Goal**: La herramienta añade contexto historico y operativo del repositorio para identificar volatilidad, expertos, integraciones de despliegue y superficie de automatizacion.
|
|
178
|
-
**Depends on**: Fase 9
|
|
179
|
-
**Requirements**: GIT-01, OPS-01, OPS-02, OUT-11
|
|
180
|
-
**Success Criteria** (what must be TRUE):
|
|
181
|
-
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
|
|
182
|
-
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
|
|
183
|
-
3. Las variables de entorno o secretos solo se reportan como metadata segura (`nombre`, `origen`, `uso aproximado`) sin exponer valores sensibles
|
|
184
|
-
4. El comando base `sourcecode .` sigue centrado en estructura + stacks + workflows, mientras que el contexto historico/operativo ampliado queda detras de flags explicitamente solicitados
|
|
185
|
-
**Plans**: 0 planes
|
|
186
|
-
**UI hint**: no
|
|
187
|
-
|
|
188
|
-
## Progreso
|
|
189
|
-
|
|
190
|
-
**Orden de ejecucion:**
|
|
191
|
-
Las fases se ejecutan en orden numerico: 1 → 2 → 3 → 4 → 5 → 6 → 7 → 8 → 9 → 10
|
|
192
|
-
|
|
193
|
-
| Fase | Planes Completos | Estado | Completada |
|
|
194
|
-
|------|-----------------|--------|------------|
|
|
195
|
-
| 1. Fundaciones | 4/4 | Complete | 2026-04-07 |
|
|
196
|
-
| 2. Deteccion Core | 4/4 | Complete | 2026-04-07 |
|
|
197
|
-
| 3. Clasificacion y Multi-Stack | 2/2 | Complete | 2026-04-07 |
|
|
198
|
-
| 4. Pulido y Publicacion | 3/3 | Complete | 2026-04-07 |
|
|
199
|
-
| 5. Scanner Universal | 4/4 | Complete | 2026-04-07 |
|
|
200
|
-
| 6. Dependencias Inteligentes | 4/4 | Complete | 2026-04-08 |
|
|
201
|
-
| 7. Grafos de Codigo | 4/4 | Complete | 2026-04-08 |
|
|
202
|
-
| 8. Documentacion Extraida | 0/0 | Not planned | - |
|
|
203
|
-
| 9. Metricas de Calidad | 0/0 | Not planned | - |
|
|
204
|
-
| 10. Contexto Git y Operativo | 0/0 | Not planned | - |
|