install-smoke: remove Slack alerting (public repo must not hold prod secrets)

[justinhelmer]

Removes the Slack-alert path from the release install-smoke workflow. The smoke checks stay and still fail a broken release loudly as a red check; Slack paging lives in polylanedotcom's private backstop, which already has the access this public repo intentionally lacks.

What & why

install-smoke.yml (added in #65) alerted #polylane-notifications on failure via op run --environment against the 1Password "Prod" environment. That environment can only be resolved by a service account with access to Prod's vaults — and granting this public repo's CI service account that access would expose the whole prod secret set to an OSS repo. Per the decision in #polylane-notifications, that access is withheld by design, so the alerting can't (and shouldn't) work here. Remove it rather than leave a permanently-failing alert step.

I confirmed before removing that the missing access is the only reason it failed and that the pattern itself is sound: the identical op run --environment 4r6j… succeeds from polylanedotcom's private workflow (control run) and fails only here — the difference is purely the service account, which is exactly the exposure we're declining to create.

Changes

• install-smoke.yml: remove the Install 1Password CLI and Alert the internal channel steps, the SECRETS_ENVIRONMENT_ID / ONEPASSWORD_CLI_* env, and the test_alert dispatch input. The two real-install legs (API-digest and checksums.txt fallback) are untouched.
• release.yml: drop secrets: inherit from the install-smoke call — no secrets are used anymore.
• Header comment now documents the split: detection here (red check on the release run, within minutes of publishing), paging in the private backstop (polylanedotcom's install-bytes runs the same real-install legs daily and holds Prod access legitimately).

Decisions

• Keep the smoke, drop only the alert. The check's core value — catching a release that breaks the installer contract (the v0.2.20 class of failure) within minutes — is fully retained as a red check on the release workflow, which is watched. What's lost is only the push notification, and that's covered by the private daily backstop.
• Don't relocate paging into this repo by other means (e.g. a repo-scoped webhook secret). Any Slack-post credential in a public repo's CI is the same category of exposure; the private repo is the correct home for it.

Validation

• The two smoke legs' assertion logic was re-run locally against the real production installer pinned to v0.2.20 after the edit — both still pass (sha256 verified + install completed + sign-in stop; fallback verified via checksums.txt with the API blocked).
• grep confirms no Slack/1Password/op/secret references remain in the workflow beyond the explanatory comment; YAML lint clean on both files.
• Post-merge receipt: a workflow_dispatch run of install-smoke (version=0.2.20) green with no alert step present.

🤖 Generated with Claude Code

[claude]

LGTM: Slack alerting is cleanly removed, the smoke check still fails loudly, and the backstop-lives-elsewhere claim checks out against live evidence.

Verified, not just taken on faith:

• Head/base: local checkout head 574fed5 matches the PR API exactly; true merge-base with origin/main (93cc6fb) equals main's current tip, so the base isn't stale. Diff vs merge-base: 2 files, +19/-74 (install-smoke.yml, release.yml) — matches the API's reported stats exactly.
• Removal is real: grepped install-smoke.yml before/after for slack/webhook/alert/1password/op-run/secrets tokens. Before: the Install 1Password CLI step, the Alert the internal channel step (op run --environment ... slack.com/api/chat.postMessage), SECRETS_ENVIRONMENT_ID/ONEPASSWORD_CLI_* env, the OP_SERVICE_ACCOUNT_TOKEN secret, and the test_alert dispatch input. After: zero code hits — the only remaining mentions are in the explanatory header comment. release.yml's secrets: inherit on the install-smoke job call is gone too, so the reusable workflow now runs with no secrets at all.
• Safety property holds: read the full post-PR YAML control flow (not just the diff). Both real-install steps still run set -euo pipefail, capture output under set +e/set -e, then gate on three grep -qF ... || { echo ::error::...; exit 1; } assertions apiece. Nothing wraps them in continue-on-error or if: always(), and release.yml still calls install-smoke as a plain needs:-linked job with no error-swallowing — a broken release still exits non-zero on the job, still shows as a red check on the release run. The alerting steps that were removed were purely additive (if: failure() || inputs.test_alert); nothing about their removal touches this control flow.
• The "who fails, who pages" claim: confirmed against live GitHub state, not just the PR description.
  • coreplanelabs/cli is a public repo (GET /repos/coreplanelabs/cli → "private": false); coreplanelabs/polylanedotcom is private ("private": true).
  • polylanedotcom has .github/workflows/install-bytes.yml: a daily-cron (schedule: "15 17 * * *") job that runs the same real-install legs plus served-bytes checks, alerts #polylane-notifications via op run --environment 4r6j7zk3wmoppaotpeds6xg63m on failure — the identical environment ID cli's pre-PR code referenced.
  • The PR body's linked "control run" (polylanedotcom run 32790697826, workflow_dispatch, actor justinhelmer) is real and did succeed (conclusion: success, 2026-08-24T23:44Z) — not a fabricated link.
  • Pulled the actual cli install-smoke run that motivated this PR (run 32786303661, same day): job logs show both real-install legs green, the 1Password-CLI-install step green, and only the Alert the internal channel step failing, with op run erroring failed to retrieve environment variables: An unexpected error occurred while processing the request — consistent with the claimed missing-Prod-access failure mode, not some other break in the smoke logic itself.
• No stale references: grepped the whole repo for test_alert, SECRETS_ENVIRONMENT_ID, ONEPASSWORD_CLI, OP_SERVICE_ACCOUNT_TOKEN, polylane-notifications — nothing left dangling outside this PR's own explanatory comments (the OP_SERVICE_ACCOUNT_TOKEN hit in cut-release.yml is a distinct, pre-existing, unrelated usage).
• YAML/local checks: both changed files parse as valid YAML. Repo has no workflow-file linter (npm run lint only covers src//codegen/); ran the full suite anyway since it's the standing local-check step: npm run codegen + typecheck clean, lint clean, test 359/359 passing — unaffected by this workflow-only change, as expected.
• CI on this head: 3/3 "checks / Test & typecheck" (20.x/22.x/24.x) green, 0 failures.

Author is justinhelmer (human) — the bot-authored/bot-approved self-approval pattern doesn't apply here.

No blocking issues.

---

Generated by Claude Code

[github-actions]

Auto-approved: Claude reviewed this PR and posted an LGTM verdict (see its review). A repo admin enabled this via the auto-approve workflow.

---

Generated by Claude Code

[justinhelmer]

Post-merge prod validation — all green ✅

Merged and validated against the freshly-cut v0.2.26 (assets: polylane.mjs + checksums.txt).

Release-integrated install-smoke (the whole point of this workflow): the install-smoke job ran inside the v0.2.26 release run and passed — steps are Fetch the production installer → Real install (API digest) → Real install (API blocked / checksums.txt), all success, with no alert step present (confirming #76's removal). A broken release would have turned this job red on the release run.

Direct prod checks against v0.2.26 through the served polylane.com/install:

Check	Result
checksums.txt matches the bundle	913e4214… == sha256(polylane.mjs) ✅
Real install, API-digest path (unpinned = what users get)	Downloading polylane v0.2.26 → ✓ sha256 verified → ✓ installed ✅
checksums.txt fallback (GitHub API blocked)	✓ sha256 verified → ✓ installed ✅
Fail-closed (both checksum sources blocked)	refuses with POLYLANE_ALLOW_UNVERIFIED=1 guidance, nothing installed ✅

Detection lives here as a red-check on the release; Slack paging remains in polylanedotcom's private install-bytes backstop. Nothing further outstanding.