feedback_no_forward_calendar_projection_in_plans_or_conversation

When planning future work, expressing build-plan structure, or discussing what comes next: do NOT project forward calendar positions, clock-time, wall-clock, or hour-thresholds. DO use Claude-effort estimates + dependency wiring.

Banned (forward calendar / clock-time projection)

1. Calendar slots in plans: “Q4 2026” / “M7-M8” / “~Sprint 1-2 (M7-M8)”
2. Forward calendar in conversation: “by next month” / “next week” / “in 6 months” / “Friday”
3. Total batch wall-clock projections: “wall-clock limited by X” / “~12-18h wall-clock”
4. Decision Matrix fallback conditions expressed in hours: “if Phase 1 cumulative >8h → cut-out + spawn R9”

Allowed (Claude-effort sizing)

1. Forward Claude-effort in conversation: “~3-5h Claude migration” / “~30-45 min Claude”
2. Total Claude-execution estimate in launch-prompt header: “Estimated ~12-18h Claude across N phases”
3. Per-phase Claude durations in launch-prompts: “Phase 1 ~3-4h Claude embedding A/B”

Past-tense dates always fine (audit + recency + provenance)

• Historical references: “A-282 landed 2026-05-22T18:49 BST”
• Recency in conversation: “6 hours ago” / “earlier this session” / “yesterday”
• Audit metadata: frontmatter lastmod: / date: / arch-state §15 [YYYY-MM-DD] timestamps / commit timestamps
• Memory filename date-suffixes (when used as disambiguators)

The cut

Calendar / clock-time FORWARD PROJECTION = banned. Claude-effort sizing = allowed. Past-tense dates = always fine.

Why

The Sprint 1 misfire was triggered partly by “Phase-1 Sprint 1 / M7-M8 ~Q4 2026” reading as a near-term calendar slot when actually it was a sequence position in Phase-1’s build calendar that hasn’t arrived yet. Forward calendar projections create false urgency / false deferral / “we’re 6-9 months early” framing. Under operator-first (A-277), TT is solo + run-and-profit not exit-chase — no external calendar to coordinate against. Dependency-state + sequence position are the planning axes that matter; calendar dates aren’t.

How to apply

• Build plans (BUILD-PLAN.md per repo + master-plan + sprint-backlog): use step-N + depends_on: notation. Phase + Milestone concepts stay as functional groupings. Calendar slots (M7-M8 / Q4 2026 / Sprint N) go.
• Cross-repo coordination: explicit cross-repo dependency wiring (ik-step-22 depends_on: v2-step-12). No “Stage 1 ends M6, Stage 2 starts M7” calendar staging.
• Decision Matrix fallback conditions: replace hour-thresholds with non-temporal triggers (e.g., context-budget %, dependency-resolution event-count, substrate-correcting finding count).
• “What’s next?” answer: query unblocked steps across all per-repo BUILD-PLAN files. NOT “what sprint are we in?”.
• Pre-dispatch check for execution batches: verify all depends_on: items are done. NOT verify calendar slot reached.
• Conversation prose: use event-anchored references for past (“after the Sprint 1 misfire”, “before A-277 lock”) + Claude-effort for forward sizing (“~3h batch”). Avoid calendar projection.

Related

• feedback-surface-phase-calendar-when-authoring-phase-implementation-launch-prompts — precursor memory; its UNDERLYING discipline (pre-dispatch gate) stays valid but its LANGUAGE needs reframing from “check master-plan calendar” to “check dependency-state”. Update in the build-plan migration sweep.
• Q1-Q5 brainstorm sketch (locked this session): per-component step-N numbering + simple depends_on: schema + customer-signal-as-steps + Phase + Milestone as functional groupings.
• feedback-keep-meta-prompts-short-for-paste-workflows — keep planning artefacts low-friction; over-engineered date-laden plans amplify friction.