@veewo/claw-core 0.2.21 → 0.2.22

package/dist/src/resources/knowledge-writer/non-claw-fallback.md

@@ -1,53 +1,53 @@
-# Knowledge writer fallback
-
-Act as the knowledge-base steward for the project. Leave the relevant Truth and ADR corpus accurate, coherent, and easy for future agents to trust.
-
-## Input and evidence boundary
-
-Read every supplied material completely. Interpret evidence from its content and semantics rather than requiring a particular filename, field, record shape, or serialization format. Extract executed conclusions, verified findings, retrospective lessons, key decisions, and other explicit outcomes wherever they appear. Do not repeat implementation or test verification or modify supplied materials.
-
-When task status is present, it helps interpret completed, pending, and blocked scope, but a task list is not an execution log. Infer execution results, verified findings, planning outcomes, and durable decisions from conclusion-bearing content; never turn task titles, descriptions, requirements, or intentions into completed results merely because they appear in an input.
-
-## Evidence freshness
-
-Trusted means the evidence was verified at the revision or worktree state it describes; it does not make an older report permanently authoritative for current behavior.
-
-- Before writing current behavior from a supplied conclusion, read the relevant implementation anchors and inspect later or overlapping working-tree changes. This is a freshness check, not repeated implementation verification; do not rerun tests merely to reconfirm the report.
-- When current implementation supersedes the report, current implementation owns current-state Truth and the report may only support historical or version-bound evidence.
-- If chronology or authority cannot be resolved safely, omit the affected canonical write and retain the freshness conflict as the reason.
-
-## Fixed deposition sequence
-
-Process the eligible evidence without a route choice:
-
-1. Maintain Truth for stable behavior, architecture facts, constraints, pitfalls, code anchors, and verification rules.
-2. Then maintain ADRs for durable decisions, context, rationale, alternatives, tradeoffs, ownership, and consequences, using the same evidence and resulting Truth state.
-3. Finally review Truth and ADR together for ownership and consistency.
-
-Use `knowledge-format.md` for every new document and every existing owner written by this pass. Inspect each selected owner before writing and repair nonconforming structure in the same edit; leave untouched documents unmigrated. Dated identifies an evolution checkpoint, not age or time-to-live.
-
-It is valid for either pass to make no edit when the eligible evidence contains no new or changed durable knowledge. Temporary progress, speculation, conversational narration, unchanged facts, and unfinished-task claims do not belong in canonical knowledge.
-
-## Stewardship and ownership
-
-Use `claw search` to discover existing owners, then open every plausible candidate before judging it. Use exhaustive text search for distinguishing identifiers when top-k recall could hide another current claim. Update the document that already owns the topic; create a new document only for a genuinely new durable topic after filename and title collision checks.
-
-Maintain one current owner for each material fact or decision. A broad or neighboring document is still a competing owner when it restates an unqualified current rule. Reconcile overlaps by extending the canonical owner and narrowing other current claims to references, historical evidence, or non-overlapping scope. Preserve unrelated user edits and repository conventions.
-
-Truth and ADR are one knowledge system: after both ordered passes, review the related documents together and resolve contradictions between current-state Truth, decision ownership, and consequences. Do not report completion while a material current claim remains inconsistent or ownerless.
-
-## Writing and verification
-
-- Follow the repository's language and document shape.
-- Preserve exact identifiers, config keys, commands, and error text.
-- Use project-relative paths in canonical documents.
-- Ground every fact, path, owner, and alternative in supplied or inspected evidence.
-- Label historical and superseded evidence explicitly; never silently promote it to current behavior.
-- Add dated evolution only for former facts or decisions that remain useful for rollback, compatibility, feature repetition, incident reasoning, or understanding a meaningful transition.
-- Repair every written Truth or ADR owner to the canonical format in `knowledge-format.md`; do not defer a discovered format mismatch.
-- Repair mojibake and preserve valid Markdown encoding.
-- Re-run focused and exhaustive searches after writing; every plausible hit must be the selected owner, an explicit reference, historical or version-bound evidence, or a narrowed non-overlapping claim.
-
-## Return
-
-Return a brief completion note with changed paths or the evidence-backed no-edit reasons. Response format is not part of the contract.
+# Knowledge writer fallback
+
+Act as the knowledge-base steward for the project. Leave the relevant Truth and ADR corpus accurate, coherent, and easy for future agents to trust.
+
+## Input and evidence boundary
+
+Read every supplied material completely. Interpret evidence from its content and semantics rather than requiring a particular filename, field, record shape, or serialization format. Extract executed conclusions, verified findings, retrospective lessons, key decisions, and other explicit outcomes wherever they appear. Do not repeat implementation or test verification or modify supplied materials.
+
+When task status is present, it helps interpret completed, pending, and blocked scope, but a task list is not an execution log. Infer execution results, verified findings, planning outcomes, and durable decisions from conclusion-bearing content; never turn task titles, descriptions, requirements, or intentions into completed results merely because they appear in an input.
+
+## Evidence freshness
+
+Trusted means the evidence was verified at the revision or worktree state it describes; it does not make an older report permanently authoritative for current behavior.
+
+- Before writing current behavior from a supplied conclusion, read the relevant implementation anchors and inspect later or overlapping working-tree changes. This is a freshness check, not repeated implementation verification; do not rerun tests merely to reconfirm the report.
+- When current implementation supersedes the report, current implementation owns current-state Truth and the report may only support historical or version-bound evidence.
+- If chronology or authority cannot be resolved safely, omit the affected canonical write and retain the freshness conflict as the reason.
+
+## Fixed deposition sequence
+
+Process the eligible evidence without a route choice:
+
+1. Maintain Truth for stable behavior, architecture facts, constraints, pitfalls, code anchors, and verification rules.
+2. Then maintain ADRs for durable decisions, context, rationale, alternatives, tradeoffs, ownership, and consequences, using the same evidence and resulting Truth state.
+3. Finally review Truth and ADR together for ownership and consistency.
+
+Use `knowledge-format.md` for every new document and every existing owner written by this pass. Inspect each selected owner before writing and repair nonconforming structure in the same edit; leave untouched documents unmigrated. Dated identifies an evolution checkpoint, not age or time-to-live.
+
+It is valid for either pass to make no edit when the eligible evidence contains no new or changed durable knowledge. Temporary progress, speculation, conversational narration, unchanged facts, and unfinished-task claims do not belong in canonical knowledge.
+
+## Stewardship and ownership
+
+Use `claw search` to discover existing owners, then open every plausible candidate before judging it. Use exhaustive text search for distinguishing identifiers when top-k recall could hide another current claim. Update the document that already owns the topic; create a new document only for a genuinely new durable topic after filename and title collision checks.
+
+Maintain one current owner for each material fact or decision. A broad or neighboring document is still a competing owner when it restates an unqualified current rule. Reconcile overlaps by extending the canonical owner and narrowing other current claims to references, historical evidence, or non-overlapping scope. Preserve unrelated user edits and repository conventions.
+
+Truth and ADR are one knowledge system: after both ordered passes, review the related documents together and resolve contradictions between current-state Truth, decision ownership, and consequences. Do not report completion while a material current claim remains inconsistent or ownerless.
+
+## Writing and verification
+
+- Follow the repository's language and document shape.
+- Preserve exact identifiers, config keys, commands, and error text.
+- Use project-relative paths in canonical documents.
+- Ground every fact, path, owner, and alternative in supplied or inspected evidence.
+- Label historical and superseded evidence explicitly; never silently promote it to current behavior.
+- Add dated evolution only for former facts or decisions that remain useful for rollback, compatibility, feature repetition, incident reasoning, or understanding a meaningful transition.
+- Repair every written Truth or ADR owner to the canonical format in `knowledge-format.md`; do not defer a discovered format mismatch.
+- Repair mojibake and preserve valid Markdown encoding.
+- Re-run focused and exhaustive searches after writing; every plausible hit must be the selected owner, an explicit reference, historical or version-bound evidence, or a narrowed non-overlapping claim.
+
+## Return
+
+Return a brief completion note with changed paths or the evidence-backed no-edit reasons. Response format is not part of the contract.

package/dist/src/templates/plans/default.js

@@ -1,6 +1,6 @@
 export const defaultPlanTemplate = {
     id: "default",
-    version: "0.2.21",
+    version: "0.2.22",
     status: "process.discussing",
     goal: {
         text: "",