sync: auto-sync from HOWARD-HOME at 2026-07-07 08:48:12

Author: Howard Enos
Machine: HOWARD-HOME
Timestamp: 2026-07-07 08:48:12
This commit is contained in:
2026-07-07 08:48:40 -07:00
parent 8efc351e25
commit 2e262c619e
4 changed files with 39 additions and 0 deletions

View File

@@ -67,3 +67,20 @@ Closed the session by reviewing the three bugs touched: marked BUG-024 and BUG-0
- Coord: 4 BUG-024 messages marked read (`cf35bf16`, `20daedf9`, `e2b01835`, `9659c5fc`); sent mike `5f8b33f7` (BUG-024 deploy) + `8c45b4dd` (detector fixed); coord todo `f7382334` (BUG-026, mike/gururmm).
- Discord DMs to mike: `1523821940047876146` (Scileppi access), `1523834569760178259` (BUG-026).
- Vault also synced an unrelated incoming entry `clients/altschuler/gururmm-site-main.sops.yaml`.
## Update: 2026-07-07 08:47 PT — bug roadmap close-out + Discord read capability
Continuation of the same session (spanned past midnight into 2026-07-07).
**Bug tracking (guru-rmm `docs/FEATURE_ROADMAP.md`):**
- BUG-024 → **FIXED** and BUG-025 (build change-detector excluded `agent/Cargo.toml`) filed **FIXED** (`fe5468e`) — commit `c248214`.
- Dug into why BUG-024's crash-loop never self-recovered → root-caused and filed **BUG-026** (OPEN/HIGH, commit `66152da`): the unix rollback watchdog is spawned via `setsid` inside the `gururmm-agent.service` cgroup; the unit sets no `KillMode` so the default `control-group` SIGKILLs the watchdog during the very restart it guards (`setsid` changes session, not cgroup). It is the only rollback path on unix (`restart_service` does `std::process::exit(0)` before the inline `rollback_binary` arm is reachable). Fix = spawn via `systemd-run --scope --collect` + bounded retry + verify. Per Howard, **flagged for Mike to fix**, not implemented: coord todo `f7382334` + Discord DM `1523834569760178259`.
**Discord reply visibility gap (resolved):**
- Discovered `discord-dm.sh` was send-only, so replies from mike/winter/rob were invisible (coord/repo sync never carries Discord replies). Confirmed the bot token CAN read DM history via `GET /channels/<id>/messages` (Message Content intent only gates gateway events, not REST fetch on channels the bot participates in).
- Added `discord-dm.sh read <user|#channel> [limit]` (reuses the same recipient/token/DM-open logic; prints oldest-first, `>>>` = their reply). Updated the SKILL.md + trigger description; added feedback memory `feedback_discord_read_replies`. Synced (skill deployed to global).
- Findings from reading: **Mike has NOT replied** to Scileppi (2026-07-06 22:44) or BUG-026 (23:34) — his last reply was 2026-07-05 (MSP360/Datto backups thread). **Winter** has a stale unanswered ask from 2026-06-24: "mark tickets resolved that have a status of customer reply and also have billing" (Syncro cleanup — not yet actioned, flagged to Howard).
**Decision:** automated reply-forwarding (a scheduled watcher polling `read`, or a bot-side relay) was scoped but NOT built — Howard opted to check replies manually via `discord-dm.sh read <user>` when needed.
**Still waiting on Mike:** (1) Scileppi SL-SERVER access to finish BUG-024's last agent, (2) BUG-026 fix. Check with `discord-dm.sh read mike`.