# Decisions — August 18, 2026 Approved by Nick Siegfried during wave 7 planning, in answer to twenty-one questions raised at the wave 6 exit and eleven follow-ups. These are **new items**, not reinterpretations of existing ones. `CLAUDE.md` forbids renumbering or reinterpreting `CR`/`F`/`S`/`A`/`B`/`C` IDs because they are referenced in documents outside this repo, so everything decided here gets its own `D` prefix and each entry names the existing item it amends. Where a `D` item changes an acceptance criterion, the original criterion is quoted and the replacement is stated, so a reader of the R2 document can see exactly what moved. Ten items. Seven are new build work; three amend criteria on work already scheduled. --- ## D1 — Sample data returns to the creator - **Amends:** `B7` (`T7.1`), `S7` (`T9.4`) - **Surface:** `html/` `wp-creation-styles.css` opens with `body.embedded .embed-hide { display: none }` — framed, the creator hides its own header, its sample-data controls and its analytics button. `T7.1` dissolves the frame, so "framed" stops being a state and those three controls need a home or a deletion. Decided: **the sample-data control comes back and is visible.** That collides with `S7`, which reduces four sample-data affordances under three names to one. It is not a contradiction: `S7`'s complaint is that there are four of them, that they are named inconsistently, and that one sits a click from live project data. A single, clearly named, confirmed affordance on the creator satisfies both. `T9.4` owns making it the only one; `T7.1` owns making it visible. **Done when:** the creator's sample-data control is reachable on the unframed page, and `T9.4` still ends with exactly one affordance app-wide. --- ## D2 — The QA distribution list is configured in the SOP - **Amends:** `CR-014` (`T7.6`) - **Surface:** `server/` + `html/` `CR-014` says entering `Ready for QA` "emails the assigned QA representative and the QA/QC members named on the work package". Asked who should receive it, the answer was **the QA group only, and the group is set up once during SOP configuration as a dropdown** — not typed per work package. That makes the recipient list SOP configuration, which means a wizard field, which means `T7.6` acquires a dependency on the wave 5 SOP wizard it did not have. Rejection routing was also settled: **a rejection notifies the work package owner and the distribution list**, not only the person who submitted it. **Replaces the `CR-014` done-when** "entering it sends email to the QA rep and named QA/QC members" with: - the QA distribution list is chosen in the SOP wizard from project members - entering `Ready for QA` emails that list and nobody else - rejection emails the work package owner and the same list --- ## D3 — The creator stays one page: side navigation plus collapsible sections - **Amends:** `F6` (`T7.2`) - **Surface:** `html/` `T7.2` as written says "section tabs or an equivalent that shows one coherent group at a time", with the done-when "no single view exceeds roughly two screen heights at 1440px". Asked to choose, the answer was **one long form with navigation down the side** — and then, when the height conflict was raised, the decision was delegated: *"do what you recommend is best to UX."* **Recommended and adopted:** one page, persistent side navigation, and each section collapsible with only the current one open by default, plus an `Expand all` control for people who would rather scroll straight through. Tabs were rejected because they hide sections a first-time author does not know exist; an uncollapsed long form was rejected because it is the ~4,700px page `F6` exists to fix. **Replaces the `F6` done-when** "no single view exceeds roughly two screen heights at 1440px" with "no single view exceeds roughly two screen heights at 1440px **at rest**" — that is, with the default collapse state, which is the state the page is actually in when it loads. Expanding everything deliberately is allowed to exceed it. **Replaces** "toggled-off sections have no tab" with "toggled-off sections have no entry in the side navigation", and "tabs are keyboard operable and follow the tab pattern with `aria-selected` and arrow keys" with "the side navigation is keyboard operable, marks the current section with `aria-current`, and each section header is a real disclosure button with `aria-expanded`". --- ## D4 — Urgent surfaces the audited override; it does not bypass the gate - **Amends:** `CR-003` (`T6.2`, shipped) and `A1` (`T7.3`) - **Surface:** `html/` Asked whether an `Urgent` package should be issuable while a constraint is still open, the first answer was "maybe, with a constraint active". The concern raised back: silently bypassing the gate would undermine the delay-documentation use case that is the entire business justification for the constraint workflow — a constraint log that can be shown to have been skipped stops supporting a notice of delay. **Answer: yes, surface the audited path instead.** So `Urgent` does not create a new bypass. It makes the existing logged-override path — `confirmEarlyRelease()` — prominent on an urgent package, so the release still produces a history entry with who, when and why. **Adds to the `T7.3` done-when list:** - an `Urgent` package with an open constraint offers the logged override in the primary action position rather than behind a secondary control - taking it still writes actor, timestamp and reason to history - no code path releases a constrained package without writing that entry --- ## D5 — Usage data moves to the admin console - **Amends:** `B7` (`T7.1`) - **Surface:** `html/` - **New task:** `T7.10` `docs/reference/creator-frame.md` §2b records that five of the nine colliding script globals are usage analytics implemented twice, and that the wizard's `showAnalytics` has no caller because the button lives on the creator. Asked where it belongs now that the creator is a page in its own right, the answer was **the admin console**. That deletes one of the two implementations rather than merging them, and takes an operator-facing control off a package-authoring screen. **Done when:** analytics is reachable from `admin.html`, no analytics control remains on the creator or the wizard, and only one of the two implementations survives. --- ## D6 — The material list uploads at SOP configuration - **Amends:** `CR-013` (`T8.5`) - **Surface:** `server/` + `html/` - **New task:** `T8.6` `CR-013` is explicit that there is no parts catalog: line items are free text, because Nate's spreadsheet and the master material workbook have not been supplied (`IMPLEMENTATION.md` section 8). Asked whether to wait for them or build the upload path now, the answer was **upload now**. This is `CR-005` applied to a second list. The location upload built at `T5.4` — paste or file, validated, rejected rows reported with the source line, editable afterwards — is the pattern to reuse rather than re-invent. **This does not open the out-of-scope parts catalog.** Section 7 defers "full material request and inventory system, including the parts catalog and warehouse integration". A project-scoped list uploaded by the project is not a catalog, carries no inventory levels and integrates with nothing. If the diff grows a stock count, it has crossed the line. **Done when:** a material list uploads during SOP configuration, `T8.5` line items select from it, free text still works when the list is empty, and no inventory or warehouse field exists in the diff. --- ## D7 — Archived projects are readable, by project admins - **Amends:** `B3` (`T5.2`, shipped), `C1` - **Surface:** `server/` + `html/` - **New task:** `T9.8` Archiving exists for both projects and work packages, and the server already refuses writes to an archived project. What it does not do is show them: an archived project leaves the launcher and there is no way back to it. Asked who should be able to open one, the answer was **project admins only**, arrived at after considering everyone. So this is a listing and a read-only render behind a role check, not a new archive mechanism. **Done when:** a project admin can list and open archived projects, everything renders read-only, a non-admin sees no archived projects at all, and no write path is reachable from the read-only view. --- ## D8 — Upload limits: 5MB a file, 2GB a project, PDFs and images, one database - **Amends:** `CR-007` (`T7.7`) - **Surface:** `server/` + `html/` Four answers, taken together: | Question | Answer | |---|---| | Per-file size limit | 5MB | | Accepted types | PDFs and images | | Where files live | the same database as everything else | | What caches offline | only the work packages assigned to that person | The follow-up was the consequence: 5MB files in the same database means every encrypted backup carries them, and a busy project reaches a gigabyte without anyone noticing until a restore is slow. Splitting the files out was **rejected** on the grounds that a backup which excludes the drawings is a backup you cannot restore from. **A per-project ceiling of 2GB was approved instead**, with a warning before it is reached. **Adds to the `CR-007` done-when list:** - a file over 5MB is refused before upload, with the limit stated - a type outside PDF and image is refused before upload, with the accepted types stated - a project at 80% of 2GB warns, and at 2GB refuses with a message naming the ceiling - the running project total is visible where uploads happen - offline caching covers the requesting user's assigned packages, not the whole project --- ## D9 — Ready for QA appears in Field View - **Amends:** `CR-014` (`T7.6`) - **Surface:** `html/` `CR-014` puts the new state on "a dashboard view or filter". Asked whether the field needs to see it too, the answer was **yes, it shows in field view**. **Adds to the `T7.6` done-when list:** Field View shows which packages are in `Ready for QA`, and the state is legible at 390px without colour being the only signal. --- ## D10 — Email is switched on and off from the admin console - **Amends:** `CR-011` (`T8.3`), `CR-014` (`T7.6`) - **Surface:** `server/` + `html/` All new outbound email in this plan ships **gated off** — a standing instruction from the wave 5 kickoff, verified against a capture sink rather than a real mail server. Asked who turns it on, the answer was **the admin controls email**. That makes the gate a stored setting with a console control, not an environment variable somebody edits on the server. Existing hardening constraints stand: the SMTP password lives in the environment and nowhere else, and no customer IP appears in an email body. **Done when:** the send path is complete and exercised against a capture sink, the default is off, an administrator can turn it on from `admin.html`, a non-administrator cannot, and changing it is written to the audit log. --- ## Closed without work **Free-text location migration.** Work packages created before `CR-004` recorded their location as typed text, and those values match nothing in the structured list, so they do not roll up. The question was whether somebody should match them by hand or leave them as history. Answer: *"It is just sample data at this point so that is ok."* No migration is built and no item is opened. If this plan ever runs against a database with real pre-`CR-004` packages in it, this decision has to be revisited before `T6.4`'s rollups can be trusted — noted here so that is a decision and not a surprise. **The off-palette colours.** `BL-004`, `BL-005`, `BL-008` and `BL-009` were each deferred by their own wave on the same grounds: fixing them changes a rendered colour, and the wave that found them was forbidden to change one. Together they are the help centre's separate 52-colour palette, two dialogs styled by inline attributes, a second brand blue and a ninth amber. Asked whether to unify them or leave them, the answer was **change them**. They stay in wave 9 under `C4`, but they are now approved work rather than four open questions. --- ## What this changes in the wave table | Wave | Was | Now also | |---|---|---| | 7 | `B7` `A1` `CR-015` `A2` `A6` `CR-014` `CR-007` `B6` `S1`(creator) `F6` | `D1` `D2` `D3` `D4` `D5` `D8` `D9` `D10`(half) | | 8 | `CR-009` `CR-010` `CR-011` `CR-012` `CR-013` | `D6` `D10`(half) | | 9 | `CR-008` `CR-017` `S6` `S7` `C1` `C2` `C4` | `D7`, and `C4` now carries the four approved colour items | Three new tasks — `T7.10`, `T8.6` and `T9.8`. Everything else is an amended criterion on a task that already existed.