D48. The plan's document: one model for the app, Word and PDF; Word written by hand, the PDF printed by Chromium (15 Oct 2026) · For developers

Revised on 16 Oct 2026 by D52: the document shows a version of the plan or its working copy; its head says the version and the history of the versions; the changes since the validated version replace the retouches as what reads in place and as Word’s tracked changes; the notes for the client are Word comments; the version property no longer counts change requests or approved retouches. The plan gets the app’s Document view, whose Export button opens a choice between .docx and PDF, since many agencies use Word’s comments to communicate. That view is « la vue que le client signe »: the same plan in sections that fold, its properties at its head, a retouch read in place, before and after; its PDF is the « Bon pour production » attached to a purchase order.

One model, data without layout (@elabora/core plan-document/model.ts planDocument(project, { date }), format elabora/plan-document/1), read by every renderer: the exports, the app’s Document view (another session), and later the review link that shows the plan alone. From plan.json, its approval and its change requests, course.json for the module’s properties, and the screens for the retouches. At its head: the module’s title, the status (« Bon pour production » when approved, « Modifié depuis sa validation », « Brouillon », « Brouillon, à valider de nouveau » once validated before), the version (the approval’s reference, the change requests accepted and the retouches approved, with their last dates), « Validé par » (the approval’s name and day), the module (duration · SCORM 1.2 · the LMSs of delivery.lms). Then Cadrage (business goal, audience, prior knowledge, spaced reminders, waivers), Objectifs, Séquence (each item, its kind, objectives, description, voice-over, sources), Textes validés (by item, « Mot pour mot » for a verbatim text), Évaluations (options with the right ones and their feedback; a numeric answer with its tolerance, feedback and expected mistakes), Sources, and a colophon with the plan’s id, its fingerprint and the day. Numbers are the document’s own (item 2, text 2.1, question 5.1); every element keeps its plan id as its anchor. Texts are the plan’s Markdown and the same as rich-text data (plan-document/rich.ts), so no renderer parses Markdown.
Its words are in the module’s language, French or English (plan-document/words.ts; another language gets the English words until it has its own), dates and numbers by Intl in that language, whatever the computer’s.
Never who wrote it. The document never says that an AI wrote the plan, which would bias a reviewer who should validate the substance. It names nobody as a writer at all: not the author of a draft, of a change request or of a retouch (Word’s tracked changes are signed « Retouche dans le module »); only those who approved (the approval, approved retouches, waivers). A test looks for « agent », « Claude », « AI », « IA » in the model, the page and the .docx.
A retouch (rule A5; replaced by D52: the changes since the validated version read in place the same way, and retouches are plain edits of the plan) not reviewed yet reads in place: the validated text and the module’s wording as one text, words deleted and inserted (diffRich: word by word when the two texts have the same paragraphs, lists and cells, otherwise the whole text replaced; a short word kept between two changes goes with them), with « Retouché le … · à revoir avec le client ». The plan has no date for the client’s next review, so none is said. A retouch approved since says « Retouche approuvée par … le … » under the text the plan took.

Word:

Written by hand, in the core (plan-document/docx.ts, about 370 lines; omml.ts for maths): the parts of a WordprocessingML package, which @elabora/node zips with createZip (D8: the same project and day, the same bytes). Weighed against docx (9.11.0, MIT, compatible with Apache-2.0): 20 MB unpacked with jszip (MIT or GPL-3.0), nanoid, xml, xml-js and hash.js, random ids and the current time in its output unless each is overridden, and a runtime dependency of a package that must stay without I/O; what the document needs of Word is small (paragraph and character styles, two tables, numbering, bookmarks, revisions, a footer), and tracked changes and bookmarks are exactly where a writer’s abstractions get in the way.
Made to be commented. Word’s own Title and Heading 1 to 3 (the navigation pane shows the sections, items and questions), named styles of its own (Elabora Body, Elabora Meta, Elabora Option…), no direct formatting but the plan’s own emphasis; tables only for the properties and the plan’s own Markdown tables; maths as Word equations (OMML converted from the MathML temml writes for the module); A4, a footer with the title and the page; the module’s language on the text (fr-FR, en-US) for Word’s spelling. A pending retouch is a tracked change: Word shows the validated wording deleted and the module’s inserted.
Bookmarks for comments to come back. Every objective, item, validated text, question and source is inside a bookmark named after its plan id (wordBookmarkName: el_ then the id, « - » as « _ » and « _ » as « _u », since Word’s names allow only letters, digits and « _ »; plan ids have no lower case, so planIdOfBookmark reads them back without ambiguity). Not done now, the idea: an import of the client’s .docx reads word/comments.xml and where each comment’s range starts in word/document.xml, finds the bookmark that encloses it, and gives the comment its plan element, as the review’s comments are placed in the sources for the author’s AI (D43); a comment outside every bookmark goes to its section. Word keeps bookmarks while the client edits and comments; one is lost only when the client deletes the whole element, and the comment then goes to the section. Whether the client accepts the tracked changes in their copy does not matter: nothing is read back from the text.
Checked by the unit tests as a package (every part well-formed with its prefixes declared, a content type for each part, relationships that lead somewhere, every style and numbering used defined, unique annotation ids, every bookmark closed, one bookmark per element, deletions holding delText only), and, where they are installed, opened by python-docx and read back by pandoc (its maths as the same LaTeX, its tracked changes with their author); by hand with LibreOffice 24 (layout, equations, tracked changes). Not against ECMA-376’s XML schemas: they are not shipped with any package we use, and a validator would be a new development dependency; Word itself was not available here.

