Task: Bucket rescoring against sprint 23's mission

Table of Contents

This page documents a task in the Sprint 23 planning session story. It captures the goal, current status, acceptance, and any notes or results.

Goal

The deep backlog refinement (task Deep backlog refinement) verified every item against the live codebase and discarded/merged what was stale, but explicitly did not re-score bucket fit — this task does that half. Score every surviving item's fit against sprint 23's mission ("Continue commissioning ores.refdata entities and codegen C++ drift correction") and move it to next or deferred accordingly. inbox is not a valid resting bucket for this pass: every item currently in inbox must end this task filed into either next or deferred, not left in inbox.

Status

Field Value
State DONE
Parent story Sprint 23 planning session
Now Nothing — inbox empty, 310 items rebucketed.
Waiting on Nothing.
Next Nothing.
Last touched 2026-07-11

Acceptance

  • Every item in inbox at task start ends the task filed into next or deferredinbox is empty of pre-existing items by the end (new captures filed during the run, if any, are the only exception).
  • Every next=/=deferred item is scored against sprint 23's mission and moved if the current bucket doesn't fit; items already correctly bucketed are left in place.
  • :ID: preserved on every move (git mv, not delete+recreate).

Plan

(Implementation strategy. Written when work starts; key decisions are distilled into the parent story's * Decisions at close, but the plan itself stays — it is the historical record of what we did.)

Notes

Test Scenarios

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Scenario State Notes
     

PRs

PR Title
   

Review

Comment summary File Decision Notes
       

Result

Rebase conflicts resolved at PR time (2026-07-11)

Rebasing onto main before merge hit 3 conflicts, all resolved without re-running the scoring pass:

  • github_style_history_diff_view.org — a concurrent session had already promoted this capture into a task under Consolidate history dialogs onto HistoryDialogBase and deleted the original (commit 570f6fca1) before this branch rebased. My commit had only edited its bucket text; accepted upstream's deletion rather than resurrecting a file that no longer has a reason to exist.
  • generic-dispatch-table-registrar-pattern.org — a genuinely new capture filed in inbox on main after this branch's scoring run started (unrelated to this task, picked up by git's rename heuristic as a false match against one of this commit's real moves). Scored it the same way as the rest — explicit "when the first second consumer appears" framing with no near-term plan — and moved it to deferred, keeping inbox empty as this task requires rather than leaving it stranded by the conflict.
  • inbox.org (auto-generated index) — regenerated via regenerate_backlog_indexes.py rather than hand-resolving conflict markers in a generated file.

Run on 2026-07-11

Follow-on to Deep backlog refinement, which explicitly deferred this half. Ran as a workflow: a discovery agent listed every surviving item across inbox (208), next (224), deferred (56) = 488 total, then 26 parallel batch agents (20 items each) scored each one's next=/=deferred fit against sprint 23's mission ("Continue commissioning ores.refdata entities and codegen C++ drift correction"), with an explicit instruction that inbox is not a valid recommendation — every inbox item had to resolve to next or deferred.

Data-quality check before applying moves

489 scored entries came back for 488 discovered items. Diffed scored-vs-discovered paths and found two anomalies, both handled before applying anything:

  • One agent expanded a directory item's path to its story.org child (trade-import-service-layer/story.org instead of the directory) — cosmetic, normalized back to the directory path.
  • One agent fabricated an entry with an empty :ID:=/title (=pricing_model_parameter_table.org_dup_placeholder, a file that does not exist) recommending nextnext (a no-op). Discarded outright rather than acted on — never trust a schema-shaped response without checking the file it claims to describe exists.

Moves applied

From → To Count
inbox → next 123
inbox → deferred 85
next → deferred 88
deferred → next 14
Total moved 310

All 310 applied via git mv (:ID: preserved); 0 errors (no missing source, no destination collision). 269 of the 310 also had their intro-paragraph bucket text ("…in the X bucket of the product backlog…") updated to match the new location and their #+updated: timestamp refreshed. The other 41 are #+type: story documents (stories carried into the backlog from a past sprint, e.g. the commission_* template stories, entity_evaluation_skill) that never had bucket text in the first place — their template says "documents a story in Sprint N" or "…in the product backlog" with no bucket label to update; their new folder location is the only bucket signal they carry, same as before the move.

Full move list (310), for traceability

Every moved item, linked by :ID:, grouped by direction. Each row's rationale is the scoring agent's one-line justification against sprint 23's mission.

Outcome

Bucket Before After
inbox 208 0
next 224 273
deferred 56 215

inbox is empty of pre-existing items, satisfying the acceptance criterion. Notably, more items ended up in deferred (215) than next (273 is still larger, but deferred nearly quadrupled) — consistent with inbox having accumulated years of speculative/ research/nice-to-have ideas never triaged, most of which are genuinely long-horizon rather than near-term candidates.

Scope note

Scoring rubric explicitly did not require sprint-23-theme fit as the sole next criterion — a well-scoped bug fix or standalone improvement was scored next on its own merits (urgency, standalone scope, readiness), not only if it matched the refdata/codegen theme. This avoided the failure mode the skill's own Step 5 warns against: demoting everything that isn't this sprint's specific theme to deferred, which would make next useless for the following sprint's planning session.

No per-item spot-check of all 310 moves was performed given the volume — this is a scope/thoroughness trade-off worth flagging, not a silent gap: a sample-based trustworthiness check (à la the deep refinement's discard check) would be a reasonable addition for a future run at this scale.

Emacs 29.3 (Org mode 9.6.15)