Adds c_msg_purge to coord.py + SKILL.md doc. Deletes coordination messages older than a
date cutoff via DELETE /api/coord/messages/{id}. Safety: --before is required (can't wipe
the store by accident), DRY-RUN by default (previews; --yes to actually delete), optional
--to scopes to one recipient session, paginates over the API's 1000-row limit cap, logs
partial failures. Replaces the ad-hoc curl loop used to purge 208 stale messages this session.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Corrects the assumption that GuruRMM merge-to-main (=deploy) is Mike-only. Mike still owns RMM
architecture/direction, but Howard can land prepared+verified branches himself — they no longer
bottleneck on Mike. Updated approval-workflow-tools-vs-projects + MEMORY.md index + logged the
correction in errorlog.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- bitdefender gz.py: add "missing name" to _EXPECTED_ERROR_MARKERS — closes the last gap in
Howard's errorlog suppression ("Missing name 'X' in 'options' object" validation errors were
still logged). Verified all 10 real spam messages now suppressed; genuine errors still log.
- memory feedback_submodule_autosync_discipline: capture the recurring auto-synced-submodule
rule (worktree or push-by-SHA + ls-remote verify; assert HEAD==origin/main before audits;
never checkout-- shared files). Recurred on Howard-Home x3 + GURU-5070 this session.
- CLAUDE.md CORE Windows bullet: promote the two top recurring mechanical traps (/tmp path
mismatch, curl.exe/plink quote-stripping) to always-loaded hard rules so they stop repeating.
Lint of errorlog.md: bitdefender expected-validation spam was ~70% of entries (Howard's
suppression now complete); fabb3421/Mail.Send drift closed earlier this session; wiki-compile
lock-release doc already fixed (entries predate the fix).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
PROBLEM: Broadcast messages were never being marked as read on the server,
only tracked in a local gitignored seen-file. This caused them to re-appear
in every new session or on different machines.
ROOT CAUSE: check-messages.sh lines 101-104 had a flawed assumption that
broadcasts share a single read_at field that would "clobber" other machines'
unread state. This was wrong - the API supports per-session read tracking.
FIX:
- check-messages.sh now marks broadcasts as read on the server (like personal
messages), in addition to tracking them in the local seen-file
- Updated comments to reflect correct behavior
- coord SKILL.md now documents auto-mark-read behavior and reply workflow
- Manually marked all 39 accumulated unread broadcasts as read
IMPACT: Broadcast messages will now be properly marked as read and won't
keep appearing across sessions. Fixes user complaint about answered questions
(pfSense cred-path, fabb3421, etc.) continuing to show up.
Logged to errorlog.md as --correction.
Found during the RMM-TEST-MACHINE full-function test (live tenant):
- assignPolicy: assigning a policyId REQUIRES inheritFromAbove:false in the same
call, else the API rejects with a misleading "inheritFromAbove should not be
used with policyId" error. Fixed assign_policy to always send it; dropped the
wrong --inherit-from-above flag.
- isolate/unisolate: the API takes a SINGLE endpointId per call, NOT an
endpointIds array (errored "not expected"). Client now loops per endpoint.
unisolate fails while the isolate task is in progress — wait + retry.
- api-reference updated with the live-verified shapes.
Full function test PASSED on RMM-TEST-MACHINE: install(offline kit/SYSTEM) ->
enroll -> move(ZZ-RMM-TEST) -> assign-policy(GPS Base, applied) -> set-label ->
scan -> reconfigure -> isolate -> unisolate -> quarantine/blocklist read ->
managed uninstall(deleteEndpoint). selftest 75/75.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Completed Companies module for bitdefender GravityZone Public API
- Implemented: getCompanyDetails, getCompanyDetailsByUser, createCompany, suspendCompany, activateCompany, deleteCompany
- Discovered updateCompany and getCompaniesList not available; companies retrieved via network inventory
- Company types: 0=Partner, 1=Customer; createCompany accepts nested licenseSubscription via JSON passthrough
- All write operations require --confirm; raw also restricts createCompany/suspendCompany/activateCompany
- selftest 49 -> 55 passing
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- Completed Accounts module for bitdefender skill (GravityZone Public API)
- Added 5 methods: getAccountDetails, createAccount, updateAccount, deleteAccount, configureNotificationsSettings
- Write methods require --confirm; raw also gates createAccount/updateAccount/configureNotificationsSettings
- Param shapes validated against official docs and safe validation probes
- configureNotificationsSettings is a setter with no required param; warning documented against empty payload on live tenant
- selftest 42 -> 49 passing
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
- assign_policy: add inheritFromAbove option; mark VERIFIED via official docs
(policyId/targetIds/forcePolicyInheritance/inheritFromAbove; not applied to
ENFORCED-policy targets).
- setPushEventSettings: documented serviceType (splunk/cef/jsonRPC), TLS 1.2+
receiver requirement, subscribeToEventTypes event-flag map; webhook receiver
pattern noted.
- api-reference.md: cite GravityZone Support Center as authoritative source.
- add references/BUILDOUT.md — master checklist to implement every API method
module-by-module; seeded with current done/todo/dead state.
- memory: reference_gravityzone_support (+ index).
selftest 42/42.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Re-verified the live tenant's full API scope and wrapped the modules the key
allows but the skill didn't expose. New CLI subcommands:
- assign-policy (gated) — apply an existing policy to endpoints/groups
(param shape policyId+targetIds verified live)
- reports, accounts, notif-settings, scan-tasks — read
- push-settings / push-stats / push-set (gated) — push event service
(status param verified; needs a receiver URL to enable)
Corrections from live probing:
- policies are NOT shallow: getPolicyDetails returns the FULL granular config.
Removed the false "shallow" warning; documented read+assign, console-only authoring.
- raw now gates assignPolicy + setPushEventSettings.
- documented dead modules (patchmanagement/phasr/maintenancewindows/integrations,
incidents.getIncidentsList) and unconfigured-push handled cleanly (rc0, no errorlog).
selftest 29/29 -> 42/42, all green against the live tenant.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
/mailbox (ACG own-mail, single-tenant 1873b1b0) and client send (suite
Exchange Operator b43e7342, multi-tenant) stay separate on purpose: 1873b1b0
is single-tenant so it cannot serve clients; consolidating onto exchange-op was
rejected (privilege creep on casual own-mail + loses Contacts). Documented the
why in commands/mailbox.md scope boundary + feedback memory so it stops being
re-litigated.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Mail.Send is NOT an open decision or a 'blocked' item: the Exchange Operator
tier (b43e7342) already holds Graph Mail.Send + Mail.ReadWrite +
MailboxSettings.ReadWrite (the suite's IR victim-notification mail path).
/mailbox (ACG own-mail) separately uses the dedicated ComputerGuru Mailbox app
1873b1b0. The deleted fabb3421/Claude-MSP-Access app is now referenced only as
DELETED/do-not-use across all live surfaces.
Corrected: remediation-tool gotchas.md (removed 'suite has no mail scopes /
mailbox BLOCKED / decision-not-executed'), commands/mailbox.md (header +
Attribution no longer name the deleted app as active), feedback memory
(promoted 'suite has Mail.Send — settled' to a headline), breach-report
template, .grok mirrors, credentials.md, CATALOG_SHARED_DATA.md, and wiki
(internal-infrastructure, glaztech, dataforth). Removed dead plaintext secret
for the deleted app from CATALOG_SHARED_DATA.md.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
