From 4f3a2fdcd4fd392edc17a4ec1ca16a3fd61a42dd Mon Sep 17 00:00:00 2001 From: Juan Manuel Diaz Moreno Date: Sun, 20 Sep 2026 22:41:59 -0500 Subject: [PATCH] docs(full-platform): correct the slack gateway's LLM provider to groq The non-technical rephrasing moved anthropic -> gemini -> groq across earlier sessions; this doc was never updated past its original anthropic draft. Reconciled to the current, deployed reality. --- full-platform/slack-approval-gateway.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/full-platform/slack-approval-gateway.md b/full-platform/slack-approval-gateway.md index 7b506b3..40688b2 100644 --- a/full-platform/slack-approval-gateway.md +++ b/full-platform/slack-approval-gateway.md @@ -12,7 +12,7 @@ Gate 2 was silent -- a run just sits paused with no notification anywhere until - Gate 1 gets a Slack message with **Approve** / **Request changes** buttons -- clicking one calls GitHub's API for real (submits the review, merges on approve). - Gate 2 gets a Slack **notification** (technical + non-technical summary, a direct link to GitHub's "Review deployments" screen) -- no button. GitHub's classic `required_reviewers` cannot be satisfied by a GitHub App token on behalf of a listed human (only Users/Teams can be listed reviewers; confirmed against GitHub's REST API docs), and the team chose to keep that approval exactly as it is today rather than replace it with a custom deployment-protection-rule app. Slack tells you it is waiting; you still approve it in GitHub. -Both messages carry a **technical** summary (the PR's own already-reviewed body sections, or deterministic job/run metadata -- verbatim, never re-derived) and a **non-technical** rephrasing generated by the Anthropic API, explicitly prompted to use only the facts given and never add anything unstated -- so a non-engineering stakeholder (a manager, a client) can understand what is about to happen without needing the technical detail. +Both messages carry a **technical** summary (the PR's own already-reviewed body sections, or deterministic job/run metadata -- verbatim, never re-derived) and a **non-technical** rephrasing generated by the Groq API, explicitly prompted to use only the facts given and never add anything unstated -- so a non-engineering stakeholder (a manager, a client) can understand what is about to happen without needing the technical detail. ## Why a third GitHub App, not one of the existing two @@ -38,7 +38,7 @@ Unlike the release/promoter Apps (consumed by GitHub Actions, so their credentia | `SLACK_SIGNING_SECRET` | `slack-interaction-handler` -- verifies a click really came from Slack | | `SLACK_BOT_TOKEN` | Both Lambdas -- post/update Slack messages | | `GITHUB_WEBHOOK_SECRET` | `github-webhook-handler` -- verifies a webhook really came from GitHub | -| `ANTHROPIC_API_KEY` | Both Lambdas -- the non-technical rephrasing | +| `GROQ_API_KEY` | Both Lambdas -- the non-technical rephrasing | The App id itself (`SLACK_APPROVER_APP_ID`) is not sensitive -- a GitHub App id is public information -- so it is passed straight through as a plain Lambda environment variable rather than a Secrets Manager entry. `microservice-app-ops`'s own delivery contract (`tests/contract/aws-dev-foundation.sh`) forbids an ordinary, state-persisted Secrets Manager value anywhere in `aws/`, precisely so no one has to judge case-by-case whether a given value is "sensitive enough" to earn the write-only treatment.