TT Claude Memory

feedback_confront_richard_tasks_at_creation_time

Properties1
descriptionAuto-creating richard-tasks at A-N amendment time / Q-locking time without IMMEDIATE confrontation (kill-condition + concrete next-action + reconsideration trigger) is anti-pattern. Tasks accumulate as unsignaled obligations Rich hasn't actually signed up for. Per Rich-directive 2026-05-02T~14:00 BST after #219-#222 surfaced as a 12-week (~£25K) Phase-1 build commitment created during ζ-Q2 ξ.+ aspirational uplift A-130 without immediate validation. At richard-task creation time, run a 2-minute "confront" check: (a) does this task have a kill-condition + concrete next-action + reconsideration trigger? OR (b) explicitly defer with reason + reconsideration trigger? OR (c) immediately challenge — does this task actually need to exist? If task can't survive these checks, don't create it. If task is genuinely needed but action-needed-from-Rich-now, surface as decision-question rather than parking as task.

5 min read

Rule: When a Q-locking decision OR A-N amendment OR scorecard outcome creates a richard-task as a downstream commitment, the task must IMMEDIATELY be either:

(a) CONFRONTED with kill-condition + concrete next-action + reconsideration trigger — and ideally spike-validated within ½-1 day before being committed as Phase-1 build budget;

(b) EXPLICITLY DEFERRED with reason + reconsideration trigger (e.g. “Year-2+ when X” or “after S{N} outcome known”) so the deferral itself is a documented decision, not a silent indefinite hold;

(c) CHALLENGED — does this task actually need to exist? Was it auto-created as a side-effect of the lock decision rather than as a genuinely-needed downstream action?

If a task can’t survive (a)/(b)/(c), do NOT create it. If task is genuinely needed AND requires Rich-decision-now, surface as a decision-question in the lock cascade rather than parking as an obligation.

Why: Per Rich-directive 2026-05-02T~14:00 BST: “i am not comfortable with critical tasks being created automatically for me. my preference is that these matters are confronted immediately.”

The pattern that triggered this codification (richard-tasks 219-222, created during ζ-Q2 ξ.+ aspirational uplift A-130 on 2026-05-02T05:20 BST):

richard-taskAuto-created scopeConfronted on 2026-05-02T~14:00Confronted outcome
#219 Cedar Analysis Phase-1 CI integration~3wk Phase-1 buildviability spike S2.10 dispatchedTBC
#220 Catala formal-verification test-suite Phase-1~4wk; “25-statute corpus”scope-mismatch with S8 surfacedDEFERRED until S4+S5+S8 outcomes known
#221 Standards-track engagement Phase-1 (OASIS)~2wk + ongoingno specific TC namedDROPPED — Year-2/3 reconsideration
#222 ICAIL 2027 Singapore paper draft~3wkno topic / co-author / deadline confirmedDROPPED — defer to ICAIL 2029

Net-net: 4 auto-created tasks → after confrontation, 1 spike-tested + 1 scope-pending + 2 dropped. ~£15-20K Phase-1 build budget recovered. Without confrontation, all 4 would have lingered as obligations consuming Phase-1 capacity Rich hadn’t actively signed up for.

The cross-Q pattern (multiple Q closures auto-created tasks similarly):

  • ζ-Q1 κ.θ → tasks 205-208 (utility-tree authoring + AHP session + ASR scenarios + BEA fitness functions)
  • ζ-Q2 ξ.η → tasks 209-212 (graph-RAG Phase-1 substrate spike + Year-2+ roadmap update + Phase-1 cost re-baseline + R-042 risk register update)
  • ζ-Q3 ε.ε → tasks 213-215 (CCO IRI verification + commit-SHA pinning + 9 i-ζ LinkML class authoring + PensionAsset Year-2+ deferral)
  • ζ-Q4 ω.η → tasks 216-218 (vendor Prudhomme alignment file + author 2 NEW SSSOM TSV rows + update iri-verify CI gate spec)
  • ζ-Q2 ξ.+ → tasks 219-222 (the trigger; confronted 2026-05-02T~14:00)

All five clusters were auto-created without per-task kill-condition + next-action validation. Retroactive review of 205-218 is in scope post-codification.

