docs(ops): reconcile Slack Stage 1 spec with main after #69/#72 - #73
Conversation
…ity label created Three corrections found reviewing this PR against origin/main (d343ec6): - §7 described Stage 2 as blocked on PR #69, which merged as 25130a4. continue-on-error is gone from both audit steps; the gate can go red. Rewritten so the technical blocker reads as cleared and the remaining gate is the operational one: nobody is subscribed yet, so a summary would post into empty channels. - Dropped the unverified "one critical and six high alerts" clause. Open Dependabot alerts today are 2 low + 1 medium, 0 high, 0 critical, and the PR #61 alert count is not reconstructible. The load-bearing fact — audit printed high, job concluded success — stands on its own. - §4 said the "security" label does not exist. Matt has created it. Also documents why §3 keeps the "statuses" default while §4 strips it: Vercel reports via commit status, not as an Actions workflow, so statuses is the only path by which a failed deploy reaches #flashstack-ci. No workflow files touched.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
mattglory
left a comment
mattglory
left a comment
There was a problem hiding this comment.
Approving. Verified independently: #69 merged 14:51, #72 merged 18:23, so the ordering claim is right. I created the security label well before #72 opened. On the 'one critical and six high' number: I actually did verify that exact figure live earlier this session via gh api repos/mattglory/Flashstack/dependabot/alerts (critical:1, high:6, low:2, medium:5) — it was real at the time, not fabricated. My guess is your token can't reach that endpoint (same shape as the branch-protection 404 you flagged earlier), which is why you couldn't reproduce it. Pulling it was still the right call — the doc is stronger resting on the reproducible claim in the security.yml comment than on a number only I could see. Merging.
This branch was successfully deployed
2 participants
Follow-up to #72. I found these reviewing #72 against
origin/main, but you merged it before I could push — no complaint, the diff you approved was correct on its own terms. These are three statements that went stale between the branch being cut and it landing. Docs only; one file.1. §7 said Stage 2 was blocked on #69 — #69 is merged
#69 landed as
25130a4, before #72 merged.continue-on-erroris gone from both audit steps, so the gate can go red and a Stage 2 summary of it can be trusted.Rewritten so the technical blocker reads as cleared, and the remaining gate is named for what it actually is — operational: nobody is subscribed yet, so a summary would post into empty channels. A summary nobody receives isn't a working integration, and I'd rather the doc say that than leave a merged PR standing as the blocker.
The before/after diagram is kept (it's the reason the decision was made) but relabelled
BEFORE #69/NOW (#69 on main, 25130a4).2. Dropped an alert count I can't substantiate
§7 said the PR #61 run concluded success "while GitHub showed one critical and six high alerts."
I can't reproduce that number. Open Dependabot alerts today are 0 high and 0 critical, and the alert state at the time of that run isn't reconstructible now. It's also the same shape as the measurement I already retracted on
Flashstack-ajv.2.7, so I'm not shipping it a second time.The load-bearing fact doesn't need it and is unchanged: the audit printed
Severity: highand the job concluded success. That's in thesecurity.ymlcomment you already merged in #69, and it stands on its own.Added in its place: the gate is green right now because the tree is genuinely clean (root audit 0 vulnerabilities, web audit 0 high / 0 critical) — not because the check can't fail. Worth stating so a future reader doesn't re-litigate it.
3. §4 said the
securitylabel doesn't exist — you created itYour approval comment on #72 says so directly. Text updated to match.
Also: why §3 keeps
statuseswhen §4 strips it§3's bullet list explained every default it drops but never mentioned
statuses, which it silently keeps — an unexplained inconsistency with §4, which strips it explicitly.There is a good reason, so it's now written down: Vercel reports through the commit-status API, not as an Actions workflow, so
workflows:{…}can't see it andstatusesis the only route by which a failed preview or production deploy reaches#flashstack-ci. The cost is per-commit status chatter on PRs. The doc now names the tradeoff and the opt-out, so if it turns out noisy in practice the decision is already framed rather than rediscovered.No command in §3 or §4 is changed by this PR.
Validation
docs/ops/SLACK_INTEGRATION.md, +28/−12. No workflow files, noCODEOWNERS.Still outstanding and unchanged by this PR:
/github subscribe list featuresfrom both channels. That output is an ephemeral, invoker-only Slack message — I can't read it from the repo or the API, so it has to come from you. It's the last thing gating Stage 2.🤖 Generated with Claude Code