[vpintorico]

What is the current state, and why does it need to change?

Release blocker and release sign-off summaries still run as Zapier Zaps 596 and 597. They post a daily Slack message to release-{platform}-{x-y-z} and Zap 597 rewrites the release PR sign-off checklist. Jira is becoming the only issue data source (MCRM-155). This repo should hold the shared action, the same way it holds post-merge-validation and publish-slack-release-testing-status. The scheduled callers stay in metamask-extension and metamask-mobile (sibling draft PRs).

What this PR does

Adds the composite action .github/actions/release-slack-summaries.

• blocker-summary ports Zap 596.
• release-validation ports Zap 597.
• Zap message text is copied through craft-596.mjs and craft-597.mjs. A thin adapter turns Jira issues into the bug shape those scripts already expect (name, url, closed as "true"/"false", assigneesLength, labels).
• Teams come from topology.json on MetaMask/MetaMask-planning (fetchMetaMaskTeams, same contents URL and base64 decode). There is no hardcoded project-to-team map.
• Release numbers come only from open release/X.Y.Z pull requests into stable. The action refuses to interpolate any other version into JQL.
• Jira access is POST /rest/api/3/search/jql only.
• The action does not mint GitHub tokens. The caller uses .github/actions/get-token and passes github-token and planning-token in.

Source snapshot: metamask-zaps@dc70d6792cbaf9d99f39982868baf7f090dea0af.

Inputs

Input	Default	Role
mode	required	blocker-summary or release-validation
platform	required	extension or mobile
github-token	required	Caller-supplied token for the client repo
planning-token	required	Caller-supplied contents: read token for MetaMask-planning
slack-bot-token	required	Existing SLACK_BOT_TOKEN. Used only when dry-run is false
jira-base-url	https://consensyssoftware.atlassian.net	Read-only search
jira-email, jira-api-token	required	POC read-only Jira credential
jira-release-blocker-jql	empty	Base blocker JQL. Per release the action appends AND cf[14565] = "V"
jira-regression-jql	empty	Optional base. Empty uses the v10 proposal default and appends AND cf[16946] = "V"
topology-jira-project-field	jiraProject	PROPOSED topology field (array or string)
test-channel	empty	When set, Slack posts go only to this channel, and the action refuses every PR body write
dry-run	true	Job summary only
allow-pr-write	false	Zap 597 checklist rewrite. Ignored when test-channel is set
github-tools-repository, github-tools-ref	action repo / ref	Same checkout inputs as the other composite actions

Safe defaults

• dry-run defaults to true. The run builds the Slack message and any checklist diff into the job summary. It does not call Slack and does not PATCH a pull request.
• allow-pr-write defaults to false. A checklist rewrite runs only for release-validation, when dry-run is false, allow-pr-write is true, and test-channel is empty.
• test-channel, when set, is the only Slack target. Real release-* channels are not used. The action also refuses the pull request body write, even if allow-pr-write is true, and logs test-channel is set. Refusing pull request body writes.... Zap 597 still rewrites those bodies during the parallel run, so a test-channel run must not write.
• An empty jira-release-blocker-jql logs OPEN and skips the blocker section. The action does not invent a filter id or a Release Blocker field id.
• A missing Slack channel (channel_not_found, not_in_channel, is_archived) is logged and that release is skipped.
• A release PR whose title is not exactly Release: V throws, so that release is not posted. The job fails after the other releases are processed.

Deviations from the agreed interface

Documented here so the sibling callers can follow them.

1. Extra inputs jira-regression-jql and topology-jira-project-field, so the Found-in query and the topology field name stay overridable. Empty regression JQL uses the v10 proposal (issuetype = Bug, Found in cf[16946], project list from proposal §4) and logs that this default is OPEN.
2. github-tools-repository and github-tools-ref, matching the other composite actions in this repo.
3. No longer a deviation. test-channel limits Slack to that channel and also refuses the pull request body write, even when allow-pr-write is true. The run logs the refusal. This matches the contract: test-channel runs never write PR bodies, because Zap 597 still rewrites them during the parallel run.
4. Blocker links are Jira issue-navigator URLs. The saved filter already limits status, so the "outside the contributing list" link uses that same per-team URL. A second all-status JQL would need the unknown Release Blocker field id.
5. An unmapped blocker project is shown as its project key (registry sentence). It is also appended to the checklist as - [ ] {KEY} when the checklist text changes, because the rewrite has no topology name to use. Writes still require allow-pr-write, and they are skipped entirely when test-channel is set.
6. The Zap's bug.platform error was a ReferenceError. The message now interpolates platform.
7. Team names are escaped before they are placed in the sign-off regular expression, so a parenthesis in a checklist label cannot throw. Current topology names have no metacharacters.
8. The 596 bot username is the Zap title with trailing newlines removed, so chat.postMessage accepts it. The message body is unchanged.
9. The teams fetch sends a User-Agent. The URL, bearer token, and base64 decode are the Zap's.
10. The five-release cap is .slice(-5) after the ascending version sort from release-versions-extraction.js (newest five). The extraction script has the sort; the cap lived in the Zapier loop. Release validation still keeps only versions ending in .0.

OPEN

• Blocker filter. jira-release-blocker-jql is empty until the "MetaMask Release Blockers" filter exists. The step logs OPEN and skips the blocker section.
• Release Blocker field id (cf[NNNNN]). Regressions flagged Yes with a Release Number other than this version are not excluded until that id exists. Pass the exclusion in jira-regression-jql once it is known.
• Regression query. The default Found-in field cf[16946] and the §4 project list are the v10 proposal. Confirm both, or pass jira-regression-jql.
• Topology field. Name and format are PROPOSED: jiraProject, array or string. The code accepts either. Teams without the field do not map, and the message uses the Zap's own "needs a team label" / registry sentences.
• Two teams listing the same Jira project. The first team in topology order is used, and the run logs OPEN.
• Testing Plan link (597-4). The first docs.google.com/spreadsheets URL in the PR body. Logged when missing.
• PR-rewrite condition (597-11). The Zapier path-B rule ("updated body does not exist") reads oddly. This port writes only when updatedReleasePrBody is produced, which is when the checklist text changed. A set test-channel still skips that write.
• Unmapped project keys on the checklist. See deviation 5. Confirm before allow-pr-write is turned on.
• Slack. chat:write.customize for the Zap bot name and icon, link_names for @release-owner-*, and who invites the existing bot to each new release channel are still untested. The action sends username, icon_emoji, and link_names: true.
• Jira credential. The POC token is Victor's, added by him in the release-notifications environment. Replace it with a scoped read-only token before cutover.
• Callers. This PR does not add release-slack-summaries.yml to the product repos. Until this merges, those drafts should pin this branch. Placeholder ref: cursor/release-slack-summaries-a324.

Checks run locally

• yarn eslint on the touched action files passed.
• node --test for gates.test.mjs passed, including the case where allow-pr-write is true and test-channel is set: the write is refused.
• Earlier full yarn test and yarn lint passed on the previous commit. This change is covered by the gate test above.