docs(workplans): require task refinement after substantial progress

Assistant: codex
Assistant-Model: gpt-6-astra
Assistant-Session: 01a13eab-1e6a-7b33-9c37-372e90ada3a2

scripts/project_rules/agents-codex.template

@@ -109,7 +109,8 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
 4. Check human-needed tasks: `GET /tasks/?needs_human=true`
 
 **During work:**
-- Update task statuses in workplan files as tasks progress
+- Update task statuses and refine task structure after substantial work; record
+  completed deliverables and split remaining scope (see Workplan Convention)
 - Record significant decisions via `POST /decisions/`
 
 **Close:**
@@ -143,6 +144,36 @@ curl -s -X PATCH "http://127.0.0.1:8000/tasks/<task_id>" \
 Work items originate as files in this repo — not in the hub. The hub is a
 read/cache/index layer that rebuilds from files.
 
+### Task refinement after substantial work (required)
+
+At each substantive checkpoint and before session close, compare the completed
+work and new knowledge with the current task structure. If substantial work was
+completed while the workplan's task granularity stayed unchanged, **add completed
+task records for those evidenced outcomes and refine the remaining tasks**.
+A long progress note inside the same broad open task does not satisfy this rule.
+
+- Give each substantial completed deliverable a task with its actual outcome,
+  completion date, evidence and limits. Retrospective recording is allowed; do
+  not invent completion dates, deliveries, native acceptance or approvals.
+- Split remaining work into independently manageable deliverables with an owner,
+  next action, completion criteria and real dependencies. Use `todo` for work
+  that can start; use `wait` only with a concrete prerequisite and unblock condition.
+- Preserve existing task IDs, Hub UUIDs and history. When narrowing an umbrella
+  task, explain the split and map moved scope to the new task IDs. Do not mark
+  the umbrella done unless its retained scope is complete; preserve externally
+  referenced acceptance gates until their dependencies are satisfied.
+- Keep task counts honest: extracting completed scope must not count the same
+  outcome twice or imply an effort-based completion percentage. Distinguish
+  source/fixture proof, actual operational proof and owner acceptance.
+- Record new risks and out-of-scope findings as explicit disposition/handoff
+  tasks or linked live work records; do not silently expand authorization.
+
+Make these changes in the repository source, commit/push, run the repository's
+required projection sync, and verify the actual projected task counts, statuses
+and dependencies. Progress events supplement the task structure; they do not
+replace it. A checkpoint report must show both substantive outcomes and newly
+refined remaining work when this rule is triggered.
+
 **File location:** `workplans/{WP_PREFIX}-NNNN-<slug>.md`
 
 **Archived location:** finished workplans may move to