From ee7049aaa62d0c38e83f20c0b3796e5eded4ca23 Mon Sep 17 00:00:00 2001 From: Craig Jennings Date: Thu, 28 May 2026 08:08:20 -0500 Subject: feat(workflows): audit-warranted pre-step + priority and tag enforcement Two changes land together because each is broken without the other. open-tasks.org gains a new Phase A.1, evaluated only in Next Mode. The phase reads :LAST_AUDIT: from notes.org and walks five state signals (reminder/task mismatch, passed scheduled date, "waiting on X" matches a shipped X, dead file: link, sub-task >75% DONE coverage). If the temporal threshold of 14 days trips, or any signal fires, Next Mode offers a task-audit run before producing the recommendation. Item 1 in the offer is "run task-audit first" per the recommendation-at-item-1 convention. task-audit.org gains two pieces. Phase C now enforces priority and type-tag presence per the project's legend, applies the [#A] dating rule from that legend, and re-assesses :quick: and :solo: from reconciled facts. Unambiguous calls land autonomously. Ambiguous ones flag NEEDS-USER instead of being guessed. A new Phase E stamps :LAST_AUDIT: on completion. --- .ai/workflows/task-audit.org | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) (limited to '.ai/workflows/task-audit.org') diff --git a/.ai/workflows/task-audit.org b/.ai/workflows/task-audit.org index edbaa8d..c999dab 100644 --- a/.ai/workflows/task-audit.org +++ b/.ai/workflows/task-audit.org @@ -73,7 +73,9 @@ For every STALE task, edit it in the main thread: - Mark statuses that moved; rewrite "waiting on X" lines whose X resolved. - Fix dead/renamed =file:= links. - *Consolidate duplicates* — when several tasks track the same thing, fold them into one home and delete the duplicates (per the user's call on which is canonical). -- *Re-assess the =:quick:= and =:solo:= tags* — reconciliation can change a task's effort or autonomy: a resolved dependency may make a stuck task =:solo:=, a scope cut may make it =:quick:=, and new complexity surfaced by the sources can invalidate either. Add or remove the tags per the definitions in [[file:task-review.org][task-review.org]] when the reconciled facts make the call clear. When they don't — an effort estimate you can't pin down, a =:solo:= gate you can't confirm — it's a NEEDS-USER flag, not a guess. +- *Ensure priority is set per the project scheme.* The top of the project's =todo.org= should carry the priority legend (=[#A]= through =[#D]=). Every task should carry an explicit priority cookie. If a cookie is missing, or no longer matches the reconciled facts, assign the right level per the legend. If the level is unambiguous from the body, do it autonomously; if it's a judgment call (especially the [#A] / [#B] line for important-but-not-urgent work), flag NEEDS-USER. Also enforce the [#A]-discipline rule from the legend — an [#A] task without a =SCHEDULED:= or =DEADLINE:= line is mis-graded and is either down-graded to [#B] (when reconciled facts say "important but not urgent") or surfaced as NEEDS-USER for the user to date. +- *Ensure a type tag is set.* Every task carries one type tag from the project's tag legend (typically =:feature:= / =:chore:= / =:spec:= / =:bug:=). If missing or wrong, assign or correct it from the body when the type is unambiguous. If two tags fit (a refactor that also fixes a bug; a spec that's also a chore), flag NEEDS-USER rather than picking one silently. +- *Re-assess the =:quick:= and =:solo:= tags* — reconciliation can change a task's effort or autonomy: a resolved dependency may make a stuck task =:solo:=, a scope cut may make it =:quick:=, and new complexity surfaced by the sources can invalidate either. Add or remove the tags per the definitions in the project's tag legend (and [[file:task-review.org][task-review.org]]) when the reconciled facts make the call clear. When they don't — an effort estimate you can't pin down, a =:solo:= gate you can't confirm — it's a NEEDS-USER flag, not a guess. - Bump =:LAST_REVIEWED:= on each edited task. Follow =todo-format.md= for completion mechanics (depth-based DONE vs dated-rewrite) and the working-files / link-hygiene rules when moving artifacts. @@ -84,6 +86,18 @@ Present the NEEDS-USER bucket as a short, scannable list — one line per task, When the trail on a task has gone cold and only the user knows the outcome, *say so and ask* — do not invent a status. ("The screen was set for 5/15; nothing in sessions, email, or chat records what came of it. Did it happen, and what's your read?") +** Phase E — Close out + +After Phase D's judgment calls are adjudicated and applied, stamp the audit run by updating =.ai/notes.org='s *Workflow State* section: + +#+begin_example +:LAST_AUDIT: YYYY-MM-DD +#+end_example + +Use today's =date= output (=date "+%Y-%m-%d"=). Overwrite the previous value — the marker reflects the most recent run, not a history. + +If the *Workflow State* section doesn't exist yet, create it (placement: after *Active Reminders*). Other workflows (notably =open-tasks.org= Next Mode's audit-warranted check) read this marker to decide whether to offer running another audit. + * Common Mistakes 1. *Guessing a judgment call instead of flagging it.* If the answer isn't in the sources, it's bucket 3. Ask. -- cgit v1.2.3