Skip to content

docs(full-platform): correct the slack gateway's llm provider to groq #56

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
Juanmadiaz45 wants to merge 1 commit into
base: main
Choose a base branch
from
Open

docs(full-platform): correct the slack gateway's llm provider to groq #56

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 2 additions & 2 deletions full-platform/slack-approval-gateway.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -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.

Expand Down
Loading