pal-e-docs

Re-Review: GroupMe bot registration + secrets + go-live validation

review-599-2026-03-28-v2 Doc

review ready
Project

Verdict: READY

Re-review after refinement. Previous review: review-599-2026-03-28 (NEEDS_REFINEMENT, 3 findings). All findings resolved.

Template Completeness

  • [x] Type -- Feature
  • [x] Lineage -- Depends on #1, #2, #3 (infra), #4 (scaffold), #5 (basketball client), #6 (AI engine), #8 (confirmation flow)
  • [x] Repo -- forgejo_admin/westside-ai-assistant + cluster ops
  • [x] User Story -- As Marcus (admin) I want the bot registered and deployed so I can start using the AI assistant
  • [x] Context -- Go-live ticket, explains GROUPME_BOT_ID rationale (posting credential, stored as secret)
  • [x] File Targets -- None (ops/validation ticket, explicitly excludes application code)
  • [x] Acceptance Criteria -- 6 items split into Phase 1 (agent, ACs 1-3) and Phase 2 (human, ACs 4-6)
  • [x] Test Expectations -- Phase 1 kubectl verification + Phase 2 manual GroupMe validation with clear handoff
  • [x] Constraints -- 5 constraints including GroupMe API details, kubectl-only secrets, group lockdown, tofu approval gate
  • [x] Checklist -- 5 items including explicit agent handoff step
  • [x] Related -- project-westside-ai-assistant, service-onboarding-sop steps 7-10
All template sections present and complete.

Traceability

  • [x] story:read-ops -- Marcus can query player/team/payment data via GroupMe
  • [x] story:write-ops -- Marcus can update player info via GroupMe with confirmation
  • [x] story:safety -- Write ops require confirmation, bot locked to approved group
  • [x] arch:A1 -- Domain Model (GroupMe webhook handler receives callbacks)
  • [x] arch:A4 -- Deployment (FastAPI pod, Tailscale funnel, k8s secrets, namespace)
  • [x] Forgejo issue -- forgejo_admin/westside-ai-assistant#7, open
Traceability complete. All three triangle legs solid.

File Targets

N/A -- ops/validation ticket with no code changes. Issue explicitly states "Files the agent should NOT touch: Application code." Correct for a go-live ops ticket. Agent acts via external APIs (GroupMe Bot API) and cluster tools (kubectl).

Repo Placement

OK. Issue filed on forgejo_admin/westside-ai-assistant. Work is external API calls + kubectl. No cross-repo code changes. Single-repo placement correct.

Dependencies

  • [x] #1 (Provision infrastructure in pal-e-services) -- backlog, documented
  • [x] #2 (Create kustomize overlay in pal-e-deployments) -- backlog, documented
  • [x] #3 (NetworkPolicy update in pal-e-platform) -- backlog, documented
  • [x] #4 (FastAPI scaffold + GroupMe webhook handler) -- backlog, documented. Previously missing, now fixed.
  • [x] #5 (Basketball-API client with Keycloak auth) -- backlog, documented. Previously missing, now fixed.
  • [x] #6 (AI engine core) -- backlog, documented
  • [x] #8 (Confirmation state machine for write operations) -- backlog, documented. New dependency added.
  • [x] Lucas tofu apply approval -- external human gate, documented in Constraints
All 7 ticket dependencies + 1 human gate documented. Lineage is complete. Issue #9 (discovered: basketball-api NetworkPolicy) is correctly not listed here -- it is a dependency of #5, not #7.

Acceptance Criteria

6 ACs split into two clearly labeled phases:
  • Phase 1 -- Agent-executable (ACs 1-3): Bot registration (specific name, callback URL, group_id), k8s secret creation (3 keys matching arch diagram), pod readiness check. All verifiable by agent via API response and kubectl.
  • Phase 2 -- Human validation (ACs 4-6): Read test, write test with confirmation, safety test. Clearly marked as manual. Agent hands off after Phase 1.
Previously missing handoff marker now present. Phase separation is explicit in both AC section and Checklist.

Secret Key Alignment

AC 2 lists 3 keys: ANTHROPIC_API_KEY, GROUPME_BOT_ID, KEYCLOAK_CLIENT_SECRET.
Architecture diagram (arch-deployment-westside-ai-assistant) lists 3 keys: ANTHROPIC_API_KEY, GROUPME_BOT_ID, KEYCLOAK_CLIENT_SECRET.
Match confirmed. Previous mismatch (GROUPME_BOT_TOKEN vs GROUPME_BOT_ID) resolved. Context section explains rationale: "GroupMe bots only have a bot_id -- there is no separate token. The bot_id acts as the posting credential."

Blast Radius

  • Files/repos touched: 0 files, 0 repos. External API + kubectl only.
  • What could break: Incorrect callback URL = bot deaf. Wrong group_id = wrong group. Missing secret key = crash-loop.
  • Rollback: Delete bot via GroupMe API, delete k8s secret, pod stops. No persistent state.
  • Sibling impact: None. First GroupMe bot in platform. Namespaced secret. No shared infra modified.

Decomposition

  • Discrete agent changes: 3 (register bot, create secret, verify pod). Meets three-thing limit.
  • Agent ACs: 3. Under the 5-AC threshold.
  • Estimated agent time: ~3 minutes. Within five-minute rule.
  • Human ACs: 3 (post-handoff, not agent work).
No decomposition needed.

Previous Findings Resolution

# Finding Status
1 [BODY] Incomplete Lineage -- missing #4 and #5 RESOLVED -- #4, #5, and new #8 all added to Lineage
2 [BODY] Agent/human handoff unclear RESOLVED -- ACs split into Phase 1 (agent) and Phase 2 (human) with explicit handoff
3 [BODY] Secret key mismatch (GROUPME_BOT_TOKEN vs arch diagram) RESOLVED -- Corrected to GROUPME_BOT_ID, matches arch diagram. Context explains rationale.

Recommendation

No action needed. All three previous findings resolved. Template complete, traceability solid, dependencies documented, ACs testable with clear agent/human handoff, secret keys aligned with architecture diagram. Ready for dispatch when all 7 dependencies are merged.