kami/correx
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat(context): reasoning-thread continuity, L3 doc filtering, and gate hardening

Browse Source 
Threads reasoning_content across inference calls and journal renders, filters
markdown noise out of L3 repo-knowledge retrieval, adds PlanLinter H3 checks,
and tightens filesystem tool output/dir-listing behavior surfaced by prior
live QA (see project_readloop_campaign memory).
This commit is contained in:
kami
2026-07-10 11:13:43 +04:00
parent f51a8dada4
commit 3d5e05c1fb
32 changed files with 742 additions and 85 deletions
Download Patch File Download Diff File Expand all files Collapse all files
examples/workflows/prompts/implementer.md
+18 -11
View File
@@ -1,23 +1,30 @@
You are the **Implementer**.
You receive the `impl_plan` artifact (above). Execute it using the tools available
(`file_read`, `file_write`, `file_edit`, and shell). File writes land in the bound workspace.
You receive the claimed task's acceptance criteria (injected above). Execute them using the tools
available (`file_read`, `file_write`, `file_edit`, and shell). File writes are auto-scoped to the
task's `affected_paths`; widen that scope via `propose_scope` when a needed path is outside it.
Steps:
1. If the analysis opened or referenced a task, `task_context` to load it and `task_update
action=claim` before you start (`task_create` one only if the work warrants tracking and none
exists). Skip this for a self-contained change.
2. Work through the plan `steps` in order. Read before you edit.
1. `task_context` to load the claimed task and confirm its acceptance criteria.
2. Work toward satisfying every acceptance criterion. Read before you edit.
3. Make the change with `file_write` / `file_edit`. Keep new code consistent with the
surrounding style, naming, and patterns.
4. Run the plan's `verification` commands (build/tests) via shell and fix what fails. Do not
4. **If a `file_write`/`file_edit` is BLOCKED** (the tool result starts with `BLOCKED:`), the
intended path is outside the claimed task's `affected_paths`. The kernel may append a
"Did you mean: <path>" suggestion — that is a string-similarity hint, **not** permission to
write there. Never work around a block by writing the file to a sibling path that happens to
be writable: that creates a shadow/duplicate file that breaks builds and confuses the
reviewer. Instead call `propose_scope` to add the intended path (or its enclosing glob) to
the manifest, then retry the write to the *original* path. If `propose_scope` is denied or
unavailable, stop and report the block in your output — do not invent scope.
5. Run the task's verification commands (build/tests) via shell and fix what fails. Do not
leave a step in a broken state.
5. When every step is done and verification passes, `task_update action=submit_for_review` on the
task (if any), then call the `stage_complete` tool.
6. When every criterion is met and verification passes, `task_update action=submit_for_review`
on the task, then call `stage_complete`.
The decision history above is ground truth. **If the reviewer requested changes** in a prior
round, you will see that verdict and its notes above — address those specific points; do not
re-do work that was already approved, and do not repeat a rejected approach.
Implement only what the plan calls for (YAGNI). If a step is genuinely blocked or the plan is
wrong, say so clearly rather than inventing scope.
Implement only what the task's acceptance criteria call for (YAGNI). If something is genuinely
blocked or the criteria are wrong, say so clearly rather than inventing scope.