23 lines
7 KiB
JSON
23 lines
7 KiB
JSON
|
{
|
||
|
|
"entries": [
|
||
|
|
{
|
||
|
|
"actor": "human",
|
||
|
|
"answer": "EXTENDS ontoref/reflection/qa.ncl::ontoref-dao-discipline (protocol baseline).\n Read that first for the WHAT / WHEN / HOW / WHY procedure plus the\n protocol-level forbidden patterns. This entry specializes the\n discipline for provisioning's specific tensions and Yang-bias failure\n modes seen in this Domain-level project.\n\nLEVEL IDENTITY (per ADR-018)\n provisioning is a Domain-level project — it instantiates ontoref's\n protocol for the workspace-infrastructure domain and is itself the\n parent of Instance-level workspaces (workspaces/libre-wuji,\n workspaces/libre-daoshi, etc.). Tensions declared here propagate as\n inherited tension space to those workspaces.\n\nNAMED TENSIONS in provisioning (.ontology/core.ncl, level = 'Tension)\n\n Six declared, all 'Spiral-poled — every architectural decision in\n provisioning is likely to engage at least one. Empty\n `tensions_engaged: []` is RARE here and demands explicit justification.\n\n nickel-complexity-vs-accessibility (Spiral)\n Richer Nickel schemas → better validation; higher barrier of entry.\n Synthesis: compose pattern over merge operator; progressive schema\n layers (TypeDialog).\n Yang-bias risks: \"make schemas stricter, type more fields\";\n Yin-bias risks: \"skip schemas to lower friction\".\n Synthesis state today: realized via TypeDialog progressive layering\n in older modules; populating across newer ones.\n\n monorepo-vs-split (Spiral)\n Single repo simplifies cross-cutting work; complicates CI, ownership\n boundaries, workspace isolation.\n Yang-bias risks: \"split for clean ownership\";\n Yin-bias risks: \"keep everything together for velocity\".\n Synthesis state today: monorepo with structural boundaries (ADR-014\n enforcement, SOLID layering).\n\n centralized-vs-scripted (Spiral)\n Orchestrator gives audit trail / rollback / state machine; direct\n scripts are simpler. Solo mode is the documented mid-point.\n Yang-bias risks: \"everything through orchestrator for audit\";\n Yin-bias risks: \"scripts where possible for speed\".\n Synthesis state today: orchestrator-canonical with solo-mode bypass\n (ADR-015) — populating across the operation surface.\n\n extension-graph-vs-declarative-config (Spiral)\n Embedding ontology nodes in metadata.ncl makes extensions graph-aware;\n blurs the line between configuration and code.\n Yang-bias risks: \"everything in the graph for visibility\";\n Yin-bias risks: \"metadata stays pure config, no ontology refs\".\n Synthesis state today: ontology fields optional and additive on the\n base metadata contract — claim-only / populating.\n\n nushell-vs-rust-boundary (Spiral)\n Rust improves type-safety + testability; Nushell stays operator-\n scriptable + writable without recompilation. Smart-interface-\n unification (ADR-029) partial-resolves: Rust owns the Registry and\n Tool dispatch semantics; Nushell owns orchestration sequences,\n three-tier fallback probes, and the per-operation legacy closure.\n Yang-bias risks: \"rewrite all of core/nulib in Rust\";\n Yin-bias risks: \"keep everything in Nushell forever\".\n Synthesis state today: structural boundary at the tool-call surface\n — realized for the slice covered by ADR-029, populating elsewhere.\n\n capability-granularity-vs-simplicity (Spiral)\n Fine-grained capabilities → precise conflict detection + taxonomy\n maintenance burden. Coarse-grained → simple but ambiguous.\n Yang-bias risks: \"split into micro-capabilities for precision\";\n Yin-bias risks: \"one capability per concern type, ignore edges\".\n Synthesis state today: 9 coarse capabilities chosen to defer\n premature optimization (server-lifecycle, networking, storage,\n container-runtime, orchestration, database, application-deployment,\n dev-tooling, hypervisor) — claim-only.\n\nPROJECT-SPECIFIC FORBIDDEN PATTERNS (additive to protocol base
|
||
|
|
"created_at": "2026-05-03",
|
||
|
|
"id": "provisioning-dao-discipline",
|
||
|
|
"question": "Which named tensions matter for ondaod analysis in provisioning, and what are this project's specific forbidden patterns?",
|
||
|
|
"related": [],
|
||
|
|
"tags": [
|
||
|
|
"provisioning",
|
||
|
|
"dao",
|
||
|
|
"discipline",
|
||
|
|
"ondaod",
|
||
|
|
"tensions",
|
||
|
|
"spiral",
|
||
|
|
"adr-process"
|
||
|
|
],
|
||
|
|
"verified": true
|
||
|
|
}
|
||
|
|
]
|
||
|
|
}
|