Plan integration follow-on: the low-energy day is a ladder — a step-up offered after a completed floor task, never led with

[NetDevAutomate]

Origin

Three owner verdicts on rubric row 3b (docs/architecture/plan-integration/receipts/now-rubric-2026-09-16.md, interactive walkthrough 2026-09-20) recorded the same finding beside a yes; the receipt names them one 0.5.x theme:

• (b) — familiar recall leads, the sit-with sits beneath it: "once I had done this, if it went well I would like the option to then take on more but not lead with the larger task."
• (c) — on the shipped screen (due recall first, micro teach-back beneath): "With an energy score of 3/10, the initial task should be light to give confidence and hopefully by doing so energy, if the task is successful then offer the user the learning task which has a higher energy score."
• (d) — the generic starter is the no-plan floor: "if this went well, a successful task often increases confidence and energy so give the user the opportunity to work on the live struggle." — recorded as the top rung: after a completed floor task, re-offer the deferred repair itself as the step-up, an option the learner takes while the win is fresh, never restored as the default.
• Also recorded: the capability numbers are subjective (3/10 vs 4/10) and the demand thresholds coarse by construction, so the ladder carries more weight than the threshold; and the owner reads a teach-back as higher demand than a plain recall although both are low in the demand classes — the ordering already agrees, the classes govern deferral not order.

What exists today (from the code on feat/energy-demand-body-double a4503a48 — verified, not recited)

• The engine is a snapshot: build_now_plan(energy=…) ranks once for the energy it is given. cli/_now.py prints that snapshot. The Today card (web/static/js/components/today-panel.js) fetches /api/now once, in init(), with no energy, and no handler re-requests it after an action — startAction, pickUpParked, dismissParked never re-plan.
• The floor tasks emit no outcome the engine can read: the starter's only door is studyloop progress "one tiny recall loop" -t <topic> -c learning; a due recall's door is the same kind of progress write; the body double's door opens a session. Nothing says "went well".
• What the step-up would re-offer is already computed and carried: energy_deferred (milestones), energy_deferred_repairs (repairs, with energy_demand and required_capability), the body-double proposal, and — for a learning row that is also due — the micro teach-back as the alternate beneath the recall (rubric 3b (c) as shipped).

What to build

1. An outcome signal from the floor task. After the primary's evidence command / Today action completes, one deterministic signal: the recorded progress row (it exists) plus a re-ask of energy ("that went — how is your energy now?", 1–10), stored with the session. No inference of "went well" from the model; the learner says so, once, in one number.
2. A re-plan keyed on it. build_now_plan runs again with the new energy and the completed action excluded; the Today card and the CLI (studyloop now --after <action> or the session's wind-down) show the next rung, not a fresh snapshot that repeats the same floor.
3. The rungs, lowest first, each already a candidate the engine knows: the familiar due recall → the sit-with (body double) → the micro teach-back on the recovered concept → one tiny concrete move on the deferred material (sibling issue) → the deferred repair itself, offered as an option with its demand stated, never as the default, and only after a completed rung.
4. Never lead with the larger task. The first primary of a low-energy day is unchanged by this issue (rubric 3b (a)–(e) yes); the ladder only ever adds a next offer after a completed one.

Constraints: deterministic (a stored energy number, a completed action, the existing deferred lists); rubric-testable (a D-16 row plants row 3's world, completes the floor task, re-asks energy 5/10 and expects the deferred repair offered as an option beneath the plan's next milestone; at 3/10 again, expects the next-cheapest rung and no repair); still a proposal (no status change, nothing auto-started); the no-plan golden byte-identical for a first call with no completed action.

Out of scope

• Changing the first primary of a low-energy day, or restoring the repair as a default at any energy below its demand.
• Inferring the outcome from transcript content or a model judgement.
• Deriving the "tiny concrete move" itself — sibling issue.

Acceptance criteria

• RED tests: a completed floor task plus a re-asked energy yields a re-plan whose primary is the next rung; the deferred repair appears as an option only when the re-asked energy meets its required_capability, and never as the primary while another rung exists; a first call with no completed action is byte-identical to today.
• Today card re-plans after an action and asks the one energy question; CLI has an equivalent.
• Rubric rows added and scored by the owner (D-16).
• Docs: docs/study-plans.md "Plan-aware now", docs/web-ui-guide.md, docs/cli-reference.md (now).

Definition of Done

• Full unit suite green; just lint; just typecheck; golden byte-identical.
• Council review of the RED and the arbitration before merge (one commit per accepted finding).
• Spec delta (openspec/specs/active-learning-decisions) and design updated in the same change.

_Milestone renamed 0.6.0 → 0.5.x on 2026-09-21 (owner rule): follow-on work ships as 0.5.N patch releases until every issue outstanding at v0.5.0 is resolved. Where the linked receipt says "0.6.0", read "the follow-on milestone"._

[NetDevAutomate]

Moved to milestone 0.6.0 on 2026-09-23 as part of defining the initial MVP.

The owner defined the MVP as the release that closes 0.5.x, and its blocker as the learning-tier feed (the mentor never writes what a session produced: zero writer calls in 143,973 historical messages). Asked which failure would embarrass him more in a stranger's hands for two weeks — a lesson not read aloud, or a mentor session whose teach-back never reached tomorrow's recommendation — he chose the latter.

This issue is a real build with its definition of done intact; it is the first work of the next line, not dropped. Nothing in its body changes.