proposal to revert color mode default

openspec/changes/revert-colour-mode-default/design.md

@@ -0,0 +1,73 @@
+# Design
+
+## Context
+
+Commit `tpypxmkn` set `*DefaultBRColorMode: None` in the shipped PPD (plus a
+"Modified by this repo" comment), documented the rationale in three README
+sections, and synced a spec requirement *Colour output is saturated by
+default*. Its own message already conceded that a `VividNoCIE` candidate
+printed identically to `None`. The decisive new evidence (see proposal.md —
+Why) is that `None` also prints identically to the **vendor default** `Normal`:
+before/after prints through the container are indistinguishable, while the
+same document through the Mac's local driver is clearly more saturated. The
+washout therefore originates in the server-side PostScript path (no client-side
+colour management), not in the printer's `UseCIEColor` switch, and no
+server-side lever is currently known.
+
+The same commit also added two features that this change does **not** touch:
+the six `APPrinterPreset` entries in the PPD and the `PRINTER_OPTIONS`
+mechanism in `entrypoint.sh`.
+
+## Goals / Non-Goals
+
+**Goals:**
+- Restore the vendor `*DefaultBRColorMode: Normal` so the shipped PPD deviates
+  from Brother's original only where the deviation earns its keep (the
+  presets).
+- Remove every saturation claim from README and spec; document the tested
+  limitation honestly, including the local-driver recommendation.
+- Encode the "no untested PPD deviations" decision at spec level so the
+  change cannot silently regress.
+
+**Non-Goals:**
+- Finding a server-side fix for the saturation gap (needs printer-side
+  investigation and physical test prints).
+- Changing the `APPrinterPreset` mappings, `PRINTER_OPTIONS`, the entrypoint
+  or the Containerfile.
+- Re-testing colour modes on the physical printer — the user already performed
+  the decisive comparison.
+
+## Decisions
+
+- **D1 — Revert the default, don't merely re-document it.** Both defaults
+  print identically, so reverting carries no regression risk, and it restores
+  the "vendor original plus marked additions" property of the PPD. Keeping
+  `None` with corrected docs would leave a deviation whose stated rationale
+  no longer exists.
+- **D2 — Spec delta = REMOVED + ADDED.** A bare removal of the disproven
+  requirement would leave no record of the decision. The ADDED requirement
+  (*Vendor colour-mode default is preserved*) is testable (installed-PPD
+  grep, `lpoptions`) and prevents future untested deviations from becoming
+  the default.
+- **D3 — Rewrite the troubleshooting section, don't patch it.** Symptom stays;
+  the cause section now states the tested facts (`None` vs. vendor default: no
+  difference; `Vivid`: no difference; `BRPrintQuality`/`TonerSaveMode`: no
+  difference) and locates the gap in the conversion path; the remedy becomes
+  "use the local driver for colour-critical output", with the printer-menu
+  hints (Toner Save off, `BRMediaType` matching the media) as the only
+  remaining adjacent levers. The `lpoptions` check now expects `*Normal`.
+- **D4 — Minimal PPD edit.** Exactly two changes: the value line back to
+  `Normal` and the three-line default comment removed. The presets comment
+  block stays, so `diff` against the vendor original shows only the presets.
+- **D5 — Split verification.** Container-side checks (installed PPD default,
+  `BRColorMode` option list, override via `PRINTER_OPTIONS` still working) are
+  automated in the integration task; the colour verdict itself is physical and
+  stays with the user, stated as such in the tasks.
+
+## Risks / Trade-offs
+
+- Someone later re-attempts a "colour fix" by re-deviating the PPD →
+  mitigated by D2 (spec) and the honest README section (D3).
+- Readers of the old README may believe the container solved washout → the
+  corrected sections now say explicitly that it does not; the only behavioural
+  change of this revert is a PPD default that prints identically.