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).
107 lines
4 KiB
Markdown
107 lines
4 KiB
Markdown
# 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:
|
|
|
|
1. **Agentes AI** — que necesitan consumir conocimiento estructurado del proyecto,
|
|
no texto libre. Antes no había consumidor que lo requiriera con urgencia.
|
|
2. **NCL/Nickel** — contratos y tipos que permiten expresar ontología sin triplestore externo.
|
|
RDF/OWL requería infraestructura pesada y expertise especializado.
|
|
3. **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 |
|