This is an automated email from the ASF dual-hosted git repository.

lukaszlenart pushed a commit to branch vote-mail-skill
in repository https://gitbox.apache.org/repos/asf/struts.git

commit f7844d2e773d36e1178f305535680f969dc2887c
Author: Lukasz Lenart <[email protected]>
AuthorDate: Sat Aug 8 08:03:35 2026 +0200

    docs: record why private@ is on the vote mail
    
    It is there for reach - not every PMC member follows dev@ and PMC votes
    are the binding ones - not for confidentiality. Stating this closes the
    loophole where an agent reads private@ as a confidential channel and
    routes advisory detail through it, which is what the disclosure baseline
    did.
    
    Co-Authored-By: Claude Opus 5 <[email protected]>
---
 .claude/skills/creating-release-vote-mail/SKILL.md            | 11 +++++++++--
 .../specs/2026-08-08-release-vote-mail-skill-design.md        | 11 +++++++++--
 2 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/.claude/skills/creating-release-vote-mail/SKILL.md 
b/.claude/skills/creating-release-vote-mail/SKILL.md
index 6429f8716..d8cb99fe1 100644
--- a/.claude/skills/creating-release-vote-mail/SKILL.md
+++ b/.claude/skills/creating-release-vote-mail/SKILL.md
@@ -66,8 +66,14 @@ solicits votes that are not binding and scatters the tally 
across two lists.
 Cc is not a compromise. If a release manager asks you to include the user 
list, the answer is
 that the `[TEST]` mail already did.
 
-`private@` goes on **Bcc, not Cc**: on the 7.1.1 and 6.8.0 votes it was on Cc, 
and reply-all
-`+1`s landed on the private PMC list.
+**`private@` is on the mail for reach, not for confidentiality.** Not every 
PMC member follows
+`dev@`, and PMC votes are the binding ones, so `private@` is what guarantees 
the binding voters
+see the call. Nothing goes there that could not go to `dev@` — its presence is 
a delivery
+decision, and it is not an exemption from the rule above.
+
+It goes on **Bcc, not Cc**: on the 7.1.1 and 6.8.0 votes it was on Cc, and 
reply-all `+1`s
+landed on the private PMC list. Bcc gives the same reach while keeping the 
tally in one thread
+on `dev@`.
 
 Subject is exactly `[VOTE] Apache Struts X.Y.Z`.
 
@@ -124,6 +130,7 @@ A vote opened on a 404 burns the window before anyone can 
test.
 |---|---|
 | "Voters can't judge fixes they can't see" | They can open the restricted 
bulletins themselves. The vote is not the disclosure channel. |
 | "It's only going to private@, so nothing leaks" | The rule is about the 
vote, not the audience. A companion mail is part of the vote. |
+| "private@ is on the mail already, so it's a channel I can use" | It is there 
so binding voters see the call, not to carry anything `dev@` cannot. |
 | "Cc'ing user@ keeps the vote on dev@ and still informs them" | The `[TEST]` 
mail informed them. Cc splits the tally. |
 | "I verified everything, so I can send" | Verification earns a draft. Sending 
is the release manager's keystroke. |
 | "I'm adding to the boilerplate, not changing it" | Insertion is editing. The 
vote call is byte-frozen. |
diff --git 
a/docs/superpowers/specs/2026-08-08-release-vote-mail-skill-design.md 
b/docs/superpowers/specs/2026-08-08-release-vote-mail-skill-design.md
index 8d8df704c..a9486d9dd 100644
--- a/docs/superpowers/specs/2026-08-08-release-vote-mail-skill-design.md
+++ b/docs/superpowers/specs/2026-08-08-release-vote-mail-skill-design.md
@@ -104,8 +104,15 @@ Bcc: [email protected]
 but the vote stays on dev@ per ASF practice"* — it knew the rule and complied 
halfway, so the
 skill names Cc explicitly rather than saying "don't send it to the user list".
 
-Bcc rather than Cc for `private@` has a reason worth recording: on the 7.1.1 
and 6.8.0 votes
-`private@` was on Cc, and reply-all `+1`s landed on the private PMC list.
+**`private@` is included for reach, not confidentiality.** Not every PMC 
member follows `dev@`,
+and PMC votes are the binding ones, so `private@` is what guarantees the 
binding voters see the
+call. Recording this matters for the security rule below: an agent that reads 
`private@` as a
+confidential channel has a ready-made justification for routing advisory 
detail there, which is
+exactly the baseline failure. Its presence is a delivery decision and nothing 
more.
+
+Bcc rather than Cc has its own reason: on the 7.1.1 and 6.8.0 votes `private@` 
was on Cc, and
+reply-all `+1`s landed on the private PMC list. Bcc gives the same reach while 
keeping the
+tally in one thread.
 
 ### 3. Draft, never send (addresses the send failure)
 

Reply via email to