- 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>
/autotask exists nowhere as a Claude command (no .claude/commands/autotask.md in
the repo; only a Grok skill by that name). It was a GURU-5070-specific artifact in
the provisional manifest and produced a spurious RED on every other machine. Removing
it clears the false FAIL fleet-wide.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Adds .claude/scripts/migrate-to-submodules.sh — self-contained, distributable by
raw URL since old clones can't pull. Detects compliance (history merge-base vs
origin, RECLONE.md+submodule offline fallback); leaves compliant clones untouched;
otherwise re-clones AND recovers the gitignored per-machine state a clone never
carries (identity.json, settings.local.json, .mcp.json, grepai, per-project
.env/.venv/.attachments), surfaces stranded unpushed commits, and FLAGS large
purged data for manual move (never re-imports it into git). Closes RECLONE.md's
"recover any uncommitted work" gap that stranded identity.json + the discord-bot venv.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Codifies the scan-first/data-driven workflow proven on Cascades (where the baked-in
non-DFS bias picked the congested channels and a data-driven DFS plan halved 5GHz retry):
- NEW survey-report.py: rolls survey-collect JSON into the fleet per-channel/per-band-group
measured busy% table + cleanest/dirtiest ranking + a suggested clean 40MHz palette. The
decision-driver that was missing (we built it by hand).
- channel-plan.sh: na palette is now DATA-DRIVEN, not hardcoded non-DFS. Adds --channels
(explicit palette) + --dfs ok|avoid|only; default considers ALL 40MHz primaries and lets
measured busy% choose. Adds load-balancing + a local-search pass -> strong co-channel to 0.
- survey-collect.sh: per-AP "cleanest" report no longer pre-filters out DFS (DFS is usually
cleanest here); marks DFS with *, points at survey-report.
- SKILL.md: documents the mandatory scan -> survey-report -> channel-plan --channels -> apply
-> validate order + the Cascades lesson.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Did it right this time: completed the full channel survey (74/74) FIRST, let the
data choose. Survey proved DFS channels are 4-5x cleaner here (2-3% busy) than
non-DFS (149/157 = 12-28%, the property's worst). Per Howard: built the plan on
the 8 clean DFS 40MHz blocks (52/60/100/108/116/124/132/140), per-AP locally-
cleanest + neighbor graph-colored -> 0 co-channel, 3.5% avg busy. Applied to 72
non-mesh APs (width 40 too); mesh excluded; voice nudged back to 5GHz.
VALIDATED: 5GHz retry 8.7->3.8 avg (-56%), median 8.2->2.1 (-74%); 2.4 ~baseline;
satisfaction median 99; voice 31/31 (17 Poly on 5GHz, 3 coverage-cases on 2.4);
all 72 APs holding DFS, 0 radar vacates.
Kept tonight: 2b (2.4 power) + DFS plan + BSS-transition. 6GHz still WPA3-blocked.
auto_upgrade still OFF. Follow-up: recurring dfs-check radar monitor.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Correction to earlier "deferred" report: after Howard pushed (5GHz needs fixing
regardless of 6GHz), I attempted width40 + non-DFS channel plan autonomously.
It did NOT validate live: 5G retry flat (8.7->8.4), 2.4 retry up (12->16) from
voice phones scattering to 2.4. ROOT CAUSE: the non-DFS channels here (149/157)
carry the heaviest EXTERNAL interference while DFS was cleaner -> forcing non-DFS
traded clean DFS for congested non-DFS. Rolled 5GHz back to baseline (channel+80MHz).
Kicked the 8 stuck Poly phones -> 6 back to 5GHz (rest are coverage-gap rooms).
End state recovered: satisfaction 98.4/med99, voice 31/31. Kept: 2b (2.4 power)
+ BSS-transition. 5GHz unchanged from start. auto_upgrade left OFF.
Doing 5GHz right needs the per-channel survey (choose channels by real cleanliness,
not non-DFS policy), reconsider non-DFS-only, 6GHz unblock (WPA3), band-steer voice.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Read-only Phase 0 baseline extended to floors 5/6 (MemCare). Findings:
- MemCare = same 3 diseases as 1-4 but untreated (2.4 at full power, not
over-thinned; all 5GHz on DFS+80MHz; min-RSSI off everywhere; 6GHz dark;
Shelby .218 stuck on 2.4 at Nurse Station).
- 5GHz static non-DFS channel-plan dry-run: co-channel pairs 19 -> 0 (kills
auto on all non-mesh APs; relieves AP 103/505 as fall-out).
- 2.4 1/6/11 re-color NEGATIVE right now (22 -> 28); defer until 2b restores
a stable Medium-power radio set.
- 7-day hour-of-day traffic: ~600 clients 24/7 (only ~10% swing); trough
01:00-04:00 MST. Change window decided: 2 AM start.
No changes applied. Survey stalled 68/74 (re-run before any 5GHz channel apply).
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
