hafiz-context-manager 0.1.0 → 0.1.1

package/dist/config/default/hafiz.yaml

@@ -12,7 +12,7 @@ tokenizer:
   soft_zone: 0.15                  # writes within cap*(1+soft_zone) succeed with a notice
 windows:                           # context window per model family; used for budgets
   default: 200000
-confirm_done: auto                 # auto | ask
+confirm_done: ask                  # ask | auto
 llm:
   # provider: none | kilo | openai-compatible | anthropic | fake (tests).  none = condensation
   # disabled (the host's own compaction stays on). kilo = run through Kilo itself (the Kilo plugin
@@ -34,8 +34,13 @@ onboarding:
   directive: >-
     Onboarding: this repo already had code when Hafiz started tracking it. Before planning new
     work, spawn the designer once with hafiz:block={root} to write the root design describing the
-    codebase as it is (overview, topology, interface, constraints). Import what you touch, stub
-    what you call: external dependencies get stubs only where current work needs them.
+    codebase as it is: stable architecture facts only (overview, topology, interface, true
+    constraints). Defects are facts, not rules: each goes in progress (kind found) on the block it
+    concerns, and only a full audit becomes a research child block. Existing choices worth keeping
+    may be decisions with rationale "existing design"; findings are never decisions until the user
+    chooses what to do. Task rules and process notes go in the report, not the store.
+    Import what you touch, stub what you call: external dependencies get stubs only where current
+    work needs them.
   roles: [manager]
 host:
   kilo:

package/dist/config/default/nudge.yaml

@@ -2,5 +2,5 @@
 # session, when the session starts to look multi-step.
 thresholds: { turns: 15, tool_calls: 25, files_written: 5, subagents_spawned: 1 }
 max_per_session: 1
-template: "Hafiz: this session has {tool_calls} tool calls across {files_written} files and no block tree. If this is multi-step work, call hafiz_track_project now (no need to ask)."
+template: "Hafiz: this session has {tool_calls} tool calls across {files_written} files in a repo Hafiz is not tracking. If this is multi-step work, call hafiz_track_project now (no need to ask)."
 auto_init: false

package/dist/config/default/roles.yaml

@@ -11,7 +11,8 @@ roles:
     view: designer
     focus_policy: all_active
     tools: [context.*, block.read, tree.list, block.create, doc.write:design, doc.patch:design,
-            edge.*, decision.record, thread.*]   # block.create: external stubs, sub-components
+            edge.*, decision.record, thread.*, progress.append:found, progress.append:question]
+    # block.create: external stubs, sub-components; progress: findings and questions only
     rules: rules/designer.md
   planner:
     view: default

package/dist/config/default/rules/common.md

@@ -35,3 +35,5 @@ need it again.
 - Pass `expected_version` when you edit a document you read. On a conflict, re-read, merge,
   retry.
 - Record facts, not intentions: what changed, what you learned, what was decided.
+- Decisions record choices someone made, not findings. Put findings in progress or, for a full
+  audit, a research block.

package/dist/config/default/rules/designer.md

@@ -8,8 +8,7 @@ blocks rely on. You do not plan steps or write code.
   `constraints`, `rationale` and `references` are optional.
 - root: `overview` and `topology`. research: `question`, then `findings` and `conclusion`.
   external: `interface` only.
-- Sections have token caps. Write tight prose and short list items. Put reasoning in
-  `rationale`, or record it as a decision.
+- Sections have token caps: write tight prose; put reasoning in `rationale`.
 
 **The interface is mandatory and precise.** It is what dependents see instead of your whole
 design.
@@ -23,8 +22,8 @@ design.
 **Writing.**
 - Use `hafiz_doc_write` (type design) for a first design and `hafiz_doc_patch` for edits. Always
   pass the `expected_version` you read.
-- On a conflict, someone changed the design since you read it. Re-read it with
-  `hafiz_block_read`, merge your change into theirs and retry. Never overwrite blindly.
+- On a conflict, re-read with `hafiz_block_read`, merge your change into theirs and retry.
+  Never overwrite blindly.
 - Interface changes on a block others depend on are breaking. Record why with
   `hafiz_decision_record`.
 
@@ -36,22 +35,26 @@ design.
   it only calls (a library, a service, another team's module) gets an `external` block: create
   it with `hafiz_block_create` (kind external), then write only its `interface` with what we use.
   Do not design external code beyond that.
-- Split a block that does two things into child blocks with `hafiz_block_create`, each with its
-  own interface.
+- Split a block that does two things into child blocks (`hafiz_block_create`), each with its own
+  interface.
 
 **Onboarding an existing codebase.** When spawned on the root of a repo that already had code,
 describe it as it is, not as it should be.
-- Read efficiently: the top-level layout, entry points, package manifests and existing docs
-  (README, ARCHITECTURE). Skim; do not read every file.
-- Write one concise root design within the caps: `overview`, `topology` (the main parts and how
-  they connect), `interface` (what the system offers its users) and `constraints`.
-- Create blocks only for areas current work touches, and stub external dependencies only where
-  that work calls them. Do not design the rest of the codebase.
+- Skim the layout, entry points, manifests and docs; do not read every file. Write one concise
+  root design with stable architecture facts only: `overview`, `topology` (main parts and how
+  they connect), `interface` (what the system offers its users) and `constraints` (true project
+  constraints, not defects).
+- Describe, do not assess. Existing choices worth keeping (local-only, SQLite) may be decisions
+  with rationale "existing design". Findings are never decisions.
+- Defects are facts, not rules: record each with `hafiz_progress_append` (kind `found`; `question` for
+  open points) on the block it concerns. Only a full audit becomes a `research` child block.
+- Task rules ("assessment only, no edits") go in your report, never the store; no process or
+  tooling notes in design sections.
+- Create blocks only for areas current work touches; stub externals only where called.
 
 **Open questions.** If a design question needs the user or the manager, `hafiz_thread_open` it on
 the block and keep designing around it. Park it with a gist (`hafiz_thread_park`) if it stays
 open when you finish. `hafiz_thread_resolve` it when answered, and record the answer with
 `hafiz_decision_record`.
 
-**Finish** with a short reply: which blocks you designed or changed, interface changes, and
-open threads.
+**Finish** with a short reply: blocks designed or changed, interface changes, open threads.

package/dist/config/default/rules/manager.md

@@ -14,7 +14,8 @@ below.
 
 **Onboarding.** If your envelope opens with an onboarding note, the repo had code before Hafiz.
 Do what it says once, before planning new work. The note goes away when the root design is
-written.
+written. Defects found are progress entries on the block they concern, never decisions; record
+a decision only when the user chooses what to do about one.
 
 **Delegating.**
 - Every task prompt you give a subagent must contain `hafiz:block=<block-id>` for the block it