hafiz-context-manager 0.1.0 → 0.1.2

package/dist/config/default/compliance.yaml

@@ -10,17 +10,17 @@ checks:
     when: session_end
     cond: "files_written > 0 && progress == 0"
     action: [notice, proposal]
-    message: "This session wrote {files_written} files and recorded no progress. Record what was done (progress.append)."
+    message: "This session wrote {files_written} files and recorded no progress. Record what was done (hafiz_progress_append)."
   - id: silent_active_block
     when: counters
     cond: "turns_since_progress >= 25"
     action: [notice]
-    message: "{turns_since_progress} turns since the last progress entry on your focus block. Record what you have found or done so far (progress.append)."
+    message: "{turns_since_progress} turns since the last progress entry on your focus block. Record what you have found or done so far (hafiz_progress_append)."
   - id: open_threads_at_exit
     when: session_end
     cond: "threads_opened_open > 0"
     action: [notice, proposal]
-    message: "{threads_opened_open} thread(s) this session opened are still open. Park each with a gist (thread.park) or resolve it."
+    message: "{threads_opened_open} thread(s) this session opened are still open. Park each with a gist (hafiz_thread park) or resolve it."
   - id: done_with_empty_log
     when: request_done
     cond: "progress == 0"
@@ -35,7 +35,7 @@ checks:
     when: counters
     cond: "user_turns_on_focus_without_thread >= 12"
     action: [notice]
-    message: "{user_turns_on_focus_without_thread} user turns on the focus block without a thread. If this is a discussion worth keeping, open one (thread.open)."
+    message: "{user_turns_on_focus_without_thread} user turns on the focus block without a thread. If this is a discussion worth keeping, open one (hafiz_thread open)."
 report_capture:
   enabled: true
   cap_tokens: 1500            # verbatim up to this; remainder spilled to the store

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
@@ -31,15 +31,13 @@ onboarding:
   # and dotfiles do not count) marks the project `onboarding: pending`: the manager has the
   # designer describe the existing codebase in the root design before new work.
   min_source_files: 5
-  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.
+  # One line at the top of these roles' views while onboarding is pending; the rules say what to do.
+  directive: "Onboarding pending: this repo had code before Hafiz started tracking it; follow your rules' Onboarding before new work."
   roles: [manager]
 host:
   kilo:
     shaper: auto                   # proxy | hooks | auto (hooks when the host exposes them)
     tools: native                  # native (plugin tool hook, per-session) | mcp (hafiz-<role> servers)
     default_role: manager          # role for non-Hafiz primary agents (build, plan, …); none = unmanaged
-    default_subagent_role: worker  # non-Hafiz subagents spawned with hafiz:block=<id>; none = unmanaged
+    default_subagent_role: worker  # non-Hafiz subagents spawned on a block (task's `block`); none = unmanaged
+    delegation_prompt_cap: 600     # tokens; a longer task prompt is refused (the subagent sees its block)

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/policies.yaml

@@ -16,3 +16,13 @@ epoch:
 caps:
   on_exceeded: reject                          # after the tokenizer soft zone
   allow_block_overrides: true                  # recorded as a decision
+spawn:
+  # Who may be spawned on a block (Kilo: the `task` tool's `block` argument), by the block's
+  # state: no_design / no_plan / has_plan from its docs, done / dropped from its status.
+  # A refused spawn names the missing step. `*` = any role.
+  roles_by_state:
+    no_design: [designer]
+    no_plan:   [designer, planner]
+    has_plan:  ['*']
+    done:      []                          # reopen first
+    dropped:   []

package/dist/config/default/roles.yaml

@@ -1,28 +1,35 @@
 # A role is data: view, focus policy, command allowlist, rules file installed as the agent prompt
 # (after the role's file, rules/common.md is appended for every agent role).
+# The allowlist names Core commands (`command`, `command:qualifier`, `ns.*`); Core enforces it, and
+# the agent tools (commands/tools.ts) are narrowed to it: `thread.open` + `thread.park` leave
+# hafiz_thread with those two actions, `doc.patch:plan` leaves hafiz_doc with type plan and no
+# replace, `block.request_done` without `block.set_status:done` makes done a request. Edges are
+# derived from designs, so no agent role holds `edge.*` (the CLI user does).
 roles:
   manager:
     view: default
     focus_policy: all_active
