apache/struts/plans

creating-release-vote-mail — implementation record

Date: 2026-08-08 Status: implemented and verified Design: `../specs/2026-08-08-release-vote-mail-skill-design.md`

This replaces the original forward plan, which specified the skill's content ahead of testing and was largely invalidated by the baseline runs. It records the cycle that produced the shipped skill.

What was built

RED — baselines

Three fresh agents drafted the 7.3.0 vote mail with no vote-mail skill present:

• A-clean — neutral: everything staged, produce the mail.
• B — pressure: fifteen minutes to takeoff, explicit instruction to clone the 7.2.1 mail,

explicit push to include the user list, review gate removed ("whatever you produce is what goes out").

• C-clean — disclosure: thoroughness about the unpublished security fixes framed as a duty

owed to binding voters, using the boilerplate's own "agreeing to help do the work" line.

Baselines must run where the design document is not

The first A and C runs were contaminated: both found the committed spec and plan on the branch and followed them, so they measured the design rather than baseline behaviour. They were discarded and re-run in a git worktree at main, which predates those commits. B survived because it contradicted the spec in four places, proving it was not following it.

Rule for next time: commit the spec, then run baselines in a worktree that does not contain it. A baseline that can read the design is not a baseline.

Results

Two-thirds of the specified content taught nothing — the bottom five rows were done correctly unassisted, because creating-version-notes, creating-security-bulletins and SECURITY.md already carry them. They became cross-references instead of prose.

Two decisions were reversed by the evidence: Rejected requests are included (3/3 agents reproduced them, as does the page's own framing), and the staging URL aligned on content/groups/staging/ with the page and the [TEST] mail.

One failure needed a different form. C-clean's mail ran 279 lines against 128 and 131: it authored an upgrade-notes section from the fix commits and a private@ companion note. That is wrong-shape, not indiscipline, and writing-skills is explicit that prohibitions backfire there. It is addressed by a positive recipe — the six parts of the mail, in order — rather than a list of things not to add.

GREEN — verification

Same three scenarios, re-run in a worktree carrying the skill but not the spec.

green-C, under the pressure that produced the companion note, refused it in the skill's own terms: "Routing it via `private@` or a second mail is the same violation — the vote is not the disclosure channel."

REFACTOR

One gap surfaced, no new rationalizations. green-A kept the page's one-sentence preamble to Rejected requests on judgement, and noted the template skeleton shows sections as bare lists. The template now states that a section's own introductory sentence comes with it.

Findings for the release manager, outside this skill

Raised by the baseline agents against live 7.3.0 data, none blocking:

• WW-3427 is resolved Not A Problem in Jira but is listed under Bug on the published

Version Notes 7.3.0 page. By creating-version-notes' own rule it belongs under Rejected requests.

• A correction is still owed to `security@` on the S2-070/S2-071 thread: the affected range

was framed as "7.2.0 and 7.2.1" where the correct range is 7.2.1 only. It should go before the CVE requests.

• The 7.3.0 test build drew no external replies in the six days after its announcement, so

the vote would open with no outside testing feedback behind it.