The externalization

This manual is the Sodimo internal reference. Some of its chapters are specific to Sodimo — the ERP is Sodiwin, the warehouse is on rue du Coin-de-Terre, the CRM pipeline is five stages long because that is how Paul runs his week. Other chapters describe patterns that are not Sodimo-specific at all — the black-box principle, the three design principles, the key-rotation calendar, the vault. Those patterns predate Sodimo and outlive it.

Until now, both kinds of material lived next to each other in the same manual, and the only way to tell one from the other was to read it. That made the manual feel heavier than it is — a reader at Sodimo could not quickly spot which chapters were Sodimo’s own recipe and which were borrowed shape. And a reader outside Sodimo (a future engagement, or someone who helped build one of the patterns originally) had no way to extract the generic material without pulling in a page of French mail-archive retention law along the way.

The externalization is the cleanup. Every chapter now carries a scope field in its frontmatter, and the manual stays exactly as it is for a Sodimo reader — no chapter is removed, no chapter is moved. The split lives in publishing, not in content.

The scope field

Every chapter under src/content/manual/en/ now carries one of three values on the scope field in its frontmatter:

• scope: sodimo — engagement-specific. Describes Sodimo, its ERP, its team, its pipeline, its dashboard. Stays here. Does not externalize.
• scope: leger — reusable pattern. Describes an idea or a workflow that is not Sodimo-particular — the black-box data-vendor contract, the three design principles, the vault. Externalizes verbatim when the second render target is wired.
• scope: both — shared pattern with a Sodimo-specific chapter. The infrastructure, the harness, the mail stack, the accounts playbook. Stays here, and a generic version extracts alongside it.

The counts, as of today:

Forty chapters, one field, three values. The classification was made one chapter at a time and is captured in the annex decisions log.

Why the cut is clean

The split works because the three artefact families below are already distinct in how they are authored and maintained. The scope field only names a boundary that was already there.

Reference templates. The .container files, the chezmoi .tmpl files, the Caddy routes, the Postfix conf snippets. They are code, not documentation — the quadlet is the configuration. Customer-specific values fill in at leger apply time via substitution. Templates describe themselves; no chapter narrates them line-by-line. They live in sodimo/dotfiles and sodimo/harness today and already separate cleanly from the manual.

Runbooks. Ordered multi-system procedures. An operator authenticates against several systems, wires configuration between them, and verifies end-to-end flow. The Cloudflare tunnel setup, the mail-migration cut-over, the leger doctor first-run check. Runbooks reference templates but never inline them. They are written against the pattern, not against Sodimo specifically — the operator substitutes the customer name at run time.

Checklist-policies. Yes/no attestations that a required state exists or a required action was performed. The customer’s Cloudflare account has all four migrated domains visible and active. The vault paper envelope is in the safe. The quarterly key rotation was completed within its window. Discrete state checks, not ordered procedures. A CP references a runbook that performs the wiring; the CP itself only attests that the wiring is in place.

A chapter that reads like ordered steps belongs in a runbook. A chapter that reads like a yes/no attestation belongs in a checklist-policy. A chapter that reads like prose explanation of a design choice belongs in the manual — and carries a scope field telling the reader whether it is Sodimo-specific, a reusable pattern, or both.

What it means for this manual

For a Sodimo reader, nothing visible changes today. The manual reads the same. The chapter order shifted slightly — the baseline-accounts-playbook draft was promoted to chapter 36 and the OpenWebUI / vault / quadlet-reference chapters each moved one slot down — but the content is intact.

The RENDER_TARGET environment variable is threaded through every component that branches on scope. When the sibling build:sodimo and build:leger npm scripts land (the last mile, tracked separately), the same src/content/manual/ tree will produce two static sites: the full Sodimo manual, and a leaner reference that contains only the scope: leger and scope: both chapters, with the Sodimo-specific passages lifted out.

What we are watching

Two chapters to revisit as the extraction firms up:

• 38-vault is currently tagged scope: leger because the paper-envelope recovery pattern is generic. But the chapter text references the specific Sodimo safe, the named admins, and the CNIL employee-consent wording. Before the external render ships, either the text becomes truly generic and stays scope: leger, or the tag moves to scope: both so the Sodimo chapter stays verbatim here while a stripped version extracts.
• 34-mail is tagged scope: both, which is right — Postfix / Dovecot / rspamd / Piler is a generic pattern. But the chapter carries a substantial block on the French CNIL employee-notice and the 10-year mail-retention policy that is a Sodimo choice, not a pattern. The generic extract will need that section stripped or moved to an appendix.

Neither is blocking. Both are flagged in the annex so the next editor knows where to look.

Pipeline status

This page exists to make the state visible. The externalization is a ratchet — once a chapter is tagged, the only change from here is the tag itself moving (e.g., leger → both if a Sodimo specificity surfaces), and the publishing pipeline catching up to the classification that is already in place.