82a358f18d
ontoref-derive: #[onto_mcp_tool] attribute macro registers MCP tool unit-structs in
the catalog at link time via inventory::submit!; annotated item is emitted unchanged,
ToolBase/AsyncTool impls stay on the struct. All 34 tools migrated from manual wiring
(net +5: ontoref_list_projects, ontoref_search, ontoref_describe,
ontoref_list_ontology_extensions, ontoref_get_ontology_extension).
validate modes (ADR-018): reads level_hierarchy from workflow.ncl and checks every
.ncl mode for level declared, strategy declared, delegate chain coherent, compose
extends valid. mode resolve <id> shows which hierarchy level handles a mode and why.
--self-test generates synthetic fixtures in a temp dir for CI smoke-testing.
validate run-cargo: two-step Cargo.toml resolution — workspace layout first
(crates/<check.crate>/Cargo.toml), single-crate fallback by package name or repo
basename. Lets the same ADR constraint shape apply to workspace and single-crate repos.
ontology/schemas/manifest.ncl: registry_topology_type contract — multi-registry
coordination, push targets, participant scopes, per-namespace capability.
reflection/requirements/base.ncl: oras ≥1.2.0, cosign ≥2.0.0, sops ≥3.9.0, age
≥1.1.0, restic declared as Hard/Soft requirements with version_min, check_cmd, and
install_hint (ADR-017 toolchain surface).
ADR-019: per-file recipient routing for tenant isolation without multi-vault. Schema
additions: sops.recipient_groups + sops.recipient_rules in ontoref-project.ncl.
secrets-bootstrap generates .sops.yaml from project.ncl in declarative mode. Three
new secrets-audit checks: recipient-routing-coherent, recipient-routing-coverage,
no-multi-vault. Adoption templates: single-team/, multi-tenant/, agent-first/.
Integration templates: domain-producer/, mode-producer/, mode-consumer/.
UI: project_picker surfaces registry badge (⟳ participant) and vault badge
(⛁ vault_id · N, green=declarative / amber=legacy) per project card. Expanded panel
adds collapsible Registry section with namespace, endpoint, and push/pull capability.
manage.html gains Runtime Services card — MCP and GraphQL toggleable without restart
via HTMX POST /ui/manage/services/{service}/toggle.
describe.nu: capabilities JSON includes registry_topology and vault_state per project.
sync.nu: drift check extended to detect //! absence on newly registered crates.
qa.ncl: six entries — credential-vault-best-practice (layered data-flow diagram),
credential-vault-templates (paths A/B/C), credential-vault-troubleshooting (15 named
errors), integration-what-and-why (ADR-042 OCI federation), integration-how-to-implement,
integration-troubleshooting.
on+re: core.ncl + manifest.ncl updated to reflect OCI, MCP, and mode-hierarchy nodes.
Deleted stale presentation assets (2026-02 slides + voice notes).
122 lines
7.3 KiB
Markdown
122 lines
7.3 KiB
Markdown
---
|
|
# Post metadata
|
|
id: "un-protocolo-tres-sujetos"
|
|
title: "Un protocolo, tres sujetos"
|
|
slug: "un-protocolo-tres-sujetos"
|
|
subtitle: "La misma pregunta aplica a tu proyecto, tu infraestructura, y a ti mismo"
|
|
excerpt: "Ontoref comenzó como un protocolo para el auto-conocimiento de proyectos de software. La misma arquitectura — DAG ontológico para lo que ES, DAG de reflexión para lo que DEVIENE — aplica sin modificación a entornos de infraestructura y a individuos. El sujeto cambia. La pregunta es idéntica: ¿qué eres, qué tensiones te definen, dónde estás versus dónde pretendes estar?"
|
|
|
|
# Publication info
|
|
author: "Jesús Pérez"
|
|
date: "2026-05-10"
|
|
published: false
|
|
featured: false
|
|
|
|
# Categorization
|
|
category: "ontoref"
|
|
tags: ["ontoref", "ontology", "infraestructura", "conocimiento-personal", "reflection"]
|
|
|
|
# Display
|
|
read_time: "7 min read"
|
|
sort_order: 3
|
|
css_class: "category-ontoref"
|
|
category_description: "Ontoref — protocolo y herramientas para el auto-conocimiento estructurado en proyectos de software"
|
|
category_published: true
|
|
---
|
|
|
|
# Un protocolo, tres sujetos
|
|
|
|
La pregunta que ontoref hace a un proyecto de software es precisa: *¿Qué eres? ¿Qué principios te definen? ¿Qué tensiones estás gestionando activamente? ¿Qué decisiones has tomado con consecuencias duraderas? ¿Dónde estás versus dónde pretendes estar?*
|
|
|
|
Resulta que es la misma pregunta que los entornos de infraestructura necesitan responder. Y los individuos.
|
|
|
|
El sujeto cambia. La pregunta es idéntica.
|
|
|
|
## Lo que los tres tienen en común
|
|
|
|
Cualquier sistema con identidad e intención comparte el mismo problema estructural:
|
|
|
|
- **Identidad** — qué es, qué principios lo definen
|
|
- **Tensiones activas** — trade-offs que no se resuelven, se gestionan
|
|
- **Decisiones duraderas** — elecciones con consecuencias que restringen el futuro
|
|
- **Estado observable** — dónde está versus dónde pretende estar
|
|
- **Deriva** — la distancia entre intención y realidad, creciendo silenciosamente con el tiempo
|
|
- **Operaciones** — las acciones que reducen esa deriva
|
|
|
|
Los proyectos de software tienen todo esto. Los entornos de infraestructura también. Las personas también.
|
|
|
|
Y todos se benefician de la misma arquitectura: una capa ontológica que captura lo que ES, y una capa de reflexión que captura lo que DEVIENE y opera para mantener ambas alineadas.
|
|
|
|
## Infraestructura
|
|
|
|
La infraestructura ya usa DAGs — Terraform, Pulumi, Ansible. Todos describen *cómo* se provisiona el sistema. Ninguno captura *por qué existe como existe*.
|
|
|
|
El "por qué" es donde vive el conocimiento:
|
|
|
|
```
|
|
Servicio "auth" --tension--> Principio "stateless"
|
|
razón: necesita session state, pero el principio lo prohíbe
|
|
|
|
Constraint "zero-downtime" --enforces--> Práctica "blue-green"
|
|
razón: ADR-infra-003, después del incidente de deploy de 2025
|
|
```
|
|
|
|
Esta información no está en el plan de Terraform. Está en la memoria del engineer que estuvo allí, en un hilo de Slack de hace ocho meses, o en ningún lado. Cuando ese engineer se va, la infraestructura pierde su propia historia — sabe lo que es, no por qué.
|
|
|
|
El ontoref de infraestructura captura las decisiones arquitectónicas de la propia infraestructura, con el mismo formalismo de ADR que los proyectos de software. Registra dimensiones de estado — qué entornos están estables, cuáles en migración activa, qué está bloqueado y por qué. El FSM no registra el estado de deploy; registra el *estado epistémico* — qué tan bien se entiende a sí misma la infraestructura.
|
|
|
|
La federación vía NATS significa que cada entorno (dev, staging, prod) se describe a sí mismo y puede ser consultado desde los proyectos que dependen de él. GitOps soberano: el conocimiento de infraestructura vive con el código de infraestructura, no en la base de datos de un vendor.
|
|
|
|
## Personal
|
|
|
|
Esta es la aplicación más radical. Pero se sigue directamente de la misma lógica.
|
|
|
|
Una persona con valores, roles e intenciones a largo plazo enfrenta exactamente el mismo problema estructural que un proyecto de software:
|
|
|
|
```
|
|
Valor "profundidad" --tension--> Rol "padre"
|
|
razón: el tiempo es finito y los dos lo demandan completamente
|
|
|
|
Decisión "dejé empresa X" --constraint--> Elecciones de carrera futuras
|
|
con el mismo peso arquitectónico que un ADR-001
|
|
|
|
Estado "aprendiendo Rust" --blocker--> "contribuir a ontoref-core"
|
|
una dimensión FSM personal, no un ítem de lista de tareas
|
|
```
|
|
|
|
El knowledge graph aquí no es un sistema de productividad. No es un segundo cerebro de notas. Es un grafo de *compromisos* — tipados, provenados, con tensiones activas nombradas en lugar de suprimidas.
|
|
|
|
El problema de deriva es idéntico: quién estás llegando a ser versus quién pretendías ser. Los modos de reflexión para una persona pueden ser revisiones semanales, evaluaciones anuales de estado, o revisiones disparadas cuando una decisión mayor introduce nuevos constraints. El loop operacional es el mismo — observa, detecta deriva, ejecuta, registra.
|
|
|
|
## El mismo stack, sujeto distinto
|
|
|
|
Los tres dominios corren en la misma infraestructura:
|
|
|
|
**Almacenamiento soberano:** El conocimiento vive junto a su sujeto — en el repo del proyecto, en el código de infraestructura, en una bóveda personal. Ningún vendor lo retiene. Sin dependencia de plataforma. Archivos NCL versionados con la misma disciplina que el código.
|
|
|
|
**Acceso multi-superficie:**
|
|
|
|
| Superficie | Consumidor |
|
|
|---|---|
|
|
| CLI (Nushell) | Developer, scripts, CI |
|
|
| UI (axum) | Revisión visual, onboarding |
|
|
| MCP | Agentes AI |
|
|
| GraphQL | Herramientas externas, dashboards |
|
|
|
|
**Alineación VCS:** El modelo de jj — donde el working copy es siempre un commit — se alinea naturalmente con el enfoque de ontoref de captura continua de estado. No hay "dirty state"; cada momento es capturable. Radicle como transporte hace el stack soberano y P2P — colaboración de código sin plataforma central.
|
|
|
|
**Federación:** Proyectos consultando los knowledge graphs de otros sin un broker central. Entornos de infraestructura exponiendo su auto-conocimiento a los proyectos que dependen de ellos. Individuos cuyo knowledge graph personal informa sus contribuciones a los proyectos en los que trabajan.
|
|
|
|
## Por qué la escala importa
|
|
|
|
La unidad más pequeña que puede adoptar ontoref es una persona. Un developer, un proyecto, un entorno de infraestructura. Sin equipo requerido. Sin conversación de presupuesto.
|
|
|
|
La unidad más grande es un ecosistema de proyectos federados y auto-descritos que pueden consultarse mutuamente sin que ninguno sea la fuente central autoritativa.
|
|
|
|
Ese rango — de individuo a ecosistema — es posible porque el protocolo es el mismo a cada escala. El DAG ontológico y el DAG de reflexión no cambian de forma según el tamaño del sujeto. Cambian en densidad y profundidad, no en estructura.
|
|
|
|
Las organizaciones que Talisman argumenta deberían invertir en infraestructura de conocimiento intentan construirla top-down, con equipos dedicados y programas de varios años. Ontoref lo hace disponible bottom-up — empezando con un solo proyecto, un solo entorno, una sola persona, cada uno describiéndose a sí mismo en el mismo lenguaje.
|
|
|
|
---
|
|
|
|
*Ontoref es open source. La especificación del protocolo, la automatización en Nushell, y los crates de Rust están en [github.com/jesusperezlorenzo/ontoref](https://github.com/jesusperezlorenzo/ontoref).*
|