How to apply:

  1. At Q-locking time — when a scorecard outcome locks an option, the lock cascade includes “richard-tasks surfaced”. For EACH task surfaced, immediately apply the (a)/(b)/(c) check. If the task survives (a) — confronted with kill-condition + next-action — author it. If only survives (b) — explicit deferral — author with the deferral reason inline. If fails both AND fails (c) challenge — DON’T create it.

  2. At A-N amendment time — same discipline. The amendment row includes “NEW richard-tasks” — each must have been confronted at lock-time. The amendment row should cite the confrontation evidence.

  3. For aspirational uplifts (A-130-style) — these are particularly risky for the auto-create-without-confront pattern because the uplift’s “Phase-1 commitments” can each spawn a 3-4wk obligation. Confront EACH leg of the uplift separately at uplift-lock time, not just the uplift as a whole.

  4. Retroactive cleanup — when this rule is triggered for the first time (today), retroactively review existing richard-tasks created before the rule was in force. Apply (a)/(b)/(c) to each. Drop / defer / scope-down as appropriate.

  5. Spike-validation as concrete next-action — for tasks that need ~3-4wk Phase-1 build to deliver, a ½-1 day pre-commit viability spike often saves 80%+ of the budget by either confirming viability cheaply or surfacing kill-conditions before commit. S2.10 Cedar Analysis confrontation spike is the canonical example.

  6. Decision-question surfacing for Rich-actions — for tasks that genuinely need a Rich-decision (e.g. “which OASIS TC?”), surface as decision-question in the lock cascade rather than parking as task. Tasks accumulate; decisions get made.

Boundary tests (when this rule fires STRONGLY):

  • ✓ Q-locking decisions creating Phase-1 build commitments
  • ✓ Aspirational uplifts (A-130-style) with 2+ implementation legs
  • ✓ Architecture-options scorecards where chosen option has multi-week downstream work
  • ✓ Acquirer-DD-narrative-load-bearing tasks (Cedar Analysis, formal-verification, standards-track)

Boundary tests (when this rule does NOT apply):

  • ✓ Genuinely operational tasks (e.g. “send Stripe invoice”, “schedule MLP call”) — these are simple Rich-actions, not multi-week build commitments
  • ✓ One-off corrections / cleanups surfaced during /review-plan or audit
  • ✓ Tasks already in-flight (someone is doing them) — only auto-creation is the issue

Codification trigger: Rich-directive 2026-05-02T~14:00 BST: “i am not comfortable with critical tasks being created automatically for me. my preference is that these matters are confronted immediately. richard-tasks 219-222 are best dealt with immediately”. Acted on by:

  • #221 + #222 DROPPED (Year-2/3 reconsideration; defer to ICAIL 2029)
  • #220 DEFERRED (decision pending until S4+S5+S8 outcomes known)
  • #219 → S2.10 viability spike dispatched
  • New rule codified (this memory)
  • Retroactive review of 205-218 scheduled

Related memories:

  • feedback_surface_alternatives_before_collapsing_synthesis_to_baseline.md — analogous “confront at decision time, not later” discipline applied to spike kill-conditions
  • feedback_logging_contract_closure_within_same_session.md — analogous “act immediately, not later” discipline applied to T-file authoring
  • feedback_v2_ik_ias_build_plan_sovereign.md — “do not rush or reorder Phase-1” discipline; this rule complements by preventing auto-created Phase-1 obligations that haven’t been validated

Forward integration:

  • Refined-prompt v3.6 → v3.7 candidate: add Step 13 — “RICHARD-TASKS CONFRONTATION DISCIPLINE — at Q-locking time, every NEW richard-task surfaced must immediately have kill-condition + concrete next-action + reconsideration trigger. If unable, drop the task or defer with reason. Surface decision-questions for Rich-actions rather than parking as tasks.”
  • Plan §1.7 cross-cutting disciplines — add this as 4th codified discipline alongside universal-production-pipeline-sequence + alternatives-first + logging-contract-within-session.
  • Q-locking cascade pattern: amendment row should cite richard-task confrontation evidence per task.

Graph View

Backlinks