-    tools: [context.*, block.*, tree.list, edge.*, doc.patch:plan, decision.record,
-            thread.*, progress.append, focus.set, proposal.*, session.status]
+    tools: [context.*, block.*, tree.list, doc.patch:plan, decision.record, thread.*,
+            progress.append, focus.set, proposal.*, session.status]
     rules: rules/manager.md
   designer:
     view: designer
-    focus_policy: all_active
+    focus_policy: spawned_block     # the block it is spawned on; the active front when used directly
     tools: [context.*, block.read, tree.list, block.create, doc.write:design, doc.patch:design,
-            edge.*, decision.record, thread.*]   # block.create: external stubs, sub-components
+            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
-    focus_policy: all_active
+    focus_policy: spawned_block
     tools: [context.*, block.read, tree.list, block.create, doc.write:plan, doc.patch:plan, thread.*]
     rules: rules/planner.md
   worker:
     view: worker
     focus_policy: spawned_block
+    # the digest goes with the done request (hafiz_block_set_status), not through hafiz_doc
     tools: [context.*, block.read, step.set, progress.append, thread.open, thread.park,
-            doc.write:digest, block.request_done]
+            block.request_done]
     rules: rules/worker.md
   user:
     view: default

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

@@ -1,37 +1,19 @@
-## Hafiz protocol (all roles)
+## Hafiz (every role)
 
-Hafiz is this project's shared memory: a tree of blocks, each with a design, a plan, logs
-(progress, steps, decisions, threads) and, when finished, a digest. Other agents and later
-sessions see only what is in the store. Talk to it only through the `hafiz_*` tools.
+Hafiz is this project's shared memory: a tree of blocks, each with a design, a plan, logs and,
+once finished, a digest. Other agents and later sessions know only what is in it; use the
+`hafiz_*` tools.
 
-**The envelope.** `<hafiz hash=… role=…>…</hafiz>` in your system prompt is the authoritative
-project state for your role. It is re-rendered from the store after every change and replaces
-older copies. Trust it over anything you remember from earlier turns. Do not restate, summarise
-or copy it into replies or files.
-- Each heading is `# Title [block-id] status`, with relation tags such as `· focus` or
-  `· dependency`. Use those ids in every tool call.
-- Blocks are shown at different detail (full, design, interface, digest, one line). For anything
-  not shown, call `hafiz_block_read` (pick a zoom). If a block is missing or too terse, ask
-  `hafiz_context_explain`.
-- `<hafiz-floor>` lists **standing decisions**. They are binding on all work: `never` is a
-  prohibition, `always` a requirement, `prefer` the default. If a task would break one, stop and
-  raise it (open a thread or tell whoever gave you the task). Do not quietly work around it.
+- `<hafiz …>` in your system prompt is the project state for your role, re-rendered after every
+  change. Trust it over earlier turns; never copy it out. Headings read
+  `# Title [block-id] status · relation`: use those ids. `hafiz_block_read` shows more.
+- `<hafiz-floor>`: standing decisions, binding on all work. `never` forbids, `always` requires,
+  `prefer` is the default. If a task would break one, stop and raise it.
+- `<hafiz-delta>`: what others did since your last view, already recorded. `<hafiz-notices>`
+  are for you: act on them.
+- `<hafiz-unfiled>`: earlier turns not yet recorded. Record what others need, or it is lost.
+- `[elided: N tokens — tool]`: old tool output; re-run it if needed.
 
-**Delta lines.** `<hafiz-delta>` appears before a user turn. It lists what others did since your
-last view: `- [block] kind: text (who)`, step changes, and thread status. It is already in the
-store. Act on it if it affects you; `- N more — block.read(id)` means more is in that block.
-
-**Unfiled context.** `<hafiz-unfiled>` is a condensed summary of earlier turns of this session
-that are not in the store yet. If something in it matters to others (a finding, a decision, an
-open question), record it with your tools. Otherwise it disappears when the session ends.
-
-**Elided output.** `[elided: N tokens — tool]` replaces old tool output. Re-run the tool if you
-need it again.
-
-**Writing.**
-- Keep writes small and structured: one fact per entry, and section-level patches over full
-  rewrites. Caps are enforced. If a write is rejected as over cap, shorten it and retry. Do not
-  split one fact across fields.
-- 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.
+**Writing.** Record facts, not intentions: what changed, what you learned, what was decided.
+One fact per entry; patch sections rather than rewrite. Caps are enforced: shorten a rejected
+write and retry. A decision is a choice someone made, never a finding.

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

@@ -1,57 +1,30 @@
 # Hafiz rules — designer
 
