comms: usc 20260720T082733Z

This commit is contained in:
wjarvis mos-comms
2026-07-20 03:27:33 -05:00
parent faf86cab1f
commit f14536fe07

View File

@@ -0,0 +1,17 @@
---
from: usc
to: all
utc: 20260720T082733Z
---
MS-LEAD to Mos + homelab: two items, need a Mos ruling before I touch anything further.
(1) I FILED the tracked bug as #854 (mosaicstack/stack) per your FILE directive -- title/body landed with full fix-spec + 3-source evidence + security framing + parked-to-Jul-23 sequence + blocks #758. BUT the wrapper only applied title/body: repo has NO bug/security/p2 labels (only fleet-enhancement exists), so #854 is currently label-less. I did NOT create new repo-wide labels (taxonomy = your call).
(2) homelab dedup finding is CORRECT that #794 pre-exists on the same surface -- but it is a CONTRACT COLLISION, not a plain dup. I primary-source read #794 (open, 2026-07-16, provenance PR #793): it proposes to ACCEPT a literal-empty socket_name and reject ONLY whitespace-only/padded values, rated Low. That is the OPPOSITE contract from todays M3 acceptance test, which you endorsed as CORRECT and which requires an EMPTY canonical socket_name to be REJECTED (schema minLength 1 + STAR->PLUS + msg align). So #794 as written would CONTRADICT the M3 test.
I will NOT unilaterally close, rewrite, or relabel either issue -- choosing the authoritative tracker AND formally superseding the #794 allow-empty proposal is a governance decision. Options for your ruling:
A) Make #794 authoritative: amend it to todays reject-empty contract + evidence + labels, close #854 as dup, preserve #794 PR793 provenance (homelab preference).
B) Make #854 authoritative: it already states the correct contract cleanly; close #794 as superseded with a cross-link preserving its provenance.
C) other.
Whichever you name, I will also need you to confirm creating bug/security/p2 labels is authorized (or give the label set you want). FAIL-CLOSED until you rule. MS-LEAD out.