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).
4 KiB
Ontoref — Por qué los DAGs de ontoref son diferentes
Referencia para posts, slides, presentaciones. Contexto: análisis de por qué DAGs son ubicuos pero nadie tiene la perspectiva de ontoref.
DAGs son ubicuos — y todos hacen lo mismo
En CI/CD, compiladores, runbooks, Airflow, dbt, Bazel: el DAG es un modelo de ejecución. Las aristas significan "esto antes que aquello". El grafo describe cómo se computa, no qué es lo que se computa. Es ordenación topológica, no conocimiento.
CI/CD: test → build → deploy
Compiler: parse → typecheck → codegen → link
Runbook: check_health → drain → restart → verify
Todos inerts. El grafo no sabe qué es el proyecto. No tiene semántica sobre sus propias aristas.
Ontoref usa DAGs en dos modos distintos
DAG ontológico — aristas con tipo semántico:
Practice "ncl-schemas" --implements--> Principle "type-safety"
Practice "ncl-schemas" --enforces--> Constraint "zero-runtime-deps"
Practice "ncl-schemas" --enables--> Capability "agent-queryable-state"
Practice "ncl-schemas" --tension--> Practice "adoption-friction"
No es "esto antes que aquello". Es conocimiento — compromisos formales sobre qué ES el proyecto y cómo se relacionan sus conceptos. El equivalente sería un compilador que sabe por qué existe y qué trade-offs tomó.
DAG de reflexión — aristas con contrato ejecutable + restricción de actor:
step "validate-state" (actor: any) --> step "run-mode" (actor: developer)
step "run-mode" (actor: developer) --> step "report" (actor: agent|developer)
No es solo ejecución. El DAG es validado como contrato antes de ejecutarse, registra su propio progreso, y sabe quién puede hacer qué.
El gap que nadie ha cerrado
Knowledge Graph world: semántica sobre el dominio del negocio
Software tooling world: DAGs sobre la ejecución del software
ontoref: semántica sobre el proyecto de software en sí mismo
El mundo de knowledge graphs (W3C, RDF/OWL, Talisman) aplica semántica a dominios empresariales — productos, clientes, transacciones. Nunca al proyecto de software mismo.
El mundo de herramientas de software (GitHub, Jira, CI/CD) trata el conocimiento del proyecto como documentos no tipados. Usa DAGs para ejecución, nunca para representación de conocimiento.
La pieza que lo hace no-trivial
Los dos DAGs se hablan:
- El DAG ontológico dice qué es el proyecto (prácticas, principios, constraints activos)
- El DAG de reflexión opera sobre ese estado — detecta deriva, ejecuta modos, registra transiciones
- Las migraciones propagan cambios del DAG ontológico a proyectos consumidores
Sin esa conexión: ontología bonita que nadie mantiene (buenas intenciones) o runbooks sin semántica (ejecución ciega).
Por qué no había emergido antes
Tres condicionantes que ahora se alinean:
- Agentes AI — que necesitan consumir conocimiento estructurado del proyecto, no texto libre. Antes no había consumidor que lo requiriera con urgencia.
- NCL/Nickel — contratos y tipos que permiten expresar ontología sin triplestore externo. RDF/OWL requería infraestructura pesada y expertise especializado.
- La escala correcta — Knowledge Graphs empresariales son proyectos de años. Ontoref opera a escala de repositorio, con adopción incremental y sin enforcement.
Para slides
Una línea: Todos usan DAGs para HACER cosas. Ontoref usa DAGs para CONOCER cosas sobre el proyecto, Y para HACER cosas, Y hace que las dos capas se hablen.
Contraste:
| DAGs tradicionales | DAGs en ontoref |
|---|---|
| Modelo de ejecución | Modelo de conocimiento + ejecución |
| Aristas: "depende de" | Aristas: implements, enforces, tension, enables |
| Inert respecto al proyecto | Semánticamente cargado con el estado del proyecto |
| Evalúa y descarta | Evalúa, registra, propaga |
| Grafo describe proceso externo | Grafo describe el proyecto mismo |