D50. The plan reads as an outline: parts, short names, a duration estimated from the screens, and screens that follow their items (15 Oct 2026)

Revised on 16 Oct 2026 by D52: reordering a validated plan is a plain edit of its working copy, shown as a move since the validated version (no change request, no window); draft_plan is now write_plan. The rest of this entry is kept as it was decided.

The app’s Plan view was a table where, for the « Nietzsche » module (20 items, 5 objectives), the eye found nowhere to land: the objectives repeated word for word in the widest column, the module’s seven parts nowhere, descriptions cut mid-word, three to five window heights. A study of 15 October drew four ways on that plan; the outline was chosen (the module’s card on the left: its goal, public, duration and objectives each named once; the parts and their items one line each, opening in place) and a board of cards for reorganising, both to be reordered by dragging. What the format and the core give them:

• items[].part and objectives[].short, optional, written by draft_plan like the rest of a draft and translated with the plan (units item.<id>.part, objective.<id>.short). A part is a run of consecutive items with the same part (an item without one continues the part before it), up to 200 characters as a section’s title; a plan without parts takes those of course.json, the sections that hold its items’ screens. short names an objective in three to five words beside its number; without it, the views cut the statement. Both rather than a separate list of parts or a second objective title: an item carries its part as a storyboard row carries its chapter, and moving it to another part is changing one field.
• One number: a plan item is numbered by the screens that cover it (3.1, 7.2–7.4); before they exist, by its part and its rank in it. The app does it; nothing is stored.
• A duration estimated from the screens (@elabora/core project/duration, screenEstimates, and seconds on each screen of the engine’s summary): the words a learner reads (the screen’s units as translation sees them, the plan’s texts and questions it shows by reference) at 150 words a minute (reading to learn, Carver’s gears, and the narration’s pace), or the voice when it says more (its recordings, or its text at 15 characters a second), then 45 s a choice question or decision, 60 s a numeric question, 90 s a free object, at least 10 s a screen. The views add it up by part and for the module, in grey and rounded (roundedMinutes: to the minute, a module over a quarter of an hour to five minutes), never per item at rest, and say nothing before the screens exist. « Nietzsche » is about 35 minutes where its title page says 45: an estimate to compare with, not a promise.
• Screens follow their items (project/plan-order, followPlanOrder), in the same change as the plan: when items change order or part, through draft_plan (a move in the patch, another part, a plan written whole in another order) or a change request applied (apply_change_request). A section whose screens cover items of one part only belongs to that part: it moves with the part, and is renamed with it when it was called as the part was and the part takes a name no part had (items moved into an existing part leave their section’s title alone, so that no two sections share one; a plan without parts counts its items’ sections’ titles as their parts, so that renaming a part the app shows from course.json renames its section). A screen that covers a single item goes with it: after the screens of the item before it in the same part, else before those of the item after it in the same part, else after the item before. A screen that covers several items, or none, stays: the others keep their order around it; so does the last screen of a section, which never ends empty. A section’s part is the one called as the section is, else the part most of its screens’ items belong to. Of the screens out of order, the fewest move (the heaviest run in the plan’s order stays). A plan without parts moves no section. Nothing moves while the items keep their order and their parts. draft_plan and apply_change_request say what moved (moved: screens, sections, renamed), and the CLI too. The plan’s numbers being the screens’, a plan reordered without its screens would show 5.1, 4.3, 5.2: the module follows the plan, as A1 already asks every screen to cover it.
• Reordering a validated plan is a change like any other (D5): the app’s drag or « Monter » and « Descendre » open the change prefilled (« Déplacer le point 4.3 après 5.1 »), the author adds why and records it as a change request of theirs; the module’s screens move when it is applied. Never a silent move of the contract, nor a refusal: the author sees at once what the move means. Revised by D52 (16 Oct 2026): the move is written at once, the screens with it, and the diff marks it moved (« c’était le point 4 »); no window, no change request.
• Who wrote the draft is not said (D35 amended): the view says « Brouillon, jamais validé », not « Brouillon écrit par Claude ». A reviewer who reads that an AI wrote it wonders whether a person did, when what matters is to validate its substance. What serves the author stays: the last change an AI made to the draft, traced on the items it touched with « Annuler ». Revisit if: authors want to keep the module’s order apart from the plan’s (a section deliberately out of the plan’s order), parts need more than a title (a goal, a duration announced to the client), the estimate drifts from what learners take (measured times from a review or an LMS), or clients want to see who wrote the first draft in the proof dossier.