timeboxing: asked ≠ started — a question to the Schedular is answered, never turned into a session (#316–#320)

[hugolytics]

Linked issues

• Map MAP: Rebuild FateForger on the four-move architecture #157 · tickets timeboxing: AskQuestion intent and Asked outcome — question is a decision in every session state #316 slack: focus demotes to the receptionist, and the two ownership rules land in the proposal contract #320 timeboxing: describe(snapshot) from StageCard, and the host answers an Asked outcome through planner_agent #317 timeboxing: the no-day short-circuit becomes a judged no_session state — start, question, cancel #318 eval: question-vs-start and question-vs-facts on the timeboxing surface, n=8 threshold 7, with a break-it check #319 (all wayfinder:task) · routing half fix(slack): the planning card's own thread is resolved before sticky focus (recovered work) #310 · found on the way receptionist: _follow_up_plan decides follow-up timing by '?' in the message — a CLAUDE.md violation on the reply path #321 timeboxing interpreter: the pro pin runs away to 16384 completion tokens on ~3–5% of calls, so one typed turn in ~25 fails as SurfaceIntentError #325
• Branch: feat/asked-not-started

The problem

03:43 today, under the Admonisher's planning card ("Not added yet"), Hugo typed "Is it planned?" The card's interpreter read it correctly — a question, decision: none (logs/llm_io_20260905_010643_9295.jsonl, record 3) — and the reply was still handed to timeboxing_agent, which opened a fresh five-stage session and posted the Stage-1 day-confirm card. No model was consulted for that.

Two faults. The routing half — sticky DM focus outranking a planning card's ownership of its own thread — landed as #310. This branch is the other half: the Schedular had no door that does not start a session. derive_timebox_intent returned StartSession() for any text before a day was locked, with no model asked, on the docstring's claim that "there is nothing to decide about"; a committed session offered only provide_facts or revise, and the interpreter had no none, so a question to the agent that just planned the day was coerced into a fact or a revision (#287 is the memory-side echo of that same coercion).

Hugo's expectation, stated: either the timeboxing agent that just did the session answers, or the Schedular that can pull my calendar sees there is no planning session and says so. The receptionist already refers "is a session planned?" to planner_agent — the mechanism existed and was never reached.

Spec: docs/superpowers/specs/2026-09-05-asked-not-started-design.md. Map: #157. Tickets: #316 #320 #317 #318 #319.

What lands

Asked is not started, and asked is not revised. A question changes nothing in the session it is asked of — and, after the final review, nothing one layer up either.

• Kernel (timeboxing: AskQuestion intent and Asked outcome — question is a decision in every session state #316): AskQuestion intent and Asked outcome. kernel.turn returns Asked before applying or saving anything; the snapshot the next load sees is byte-identical (tested by full model_dump() equality). question is offered in every open state; cancelled still offers nothing. The user's words reach the answerer verbatim — the schema carries no text field for the decision, so the model cannot paraphrase them.
• A session row is created only by an intent that starts one (timeboxing: the no-day short-circuit becomes a judged no_session state — start, question, cancel #318, final review's Critical): the kernel loads non-creating first; no row + question → in-memory snapshot; no row + cancel → TurnFailed(nothing_to_cancel); a cancel on an existing day-less, artifact-less row is refused the same way. Before this, "never mind" as the first words in a DM wrote cancelled onto the thread-blind DM key and every later typed turn died with the generic sentence.
• The no-day short-circuit is a judged state (timeboxing: the no-day short-circuit becomes a judged no_session state — start, question, cancel #318): no_session offers start / question / cancel; the interpreter decides. Only an empty opening turn (a bare command) starts without asking. The AST guard proves the one remaining StartSession() return sits under an if on user_text — and was shown to fail on the reverted code. cancel before a day is auto-start: a restart during the opening turn leaves a half-open, day-less session that blocks for an hour and cannot be cancelled or expired #299's option 3, landed here.
• The host answers (timeboxing: describe(snapshot) from StageCard, and the host answers an Asked outcome through planner_agent #317): describe_session is the prose renderer beside the Block Kit one, over the same StageCard (day, stage, context, decided items by owner, the open question with its why_needed and offered options, the commit receipt). An Asked outcome is sent to planner_agent — the calendar's answerer, the same one the receptionist refers to — as the described session plus the verbatim question; the "thinking…" card becomes the answer. No card transition, no panel sync, no relabel, no activity mark, no ladder cancel, no row. A failed answer is one in-thread line and one metered error (surface_intent/answer_failure), never a retry, never a session start.
• Focus demotes to the receptionist (slack: focus demotes to the receptionist, and the two ownership rules land in the proposal contract #320): fix(slack): the planning card's own thread is resolved before sticky focus (recovered work) #310 demoted to the channel default, a no-op when that default is itself timeboxing_agent. The two general rules are now in docs/architecture/proposal_object_contract.md §7: a surface owns the thread its root posted, over focus; an agent that owns a workflow offers question in every state its surface allows.
• Eval (eval: question-vs-start and question-vs-facts on the timeboxing surface, n=8 threshold 7, with a break-it check #319): tests/integration/test_eval_timebox_question.py, @slow, n=8 / threshold 7, on the production interpreter client (build_autogen_chat_client("timeboxing_agent") → the deepseek pro pin as .env has it), no temperature pin. 19/19 cases, every positive ≥ 7/8, zero wrong decisions. The break-it check as first specified was unpassable and the eval said so: with question in allowed_decisions, the label alone reads a pure interrogative as a question (7–8/8 with the paragraph stripped). What the paragraph actually carries, and what the check now strips — asserting the flip (wrong outnumbering right), not the absence of the right answer: a question carrying a fact on a committed session ("did you move lunch? I sleep 00:30-08:30" → fact 8/8 with it, question wins without), and a fresh-session calendar question ("what's on my calendar tomorrow?" → AskQuestion 8/8 with it, StartSession 8/8 vs 0/8 without — the incident, reproduced on demand). A draw is redrawn once only when its failure carries a transport __cause__; a wrong decision is never redrawn. Every case whose words appeared in the paragraph was reworded. The final commit, a47e0bb, is from the peer session admonish-1-34 whose Task 5 agent measured the fresh-session flip; its report is task-5-report-second-agent.md in the (git-ignored) SDD workspace.

Verification

• Subagent-driven: five tasks, each a fresh opus implementer and a fresh opus task review; two fix rounds (Task 1: the state-matrix guard covered 2 of 6 states; Task 4: no_session had been placed before the cancelled check, and the AST guard passed on the reverted code). Whole-branch review (opus): 1 Critical, 2 Important, 3 promoted Minors — one fix wave, scoped re-review clean. Every ruling and every deferred minor is in the ledger, .superpowers/sdd/2026-09-05-asked-not-started/progress.md (git-ignored; ask for it).
• Offline suite on this tree, rebased on 7ef1013: 3096 passed, 10 skipped, 1 xfailed, 1 failed — tests/e2e/test_slack_handoff_flow.py::test_slack_handoff_sets_focus_and_forwards, pre-existing on main (asserts the *agent*\ntext format fix(slack): a reply on a proposal thread is read against the proposal (#88 increment one) #281 removed; bisected by a peer to a71f213, theirs to fix).
• Every new test was written failing first; each fix was mutated to confirm the test catches it (documented per task in the reports).
• No live Slack run. Reproducing the incident needs a real timeboxing session first to pin sticky focus, then a typed question under a planning card — that is the rubric below, for the human.

Commands run (from .worktrees/asked-not-started):

PYTHONPATH=src ../../.venv/bin/python -m pytest tests -m "not slow" -q
# 1 failed, 3096 passed, 10 skipped, 101 deselected, 1 xfailed   (rebased on 7ef1013)
set -a; source .env; set +a
PYTHONPATH=src ../../.venv/bin/python -m pytest tests/integration/test_eval_timebox_question.py -m slow -q -p no:cacheprovider
# 18 passed (n=8 per case), 4 transport retries in 144 draws, model deepseek/deepseek-v4-pro-0813:nitro
git merge-tree --write-tree origin/main HEAD   # exit 0: clean against 7ef1013

Found on the way, not fixed here

• timeboxing interpreter: the pro pin runs away to 16384 completion tokens on ~3–5% of calls, so one typed turn in ~25 fails as SurfaceIntentError #325 — the pro pin runs away to 16384 completion tokens on ~3–5% of interpreter calls (reasoning_tokens=73, $0.043 each). Every miss in 272 eval draws was this, never a misjudgement. ~1 typed timeboxing turn in 25 gets "I couldn't read that reply". Pre-existing, invisible to the unit suite. A peer session (admonish-1-34) measured a reproducible skew toward fresh-session questions — 9 retries in 152 draws (5.9%): fresh questions 5, fresh starts 3, committed 1 — not an absolute; that bears on where a max_tokens cap lands.
• receptionist: _follow_up_plan decides follow-up timing by '?' in the message — a CLAUDE.md violation on the reply path #321 — the receptionist decides follow-up timing by "?" in message.content, a CLAUDE.md violation whose path this branch widens (bounded to a 5-vs-15-minute delay).
• The live bot (started 03:06) logged google_gemini-3.6-flash for both interpreters at 03:43 while .env carries no google id; .env was modified at 15:59. models: the direct-API side runs on the decided pins, the judge reads them, and an agent never changes one #323/docs(agents): the timeboxing instruction files stop naming gemini as the model they talk to #324 have since cleaned the last gemini references — confirm the running process picked up the pins after a restart.

Deferred, by ruling (in the ledger, none a merge gate)

A question turn is not idempotent (never saved, so a Slack redelivery re-asks — forced by the byte-identical invariant; the answer edits one message in place). The nothing_to_cancel card still draws Cancel/Retry. An interpreter that raises no longer marks activity (it is already a loud SurfaceIntentError). strftime('%A') in the description is locale-dependent. The start gloss in QUESTION_PARAGRAPH has positive evidence but no break-it of its own. Map #157's compounding ask: the second read-only intent is cheaper for describe_session, and still pays a label in seven hand-built _display_context tuples — a shared suffix and a _READ_ONLY_INTENTS tuple would make it near-free.

Before merging (Hugo)

• Restart the bot from a clean checkout at this branch, stock scripts/demo.py start, and confirm the log names the pins, not gemini.
• Run one real timeboxing session in the DM to completion (this pins user_focus to the Schedular), then type "Is it planned?" under a planning card. Expected: the receptionist → planner_agent answers from the calendar in the card's thread; no Stage-1 card.
• In the DM with no session open, type "what's on my calendar tomorrow?". Expected: an answer, no session opened, no timeboxing_session_states row created, and the planning nudge for that hour still fires.
• In the DM with no session open, type "never mind". Expected: "There is no planning session to cancel yet." — and the next message still works.
• After a committed session, type "when is deep work?" in its thread. Expected: an answer from the receipt; the session's revision unchanged in timeboxing_session_states.
• Decide timeboxing interpreter: the pro pin runs away to 16384 completion tokens on ~3–5% of calls, so one typed turn in ~25 fails as SurfaceIntentError #325's fix (a max_tokens cap on the interpreter client, or re-measuring high effort on it) — an agent changes no pin.

🤖 Generated with Claude Code