diff options
| author | Craig Jennings <c@cjennings.net> | 2026-05-14 07:30:31 -0500 |
|---|---|---|
| committer | Craig Jennings <c@cjennings.net> | 2026-05-14 07:30:31 -0500 |
| commit | db87d0793a04b88fa1347ca5259f537aa8838a79 (patch) | |
| tree | 61bb965f1e0804ac3ffaa7ac491d14a58229932e | |
| parent | 99252c04a5a0113947681dfb4276116d4aa69983 (diff) | |
| download | rulesets-db87d0793a04b88fa1347ca5259f537aa8838a79.tar.gz rulesets-db87d0793a04b88fa1347ca5259f537aa8838a79.zip | |
chore(inbox): remove sync-child-priority spec — implemented
| -rw-r--r-- | inbox/child-priority-sync-todo-cleanup.md | 69 |
1 files changed, 0 insertions, 69 deletions
diff --git a/inbox/child-priority-sync-todo-cleanup.md b/inbox/child-priority-sync-todo-cleanup.md deleted file mode 100644 index e7ef9b5..0000000 --- a/inbox/child-priority-sync-todo-cleanup.md +++ /dev/null @@ -1,69 +0,0 @@ -# Add `--sync-child-priority` to `todo-cleanup.el` - -## Context - -When a parent task in `todo.org` is reprioritized, its child sub-tasks frequently drift — they keep their original priority cookies even after the parent's importance changes. Today there's no automatic mechanism to keep them in sync. Craig has been requesting the sync manually via cj comments (e.g., the Whisper voice-input parent was `[#B]` while children were `[#D]` until 2026-05-14). - -## Recommended home - -**`~/code/rulesets/.claude/scripts/todo-cleanup.el`** (and its per-project copies at `<project>/.ai/scripts/todo-cleanup.el`). - -Rationale: this script already runs at every wrap-up via the wrap-it-up workflow (Step 3 — hygiene + archive-done passes), already operates on `todo.org` AST, and already produces a reviewable git diff before the wrap-up commit. Adding a child-priority-sync pass here means drift is caught automatically every wrap-up, with git as the review surface, idempotent across runs. - -Alternatives considered and rejected: - -- **Stay in `/respond-to-cj-comments`.** Reactive only — drift accumulates between cj comments. Mixes concerns (annotation processing vs structural maintenance). -- **Daily-prep workflow Phase 8.** Daily cadence, but wrap-up already covers it and runs more frequently. No reason to add a second cadence. -- **Org-mode advice on `org-priority` in Emacs config.** Fires only on interactive priority changes. Misses anything introduced by file merge / rebase / external edits. Per-machine config drift risk. -- **Dedicated `/sync-priorities` skill.** Explicit but requires Craig to remember to run it. Loses the "automatic at wrap-up" property. - -## Implementation outline - -Add two new modes to `todo-cleanup.el`, mirroring the existing `--archive-done` pattern: - -- `--check-child-priority` — report-only. Walks every parent task, lists any child whose priority cookie is lower than the parent's (no writes). -- `--sync-child-priority` — apply. Bumps each child whose priority is lower than the parent's so it matches. - -Integration point: invoked from `wrap-it-up.org` Step 3, after the hygiene pass and the `--archive-done` pass. Two-step in the workflow: -1. Run `--check-child-priority` (preview). -2. If items surface, run `--sync-child-priority` (apply). Diff lands in the wrap-up commit for review. - -The script needs to: -1. Walk the org AST (use `org-element-parse-buffer`). -2. For each `headline` element with a priority cookie, find its `headline` children one level deeper. -3. Compare priorities. Org priority cookies are `[#A]`, `[#B]`, `[#C]`, `[#D]` — A is highest. "Lower than parent" = numerically higher letter (e.g., child `[#D]` under parent `[#B]` → drift). -4. Apply the bump: rewrite the child's priority cookie to match the parent's. -5. Report what changed for the wrap-up summary. - -## Open questions (Craig — answer before implementation) - -1. **Sync direction.** Down-only (parent → children), or also up (highest-priority child → parent)? The default for now is down-only; up-syncs feel like they'd cause more confusion than they solve, but worth confirming. - -2. **Opt-out for deliberately-lower children.** The Whisper task has Follow-up sub-tasks (VAD, CUI gating, Phase 2 self-hosted Whisper) that were *deliberately* `[#D]` to mark them post-MVP. Bumping them silently would lose that signal. Options: - - **Heading-prefix match.** Tasks whose heading starts with `Follow-up:`, `Spike:`, `Stretch:`, or similar marker are skipped. - - **Org tag.** Tag the heading with `:no-sync:` to opt out (`*** TODO [#D] Follow-up: VAD :no-sync:`). - - **Org property.** `:PROPERTIES:\n:NO_SYNC: t\n:END:` block on the heading. - - Pick one (or some combination). Tag is probably lowest-friction. - -3. **Auto-apply at wrap-up, or `--check` first by default?** Two patterns: - - Wrap-up always runs `--check-child-priority`, surfaces what would change, asks Craig before applying. Slower but safer. - - Wrap-up runs `--sync-child-priority` directly. Diff is in the commit, can be reverted if wrong. Faster, matches the `--archive-done` cadence (which is also auto-apply). - Existing `--archive-done` is auto-apply, so for consistency I'd default to auto-apply unless there's a reason to be more cautious here. - -4. **Parent with no priority cookie, but children with cookies.** Edge case — a parent might be a section grouper with no priority of its own, while children carry cookies. Options: - - Leave alone (parent has no priority to sync from). - - Strip the children's cookies so the section reads consistently. - - Treat the highest-priority child as the parent's implicit priority. - Probably leave alone for now — simpler and matches "down-only" framing. - -## When Craig answers these - -The next session can wire `--sync-child-priority` into both: -- `~/code/rulesets/.claude/scripts/todo-cleanup.el` (source) -- `<project>/.ai/scripts/todo-cleanup.el` (per-project copy) - -Plus extend `~/code/rulesets/.claude/commands/wrap-it-up.org` Step 3 to invoke the new mode after `--archive-done`. - -## Provenance - -Surfaced via cj comment on the Whisper voice-input parent task on 2026-05-14 after manually bumping 12 children from `[#D]` to `[#B]`. Recommendation drafted in response; Craig asked to file it here for later implementation rather than answer the clarifying questions inline. |
