[Mark/mesh-seed #231 follow-up] Discord bot deployment gap: code shipped but not wired into stack — docker-compose.yml not amended, no DISCORD_BOT_TOKEN provisioned #277

Closed
opened 2026-08-14 05:23:55 +00:00 by Mark · 3 comments
Owner

Summary

The #231 "Discord Bot Foundation" fix (commit f382d36e47, issue closed 2026-08-09) ships the discord bot as code-only. Deployment integration was never landed: docker/docker-compose.yml was not amended on any branch, so there is no discord service / profile / image; and no DISCORD_BOT_TOKEN is provisioned anywhere, so the bot cannot authenticate or run.

Reproduction steps

  1. Scan all branches for discord in compose: git log --all -p -- docker/docker-compose.yml | grep -i discord — zero hits (verified on every branch 2026-08-09 and 2026-08-13).
  2. docker images | grep discord — no image; docker ps -a | grep discord — no container; no systemd unit; no nodehub app.
  3. env | grep DISCORD_BOT_TOKEN and ~/.env — empty; no secrets-backend value anywhere.
  4. Start the bot service without a token — exits 1 with structured log "Environment secret not found: DISCORD_BOT_TOKEN".

Actual behavior

Bot code (docker/discord_bot.py, ~53KB after the #232–#274 build-out) exists and 151/151 discord unit tests pass on clean master, but the bot cannot run: no compose service, no image, no token. The #231 acceptance criteria "starts/stops cleanly as an optional docker compose --profile discord service" and "bot authenticates and stays connected" are unmet.

Expected behavior

Per the #231 plan (5.4 amendment): amend docker/docker-compose.yml with an optional profiles: ["discord"] service building from docker/Dockerfile.discord with HEALTHCHECK on 8082, and provision DISCORD_BOT_TOKEN through the secrets manager so the bot authenticates and stays connected. This deployment gap is tracked as a follow-up to the closed #231.

Evidence

Verified by post-deploy probe 2026-08-09 and re-verified 2026-08-13 (4 days later, findings unchanged): all branches scanned, no discord in compose; no token; missing-token exit-1 behavior confirmed. No prior open issue references this gap (checked 9 open issues in Mark/mesh-seed).

Source: kanban card t_c346d13a (post-deploy probe for fixit card t_29fc90cc).

## Summary The #231 "Discord Bot Foundation" fix (commit f382d36e47, issue closed 2026-08-09) ships the discord bot as code-only. Deployment integration was never landed: `docker/docker-compose.yml` was not amended on any branch, so there is no discord service / profile / image; and no `DISCORD_BOT_TOKEN` is provisioned anywhere, so the bot cannot authenticate or run. ## Reproduction steps 1. Scan all branches for discord in compose: `git log --all -p -- docker/docker-compose.yml | grep -i discord` — zero hits (verified on every branch 2026-08-09 and 2026-08-13). 2. `docker images | grep discord` — no image; `docker ps -a | grep discord` — no container; no systemd unit; no nodehub app. 3. `env | grep DISCORD_BOT_TOKEN` and `~/.env` — empty; no secrets-backend value anywhere. 4. Start the bot service without a token — exits 1 with structured log "Environment secret not found: DISCORD_BOT_TOKEN". ## Actual behavior Bot code (`docker/discord_bot.py`, ~53KB after the #232–#274 build-out) exists and 151/151 discord unit tests pass on clean master, but the bot cannot run: no compose service, no image, no token. The #231 acceptance criteria "starts/stops cleanly as an optional `docker compose --profile discord` service" and "bot authenticates and stays connected" are unmet. ## Expected behavior Per the #231 plan (5.4 amendment): amend `docker/docker-compose.yml` with an optional `profiles: ["discord"]` service building from `docker/Dockerfile.discord` with HEALTHCHECK on 8082, and provision `DISCORD_BOT_TOKEN` through the secrets manager so the bot authenticates and stays connected. This deployment gap is tracked as a follow-up to the closed #231. ## Evidence Verified by post-deploy probe 2026-08-09 and re-verified 2026-08-13 (4 days later, findings unchanged): all branches scanned, no discord in compose; no token; missing-token exit-1 behavior confirmed. No prior open issue references this gap (checked 9 open issues in Mark/mesh-seed). Source: kanban card t_c346d13a (post-deploy probe for fixit card t_29fc90cc).
Mark 2026-08-14 05:23:55 +00:00
  • closed this issue
  • added the
    bug
    label
Author
Owner

DISCORD_BOT_TOKEN is now provisioned (kanban t_f118b20c): real 72-char token from operator host secret store (/home/b/.hermes/.env), written to docker/.env (gitignored, mode 600). Compose renders the value via ${DISCORD_BOT_TOKEN:-}; secrets_manager.resolve(secret://env/DISCORD_BOT_TOKEN) passes with skill context discord_bot. Runbook added: docs/runbooks/discord-bot.md (local commit 443d6b5, unpushed).

DISCORD_BOT_TOKEN is now provisioned (kanban t_f118b20c): real 72-char token from operator host secret store (/home/b/.hermes/.env), written to docker/.env (gitignored, mode 600). Compose renders the value via ${DISCORD_BOT_TOKEN:-}; secrets_manager.resolve(secret://env/DISCORD_BOT_TOKEN) passes with skill context discord_bot. Runbook added: docs/runbooks/discord-bot.md (local commit 443d6b5, unpushed).
Author
Owner

Launcher pre-dispatch blocked for follow-up fixup card (kanban t_ce3157cb).

The preflight gate .gsd/gates/pre-dispatch.sh 277 exits non-zero because the main repo checkout is baseline-dirty with unrelated work in progress:

M docs/DEVELOPER_GUIDE.md (2026-08-19)
?? .worktrees/ (2026-08-19)
?? .kilo/plans/*.md (older plans)

The current branch is fix/mesh-seed-284-zipkin (unrelated to #277). The launcher does not touch tooling state; the janitor needs to reconcile the baseline before re-dispatching.

The two concrete #277 runtime blockers documented in the card body remain valid and unfixed:

  1. docker/docker-compose.yml networks block declares name: docker/gateway — invalid for docker engine (slash rejected). Real on-host network is docker_mesh-network.
  2. docker/Dockerfile.discord builds an image missing prometheus_client; needs prometheus-client>=0.19.0 added to docker/requirements.txt.

No fix has been pushed. Once the baseline is reconciled the fixup will land on a fresh fix/277-runtime worktree.

Launcher pre-dispatch blocked for follow-up fixup card (kanban t_ce3157cb). The preflight gate `.gsd/gates/pre-dispatch.sh 277` exits non-zero because the main repo checkout is baseline-dirty with unrelated work in progress: M docs/DEVELOPER_GUIDE.md (2026-08-19) ?? .worktrees/ (2026-08-19) ?? .kilo/plans/*.md (older plans) The current branch is `fix/mesh-seed-284-zipkin` (unrelated to #277). The launcher does not touch tooling state; the janitor needs to reconcile the baseline before re-dispatching. The two concrete #277 runtime blockers documented in the card body remain valid and unfixed: 1. `docker/docker-compose.yml` networks block declares `name: docker/gateway` — invalid for docker engine (slash rejected). Real on-host network is `docker_mesh-network`. 2. `docker/Dockerfile.discord` builds an image missing `prometheus_client`; needs `prometheus-client>=0.19.0` added to `docker/requirements.txt`. No fix has been pushed. Once the baseline is reconciled the fixup will land on a fresh `fix/277-runtime` worktree.
Author
Owner

Launcher note (2026-09-05 22:56 PT, kilo-gsd-runner @ kanban t_ce3157cb): a follow-up fixup card targeting this issue (external network name + missing prometheus_client in discord-bot image) was unable to claim because the issue is state=closed. The close 2026-08-14T12:32:53Z happened after commit f13a933 landed — technically a legitimate close, BUT the parent verifier sweep found two runtime acceptance-criteria gaps (#231(a) cold-start, #231(b) auth) that this card exists to fix. To unblock the work, please either (a) reopen #277 so the kanban claim can take, or (b) open a new follow-up issue and re-target the kanban card at that number. Card body documents the exact fixes (network name docker/gateway -> legal slug; add prometheus-client>=0.19.0 to docker/requirements.txt).

Launcher note (2026-09-05 22:56 PT, kilo-gsd-runner @ kanban t_ce3157cb): a follow-up fixup card targeting this issue (external network name + missing `prometheus_client` in discord-bot image) was unable to claim because the issue is `state=closed`. The close 2026-08-14T12:32:53Z happened after commit `f13a933` landed — technically a legitimate close, BUT the parent verifier sweep found two runtime acceptance-criteria gaps (#231(a) cold-start, #231(b) auth) that this card exists to fix. To unblock the work, please either (a) reopen #277 so the kanban claim can take, or (b) open a new follow-up issue and re-target the kanban card at that number. Card body documents the exact fixes (network name `docker/gateway` -> legal slug; add `prometheus-client>=0.19.0` to `docker/requirements.txt`).
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Mark/mesh-seed#277
No description provided.