#+TITLE: Request: wrap-up should recommend cross-project destinations for outstanding inbox items (and transcripts)
#+DATE: 2026-06-13

* Context

Handoff from archsetup (2026-06-13). This is a feature request for the canonical =wrap-it-up.org= workflow (=claude-templates/.ai/workflows/=), so it lands in rulesets and syncs out to every project.

Today the wrap-up has an inbox step (Step 3, "Inbox sanity check"): it counts unprocessed handoffs and tells the user to run =process-inbox.org= or defer each one. That step answers "is the inbox clean?" but it doesn't help route anything — it just blocks the wrap until the items are processed in place.

Craig wants a second, lighter capability layered on: at wrap-up, when outstanding inbox items remain, surface them, recommend where each actually belongs, and offer to move the whole batch there in one keystroke. Not mandatory. The point is routing, not gating.

* The behavior Craig described

When the wrap-up finds outstanding inbox items:

1. *Notify* that there are items to clear.
2. *List* them, each with a recommended destination project.
3. *Offer two options, batch-level:*
   - "Go with my recommendations" — apply every recommended move.
   - "Skip" — leave the whole batch where it is.

That's the whole interaction. Two options, not per-item triage. The skip option exists because there are real cases where Craig wants the entire batch to stay put, and forcing a per-item walk would tax those cases. Not a mandatory wrap gate either — a skip is a clean, complete wrap.

* What "move" means

Moving an inbox item that is a *task or event* means relocating it into the recommended project's =todo.org=, under that project's "Open Work" section, as a proper org task (per =todo-format.md= — terse heading, body for detail, tags on the heading line).

Two grounding points for whoever builds this:

- *Destination anchor already exists.* =todo-cleanup.el='s =--archive-done= already locates a project's "Open Work" section by the unique level-1 heading containing "Open Work" (case-insensitive). The move can reuse that same matcher to find the insertion point, and skip/​surface a project whose =todo.org= lacks the heading rather than guessing.
- *Destination can be any project, not just an .ai project.* The recommendation engine should consider every project with a =todo.org=, whether or not it has an =.ai/= directory. The existing project discovery (=inbox-send.py --list=, the =ai= launcher) filters on =.ai/protocols.org=, which is too narrow here — widen it to "has a =todo.org= with an Open Work section." A plain code repo Craig keeps a =todo.org= in is a valid destination.

* Meeting transcript recordings — the parallel step

Craig wants "something similar and appropriate" for meeting transcript recordings. Similar in shape (surface, recommend a destination project, batch go/skip), but the action differs because a transcript is a document, not a task.

My read on what "appropriate" means here:

- *Filing, not todo-insertion.* Moving a transcript means relocating the recording (and any transcript text) into the recommended project's permanent home, following =working-files.md=: renamed to =YYYY-MM-DD-<slug>-transcript.<ext>= and moved flat into that project's =assets/= (or area-scoped =assets/=). Not into =todo.org=.
- *Open question worth Craig's call:* should filing a transcript also extract action items into the destination's =todo.org=? A meeting usually produces both an artifact to keep and tasks to track. The clean split: file the recording as the artifact, and if it carries action items, surface those as a separate task-routing batch (which is exactly the first capability above). That keeps the two mechanisms orthogonal — transcripts file as documents, their action items route as tasks. But Craig may want a single combined "process this transcript" move. Flagging it rather than deciding.
- *Where transcripts accumulate* isn't something archsetup knows. Whoever builds this should pin the source location (a recordings inbox, a downloads dir, wherever signal-cli or the meeting tooling drops them) before wiring the recommendation.

* Relationship to the existing inbox step

These compose; they don't replace each other. The existing "Inbox sanity check" is about *processing* handoffs through the value gate (=process-inbox.org=: act / file / reject). This new step is about *routing* items that are already understood to be real tasks or events to the project where they belong. A natural ordering: process-inbox first decides what's worth keeping, then this step routes the keepers to the right project. Whether they merge into one wrap-up step or stay two is a rulesets design call — I'd lean toward keeping the gate and the router visibly separate, since one blocks the wrap and the other is optional.

* Implementation notes (for whoever picks this up)

- The cross-project task move probably wants a small helper (extend =todo-cleanup.el=, or a new =.ai/scripts= tool) that inserts a task subtree under a named project's "Open Work" heading and removes the source item atomically. Doing it by hand-edit across two projects is error-prone.
- The recommendation logic is the interesting part: infer the destination project from the item's content (project names, file paths, topic) against the discovered project list. Worth keeping conservative — a low-confidence recommendation should say so, so "go with my recommendations" stays trustworthy as a single keystroke.
- Honor the cross-project boundary discipline (=cross-project.md=): moving an item into project X's =todo.org= is writing into X's scope. Within the wrap-up's batch-confirmed "go" that's authorized, but the move should still be visible (it shows in X's next git diff) and ideally leave a one-line provenance note.

* Reply

Drop a note in archsetup's inbox (=~/code/archsetup/inbox/=) if you want to talk through the design before building, or just let it land in the canonical workflow and sync out. No archsetup-side work is involved — this is entirely a rulesets workflow change.