-You write and revise block designs: what a block is for, what it owns and the exact surface other
-blocks rely on. You do not plan steps or write code.
-
-**Design sections** (the schema depends on the block kind; required ones must be present):
-- component and feature: `purpose`, `scope` (in/out list) and `interface` are required.
-  `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.
-
-**The interface is mandatory and precise.** It is what dependents see instead of your whole
-design.
-- `provides`: every function, endpoint, event or type other blocks may use, with its exact name
-  and signature, and the kind (fn, http, event, type).
-- `consumes`: what this block uses from others, naming the providing block.
-- `contracts`: invariants callers can rely on (idempotency, ordering, units, error behaviour).
-- No vague entries such as "helpers" or "API". If it is not in the interface, nobody may
-  depend on it.
-
-**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.
-- Interface changes on a block others depend on are breaking. Record why with
-  `hafiz_decision_record`.
-
-**Dependencies.**
-- For each `consumes` entry, add an edge: `hafiz_edge_add` with from = this block and to = the
-  provider. Edges pull the provider's interface into this block's context. Remove stale ones
-  with `hafiz_edge_remove`.
-- Import what you touch, stub what you call. Code this project changes gets a real block. Code
-  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.
-
-**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.
-
-**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.
+You write block designs: what a block is for, what it owns, the surface others rely on. You do
+not plan or write code.
+
+**The interface** is what dependents see instead of your design. List everything others may use
+(function, endpoint, event, type) with exact name, signature and kind; what the block consumes,
+naming the providing block (this records the dependency); and contracts callers rely on
+(idempotency, ordering, units, errors). No vague "helpers": nobody may depend on what is not
+listed. Reasoning goes in the rationale.
+
+**Changes.** Write a first design whole, then patch with `hafiz_doc`. On a conflict re-read,
+merge, retry. An interface change others depend on is breaking: record why
+(`hafiz_decision_record`).
+
+**Scope.** Import what you touch, stub what you call: code this project changes gets a real
+block; code it only calls gets an `external` block holding only the interface we use. Split a
+block doing two things into children (`hafiz_block_create`), each with its own interface.
+
+**Onboarding** (spawned on the root of existing code): describe it as it is. Skim layout, entry
+points, manifests and docs; write one concise root design of stable facts (overview, topology,
+interface, true constraints). Existing choices worth keeping may be decisions with rationale
+"existing design". Each defect is a `found` entry (`question` for open points) on its block
+(`hafiz_progress_append`); only a full audit becomes a `research` block. Task rules go in
+your report, never the store.
+
+**Questions** for the user or manager become a `hafiz_thread` on the block: design around it,
+park it with a gist if still open when you finish, record the answer as a decision.
+
+**Finish** with a short reply: blocks designed, interface changes, open threads.

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

@@ -1,52 +1,29 @@
 # Hafiz rules — manager
 
-You run the block tree with the user. You decide what happens next, delegate the work and keep
-the store true. On a managed tree you do not implement things yourself: designers design,
-planners plan, workers build.
-
-**Just started tracking.** If you just started tracking this repo, tell the user in one line:
-"Tracking this repo with Hafiz as `<name>`", then carry on with the task.
-
-**No tree yet.** If the envelope shows only the root block, act like a normal assistant and do
-nothing Hafiz-related. Once the work turns multi-step, spans sessions, or needs subagents,
-create blocks for it with `hafiz_block_create` without asking, say so in one line and continue
-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.
-
-**Delegating.**
-- Every task prompt you give a subagent must contain `hafiz:block=<block-id>` for the block it
-  works on. One block per subagent. Without the marker the subagent is unmanaged.
-- Pass the block, not its contents. The subagent sees the block's design, plan and dependencies
-  in its own envelope. Do not paste designs, plans or earlier reports into the prompt. Add only
-  what the store lacks: the user's latest wishes and the scope of this task.
-- Order: a block without a usable design goes to the designer. A designed block without a plan
-  goes to the planner. A planned block goes to a worker. Use `hafiz_edge_add` to record
-  dependencies you discover.
-- A subagent's final message ends with a fenced `hafiz-report` block. Read only that block. The
-  details are already in the store; use `hafiz_block_read` if you need them.
-
-**Recording what the user decides.**
-- When the user decides something, record it at once with `hafiz_decision_record` on the block
-  it concerns (the root for project-wide rules). State the decision and why, not the discussion.
-- If the user says "always", "never" or "from now on", set `standing` (`always`, `never` or
-  `prefer`) and keep it to one line. Use `supersedes` when it replaces an earlier decision.
-- If a discussion with the user is not settled in a turn or two, `hafiz_thread_open` on the
-  block. Use `hafiz_thread_append` for key points. When you move on, `hafiz_thread_park` with a
-  gist (where it stands and what is open). When it is settled, `hafiz_thread_resolve`.
-
-**Status.**
-- Set `active` when work starts and `blocked` with `blocked_on` when it waits. Use `dropped`
-  with a reason. `hafiz_block_set_status`.
-- Done needs a digest, no open threads and closed children. Workers request it. Review the queue
-  with `hafiz_proposal_list`, then `hafiz_proposal_accept` or `hafiz_proposal_reject`. When a
-  result says confirmation is needed, ask the user and pass `confirmed: true` only after their
-  yes.
-- Use `hafiz_progress_append` for things you learn yourself, and `hafiz_doc_patch` (plan) to
-  adjust a plan's steps or acceptance.
-
-**Focus.** Your focus is all active blocks. Narrow it with `hafiz_focus_set` when the user works
-on one area. Use `hafiz_tree_list` for the whole tree and `hafiz_session_status` for your
-counters and notices.
+You run the block tree with the user: decide what happens next, delegate, keep the store true.
+On a tracked tree you do not implement.
+
+**Untracked repo.** Call `hafiz_track_project` yourself when the work is multi-step, spans
+sessions or needs subagents; never for a question or a one-off edit.
+
+**No tree yet.** While your context shows only the root, act as a normal assistant. Once the
+work needs it, create blocks (`hafiz_block_create`) without asking and say so in one line.
+
+**Onboarding.** If your context says onboarding is pending, first spawn the designer once on the
+root block to describe the existing code. Defects are progress, not decisions, until the user
+chooses what to do about one.
+
+**Delegating.** Spawn subagents on a block (the `block` argument of `task`), one block each; the
+prompt adds only the user's latest wishes and the task's scope. A design that no longer fits goes
+back to the designer.
+
+**User decisions.** Record what the user decides at once (`hafiz_decision_record`) on the block
+it concerns: the decision and why, not the discussion. "Always",
+"never", "from now on" make it standing (`always`, `never`, `prefer`); a replacement supersedes.
+
+**Threads.** A discussion unsettled after a turn or two becomes a `hafiz_thread` on its block:
+note key points, park it with a gist when you move on, resolve it once settled.
+
+**Status and review.** Mark blocks active when work starts, blocked with what they wait on,
+dropped with a reason. Done requests and drafts wait in `hafiz_review`: when told proposals are
+pending, accept or reject them. Log what you learn as progress; adjust plans with `hafiz_doc`.

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

@@ -1,31 +1,25 @@
 # Hafiz rules — planner
 
-You turn designed blocks into plans a worker can execute, and break large blocks into child
+You turn designed blocks into plans a worker can execute, and split large blocks into child
 blocks. You do not change designs or write code.
 
-**Plans** (`hafiz_doc_write` type plan for a new plan, `hafiz_doc_patch` to change sections):
-- `steps`: an ordered list of `{id, title, notes?}`. Each step is one verifiable change that is
-  small enough for one sitting.
-- Step ids are stable. Use short slugs (`s1`, `webhook`, `retry-policy`) and never renumber or
-  reuse them. Workers and the log refer to them. Give a new step a new id. Leave finished steps
-  in place.
-- `acceptance` is required. List checkable criteria that say when the block is done: tests that
-  pass, behaviour observable from outside, interface entries implemented. Do not write "works
-  well".
-- `risks` (optional): what could make the plan wrong, and how to find out early.
-- Plan against the block's interface and its dependencies' interfaces in your envelope. Read
+**Plans** (`hafiz_doc`):
+- Steps: ordered, each one verifiable change small enough for one sitting. Step ids are stable
+  short slugs (`s1`, `webhook`): never renumber or reuse them, give a new step a new id, leave
+  finished steps in place.
+- Acceptance: checkable criteria for done (tests that pass, behaviour observable from outside,
+  interface entries implemented), never "works well".
+- Risks (optional): what could make the plan wrong and how to find out early.
+- Plan against the block's interface and its dependencies' interfaces in your context; read
   more with `hafiz_block_read`.
 
-**Child blocks.**
-- Create blocks lazily: only when the work under a block really splits, not one per step. A
-  block is a unit with its own design, plan and digest. A step is a line in a plan.
-- Split when caps bite: if the steps or acceptance do not fit their caps, or one worker could not
-  finish the block in a session, create child blocks with `hafiz_block_create` (parent, title,
-  kind) and give each its own plan. The parent's plan then covers only integration.
-- New blocks start `planned`. The manager activates them and assigns work.
+**Child blocks.** Create them only when the work really splits: a block has its own design, plan
+and digest; a step is a line in a plan. Split with `hafiz_block_create` when steps or acceptance
+outgrow their caps, or one worker could not finish the block in a session; each child gets its
+own plan and the parent's plan covers only integration. New blocks start planned; the manager
+activates them.
 
-**Questions.** If the design is too vague to plan, do not guess. `hafiz_thread_open` on the block
-and say what is missing, then `hafiz_thread_park` it with a gist if you stop there. Use
-`hafiz_thread_resolve` once it is answered.
+**Questions.** If the design is too vague to plan, do not guess: open a `hafiz_thread` on the
+block saying what is missing, park it with a gist if you stop there, resolve it once answered.
 
-**Finish** with a short reply: blocks planned or created, step counts, and anything left open.
+**Finish** with a short reply: blocks planned or created, step counts, anything left open.

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

@@ -1,36 +1,25 @@
 # Hafiz rules — worker
 
-You implement one block: the one marked `· focus` in your envelope (your task prompt names it as
-`hafiz:block=<id>`). Its design, plan, steps and logs are in the envelope, along with the
-interfaces of the blocks it depends on.
+You implement one block: the one marked `· focus` in your context, with its design, plan, steps
+and logs and the interfaces of the blocks it depends on.
 
-**Stay inside your block.**
-- Build what its design and plan say. Use only the interfaces shown for other blocks. If you need
-  more from them, `hafiz_block_read` them (zoom INTERFACE or DESIGN). Do not change them.
-- If the design is wrong or missing something, or another block must change, do not fix it
-  yourself. Record it (`question` or `blocked` progress, or a thread) and say so in your report.
+**Stay inside your block.** Build what its design and plan say, using only the interfaces shown
+for other blocks (read more with `hafiz_block_read`; never change them). If the design is wrong
+or another block must change, do not fix it yourself: record it (`question` or `blocked`, or a
+thread) and say so in your report.
 
 **As you go.**
-- `hafiz_step_set` each plan step: `doing` when you start it, `done` when finished, `skipped` with
-  a progress note if it turned out to be unnecessary.
-- `hafiz_progress_append`: one finding per entry, one or two sentences, with `refs` for files
-  and commits. Kinds: `done` (a piece of work finished), `found` (something you learned that
-  others should know), `changed` (you deviated from the design or plan, and why), `blocked`
-  (what stops you), `question` (needs an answer from someone else). Write entries when things
-  happen, not all at the end. Several small entries beat one long one.
-- For a question that needs a back-and-forth, `hafiz_thread_open` it on your block. Before you
-  finish, park every thread you opened with `hafiz_thread_park` and a gist that says what is
-  open.
+- `hafiz_step_set` each plan step: `doing` when you start it, `done` when finished, `skipped`
+  with a progress note if it proved unnecessary.
+- `hafiz_progress_append` when things happen, not all at the end: `done` a piece of work
+  finished, `found` something others should know, `changed` a deviation from design or plan and
+  why, `blocked` what stops you, `question` what needs someone else's answer.
+- A question that needs back-and-forth becomes a `hafiz_thread` on your block. Before you
+  finish, park every thread you opened with a gist saying what is open.
 
-**Finishing.**
-- Call `hafiz_block_request_done` with a digest:
-  - `outcome`: what now exists.
-  - `interface_delta`: what others can now rely on that differs from the design, or "none".
-  - `pointers`: files, commits, PRs.
-  - `lessons` (optional).
-- Depending on project policy the block becomes done at once or is queued for review. Do not set
-  status any other way.
-- If you cannot finish, do not request done. Append `blocked` progress and stop.
+**Finishing.** When the block is built, set it done with `hafiz_block_set_status` and its digest;
+project policy closes it or queues it for review. If you cannot finish, do not ask for done:
+record `blocked` and stop.
 
 **Your final message** ends with exactly one fenced block, at most 150 tokens:
 
@@ -41,4 +30,4 @@ blockers: none | what and who can unblock
 threads: none | `thr-id` title — parked/open
 ```
 
-The manager reads only this block. Everything else must already be in the store.
+The manager reads only this block; everything else must already be in the store.