Staging is not the pain; the last fifty feet are - the correct floor lay-down,
shark cage or conduit tree instead of material picked at will by whoever is
closest. The Kitting & MIMO section gains:
- Delivery Building / Floor / Sector: the SAME dependent pickers CR-004 built,
through the same fillLocSelect (which learned an optional field-map instead
of being copied), reading the same project location lists, storing PATHS.
A parallel free-text location vocabulary is exactly what CR-004 removed;
none was added.
- A free-text detail field for the specifics ("Shark cage 7, conduit tree C"),
persisted as delivDetail.
- deliveryLoc, the composed display string (labels off the shared lists, then
the detail after a dash) - which is what the CR-011 email already reads
(kitting_body preferred deliveryLoc from day one, with mimoLoc as the
pre-CR-012 fallback) and what the package printout now carries as its own
Delivery Location row.
Verification (each probe run alone): kitting_check.py extended to 26/26 (the
delivery selects are asserted to offer the SAME option list as the CR-004
trio, values persist as paths, the printout carries the composed value);
kitting_notify_check 17/17 now asserting the mail carries CR-012's composed
value, not the fallback. Regression: locations_check 58/58.
Items: CR-012
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
A kitting status change (detected on the upsert, which is how the browser and
the offline outbox both save) emails the package's distribution list
(distributionIds) plus its warehouse owner (kitOwnerId - CR-010's default
recipient), minus the actor, deduplicated. The mail matches the house
convention - greeting, one line of what happened, the deep link, the
automated-message footer - and says old status, new status, who, and the
delivery location (deliveryLoc when CR-012 lands at T8.4; mimoLoc today).
The link opens THAT package (X1), same wp_link as every other mail.
No burst: an unsent notification for the same package and recipient is
REWRITTEN to the newest transition instead of joined by a sibling - three
rapid changes leave one row per recipient saying where kitting ended up,
while the audit history keeps all three, uncoalesced. Found by the probe and
fixed: a row held while email was OFF stayed 'skipped' forever; the change
that finds email ON now promotes it to pending and schedules it - otherwise
turning the gate on silently orphaned everything coalesced before it.
The gate is T7.6's gate, reused - the probe greps that no second email flag
exists anywhere. Off by default; admin-only (403 for anyone else); every send
terminates at the in-process SMTP sink with count and recipients asserted; no
real mail leaves this branch. Send failures ride the shared notify.deliver
path whose failure handling qa_gate_check pins.
Verification (each probe run alone): NEW tests/kitting_notify_check.py 17/17
(the sink is imported from qa_gate_check - one sink implementation, not two).
Regression: qa_gate_check 40/40.
Items: CR-011, D10 (X1 honored)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
