@shgroup/dsh-serenity-hooks 1.51.4 → 1.51.5

package/dsh.plugin.json

@@ -1,6 +1,6 @@
 {
   "id": "dsh-serenity-hooks",
-  "version": "1.51.4",
+  "version": "1.51.5",
   "main": "lib/index.js",
   "description": "宁静号 ACC harness（Native Cordis 插件）：给 DSH 装一个「AI 工作区」——12 个工具（container_fs/container_trajectory/dashboard/container_git/msm/praxis/handyman/localstore/container_admin/im-bridge/acc-diag/diagram；后三个按配置条件出现）+ 机械约束（安全模式/工作区围墙/密钥守卫）+ 轨迹日志与原地重建 + 网页登录入口/微信桥/子角色/对外问答页/trajectory 唤醒注册表。适配 DSH 0.1.7-rc.1（deepseek-ai/deepseek-harness）。",
   "engines": {

package/lib/index.js

@@ -1077,7 +1077,7 @@ Directory of ACC capabilities — each area lists where to go for details (guide
                           + cro-guide CRO 编写指南）
                          原 logbook 已并入（v1.33 用户裁决：废除 logbook 词）；close/archive 删（归档走 container_fs mv），
                          health/qa/summary 分别并入 use / list，hook-develop-guide 并进 container_admin msm guide
-  ② 认知质量框架      → praxis（eap/neat/cce 三合一——可实践理论注入，section 渐进披露，无参即目录）
+  ② 认知质量框架      → praxis（eap/neat/cce/ontology 四合一——可实践理论注入，section 渐进披露，无参即目录）
   ③ 工具与执行        → container_fs（容器文件系统 15 子命令）/ container_git（git）/ dashboard（health 含注册表检查/time/wait）
                          acc_msm 已并入 msm（执行+发现）与 container_admin（管理）——msm("<name>", ["<args>"])；inspect=true 查用法
                          handyman（杂工 agent 编排——guide 子命令：handyman guide）
@@ -3145,7 +3145,7 @@ function toolsBlock() {
 		"  dashboard    — always-on container instruments: health (CCC three-principle check + registry integrity) / time (now) / wait (N seconds)",
 		"  container_git— git operations (status/commit/push/log)",
 		"  msm          — execute a registered CCC MSM: msm(name, args); partial name returns candidates; inspect=true shows usage",
-		"  praxis       — actionable theory injection: praxis (index) / praxis eap / praxis neat / praxis cce",
+		"  praxis       — actionable theory injection: praxis (index) / praxis eap / praxis neat / praxis cce / praxis ontology",
 		"  handyman     — delegate work to a worker agent on a CCC-whitelisted model; mode=\"foreground\" (default) = child agent(s) run once and return their final text (jobs=[...] fans out in parallel, cap 10, per-job model); mode=\"background\" = loop-validated worker (completion code + round cap + restart + progress file), jobs=[] orchestrates parallel work",
 		"  localstore   — ACC local credential/config storage (CCC-root localstore.json; git policy localstore.gitTrack default deny)",
 		"  container_admin — container administration (the maintenance bay): role (Skiff roles: guide/validate/apply/list) / msm (register/deregister/check/guide/catalog/ccc-config) / config (view)",
@@ -4340,16 +4340,256 @@ CCE answers "how structured knowledge should keep evolving across time without l
 Serenity's session system, session tracking, and entropy management mechanisms (SQC quality loop) are all engineering implementations of CCE;
 the behavioral constraints embedded in CCC system prompts come from CCE.`;
 //#endregion
+//#region src/tools/ontology.ts
+/**
+* ontology.ts — Ontology Engineering 内容源（本体论工程方法群；v1.51.5 并入 praxis 第四段）
+*
+* 内嵌方法内容（自包含，不依赖已安装技能）：把「做本体论工程」的完整方法群
+* （触发 → 编码 → 四组判据 → OEPE 循环 → 工作流 → 公理 → 反模式）压成一份可即时注入的手册。
+*
+* 🔴 **本文件是 ACC 层**（D23：机制与措辞归 ACC、数据与纪律归 CCC）：
+*   · 只写**通用方法**，不出现任何具体 CCC 的名字，也不带任何领域模型；
+*   · 判据群（M/L/D/V）是方法的**标准编号**（与参考实现同源），容器不必有同名引擎也能用；
+*   · **模型语料（.ttl）与具体公理内容属 CCC**，不在本文件。
+*/
+const ONTOLOGY_CONTENT = `# Ontology Engineering — Method Family (本体论工程方法群)
+
+> **Any creative action — a new concept, a new term, a new skill, a new MSM, a new architectural layer —
+> is preceded by explicitly encoding WHAT EXISTS, HOW THINGS RELATE, and WHAT IS CONSTRAINED.**
+>
+> Without it: idea → implementation (all ΔH_in becomes H_op).
+> With it: idea → structure → implementation (structure absorbs part of ΔH_in).
+
+## 1. When to invoke
+
+- introducing a new concept, term, or vocabulary
+- creating a skill, or changing an existing skill's scope/dependencies
+- creating an MSM (Mech or Semi-Mech)
+- introducing a new architectural layer or a cross-domain concept
+- any moment of "what IS this thing here, and how does it relate to everything else?"
+
+## 2. Core cognition
+
+**Ontology = before acting, make explicit what exists, how it relates, and what is constrained.**
+
+Ontology is one of CCE's \`ΔH_org\` operators: it records the *structure* of new content at the moment the
+content is produced, so that future agents do not have to reverse-engineer structure out of prose.
+It is EAP applied at the layer of domain structure:
+
+| EAP demand | How ontology satisfies it |
+|---|---|
+| E↑ Explicitness | types / relations / axioms are stated, not implied |
+| R↓ Reconstructability | a new agent reads structure directly instead of inferring it |
+| S↑ Stability | the \`.ttl\` file is the single structural source of truth |
+
+**Consequence**: in a container, *every act of creation adds an entity to a domain* — so updating the
+ontology is part of the creative act, not an extra chore.
+
+## 3. Encoding — Turtle (\`.ttl\`)
+
+All models use W3C Turtle. **Why Turtle**: LLMs already carry RDF/OWL/Turtle in their training data, so the
+notation costs ~zero context to explain.
+
+- **Standard namespaces**: \`rdf:\`, \`rdfs:\`, \`owl:\`, \`xsd:\`
+- **Container-local namespace**: \`sr:\` — a container-chosen URI used for \`rigidity\`, \`identity\`,
+  \`unity\`, \`dependence\`, \`cardinality\`, \`axiom\`, \`dependsOn\`, … (the container fixes the URI; the
+  method does not)
+
+**Modelling vocabulary**: *Type* · *Relation* (with domain/range) · *Axiom* (a named constraint), plus
+**meta-properties** attached to types: rigidity (\`+R\` rigid / \`~R\` semi-rigid / \`-R\` anti-rigid),
+identity, unity, dependence.
+
+## 4. Judgement set A — structural validation \`M1–M10\` (deterministic, machine)
+
+Run after every write; these are decidable from the file alone.
+
+| ID | Check | Catches |
+|---|---|---|
+| **M1** | Referential integrity | a type/relation/type-in-relation is referenced but not defined |
+| **M2** | Taxonomy acyclicity | a cycle in the \`subClassOf\` graph |
+| **M3** | Rigidity inheritance | a child is **more rigid** than its parent (rigid must not subsume anti-rigid) |
+| **M4** | Identity presence | a **rigid** type carries no identity (own or inherited) |
+| **M5** | Dependency acyclicity | a cycle in the existence-dependency graph |
+| **M6** | Cardinality consistency | malformed or mutually contradictory cardinalities |
+| **M7** | Enum coverage | an enumerated value set is incomplete/inconsistent with its use |
+| **M8** | Axiom syntax | an axiom is not syntactically well-formed |
+| **M9** | Axiom reference check | an axiom references an undefined type/relation |
+| **M10** | Import/file error | an imported \`.ttl\` is missing or unparsable |
+
+## 5. Judgement set B — semantic hints \`L1–L5\` (strict mode; machine emits, model judges)
+
+These are **questions, not verdicts** — the engine prints them so an LLM can answer them.
+
+| ID | Hint |
+|---|---|
+| **L1** | type has **no rigidity label** — should it be rigid or anti-rigid? |
+| **L2** | **missing constraints** — are temporal / state axioms absent? |
+| **L3** | **identity adequacy** — is the declared identity sufficient for uniqueness? |
+| **L4** | **type semantics** — are there missing distinctions between types? |
+| **L5** | **axiom coverage** — do axioms reference concepts that are not defined as types? |
+
+## 6. Judgement set C — semantic review \`D1–D8\` (model, ideally a read-only subagent)
+
+Structure can pass \`M*\` and still be wrong. \`D*\` is where an LLM reviews meaning.
+
+| ID | Dimension | Asks |
+|---|---|---|
+| **D1** | Type semantics | are names/descriptions/boundaries clear and correct? split or merge needed? |
+| **D2** | Taxonomy quality | does every \`subClassOf\` pass the **is-a test**? missing/incorrect links? disjointness? sensible depth (3–7 levels typical)? |
+| **D3** | Rigidity audit | is every rigid/anti-rigid/semi-rigid assignment justified? is inheritance consistent? |
+| **D4** | Identity criteria | do identity keys guarantee uniqueness? natural vs surrogate? any identity resting on mutable properties? |
+| **D5** | Relation semantics | real-world interpretation? domain/range correct? property characteristics true? cardinalities physically possible? |
+| **D6** | Axiom completeness & correctness | sound? missing temporal / state / dependency / instance-level cardinality constraints? |
+| **D7** | Domain completeness | what real-world entities are **not** modelled? missing relations? lifecycle/state machines? edge cases? wide/deep enough? |
+| **D8** | OntoClean deep review | the six meta-properties, applied down the whole taxonomy |
+
+**OntoClean's six meta-properties** (the vocabulary \`D8\` reason with):
+
+| Meta-property | Notation | Question |
+|---|---|---|
+| Identity | \`+I\` / \`-I\` | what criterion distinguishes instances of this type? |
+| Unity | \`+U\` / \`~U\` / \`-U\` | can instances form a whole? any anti-unity type ("pile of sand")? |
+| Rigidity | \`+R\` / \`~R\` / \`-R\` | is the property essential to every instance, in every context? |
+| Dependence | \`+D\` / \`-D\` | does this type's existence necessarily imply another's? |
+| Sortal vs non-sortal | — | can an identity criterion exist at all? |
+| Backbone taxonomy | — | does the rigid-only backbone form a consistent tree? |
+
+## 7. Judgement set D — runtime compliance \`V1–V4\` (declaration ↔ reality)
+
+Ontology is not only a model of the world — it also **declares facts about the container itself**, so those
+declarations must be checked against the container's actual state.
+
+| ID | Check |
+|---|---|
+| **V1** | declared skill directories exist |
+| **V2** | orphan directories (present on disk, absent from the model) |
+| **V3** | MSM registration consistency (declared ownership ↔ registry) |
+| **V4** | session health (duplicate goals · session count · stale sessions) |
+
+## 8. The OEPE loop — Ontology → EAP → Prompt-Enhancement
+
+The reusable audit cycle. **Do not spend human effort hand-reviewing prose** — let the ontology be the
+structural blueprint, let a subagent do semantic review in an isolated context, and let the human only
+confirm the direction of repair.
+
+\`\`\`
+O ── Ontology
+│    ① write the domain .ttl: types + relations + axioms
+│    ② check --level strict         → 0 errors
+│    ③ explain                      → natural-language summary (reasoning context for the next stage)
+│    ④ review --level onto-clean    → structured review prompt (D7 + D8)
+│
+├── E ── EAP audit
+│    ⑤ take the ontology axioms as the TOP constraint; evaluate the target artifact against each
+│    ⑥ EAP scoring (E/R/S) + ambiguous-word scan
+│    ⑦ emit a compliance matrix: PASS / WEAK / VIOLATION
+│
+└── PE ── Prompt-Enhance
+     ⑧ VIOLATION → repair (P1)
+     ⑨ WEAK → strengthen (P2)
+     ⑩ PASS → keep
+     ⑪ re-run check → audit → until everything is PASS
+\`\`\`
+
+**Severity classes** used across the review dimensions:
+
+| Class | Meaning |
+|---|---|
+| **P0 Critical** | causes incorrect behaviour, data corruption, or violates a domain law |
+| **P1 High** | makes the ontology misleading, or unable to serve its stated purpose |
+| **P2 Medium** | reduces quality / clarity / reusability |
+| **P3 Low** | minor improvement or style suggestion |
+
+**Typical artifacts**: \`<domain>-ontology.ttl\` (O) · \`onto-clean-review.md\` (O) · \`skill-audit-report.md\` (E).
+
+## 9. Workflows
+
+**New skill**
+\`\`\`
+① what type is this skill? which skills does it depend on? what are its domain entities?
+② if the domain is complex enough → build a domain ontology (types / relations / axioms)
+③ write SKILL.md so that its declared dependencies match the axioms
+④ structural check → 0 errors
+⑤ axiom compliance → no violation of existing axioms
+\`\`\`
+
+**New concept / term**
+\`\`\`
+① is this a SUBTYPE of an existing type, or a NEW type?
+② new type → add a subClassOf to the container-level registry ontology
+③ subtype   → add a subClassOf to the domain ontology
+④ does it need a new relation or axiom?
+⑤ structural check → 0 errors
+\`\`\`
+
+**New MSM**
+\`\`\`
+① Mech (deterministic) or Semi-Mech (model in the loop)?
+② which ONE skill owns it?
+③ consistent with the container's BuiltinTool/MSM type in the architecture ontology?
+④ record it in that skill's ontology entry
+⑤ register it through the container's registry (never by editing the registry file directly)
+\`\`\`
+
+## 10. Universal axioms (violating any of these is a defect, not a style choice)
+
+| Axiom | Content | Consequence of violation |
+|---|---|---|
+| Unique name | two skills may not share a name | routing becomes ambiguous |
+| SKILL.md required | every skill has a SKILL.md | agents cannot locate the domain knowledge |
+| Dependency complete | using another skill's tool ⇒ declare the dependency | implicit coupling surfaces at runtime (H_op↑) |
+| MSM ownership | every MSM belongs to exactly one skill | the MSM cannot be indexed |
+| Dependency acyclic | \`skillDependsOn\` must not form a cycle | load order becomes undefined |
+
+**Axiom discipline**: axioms are named (\`AX-*\`), individually citable, and each carries a rationale.
+Breaking an axiom is allowed only by stating the break explicitly and recording the reason.
+
+## 11. Dispatching a review subagent
+
+Both OEPE review stages run in an isolated context. Three rules make them work:
+
+1. **Mandatory opening block** — the prompt must begin by requiring the subagent to load the ontology
+   method (and EAP, for the audit stage). Without it the subagent does not know the standard it is applying,
+   and its output is worthless.
+2. **Read-only** — the reviewer never edits files. Review and repair are separated: the reviewer reports,
+   the human confirms direction, the agent repairs.
+3. **Structured output** — one line per finding: \`<ID> [<Severity>] <Finding> — <Evidence> — <Suggestion>\`,
+   then a summary: top issues · health grade (A–F) · prioritized repair list. Findings are written to the
+   session directory, never into the skill directory.
+
+## 12. Anti-patterns
+
+| Anti-pattern | Why it is wrong |
+|---|---|
+| modelling **instances** as **types** | the taxonomy inflates and stops carrying meaning |
+| an "is-a" relation that fails the **is-a test** in some context | structural checks pass, semantics rot |
+| a rigid type with **no identity** | nothing distinguishes its instances (M4) |
+| identity resting on a **mutable property** | the entity's identity changes as data changes |
+| a child that is **more rigid** than its parent | OntoClean violation (M3) |
+| putting **implementation detail** into the domain ontology | the model then tracks code, not the domain |
+| a second, competing source of truth for structure | E↓, and the drift is silent |
+| writing the model **after** the code | structure is reverse-engineered from accidents |
+
+## 13. Relation to the other praxis frameworks
+
+- **EAP** — how a piece of knowledge should be structured (static quality). Ontology is EAP applied to
+  domain structure.
+- **CCE** — how structured knowledge keeps evolving without losing coherence (dynamic persistence).
+  Ontology is one of CCE's \`ΔH_org\` operators.
+- **Neat** — the collaboration protocol for the *design conversation* that produces the model.
+`;
+//#endregion
 //#region src/tools/praxis.ts
 /**
-* praxis.ts — praxis（可实践理论注入工具，v1.30 合并 eap/neat/cce）
+* praxis.ts — praxis（可实践理论注入工具，v1.30 合并 eap/neat/cce；v1.51.5 增 ontology）
 *
-* eap / neat / cce 三个知识工具合并为一个——它们都是「可实践理论」：
-* 调用时把对应框架注入当前认知（指导输出质量 / 协作协议 / 连续性工程）。
+* eap / neat / cce / ontology 四个知识源合并为一个——它们都是「可实践理论」：
+* 调用时把对应框架注入当前认知（指导输出质量 / 协作协议 / 连续性工程 / 本体论工程）。
 * 名字：praxis（理论与实践的统一——理论注入实践，实践反哺理论）。
 * Metaphor 映射：Engineering Drawings（图纸 = 可实践理论的编码，第 3 条隐喻）。
 *
 * section 参数渐进披露：不传 = 返回精简目录；传 = 返回对应框架全文/章节。
+* 每个框架一个内容文件（单一真相源）：eap.ts / neat.ts / cce.ts / ontology.ts。
 */
 /** 知识源：与各原工具内容保持一致（单一真相源——eap/neat/cce 各自源文件已并入此处） */
 /** 框架清单（无参调用时返回的精简目录） */
@@ -4357,6 +4597,7 @@ const PRAXIS_INDEX = `praxis — 可实践理论注入（认知框架，按需
 选择框架：praxis eap（认知质量——E↑/R↓/S↑ 三变量 + 输出前自检）
           praxis neat（Neat 协作协议——小步对齐/显式决策/文档驱动）
           praxis cce（认知连续性工程——容器 5 行为约束 + H_op 操作熵）
+          praxis ontology（本体论工程方法群——触发/编码/四组判据 M·L·D·V/OEPE 循环/公理/反模式）
 无参返回本目录；详情以对应框架原文为准（单一真相源）。
 `;
 function renderText$5(value) {
@@ -4367,15 +4608,16 @@ function renderText$5(value) {
 }
 const praxisTool = defineTool({
 	name: "praxis",
-	description: "Praxis — actionable theory injection (cognitive frameworks, loaded on demand): eap (cognitive quality: E↑ explicitness / R↓ reconstructability / S↑ stability + self-check checklist) / neat (Neat design collaboration protocol: small-step alignment, explicit decisions, document-driven) / cce (Cognitive Continuity Engineering: container identity/accessibility/evolution under bounded resources). No section returns the index; pass a section to load that framework.",
+	description: "Praxis — actionable theory injection (cognitive frameworks, loaded on demand): eap (cognitive quality: E↑ explicitness / R↓ reconstructability / S↑ stability + self-check checklist) / neat (Neat design collaboration protocol: small-step alignment, explicit decisions, document-driven) / cce (Cognitive Continuity Engineering: container identity/accessibility/evolution under bounded resources) / ontology (ontology engineering method family: when to model, Turtle encoding, four judgement sets M1-M10 structural / L1-L5 semantic hints / D1-D8 semantic review incl. OntoClean / V1-V4 runtime compliance, the OEPE audit loop, workflows, universal axioms, anti-patterns). No section returns the index; pass a section to load that framework.",
 	parameters: { section: {
 		type: "string",
 		enum: [
 			"eap",
 			"neat",
-			"cce"
+			"cce",
+			"ontology"
 		],
-		description: "Framework to inject: eap / neat / cce. Omit for the praxis index."
+		description: "Framework to inject: eap / neat / cce / ontology. Omit for the praxis index."
 	} },
 	output: {
 		schema: { type: "string" },
@@ -4385,6 +4627,7 @@ const praxisTool = defineTool({
 		if (args.section === "eap") return EAP_CONTENT;
 		if (args.section === "neat") return NEAT_CONTENT;
 		if (args.section === "cce") return CCE_CONTENT;
+		if (args.section === "ontology") return ONTOLOGY_CONTENT;
 		return PRAXIS_INDEX;
 	}
 });

package/lib/tools/ontology.d.ts

@@ -0,0 +1,12 @@
+/**
+ * ontology.ts — Ontology Engineering 内容源（本体论工程方法群；v1.51.5 并入 praxis 第四段）
+ *
+ * 内嵌方法内容（自包含，不依赖已安装技能）：把「做本体论工程」的完整方法群
+ * （触发 → 编码 → 四组判据 → OEPE 循环 → 工作流 → 公理 → 反模式）压成一份可即时注入的手册。
+ *
+ * 🔴 **本文件是 ACC 层**（D23：机制与措辞归 ACC、数据与纪律归 CCC）：
+ *   · 只写**通用方法**，不出现任何具体 CCC 的名字，也不带任何领域模型；
+ *   · 判据群（M/L/D/V）是方法的**标准编号**（与参考实现同源），容器不必有同名引擎也能用；
+ *   · **模型语料（.ttl）与具体公理内容属 CCC**，不在本文件。
+ */
+export declare const ONTOLOGY_CONTENT = "# Ontology Engineering \u2014 Method Family (\u672C\u4F53\u8BBA\u5DE5\u7A0B\u65B9\u6CD5\u7FA4)\n\n> **Any creative action \u2014 a new concept, a new term, a new skill, a new MSM, a new architectural layer \u2014\n> is preceded by explicitly encoding WHAT EXISTS, HOW THINGS RELATE, and WHAT IS CONSTRAINED.**\n>\n> Without it: idea \u2192 implementation (all \u0394H_in becomes H_op).\n> With it: idea \u2192 structure \u2192 implementation (structure absorbs part of \u0394H_in).\n\n## 1. When to invoke\n\n- introducing a new concept, term, or vocabulary\n- creating a skill, or changing an existing skill's scope/dependencies\n- creating an MSM (Mech or Semi-Mech)\n- introducing a new architectural layer or a cross-domain concept\n- any moment of \"what IS this thing here, and how does it relate to everything else?\"\n\n## 2. Core cognition\n\n**Ontology = before acting, make explicit what exists, how it relates, and what is constrained.**\n\nOntology is one of CCE's `\u0394H_org` operators: it records the *structure* of new content at the moment the\ncontent is produced, so that future agents do not have to reverse-engineer structure out of prose.\nIt is EAP applied at the layer of domain structure:\n\n| EAP demand | How ontology satisfies it |\n|---|---|\n| E\u2191 Explicitness | types / relations / axioms are stated, not implied |\n| R\u2193 Reconstructability | a new agent reads structure directly instead of inferring it |\n| S\u2191 Stability | the `.ttl` file is the single structural source of truth |\n\n**Consequence**: in a container, *every act of creation adds an entity to a domain* \u2014 so updating the\nontology is part of the creative act, not an extra chore.\n\n## 3. Encoding \u2014 Turtle (`.ttl`)\n\nAll models use W3C Turtle. **Why Turtle**: LLMs already carry RDF/OWL/Turtle in their training data, so the\nnotation costs ~zero context to explain.\n\n- **Standard namespaces**: `rdf:`, `rdfs:`, `owl:`, `xsd:`\n- **Container-local namespace**: `sr:` \u2014 a container-chosen URI used for `rigidity`, `identity`,\n  `unity`, `dependence`, `cardinality`, `axiom`, `dependsOn`, \u2026 (the container fixes the URI; the\n  method does not)\n\n**Modelling vocabulary**: *Type* \u00B7 *Relation* (with domain/range) \u00B7 *Axiom* (a named constraint), plus\n**meta-properties** attached to types: rigidity (`+R` rigid / `~R` semi-rigid / `-R` anti-rigid),\nidentity, unity, dependence.\n\n## 4. Judgement set A \u2014 structural validation `M1\u2013M10` (deterministic, machine)\n\nRun after every write; these are decidable from the file alone.\n\n| ID | Check | Catches |\n|---|---|---|\n| **M1** | Referential integrity | a type/relation/type-in-relation is referenced but not defined |\n| **M2** | Taxonomy acyclicity | a cycle in the `subClassOf` graph |\n| **M3** | Rigidity inheritance | a child is **more rigid** than its parent (rigid must not subsume anti-rigid) |\n| **M4** | Identity presence | a **rigid** type carries no identity (own or inherited) |\n| **M5** | Dependency acyclicity | a cycle in the existence-dependency graph |\n| **M6** | Cardinality consistency | malformed or mutually contradictory cardinalities |\n| **M7** | Enum coverage | an enumerated value set is incomplete/inconsistent with its use |\n| **M8** | Axiom syntax | an axiom is not syntactically well-formed |\n| **M9** | Axiom reference check | an axiom references an undefined type/relation |\n| **M10** | Import/file error | an imported `.ttl` is missing or unparsable |\n\n## 5. Judgement set B \u2014 semantic hints `L1\u2013L5` (strict mode; machine emits, model judges)\n\nThese are **questions, not verdicts** \u2014 the engine prints them so an LLM can answer them.\n\n| ID | Hint |\n|---|---|\n| **L1** | type has **no rigidity label** \u2014 should it be rigid or anti-rigid? |\n| **L2** | **missing constraints** \u2014 are temporal / state axioms absent? |\n| **L3** | **identity adequacy** \u2014 is the declared identity sufficient for uniqueness? |\n| **L4** | **type semantics** \u2014 are there missing distinctions between types? |\n| **L5** | **axiom coverage** \u2014 do axioms reference concepts that are not defined as types? |\n\n## 6. Judgement set C \u2014 semantic review `D1\u2013D8` (model, ideally a read-only subagent)\n\nStructure can pass `M*` and still be wrong. `D*` is where an LLM reviews meaning.\n\n| ID | Dimension | Asks |\n|---|---|---|\n| **D1** | Type semantics | are names/descriptions/boundaries clear and correct? split or merge needed? |\n| **D2** | Taxonomy quality | does every `subClassOf` pass the **is-a test**? missing/incorrect links? disjointness? sensible depth (3\u20137 levels typical)? |\n| **D3** | Rigidity audit | is every rigid/anti-rigid/semi-rigid assignment justified? is inheritance consistent? |\n| **D4** | Identity criteria | do identity keys guarantee uniqueness? natural vs surrogate? any identity resting on mutable properties? |\n| **D5** | Relation semantics | real-world interpretation? domain/range correct? property characteristics true? cardinalities physically possible? |\n| **D6** | Axiom completeness & correctness | sound? missing temporal / state / dependency / instance-level cardinality constraints? |\n| **D7** | Domain completeness | what real-world entities are **not** modelled? missing relations? lifecycle/state machines? edge cases? wide/deep enough? |\n| **D8** | OntoClean deep review | the six meta-properties, applied down the whole taxonomy |\n\n**OntoClean's six meta-properties** (the vocabulary `D8` reason with):\n\n| Meta-property | Notation | Question |\n|---|---|---|\n| Identity | `+I` / `-I` | what criterion distinguishes instances of this type? |\n| Unity | `+U` / `~U` / `-U` | can instances form a whole? any anti-unity type (\"pile of sand\")? |\n| Rigidity | `+R` / `~R` / `-R` | is the property essential to every instance, in every context? |\n| Dependence | `+D` / `-D` | does this type's existence necessarily imply another's? |\n| Sortal vs non-sortal | \u2014 | can an identity criterion exist at all? |\n| Backbone taxonomy | \u2014 | does the rigid-only backbone form a consistent tree? |\n\n## 7. Judgement set D \u2014 runtime compliance `V1\u2013V4` (declaration \u2194 reality)\n\nOntology is not only a model of the world \u2014 it also **declares facts about the container itself**, so those\ndeclarations must be checked against the container's actual state.\n\n| ID | Check |\n|---|---|\n| **V1** | declared skill directories exist |\n| **V2** | orphan directories (present on disk, absent from the model) |\n| **V3** | MSM registration consistency (declared ownership \u2194 registry) |\n| **V4** | session health (duplicate goals \u00B7 session count \u00B7 stale sessions) |\n\n## 8. The OEPE loop \u2014 Ontology \u2192 EAP \u2192 Prompt-Enhancement\n\nThe reusable audit cycle. **Do not spend human effort hand-reviewing prose** \u2014 let the ontology be the\nstructural blueprint, let a subagent do semantic review in an isolated context, and let the human only\nconfirm the direction of repair.\n\n```\nO \u2500\u2500 Ontology\n\u2502    \u2460 write the domain .ttl: types + relations + axioms\n\u2502    \u2461 check --level strict         \u2192 0 errors\n\u2502    \u2462 explain                      \u2192 natural-language summary (reasoning context for the next stage)\n\u2502    \u2463 review --level onto-clean    \u2192 structured review prompt (D7 + D8)\n\u2502\n\u251C\u2500\u2500 E \u2500\u2500 EAP audit\n\u2502    \u2464 take the ontology axioms as the TOP constraint; evaluate the target artifact against each\n\u2502    \u2465 EAP scoring (E/R/S) + ambiguous-word scan\n\u2502    \u2466 emit a compliance matrix: PASS / WEAK / VIOLATION\n\u2502\n\u2514\u2500\u2500 PE \u2500\u2500 Prompt-Enhance\n     \u2467 VIOLATION \u2192 repair (P1)\n     \u2468 WEAK \u2192 strengthen (P2)\n     \u2469 PASS \u2192 keep\n     \u246A re-run check \u2192 audit \u2192 until everything is PASS\n```\n\n**Severity classes** used across the review dimensions:\n\n| Class | Meaning |\n|---|---|\n| **P0 Critical** | causes incorrect behaviour, data corruption, or violates a domain law |\n| **P1 High** | makes the ontology misleading, or unable to serve its stated purpose |\n| **P2 Medium** | reduces quality / clarity / reusability |\n| **P3 Low** | minor improvement or style suggestion |\n\n**Typical artifacts**: `<domain>-ontology.ttl` (O) \u00B7 `onto-clean-review.md` (O) \u00B7 `skill-audit-report.md` (E).\n\n## 9. Workflows\n\n**New skill**\n```\n\u2460 what type is this skill? which skills does it depend on? what are its domain entities?\n\u2461 if the domain is complex enough \u2192 build a domain ontology (types / relations / axioms)\n\u2462 write SKILL.md so that its declared dependencies match the axioms\n\u2463 structural check \u2192 0 errors\n\u2464 axiom compliance \u2192 no violation of existing axioms\n```\n\n**New concept / term**\n```\n\u2460 is this a SUBTYPE of an existing type, or a NEW type?\n\u2461 new type \u2192 add a subClassOf to the container-level registry ontology\n\u2462 subtype   \u2192 add a subClassOf to the domain ontology\n\u2463 does it need a new relation or axiom?\n\u2464 structural check \u2192 0 errors\n```\n\n**New MSM**\n```\n\u2460 Mech (deterministic) or Semi-Mech (model in the loop)?\n\u2461 which ONE skill owns it?\n\u2462 consistent with the container's BuiltinTool/MSM type in the architecture ontology?\n\u2463 record it in that skill's ontology entry\n\u2464 register it through the container's registry (never by editing the registry file directly)\n```\n\n## 10. Universal axioms (violating any of these is a defect, not a style choice)\n\n| Axiom | Content | Consequence of violation |\n|---|---|---|\n| Unique name | two skills may not share a name | routing becomes ambiguous |\n| SKILL.md required | every skill has a SKILL.md | agents cannot locate the domain knowledge |\n| Dependency complete | using another skill's tool \u21D2 declare the dependency | implicit coupling surfaces at runtime (H_op\u2191) |\n| MSM ownership | every MSM belongs to exactly one skill | the MSM cannot be indexed |\n| Dependency acyclic | `skillDependsOn` must not form a cycle | load order becomes undefined |\n\n**Axiom discipline**: axioms are named (`AX-*`), individually citable, and each carries a rationale.\nBreaking an axiom is allowed only by stating the break explicitly and recording the reason.\n\n## 11. Dispatching a review subagent\n\nBoth OEPE review stages run in an isolated context. Three rules make them work:\n\n1. **Mandatory opening block** \u2014 the prompt must begin by requiring the subagent to load the ontology\n   method (and EAP, for the audit stage). Without it the subagent does not know the standard it is applying,\n   and its output is worthless.\n2. **Read-only** \u2014 the reviewer never edits files. Review and repair are separated: the reviewer reports,\n   the human confirms direction, the agent repairs.\n3. **Structured output** \u2014 one line per finding: `<ID> [<Severity>] <Finding> \u2014 <Evidence> \u2014 <Suggestion>`,\n   then a summary: top issues \u00B7 health grade (A\u2013F) \u00B7 prioritized repair list. Findings are written to the\n   session directory, never into the skill directory.\n\n## 12. Anti-patterns\n\n| Anti-pattern | Why it is wrong |\n|---|---|\n| modelling **instances** as **types** | the taxonomy inflates and stops carrying meaning |\n| an \"is-a\" relation that fails the **is-a test** in some context | structural checks pass, semantics rot |\n| a rigid type with **no identity** | nothing distinguishes its instances (M4) |\n| identity resting on a **mutable property** | the entity's identity changes as data changes |\n| a child that is **more rigid** than its parent | OntoClean violation (M3) |\n| putting **implementation detail** into the domain ontology | the model then tracks code, not the domain |\n| a second, competing source of truth for structure | E\u2193, and the drift is silent |\n| writing the model **after** the code | structure is reverse-engineered from accidents |\n\n## 13. Relation to the other praxis frameworks\n\n- **EAP** \u2014 how a piece of knowledge should be structured (static quality). Ontology is EAP applied to\n  domain structure.\n- **CCE** \u2014 how structured knowledge keeps evolving without losing coherence (dynamic persistence).\n  Ontology is one of CCE's `\u0394H_org` operators.\n- **Neat** \u2014 the collaboration protocol for the *design conversation* that produces the model.\n";

package/lib/tools/praxis.d.ts

@@ -1,13 +1,14 @@
 /**
- * praxis.ts — praxis（可实践理论注入工具，v1.30 合并 eap/neat/cce）
+ * praxis.ts — praxis（可实践理论注入工具，v1.30 合并 eap/neat/cce；v1.51.5 增 ontology）
  *
- * eap / neat / cce 三个知识工具合并为一个——它们都是「可实践理论」：
- * 调用时把对应框架注入当前认知（指导输出质量 / 协作协议 / 连续性工程）。
+ * eap / neat / cce / ontology 四个知识源合并为一个——它们都是「可实践理论」：
+ * 调用时把对应框架注入当前认知（指导输出质量 / 协作协议 / 连续性工程 / 本体论工程）。
  * 名字：praxis（理论与实践的统一——理论注入实践，实践反哺理论）。
  * Metaphor 映射：Engineering Drawings（图纸 = 可实践理论的编码，第 3 条隐喻）。
  *
  * section 参数渐进披露：不传 = 返回精简目录；传 = 返回对应框架全文/章节。
+ * 每个框架一个内容文件（单一真相源）：eap.ts / neat.ts / cce.ts / ontology.ts。
  */
 /** 框架清单（无参调用时返回的精简目录） */
-export declare const PRAXIS_INDEX = "praxis \u2014 \u53EF\u5B9E\u8DF5\u7406\u8BBA\u6CE8\u5165\uFF08\u8BA4\u77E5\u6846\u67B6\uFF0C\u6309\u9700\u52A0\u8F7D\uFF09\n\u9009\u62E9\u6846\u67B6\uFF1Apraxis eap\uFF08\u8BA4\u77E5\u8D28\u91CF\u2014\u2014E\u2191/R\u2193/S\u2191 \u4E09\u53D8\u91CF + \u8F93\u51FA\u524D\u81EA\u68C0\uFF09\n          praxis neat\uFF08Neat \u534F\u4F5C\u534F\u8BAE\u2014\u2014\u5C0F\u6B65\u5BF9\u9F50/\u663E\u5F0F\u51B3\u7B56/\u6587\u6863\u9A71\u52A8\uFF09\n          praxis cce\uFF08\u8BA4\u77E5\u8FDE\u7EED\u6027\u5DE5\u7A0B\u2014\u2014\u5BB9\u5668 5 \u884C\u4E3A\u7EA6\u675F + H_op \u64CD\u4F5C\u71B5\uFF09\n\u65E0\u53C2\u8FD4\u56DE\u672C\u76EE\u5F55\uFF1B\u8BE6\u60C5\u4EE5\u5BF9\u5E94\u6846\u67B6\u539F\u6587\u4E3A\u51C6\uFF08\u5355\u4E00\u771F\u76F8\u6E90\uFF09\u3002\n";
+export declare const PRAXIS_INDEX = "praxis \u2014 \u53EF\u5B9E\u8DF5\u7406\u8BBA\u6CE8\u5165\uFF08\u8BA4\u77E5\u6846\u67B6\uFF0C\u6309\u9700\u52A0\u8F7D\uFF09\n\u9009\u62E9\u6846\u67B6\uFF1Apraxis eap\uFF08\u8BA4\u77E5\u8D28\u91CF\u2014\u2014E\u2191/R\u2193/S\u2191 \u4E09\u53D8\u91CF + \u8F93\u51FA\u524D\u81EA\u68C0\uFF09\n          praxis neat\uFF08Neat \u534F\u4F5C\u534F\u8BAE\u2014\u2014\u5C0F\u6B65\u5BF9\u9F50/\u663E\u5F0F\u51B3\u7B56/\u6587\u6863\u9A71\u52A8\uFF09\n          praxis cce\uFF08\u8BA4\u77E5\u8FDE\u7EED\u6027\u5DE5\u7A0B\u2014\u2014\u5BB9\u5668 5 \u884C\u4E3A\u7EA6\u675F + H_op \u64CD\u4F5C\u71B5\uFF09\n          praxis ontology\uFF08\u672C\u4F53\u8BBA\u5DE5\u7A0B\u65B9\u6CD5\u7FA4\u2014\u2014\u89E6\u53D1/\u7F16\u7801/\u56DB\u7EC4\u5224\u636E M\u00B7L\u00B7D\u00B7V/OEPE \u5FAA\u73AF/\u516C\u7406/\u53CD\u6A21\u5F0F\uFF09\n\u65E0\u53C2\u8FD4\u56DE\u672C\u76EE\u5F55\uFF1B\u8BE6\u60C5\u4EE5\u5BF9\u5E94\u6846\u67B6\u539F\u6587\u4E3A\u51C6\uFF08\u5355\u4E00\u771F\u76F8\u6E90\uFF09\u3002\n";
 export declare const praxisTool: import("@deepseek-ai/dsh-tools").ToolDefinition;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@shgroup/dsh-serenity-hooks",
-  "version": "1.51.4",
+  "version": "1.51.5",
   "description": "宁静号 ACC harness（Native Cordis 插件）——给 DeepSeek Harness 装一个「AI 工作区」：12 个工具（container_fs/container_trajectory/dashboard/container_git/msm/praxis/handyman/localstore/container_admin/im-bridge/acc-diag/diagram）+ 机械约束（安全模式/工作区围墙/密钥守卫/对外输出守卫）+ 工作日志与原地重建 + 网页登录入口/微信桥/子角色/对外问答页/trajectory 唤醒注册表。适配 DSH 0.1.7-rc.1。",
   "license": "MIT",
   "repository": {