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).
67 lines
2.7 KiB
Markdown
67 lines
2.7 KiB
Markdown
# Ontoref — Yin/Yang: Lo que Talisman no resuelve
|
|
|
|
Referencia para posts, slides, presentaciones.
|
|
Contexto: extracción del análisis comparativo con "Steal This Deck" (Talisman, KGC 2026).
|
|
|
|
---
|
|
|
|
## El gap del argumento de Talisman
|
|
|
|
Talisman describe infraestructura de conocimiento como artefacto de construcción —
|
|
vocabularios, ontologías, knowledge graphs. El problema que identifica (governance
|
|
"forever, not a project") lo *nombra* pero no lo *resuelve*. Su stack termina en
|
|
"Govern" como sexto paso, sin mecanismo interno de mantenimiento.
|
|
|
|
**La pregunta que no responde:**
|
|
- ¿Quién vigila que la ontología no derive respecto al sistema real?
|
|
- ¿Quién detecta cuando una decisión arquitectónica invalida un nodo del grafo?
|
|
- ¿Quién propaga los cambios a los consumidores?
|
|
|
|
Sin ese cierre operacional, la ontología más rigurosa acaba siendo buenas intenciones
|
|
formalizadas. Archaeology, no infrastructure.
|
|
|
|
---
|
|
|
|
## Ontoref es las dos mitades
|
|
|
|
```
|
|
Ontology (Yin — lo que ES) Reflection (Yang — lo que DEVIENE)
|
|
─────────────────────────────── ────────────────────────────────────
|
|
.ontology/core.ncl reflection/modes/*.ncl
|
|
Nodos, edges, constraints DAGs ejecutables, pasos reportables
|
|
Compromisos formales Operaciones que cambian estado
|
|
state.ncl (fotografía) state.ncl FSM (transición activa)
|
|
ADRs (decisión tomada) migrations/ (propagación al ecosistema)
|
|
describe project sync diff --docs (detección de deriva)
|
|
```
|
|
|
|
Sin Reflection, la ontología cristaliza — describe lo que el proyecto *quería ser*
|
|
en el momento en que se escribió.
|
|
|
|
Sin Ontology, Reflection es ejecución sin verdad — sabe *qué hacer* pero no *qué es*.
|
|
|
|
---
|
|
|
|
## La tensión nombrada en core.ncl
|
|
|
|
> "Ontology vs Reflection: Ontology captures what IS (invariants, structure, being).
|
|
> Reflection captures what BECOMES (operations, drift, memory).
|
|
> Both must coexist without one dominating. This tension is onref's core identity."
|
|
|
|
Talisman articula bien el Yin. Ontoref es la respuesta al Yang que su framework no provee.
|
|
|
|
---
|
|
|
|
## Para slides
|
|
|
|
**Una línea:** Talisman dice "construye ontologías, goviernalas". Ontoref es el mecanismo
|
|
de governance interno que hace que esa instrucción sea ejecutable.
|
|
|
|
**Contraste visual:**
|
|
|
|
| Talisman (KGC 2026) | Ontoref |
|
|
|---|---|
|
|
| Construye knowledge infrastructure | Construye + mantiene desde adentro |
|
|
| Governance como paso final | Reflection como loop continuo |
|
|
| Ontología como artefacto | Ontología + operaciones coexistentes |
|
|
| "Forever, not a project" (aspiración) | FSM + modes + migrations (mecanismo) |
|