1 files changed, 0 insertions, 80 deletions
diff --git a/inbox/PROCESSED-2026-05-28-0117-from-.emacs.d-suggestion-open-tasks-hybrid-friction-cascade.org b/inbox/PROCESSED-2026-05-28-0117-from-.emacs.d-suggestion-open-tasks-hybrid-friction-cascade.org
deleted file mode 100644
index 43bb0ba..0000000
--- a/inbox/PROCESSED-2026-05-28-0117-from-.emacs.d-suggestion-open-tasks-hybrid-friction-cascade.org
+++ /dev/null
@@ -1,80 +0,0 @@
-#+TITLE: Suggestion — hybrid output shape for open-tasks.org Phase C Next Mode
-#+FROM: dotemacs (~/.emacs.d)
-#+DATE: 2026-05-28
-
-* Suggestion
-
-Update =claude-templates/.ai/workflows/open-tasks.org= Phase C → Next Mode to present two outputs together: the existing importance/urgency cascade recommendation up top, plus a 3-option friction filter underneath ranked by =:quick:solo:= > =:quick:= > =:solo:=. The user picks the row that matches their current state.
-
-The current cascade picks one task by importance/urgency (DOING > Active Reminders > Deadlines > priority order). That works when Craig is sharp and has time. It fails when the winner is a partially-blocked decision, hardware-dependent verify, or large refactor — the recommendation gets declined and the cascade falls through. The friction filter sidesteps that mismatch by surfacing tasks Craig can actually finish given a 20-minute window or a flagging-energy moment.
-
-Replacing the cascade entirely (which was the literal first proposal in the dotemacs session) drops the cascade's teeth on deadlines and priority — an =[#A]= deadline-tomorrow task that lacks =:quick:= or =:solo:= would go invisible. The hybrid preserves the cascade's importance/urgency forcing while adding the friction-based override path.
-
-* Why
-
-Two reinforcing effects, both surfaced in the dotemacs session 2026-05-28 (taskaudit + task-review):
-
-1. =:quick:= and =:solo:= tagging coverage is growing. The =task-review.org= workflow already assesses both tags on every review pass, so the friction filter degrades gracefully today (small set, growing over time) rather than catastrophically (empty list if no tags exist yet).
-
-2. The cascade and the friction filter answer different questions. Cascade = "what matters most?" Friction filter = "what shape of task can I actually finish right now?" The hybrid lets Craig pick the question to answer based on the state of his day.
-
-The proposed shape also pairs cleanly with the just-suggested "recommendation at item 1" convention (separate inbox drop, =2026-05-28-0014-from-.emacs.d-suggestion-numbered-options-recommendation-first.org=) — the friction block is exactly the kind of inline-numbered choice list that convention is meant for.
-
-* Proposed Phase C → Next Mode rewrite
-
-Replace the existing "Apply the prioritization cascade in order. Stop at the first matching step:" through the cascade's six steps with two sections:
-
-** Step 1 — Cascade recommendation (importance/urgency)
-
-Apply the prioritization cascade in order. Stop at the first matching step. This is the importance/urgency answer — what matters most right now.
-
-(Steps 1–6 unchanged from current workflow: DOING, Active Reminders, Deadline-driven, V2MOM, Simple priority, All done.)
-
-Present as a single task with the matched cascade step in the reason line.
-
-** Step 2 — Friction filter (effort + autonomy)
-
-Independently of the cascade, scan the open-task set for tasks tagged =:quick:= and =:solo:=. Build three ranked picks:
-
-- Quick + solo: the top task carrying both tags
-- Quick: the top task carrying =:quick:= only
-- Solo: the top task carrying =:solo:= only
-
-Within each row, pick the single task per the same-level tie-breakers already defined (blocks-other-work, recently-discussed, most-foundational). If a row has no tasks, omit it rather than padding.
-
-** Output shape
-
-#+begin_example
-Cascade recommendation (importance/urgency):
-- <task>  — [#priority], <cascade-reason>
-
-If you want lower friction instead:
-1. Quick + solo: <task> — [#priority], ~<est>
-2. Quick:       <task> — [#priority], ~<est>
-3. Solo:        <task> — [#priority]
-#+end_example
-
-The cascade recommendation reads as the "answer" — what Craig probably wants if his day is going well. The friction block reads as the override — what he picks when the cascade winner isn't actionable in this moment. The 3 rows are numbered with item 1 (=:quick:solo:=) as the strongest friction pick, per the numbered-options-with-recommendation-first convention.
-
-* Edge cases
-
-- If the friction filter has zero rows (no =:quick:= or =:solo:= tasks in the open set), omit the friction block entirely and present only the cascade recommendation.
-- If the cascade recommendation and the =:quick:solo:= row are the same task, dedupe — show it once at the top with both labels.
-- If Craig declines the cascade recommendation, drop to the friction block as the natural next prompt (rather than continuing through the cascade) — the friction filter IS the override path.
-
-* Update to "Common Mistakes" section
-
-Add:
-
-- *Skipping the friction block when the cascade recommendation isn't actionable.* The friction block is the override path; don't fall through to lower-cascade-tier tasks if a =:quick:= or =:solo:= task is what's actually needed.
-- *Recommending more than one task in the friction block.* One task per row (quick+solo / quick / solo), not a per-row shortlist.
-
-The existing "Recommending more than one task in next mode" mistake should be tightened to mean the cascade recommendation only — the friction block is by design a 3-row choice.
-
-* Adoption shape
-
-Additive to the existing workflow — cascade logic survives unchanged in Step 1; the friction filter is a new Step 2 with bounded scope. Every project's existing =todo.org= continues to work; tag coverage grows naturally via =task-review.org=.
-
-* Source
-
-Drafted from the dotemacs session 2026-05-28. Adjudicated decision: hybrid (option 1) chosen over literal-replace (option 2) and separate-trigger (option 3). Discussion captured in the session log.