fn_registry/bash/functions/pipelines/clone_project_subrepos.md

name, kind, lang, domain, version, purity, signature, description, tags, uses_functions, uses_types, returns, returns_optional, error_type, imports, params, output, tested, tests, test_file_path, file_path

name	kind	lang	domain	version	purity	signature	description	tags	uses_functions	uses_types	returns	returns_optional	error_type	imports	params	output	tested	tests	test_file_path	file_path
clone_project_subrepos	function	bash	pipelines	1.0.0	impure	clone_project_subrepos <project_id> [--owner OWNER] [--dry-run]	Clona todos los sub-repos Gitea de los artefactos (apps + analysis, NO vaults) de un project. Util en PC recien clonado para traer un project entero sin clonar uno a uno.	git gitea project launcher				false	error_go_core		name desc project_id ID del project en tabla projects (ej. fn_monitoring, osint_graph) name desc --owner Dueno Gitea de los repos, default dataforge name desc --dry-run Modo simulacion: imprime las acciones sin ejecutarlas	Tabla de resultados por sub-repo: kind | name | status (cloned/skip/failed). Exit 0 si todo cloned o skip, 1 si algun failed.	false			bash/functions/pipelines/clone_project_subrepos.sh

Ejemplo

# Desde fn_registry recien clonado en PC nuevo
./fn run clone_project_subrepos fn_monitoring

# Resultado esperado:
# KIND       NAME                                STATUS
# ---------- ----------------------------------- -------
# app        call_monitor                        [cloned]
# app        registry_dashboard                  [cloned]
# app        sqlite_api                          [cloned]
# analysis   domain_coverage_gaps                [cloned]
#
# Siguiente paso sugerido:
#   cd $HOME/fn_registry && CGO_ENABLED=1 ./fn index && ./fn sync

# Con owner alternativo
./fn run clone_project_subrepos aurgi --owner miorg

# Dry-run para ver que clonaria sin ejecutar
./fn run clone_project_subrepos osint_graph --dry-run

Cuando usarla

Cuando llegas a un PC nuevo con solo fn_registry clonado y quieres trabajar en un project concreto sin clonar cada sub-repo a mano. Tambien tras fn sync cuando los pc_locations indican que faltan artefactos del project en este PC.

Flujo interno

1. Valida que registry.db existe y que project_id esta en tabla projects.
2. Query SQL: SELECT 'app'... FROM apps WHERE project_id=? UNION ALL SELECT 'analysis'... FROM analysis WHERE project_id=? — vaults excluidos deliberadamente.
3. Por cada artefacto: si dir_path/.git existe → [skip]; si repo_url esta vacio en BD → construye ${GITEA_URL}/<owner>/<basename>; ejecuta git clone --branch master.
4. Imprime tabla resumen. Sugiere fn index && fn sync al terminar.

Variables de entorno

• FN_REGISTRY_ROOT — raiz del registry; default $HOME/fn_registry
• GITEA_URL — URL base de Gitea; default https://gitea-dgg044oo04woo4ggcsws4gk0.organic-machine.com
• Auth git/ssh: el pipeline confía en la config local del usuario (SSH key, credential helper)

Gotchas

• Vaults NO se clonan. Son symlinks a datos externos; el usuario los crea aparte (mkdir -p ~/vaults/... && ln -s ...).
• Si repo_url esta vacio en BD, se construye como ${GITEA_URL}/<owner>/<basename(dir_path)>. Si tu convencion de nombres Gitea difiere, rellena repo_url en los app.md/analysis.md antes de ejecutar y re-indexa.
• Auth: el script no inyecta credenciales. Si clone falla por auth, configura SSH key o credential helper (git config --global credential.helper ...) y relanza.
• El project debe existir en tabla projects y los artefactos llevar project_id correcto en su .md. Si no, el query no devuelve filas. Verificar con: sqlite3 registry.db "SELECT id FROM projects;".
• Branch master asumido. Todos los repos del ecosistema usan master (ADR 0002). Si un repo usa otra branch, clonar manualmente.
• Artefactos sin dir_path quedan como [skip: dir_path vacio en BD]. Rellenar el campo en el .md y re-indexar.