Files

n.siegfried 0dbc240900 Wave 7 prep - record the Aug 18 decisions as D1-D10 and amend the waves

Nick answered 21 questions at the wave 6 exit and 11 follow-ups. Seven answers
are new build work, three amend acceptance criteria on tasks already scheduled,
and two close questions without work. None of it had an item ID, so none of it
could be built under CLAUDE.md's first rule.

New items D1-D10 in docs/waves/decisions-2026-08-18.md. A new prefix rather than
widened CR/F/S/A/B/C numbers - those are referenced in documents outside this
repo and CLAUDE.md forbids reinterpreting them. Every D entry names the item it
amends and quotes the criterion it replaces, so a reader of R2 can see what moved.

  D1  sample data returns to the creator                    B7, S7   T7.1
  D2  QA distribution list configured in the SOP            CR-014   T7.6
  D3  side navigation and collapsible sections, not tabs    F6       T7.2
  D4  Urgent surfaces the audited override, never bypasses  CR-003/A1 T7.3
  D5  usage data moves to the admin console                 B7       T7.10 (new)
  D6  material list uploads at SOP configuration            CR-013   T8.6  (new)
  D7  archived projects readable by project admins          B3, C1   T9.8  (new)
  D8  5MB a file, 2GB a project, PDFs and images, one DB    CR-007   T7.7
  D9  Ready for QA appears in Field View                    CR-014   T7.6
  D10 email switched on and off from the admin console      CR-011/14 T7.6, T8.3

Two decisions were mine to make and are recorded as such. D3: the written F6
criterion (no view over two screen heights) and the answer (one long form with
side nav) cannot both hold, so the criterion now reads 'at rest' and sections
collapse by default - tabs hide sections a first-time author does not know exist.
D8: keeping 5MB files in the same database means every encrypted backup carries
them; splitting them out was rejected because a backup without the drawings
cannot restore, so a 2GB per-project ceiling was approved instead.

Also corrected, not amended: CLAUDE.md and IMPLEMENTATION.md X2 both cited
wp-creation-app.js:1962-1972 as the protected logged-override path that T7.3 is
forbidden to remove. Those lines are deletePackage() and clearSaved(). The path
is confirmEarlyRelease() at :1002. Both documents now name it by function so the
reference survives the T7.1 rewrite that is about to move it.

Wave 9 gains T9.9, a sweep of the nine backlog entries that name wave 9 as their
home. Left unscheduled they surface at T9.7, which has no room to fix anything.
The four colour items in it (BL-004/005/008/009) are now approved work.

T9.5's help-tip count corrected from 15 to 18 and dated: three were added during
waves 5 and 6 by tasks reusing the component as designed, each unreachable for
the same reason. Scheduling a broken component late makes every reuse cost more.

Closed without work: the free-text location migration. Every location on record
is sample data because no real list has been loaded, so there is nothing to
migrate. Recorded with the condition that invalidates it - the first real
project - so it is a decision rather than a surprise.

Items: D1 D2 D3 D4 D5 D6 D7 D8 D9 D10
Task: T7.0 (wave 7 prep)

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

2026-08-18 13:29:58 -05:00

12 KiB

Raw Blame History

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

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.

12 KiB Raw Blame History