22 lines
7 KiB
JSON
22 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 baseline)\n\n - \"Just use a Nushell script\" without considering the Rust boundary\n (ADR-029) — collapses nushell-vs-rust-boundary; the structural\n Registry/dispatch layer is where logic earns its place in Rust.\n\n - \"Add this to metadata as ontology nodes\" reflexively — collapses\n extension-graph-vs-declarative-config; ontology fields are optional\n and only earn their place for non-trivial platform relationships.\n\n - \"Bypass orchestrator for this one operation\" outside solo-mode —\n collapses centralized-vs-scripted; the orchestrator's audit trail\n is load-bearing for ADR-014 boundary enforcement.\n\n - \"Split the repo to clean up these dependencies\" — collapses\n monorepo-vs-split before measuring whether dependency cost actually\n exceeds cross-cutting velocity benefit.\n\n - \"Add stricter Nickel contracts everywhere\" — collapses nickel-\n complexity-vs-accessibility; progressive layering is the synthesis,\n not maximal strictness.\n\n - \"Split this capability into N sub-capabilities\" without conflict-\n detection failures observed in practice — collapses capability-\n granularity-vs-simplicity; the 9-coarse set is intentional.\n\nADR INTEGRATION (criterion 5 in provisioning)\n\n Most provisioning ADRs touch at least one Spiral. tensions_engaged: []\n demands explicit justification. When the proposed ADR engages a Spiral\n tension and proposes severity = 'Hard with a biconditional check, that\n is a Yang-collapse smell — Spiral decisions get 'Soft constraints\n reporting direction of motion, not binary pass/fail biconditionals.\n\nWORKSPACE INHERITANCE (Instance-level projects under workspaces/)\n\n Workspaces (workspaces/libre-wuji, workspaces/libre-daoshi, etc.) are\n Instance-level (ADR-018) and inherit provisioning's tension space when\n their own decisions touch the same axes. A workspace ADR that engages\n centralized-vs-scripted (e.g. picking a deployment strategy) MUST\n reference provisioning's tension by id, not redefine it. Workspaces\n may declare their own tensions in addition; the union of own + parent\n is the relevant tension set for ondaod criterion 5 in workspace ADRs.\n\nREFERENCES\n - ontoref qa::ontoref-dao-discipline protocol baseline (read first)\n - .ontology/core.ncl the six named tensions\n - workspaces/<ws>/reflection/qa.ncl::<ws>-dao-discipline\n workspace-side extensions\n - global ~/.claude/CLAUDE.md::adr?, ondaod discipline references",
|
|
"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
|
|
}
|
|
]
|
|
}
|