ontoref/assets/work-group-ore/demo
Jesús Pérez 82a358f18d
Some checks failed
Nickel Type Check / Nickel Type Checking (push) Has been cancelled
Rust CI / Security Audit (push) Has been cancelled
Rust CI / Check + Test + Lint (push) Has been cancelled
feat: #[onto_mcp_tool] catalog, OCI credential vault layer, validate ADR-018 mode hierarchy
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).
2026-05-12 04:46:15 +01:00
..
option-a-owner feat: #[onto_mcp_tool] catalog, OCI credential vault layer, validate ADR-018 mode hierarchy 2026-05-12 04:46:15 +01:00
option-b-layers feat: #[onto_mcp_tool] catalog, OCI credential vault layer, validate ADR-018 mode hierarchy 2026-05-12 04:46:15 +01:00
recording feat: #[onto_mcp_tool] catalog, OCI credential vault layer, validate ADR-018 mode hierarchy 2026-05-12 04:46:15 +01:00
README.md feat: #[onto_mcp_tool] catalog, OCI credential vault layer, validate ADR-018 mode hierarchy 2026-05-12 04:46:15 +01:00
script.md feat: #[onto_mcp_tool] catalog, OCI credential vault layer, validate ADR-018 mode hierarchy 2026-05-12 04:46:15 +01:00

Mini-demo — Working Group OntoRef

Dos opciones de mini-demo (~8-10 min) para la sesión de presentación. La demo se ejecuta en vivo desde una terminal cuando las slides llegan a la slide-anchor "Demo en vivo".

Cuál usar

Opción Recomendada para Complejidad
A — Owner por servicio Audiencia mixta de developers (cualquier stack) Baja, ~12 líneas
B — Capas sin acople Audiencia rustacean / backend con experiencia Media, ~30 líneas

Recomendación: usar la opción A en la primera sesión. La opción B queda guardada por si en alguna repetición del WG la audiencia exige más sofisticación.

Estructura de cada opción

Cada opción tiene tres archivos .ncl que representan los tres pasos de la demo:

option-X/
├── README.md                Descripción de la opción
├── core.start.ncl           Paso 1: archivo mínimo sin contrato
├── core.with-contract.ncl   Paso 2: contrato añadido, nickel export pasa
└── core.broken.ncl          Paso 3: violación, nickel export falla

El presentador no copia estos archivos durante la demo — los va escribiendo en vivo. Los archivos sirven como:

  • Referencia de lo que tiene que terminar escribiendo
  • Plan B si se queda en blanco (cp core.with-contract.ncl /tmp/demo-wg/core.ncl)
  • Material de grabación asciinema para Plan B audiovisual

Ejecutar manualmente para ensayar

cd /tmp && rm -rf demo-wg && mkdir demo-wg && cd demo-wg

# Paso 1
cp /Users/Akasha/Development/ontoref/assets/work-group-ore/demo/option-a-owner/core.start.ncl ./core.ncl
nickel export core.ncl    # exporta JSON

# Paso 2
cp /Users/Akasha/Development/ontoref/assets/work-group-ore/demo/option-a-owner/core.with-contract.ncl ./core.ncl
nickel export core.ncl    # exporta JSON

# Paso 3
cp /Users/Akasha/Development/ontoref/assets/work-group-ore/demo/option-a-owner/core.broken.ncl ./core.ncl
nickel export core.ncl    # falla con missing definition for 'owner'

Plan B audiovisual

Ver recording/README.md para la grabación con asciinema y cómo reproducirla si la demo en vivo falla.