PDF:

The page printed by Chromium rather than a PDF writer in JavaScript. One HTML page (plan-document/html.ts) with its fonts inline (Inter and JetBrains Mono from @elabora/fonts, OFL) and an @page rule for A4, its margins and its footer (CSS page-margin boxes: the title, « Page n / N »), so a print needs no header template and no option but preferCSSPageSize, the background, a tagged PDF and an outline from the headings (PLAN_PDF_PLAYWRIGHT, PLAN_PDF_ELECTRON). The same page is the --format html export and can be the review link’s. A writer such as pdfkit (0.20.2, MIT, 10.5 MB with fontkit and linebreak) would need a second layout of everything the page lays out (rich text, lists, tables, a retouch’s marks, page breaks) and of maths, which it cannot draw from MathML.
The same PDF from the app and the command line. The app prints the page the engine gives (planDocumentPage) with webContents.printToPDF(PLAN_PDF_ELECTRON); the command line prints it the same way with Elabora’s Electron when the app is installed (D26): a browser worker’s main process loads the page in an offscreen window of PLAN_PDF_WINDOW and calls printToPDF(PLAN_PDF_ELECTRON) (printWithElectron), since Electron’s DevTools protocol has no Page.printToPDF and Playwright’s page.pdf fails there (tried on 16 Oct with Electron 44: « ‘Page.printToPDF’ wasn’t found »). Without the app, Google Chrome, Microsoft Edge or Playwright’s Chromium print it (printPlanDocument, Playwright’s page.pdf, PLAN_PDF_PLAYWRIGHT). Both call finishPlanPdf, which sets the PDF’s dates to the document’s day (Chromium writes the time it printed). The same page and settings in the same Chromium give the same bytes: the app’s « Exporter ▾ › PDF… » and elabora plan export --format pdf run with its Electron give the same file (the app’s try:plan-document checks it), and an end-to-end test prints twice; another Chromium version may move a line, never the content. Without any Chromium the command says so and offers --format docx or html. The page holds a Content-Security-Policy that lets it fetch nothing (its style, fonts and images are inline), and a print through Electron that has not ended after 60 s stops.
Skia embeds the variable fonts of @elabora/fonts as Type 3 fonts: the text stays selectable and searchable (each glyph maps to Unicode), but some viewers draw Type 3 less finely than TrueType.

Where: elabora plan export [dir] [--format pdf|docx|html] [--out <file>] [--date YYYY-MM-DD] [--json] (default dist/<course id>-plan.<format>); MCP elabora_export_plan_document { format } (into dist/, for an author who asks their agent to send the plan); @elabora/node/plan-document exportPlanDocument, writePlanDocument, readPlanDocument, planDocumentPage, planDocumentWord, printPlanDocument; the engine’s planDocument, planDocumentPage and exportPlanDocument.

What the data does not hold yet, and the app’s mockups show: a second approver for one side of the plan (approval.by is one name), the number of learners (« 2 300 apprenants »: nothing in course.json), and the date of the client’s next review. Each would be a field of the format (approval.cosigners[] { by, scope }, course.json audienceSize, approval.nextReview), still to be decided; the document says what it can meanwhile.

The document’s day is the author’s (16 Oct 2026): the default date of planDocument (and so of elabora plan export) is the day in the computer’s time zone (localDay), not UTC’s, which said yesterday between midnight and 2 a.m. in France; the approval of the plan, a retouch, a decision and a translation’s approval are stamped with the same day, so that the app’s Sommaire and the document’s head say the same date. --date and PlanDocumentOptions.date still win.

Revisit if: clients send back their commented .docx (the import above, then possibly w:commentsExtended for replies), a client needs PDF/A (static font instances instead of the variable files, and Chromium’s PDF/A is not offered: a post-processing step), a language beyond French and English asks for its own words, or Word shows a fault the tests here could not see.