kpi_card:
- v1.1: envuelve el contenido en BeginChild con surface bg + border +
radius::md + padding::md (tokens). Replica Mantine Paper withBorder
radius="md" p="md" usado en @fn_library/kpi_card.tsx.
- Ancho adaptativo via GetContentRegionAvail — requiere contenedor que
propague ancho constrained (ImGui::BeginTable). dashboard_grid / BeginGroup
no funcionan porque no constrainen ancho y la card desborda la celda.
- Linea de trend SIEMPRE visible: delta, sparkline, o em dash (text_dim)
como placeholder, para que un grid de KPIs quede alineado vertical.
- Colores del delta via tokens (success/error) en vez de hardcoded ImVec4.
bar_chart:
- v1.1: altura explicita como parametro (default 200px). Sin esto, ImPlot
con ImVec2(-1, 0) entra en feedback loop cuando esta dentro de un
dashboard_panel (BeginChild con AutoResizeY): plot pide espacio -> padre
se redimensiona -> plot recalcula. Efecto visual: las barras se deslizan
los primeros frames.
- Ejes blindados: Lock + NoInitialFit + Cond_Always ademas de los flags
previos. Y max pre-calculado con 15% de headroom.
- Sin inputs (NoInputs|NoFrame|NoBoxSelect|NoMouseText): estos charts son
de resumen, no de exploracion.
Actualizados los .md correspondientes con el contrato visual + requisitos
de contenedor, para que cualquier dashboard que componga estos primitivos
obtenga el mismo look.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- cpp/functions/gfx/gl_loader.{h,cpp,md}: mini loader para OpenGL 2.0+
(Linux no-op via GL_GLEXT_PROTOTYPES, Windows wglGetProcAddress)
- Portar gl_shader/gl_framebuffer/fullscreen_quad/shader_canvas al loader
- CMakeLists: WIN32_EXECUTABLE para lanzar sin consola en Windows
- apps/shaders_lab/shaders_lab.exe: binario PE32+ precompilado
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- sqlite_api se extrae a su propio repo Gitea (dataforge/sqlite_api),
siguiendo la convencion de apps/*/ (cada app = su repo).
- registry.db ya estaba en .gitignore (regenerable con fn index +
fn sync), pero seguia tracked por historia. Destracked.
- project.md de fn_monitoring ampliado con operacion completa:
arranque del service (dev / start.sh / systemd user), flujo de
datos dashboard, troubleshooting, como extender.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Trasladar principios del DESIGN_SYSTEM.md de @fn_library (Mantine/React)
al mundo C++/ImGui sin añadir deps externas:
cpp/functions/core/
tokens — colors/spacing/radius/font_size como constexpr +
apply_dark_theme() al ImGuiStyle global. Dark + indigo
primary (Mantine-inspired).
badge — etiqueta inline 6 variantes (Default/Success/Warning/
Error/Info/Outline). <Badge> de @fn_library en C++.
empty_state — placeholder centrado para tablas/listas vacías.
page_header — header con title + subtitle + separator + hueco
para acciones (patrón begin/end).
Scope limitado (KISS) a fases 1-2 del plan: tokens + 3 primitivos.
No se duplica dashboard_panel con un "card" — el existente ya cumple
el rol. Fases 3-5 (charts ImPlot line/area, app_shell con navbar,
toast/alert) quedan fuera hasta que el dashboard crezca en alcance.
Resultado:
- 869 funciones (+4) en registry.db.
- Dashboard con header homogéneo y empty states en todas las tablas.
- Sin hardcode de ImVec4 disperso en views.cpp.
Diary + CHANGELOG actualizados.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Infraestructura de documentación operativa y de decisiones:
- docs/adr/ — Architecture Decision Records. Incluye plantilla y
ADR 0001 documentando el experimento y retirada de GitButler.
- docs/diary/ — diario de avances con un archivo por día.
Primera entrada 2026-04-24.md retrocubriendo esta sesión
(conectar aurgi-pc, dashboard fn_monitoring, funciones systemd
locales, ADR GitButler, regla KISS).
- CHANGELOG.md — formato Keep a Changelog para cambios cara a
usuario/agentes. Sección 2026-04-24 con Added/Changed/Fixed/Removed.
- .claude/commands/entrada_diario.md — slash command para añadir
entradas al diario con formato consistente.
Separación:
diary = contexto operativo diario
CHANGELOG = qué cambió en el código
ADR = por qué se decidió algo
rules = reglas operativas del agente
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Formaliza la filosofía de mantener projects/ y apps/ simples:
- preferir herramientas del sistema o del registry antes que paquetes
externos,
- cuestionar cada nueva dependencia (coste/beneficio, riesgo upstream),
- evitar abstracciones especulativas,
- ser consciente del flujo de trabajo actual.
Incluye el aprendizaje del experimento con GitButler (retirado en commit
correspondiente de repo_Claude) como caso concreto de una herramienta
externa que añadió complejidad sin beneficio en nuestro contexto.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Nuevas primitivas para gestionar servicios systemd del sistema desde
el registry (antes solo había versiones remotas via SSH para deploy VPS):
bash/functions/infra/
systemd_local_install_unit — escribir unit en /etc/systemd/system + daemon-reload
systemd_local_enable — systemctl enable
systemd_local_start — systemctl start + MainPID
systemd_local_restart — systemctl restart + MainPID
systemd_local_status — ActiveState/SubState/pid/enabled + journal tail (no sudo)
systemd_local_uninstall — stop + disable + rm unit + daemon-reload (idempotente)
bash/functions/pipelines/
install_systemd_service — pipeline que compone las anteriores; args
--name --exec [--workdir --user --env KEY=VAL
--after --restart --type]
Requisito: sudo sin password para systemctl + escritura en /etc/systemd/system/.
En WSL: systemd=true en /etc/wsl.conf.
Registrado sqlite_api como servicio del sistema con este pipeline, queda
vivo al arrancar WSL. Dashboard ya no necesita arrancar la API manualmente.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- registry.db ahora gitignored y regenerable con 'fn index' +
completable con 'fn sync'. Evita conflictos entre ramas / PCs.
- Re-registrar submódulo cpp/vendor/glfw en .gitmodules con path
limpio (antes heredado con /home/lucas/...). Necesario para el
cross-compile Windows del registry_dashboard.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Covers the client-side linking flow (not the server deploy, which
already lives in bash/functions/infra/setup_registry_api.md):
- Requisitos: server UP, fn binary, pass con 3 entradas, GPG desbloqueada.
- Paso 1: ~/.fn_pc (identidad).
- Paso 2: FN_REGISTRY_API + REGISTRY_API_TOKEN — 3 opciones (zshrc snippet
desde pass, direnv por proyecto, a mano por sesión).
- Paso 3-4: verificar con fn sync status + primer fn sync.
- Troubleshooting table (401, 403, localhost:8420, GPG cache, etc).
docs/README.md enlaza al nuevo fichero. registry.db actualizada tras
primer sync contra el server desde esta sesión.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
From: sources/frontend_designs/Ads Analytics Dashboard _standalone_.html
New components:
- funnel_chart_ts_ui — visualización de funnel de conversión con barras
degradadas y tasa entre etapas como Badge semántico.
- heatmap_grid_ts_ui — matriz rows × cols con intensidad color-mix sobre
el primary color. Genérica (day×hour, cohort, correlation...).
Improvements:
- alert_ts_ui v1.1.0 — añadidas variantes semánticas success, warning, info
(antes: solo default y destructive).
- data_table_ts_ui v1.1.0 — prop opcional density: compact | cozy | roomy.
No rompe API existente (default 'cozy' = comportamiento previo).
Barrel frontend/functions/ui/index.ts actualizado con los dos nuevos
exports y el type DataTableDensity.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
- frontend/DESIGN_SYSTEM.md: contrato del @fn_library (regla suprema para
Claude Design y agentes).
- frontend/design_prompts/: 11 plantillas de prompt (onboarding, dashboard,
crud, detail, settings, auth, error, custom, handoff_integrate) +
questionnaire numerado para arranque rapido.
- .claude/commands/extract-design.md: workflow de 10 pasos para extraer
componentes nuevos y mejoras desde exports "standalone" de Claude Design
al registry, sync al espejo fn-design-system y push a gitea+github.
- .claude/scripts/extract_design_bundle.py: decodificador del bundle
(base64+gzip en manifest, nombra JSX por heuristica de header).
- .gitignore: ignorar subrepos/*/ (el mirror fn-design-system es repo
propio con remotes dataforge/fn-design-system + gutierenmanuel/fn-design-system).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Los 4 init pipelines (init_api_app, init_web_app, init_desktop_app,
init_cli_app) estan implementados, verificados end-to-end con `fn run`, e
indexados en registry.db como kind=pipeline + tag=launcher. Guia consolidada
en docs/init-pipelines.md.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
docs/init-pipelines.md: referencia rapida de los 4 init pipelines con tabla
resumen, arbol de decision, combinaciones comunes, FAQ y estructura
generada por tipo.
registry.db: re-indexado para registrar los 4 nuevos pipelines como
kind=pipeline, purity=impure, domain=pipelines, tag=launcher.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Genera apps/{nombre}/ con main.go (subcommand routing via os.Args + switch),
cmd_version.go, cmd_status.go, Makefile (build/run/install/test/vet/clean),
.gitignore, go.mod y app.md. Sin cobra/urfave — consistente con el resto de
apps del registry.
Flag --with-tui anade model.go con un modelo Bubbletea fullscreen (lista
filtrable con bubbles/list, spinner con bubbles/spinner, dark theme con
lipgloss). main.go arranca la TUI con tea.NewProgram(m, WithAltScreen) si no
hay args; sino hace subcommand routing normal.
Verifica con go mod tidy + go vet.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Genera apps/{nombre}/ con Wails v2 backend (main.go con embed frontend/dist,
app.go con struct App y bindings Greet/GetVersion) + frontend Vite+React+Mantine
con alias @fn_library.
Flag --with-db anade store.go con SQLite (schema items) y bindings CRUD
(ListItems, CreateItem); app.go se regenera con campo db.
wails.json con scripts pnpm, go.mod con replace a fn-registry, app.md con
framework wails+vite+react+mantine y dir_path correcto.
Verifica con go mod tidy al final. wails build requiere CLI instalado pero
el scaffold funciona sin el.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Extiende init_api_app anadiendo la capa frontend: pnpm + vite + react +
@mantine/core. Genera frontend/ con vite.config.ts (proxy /api y /health al
backend + alias @fn_library a frontend/functions/ui), src/main.tsx con
MantineProvider, src/App.tsx con AppShell y src/pages/Home.tsx consumiendo
/api/v1/status.
Flags: --port N, --with-auth, --with-db (delegadas a init_api_app).
Docker compose para desarrollo. Verifica con pnpm install && pnpm build si
pnpm esta disponible (skippable con SKIP_PNPM_BUILD=true).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Genera apps/{nombre}/ con main.go (http_serve + router + middleware chain +
graceful shutdown), handlers.go (HTTPJSONResponse), config.go (env vars),
migrations/001_initial.sql, Makefile, .env.example, .gitignore, go.mod y
app.md con frontmatter correcto.
Flags opcionales:
--port N puerto default del server (default 8080)
--with-auth jwt_middleware + login/register + tabla users/sessions
--with-db store.go con helpers CRUD y setup SQLite
--with-ops stub para fn ops init
Compone 8+ funciones del registry (http_*, migration_up, password_*, jwt_*).
Verifica con go vet al final.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Fase 5 del issue 0010 — RBAC y middlewares de auth.
- rbac_check es pura: solo recorre la matriz roles/permisos
- jwt_middleware extrae token del header Authorization: Bearer, valida e
inyecta claims en el context con una key privada (jwtCtxKey struct{})
- rbac_middleware requiere jwt_middleware antes; lee role de claims.Custom
- Helper JWTClaimsFromContext para acceder a las claims desde handlers
- 401 claro si RBAC se usa sin JWT antes (code: no_claims)
Fase 4 del issue 0010 — cliente OAuth2 sin golang.org/x/oauth2.
- Oauth2AuthURL es pura: solo construye la URL con net/url
- Oauth2Exchange/Refresh hacen POST application/x-www-form-urlencoded
- ExpiresAt calculado como now + expires_in del proveedor
- Refresh conserva el token original si el proveedor no devuelve uno nuevo
- Tests con httptest.NewServer como mock del proveedor
Fase 3 del issue 0010 — sesiones SQLite como alternativa a JWT.
- Tabla sessions creada con CREATE TABLE IF NOT EXISTS (autosetup)
- Tokens de 32 bytes aleatorios (crypto/rand) codificados en hex (256 bits)
- Indices en user_id y expires_at
- Prepared statements para evitar SQL injection
- SessionCleanup para eliminar expiradas periodicamente
Fase 1 del issue 0010 — tipos base del sistema de auth en dominio infra.
Define las estructuras que usaran jwt_*, session_*, oauth2_* y rbac_*.
Añade dep golang.org/x/crypto/bcrypt para el hashing de passwords.
external/ contiene symlink a repo_Claude (skills).
worktrees/ es el directorio que usa parallel-fix-issues.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Anade tests unitarios e integracion sobre SQLite in-memory:
- CRUDDefineResource: casos felices y rechazo de inputs invalidos
(nombre vacio, tipos no soportados, nombres reservados, duplicados).
- CRUDGenerateTableSQL: columnas base, NOT NULL/UNIQUE/DEFAULT, deleted_at
con soft_delete y verificacion de que el DDL es ejecutable en sqlite.
- Create + Get: creacion feliz, validaciones required/min_length/max_length/
enum/min/max, 409 en UNIQUE, GET 200/404.
- List: paginacion, filtros, orden ascendente, campos desconocidos ignorados.
- Update: partial update, 404 y validacion de campos enviados.
- Delete: hard delete, soft delete, 404, ocultar soft-deleted en list.
- Integracion end-to-end con httptest.NewServer cubriendo CRUD completo y
multiples recursos registrados en el mismo mux.
Anade los 5 handlers CRUD genericos (list, get, create, update, delete) a
partir de un CRUDResource y *sql.DB, la factory crud_generate_handlers que
compone los 5 en un mapa, y crud_register_routes que registra todas las
rutas REST en un http.ServeMux con la sintaxis METHOD /path de Go 1.22+.
Caracteristicas:
- List con paginacion (page, per_page), orden (sort_by, sort_dir) y
filtros exactos (filter_<campo>), validando nombres de columna contra
la definicion del recurso para evitar SQL injection.
- Create valida required y validaciones (min/max, min_length/max_length,
pattern, enum) antes de insertar; mapea UNIQUE violations a 409.
- Update hace partial update — solo los campos presentes en el JSON.
- Delete hace hard delete o soft delete segun CRUDResource.SoftDelete.
- UUIDs generados via github.com/google/uuid; timestamps en RFC3339Nano UTC.
Los handlers usan las funciones HTTP del registry (http_json_response,
http_error_response, http_parse_body) y se pueden componer con el mux
via http_router.
Anade los tipos CRUDResource, CRUDField, CRUDListParams y CRUDListResult
que modelan un recurso CRUD sobre SQLite, junto con dos funciones puras:
- crud_define_resource valida nombre, tabla y campos (tipos SQLite validos,
nombres reservados, duplicados) antes de retornar el CRUDResource.
- crud_generate_table_sql genera el DDL CREATE TABLE IF NOT EXISTS con
id TEXT PRIMARY KEY, timestamps estandar y, si aplica, deleted_at para
soft delete.
Primera capa de 0021 — el resto (handlers + registro de rutas) se apoya
sobre estas estructuras.
egutierrez