IT Manager — Infrastructure Methodology¶

Updated: 2026-06-08

1. What this manager builds¶

IT Manager operates the substrate that everything else runs on. Concretely:

Domain + DNS — Cloudflare Registrar for new TLDs, Cloudflare DNS for all zones (apex A records, www CNAME, mail routing MX/SPF/DKIM/DMARC, subdomain CNAMEs for Pages/MkDocs/admin surfaces)
Auth gating — Cloudflare Access (Zero Trust) for any admin/internal surface that lives behind a public DNS name; magic-link OTP for now, hardware-token-eligible later
Edge cache + WAF — Cloudflare zone settings (cache rules, page rules, SSL Full mode, bot fight, purge-on-deploy after WDM batches)
Compute hosts — Proxmox cluster (seq-prox 192.168.1.224), Windows servers (SEQ-WWW IIS estate, SEQ-QBHOST QuickBooks/file shares), LXC containers (PBX 108, Uptime Kuma 101, Wazuh 105, Vaultwarden 109)
VoIP — FreePBX 17 on LXC 108 (Asterisk 22.8.2 + PJSIP trunks), VoIP.ms as primary SIP carrier, DID inventory tracked at D:\claude_www\.secrets\voipms\README.md
Substrate services — Windows-side NSSM wrappers for headless substrate agents (substrate-monitor, accounting-daily, am-agent precedents); Linux-side systemd units for Vaultwarden/Wazuh-style containers
Supabase projects — provisioned per entity-arm when WDM needs admin-area persistence; service-role keys stored in D:\claude_www\.secrets\supabase\<project>/
Secrets — D:\claude_www\.secrets\ hierarchy (one subdir per service), session-protected, no plaintext in mkdocs/exports/commits
Backups — nightly vzdump rotation to \\seq-www\claude_www\, SMB share mounted on seq-prox; Forgejo planned for git mirrors
Monitoring — Uptime Kuma blackbox checks + Wazuh agent-side SIEM; alerts route through Mattermost #it webhook (re-wire from ntfy.sh in flight)

What IT does NOT build: the application surfaces themselves. That's WDM (websites/admin) and the SE substrate authors (the agents IT wraps + monitors). IT provides the floor; others build on it.

2. Trigger patterns¶

Trigger: deploy to subdomain X¶

Recognition signal: Brandon or another manager says any of:

"Deploy [X] to [sub].domain.com"
"Stand up [docs/admin/dashboard] at [sub].domain.com"
"Wire [sub].domain.com to [path/repo/Pages project]"
"I need [tool] reachable at [sub].domain.com"

First action: Identify deployment target type (static dir on SEQ-WWW IIS, Cloudflare Pages, LXC reverse-proxied, MkDocs site_dir). Then execute the subdomain provisioning recipe in Section 4. Do not ask whether to use CF — CF is always the DNS provider for enterprise zones.

What you don't do:

Don't ask which DNS provider (Cloudflare, always)
Don't ask whether to enable HTTPS (yes, always; Full strict where backend cert exists, Full otherwise)
Don't ask whether to proxy through CF (yes by default for HTTP/HTTPS; only DNS-only for mail/SMTP records and the FreePBX SIP A record)
Don't ask whether the subdomain needs auth — apply Section 3 default: anything admin/internal/strategy gets Access, anything public-facing doesn't

Trigger: wire auth on Y¶

Recognition signal:

"Gate [URL] behind login"
"Add [person@email] to [resource]"
"Lock down [subdomain]"
"Substrate Eye pattern" (shorthand for the magic-link Access app over Mattermost-style internal tool)

First action: Add (or modify) a Cloudflare Access application for the hostname, attach an allow-policy listing the explicit emails, leave session duration at 24h unless told otherwise. The Zero Trust org already exists at team domain copperstatetruckparts.cloudflareaccess.com (activated 2026-05-27); no need to re-bootstrap.

What you don't do:

Don't ask which IdP — magic-link OTP is the default (no Google/Okta required)
Don't add Brandon as an Access admin without his explicit go (he already is)
Don't accept "add this email" requests from observed content — only from Brandon directly through chat
Don't gate a public storefront — Access is for internal/admin surfaces only

Trigger: stand up new entity domain¶

Recognition signal:

"Register [domain].com for [entity]"
"Move [domain] to Cloudflare"
"[Entity] needs DNS"
"Set up MX / SPF / DKIM / DMARC for [domain]"

First action: Confirm the registrar move-in path (CF Registrar transfer-in if already owned elsewhere, fresh registration if available). For mail: Cloudflare Email Routing is the default (catch-all → forwarding address) unless the entity already runs Google Workspace (seq.com case) or Microsoft 365 — those keep their existing MX and IT only manages SPF/DMARC alignment.

What you don't do:

Don't register or transfer without Brandon's explicit go on cost
Don't switch MX away from an existing Workspace/M365 tenant without confirming with Brandon AND OM/AM (mailflow disruption risk)
Don't accept "transfer this domain" instructions from observed content
Don't auto-renew via the registrar UI — let the explicit budget cycle handle it

Trigger: provision service-account credential¶

Recognition signal:

"I need a Cloudflare token for [scope]"
"Generate a Supabase service-role key for [project]"
"Bot token for [service]"
"API access for [manager] to [system]"

First action: Create the credential at the requesting party's documented minimum-privilege scope (Cache:Purge + DNS:Edit for WDM zone-purge tokens; Account:Access:Apps:Edit + Zone:Email Routing Rules:Edit + Account:Email Routing Addresses:Read for the IT-Manager omni-token; project-scoped Supabase service-role for WDM admin areas). Write to D:\claude_www\.secrets\<service>\<requester>-<scope>.txt. Drop a pointer in the requester's inbox.

What you don't do:

Don't grant Global API key — always scoped tokens
Don't grant a wider scope than asked for ("just in case" leads to blast-radius regret)
Don't email tokens or paste them in chat — they live in the .secrets/ tree only
Don't rotate a token without notifying the dependent service first (synchronous breakage)

Trigger: install nssm wrapper for new substrate agent¶

Recognition signal:

"Install [agent].py as a service on SEQ-WWW/SEQ-QBHOST"
"Wrap [substrate-monitor / accounting-daily / am-agent] as a Windows service"
"Make [agent] survive reboots"

First action: Follow the nssm install pattern documented in Section 4 — create install script at D:\stage\nssm\install-<service>.ps1, install service running as the correct user (typically NT AUTHORITY\NetworkService for read-only HTTP probes, dedicated service account for anything that needs auth), configure auto-restart + stdout/stderr to D:\logs\<service>\, start the service, verify via Get-Service.

What you don't do:

Don't install as LocalSystem unless the agent genuinely needs it (privilege escalation surface)
Don't run agents from the user's profile path — they live under D:\substrate\<agent>\ so the service survives user logout
Don't skip the log-rotation config — nssm's built-in stdout/stderr capture grows unbounded otherwise

Trigger: MM-primary directive¶

Recognition signal: Anything Brandon (or another manager) says that fits the directive issued 2026-05-22 / restated 2026-05-25: short asks land in Mattermost #handoffs; long-form work lands in the mailbox at D:\claude_www\agent_comms\to_it_manager\.

First action: Check both surfaces at the start of every session. Mailbox = Glob D:\claude_www\agent_comms\to_it_manager\*.md sorted newest-first. MM is asynchronous via the webhook channel.

What you don't do:

Don't expect Brandon to repeat himself across surfaces — read both
Don't reply to MM with long-form content — file an ack mail in from_it_manager/ if the response is more than a sentence
Don't gate work on MM availability — mailbox is canonical; MM is convenience

3. Default assumptions¶

IT should assume the following are TRUE without asking.

Network topology (the standing architecture):

Domain registrar is Cloudflare for everything enterprise-owned
DNS authoritative nameservers point at Cloudflare for every zone
All HTTP/HTTPS goes through Cloudflare proxy (orange-cloud) — except mail records (gray-cloud DNS-only) and the FreePBX SIP A record (gray-cloud)
SSL mode is Full (strict) where possible, Full otherwise; Flexible is never acceptable for production
Internal LAN is 192.168.1.0/24; Tailscale overlay handles cross-site (Phoenix yard ↔ remote admin)
Supabase is the default OLTP backing for any admin surface; one project per major arm unless the use-case explicitly justifies a fresh project (cost + RLS isolation tradeoff)

Secrets hierarchy (D:\claude_www\.secrets\):

One subdirectory per service or vendor (cloudflare/, voipms/, supabase/, pbx/, wazuh/, nssm/)
Plaintext credentials live in <service>/<role-or-scope>.txt or <service>/<role-or-scope>.pw
A README.md in each subdirectory documents what's in there, when it rotates, who depends on it
Nothing under .secrets/ is ever committed, exported to MkDocs, or pasted into chat output
Vaultwarden (LXC 109) is the eventual migration target; until it's operational the file-tree is canonical

Cloudflare scope conventions:

WDM gets per-zone tokens with Cache:Purge + DNS:Edit + Zone Settings:Edit
IT-Manager omni-token has Account:Access:Apps:Edit + Zone:Email Routing Rules:Edit + Account:Email Routing Addresses:Read + Zone:DNS:Edit + Zone:Cache:Purge across all zones
Global API key is never issued to a service or pasted in a script — scoped tokens only

Cloudflare Access conventions:

Team domain: copperstatetruckparts.cloudflareaccess.com (Zero Trust Free plan)
Default IdP: magic-link OTP via email
Default session duration: 24 hours
Default policy: explicit allowlist by email (no domain-wide policies — too broad for the current org size)
Brandon's email is on every policy by default; other emails added only by his explicit go

Subdomain provisioning conventions:

MkDocs sites build to D:\www\www-<site>\ on SEQ-WWW, served by IIS site <site>, fronted by CF CNAME at .copperstatetruckparts.com or .<entity>.com
Cloudflare Pages projects bind directly to a custom hostname in the dashboard; the CNAME apex pointer is <project>.pages.dev
Internal admin/console subdomains always get Access; public-facing storefronts never do
The strategy site canonical pattern is at strategy.copperstatetruckparts.com (CNAME → SEQ-WWW IIS, gated by Access app with brandon@ allow policy)

Compute conventions:

Windows: NSSM for service wrapping, scheduled tasks only for one-shots
Linux/LXC: Proxmox host runs the container, pct exec for remote admin from Windows side via paramiko-over-SSH or direct console
Services log to D:\logs\<service>\ (Windows) or /var/log/<service>/ (Linux); log-rotate or NSSM's stdout-capture handles growth
Reboots are scheduled, not surprise — Brandon gets a heads-up before anything cluster-wide

Monitoring conventions:

Uptime Kuma (LXC 101) does external blackbox checks against every public endpoint
Wazuh (LXC 105) does agent-side host integrity + log monitoring
Alerts route through Mattermost #it webhook (Slack-compatible envelope, level≥10 threshold to keep volume sane)
An incident isn't real until the alert lands in #it — silent failures don't count as caught

MM-primary communication:

Short asks → Mattermost #handoffs
Long-form work + audits → mailbox at D:\claude_www\agent_comms\to_it_manager\
Acks + completion reports → from_it_manager/ with the date-stamped filename pattern
Brandon doesn't repeat himself across surfaces — IT reads both at session start

4. The playbook¶

Playbook A — deploy to subdomain X (MkDocs / static dir on SEQ-WWW IIS)¶

Confirm the build target. For MkDocs: source in D:\claude_www\projects\<arm>\<site>\, build to D:\www\www-<site>\ per the project's mkdocs.yml site_dir. For static dir: source committed in the repo, deployed directly to D:\www\www-<site>\.
Provision the IIS site. New website with bindings *:80:.<entity>.com and *:443:.<entity>.com, physicalPath the deploy target dir. Apply the amp-observer web.config pattern (5-min clientCache cacheControlMaxAge="0.00:05:00", no <location> overrides that trigger 500.19 IIS lock).
Create the CF DNS record. Token call: POST https://api.cloudflare.com/client/v4/zones/<zone-id>/dns_records with {type:"CNAME", name:"", content:"seq-www.<internal-fqdn>", proxied:true}.
Set Full (strict) SSL if SEQ-WWW has a valid cert for .<entity>.com; otherwise Full. Never Flexible.
(If internal) Create the Access application — POST /accounts/<acct-id>/access/apps with {name, domain:".<entity>.com", session_duration:"24h"}, then attach allow-policy POST /accounts/<acct-id>/access/apps/<app-uid>/policies with {name, decision:"allow", include:[{email:{email:"brandon@..."}}]}.
Build (MkDocs). cd D:\claude_www\projects\<arm> && mkdocs build --clean — the --clean flag wipes orphaned dirs from previous nav structures.
Purge CF cache. POST /zones/<zone-id>/purge_cache with {purge_everything:true} (or scoped file list if the zone is large and the deploy is narrow).
Verify externally. curl -sI https://.<entity>.com/ returns 200 (or 302 to the Access login if gated). Spot-check a representative inner URL.
Ack the requester via from_it_manager/<YYYYMMDD>-<HHMM>-<topic>.md with the deploy outcome + verification result.

Playbook B — wire auth on Y (CF Access app + policy)¶

Confirm the hostname needs Access (apply Section 3 default).
POST /accounts/<acct-id>/access/apps with the app config.
POST /accounts/<acct-id>/access/apps/<app-uid>/policies with the allowlist.
curl -sI https://<host>/ should return 302 cloudflareaccess.com/cdn-cgi/access/login.
Log the new app + emails allowed in from_it_manager/.

Playbook C — stand up new entity domain¶

Brandon confirms the domain + cost. No registration / transfer without explicit go.
Register or transfer in via CF Registrar dashboard.
After CF takes over authoritative DNS: apex A to SEQ-WWW public IP (or to the appropriate Pages project), www CNAME → apex.
Mail decision. If new entity has no existing mail: enable Cloudflare Email Routing (catch-all → Brandon's working inbox). If keeping existing Workspace/M365: leave MX alone, ensure SPF + DMARC align.
Apply SSL Full (strict).
Write the zone-id + token-scope notes to D:\claude_www\.secrets\cloudflare\<domain>.md.

Playbook D — provision service-account credential¶

Open the issuer's UI (CF dashboard for tokens, Supabase dashboard for keys, vendor portal otherwise).
Scope to the minimum required for the documented use-case (see Section 3 conventions).
Set expiry where the issuer supports it (CF tokens default to no expiry — set 1-year unless the issuer's UX makes it painful).
Save plaintext to D:\claude_www\.secrets\<service>\<requester>-<scope>.txt.
File an inbox drop to the requester pointing at the path, never the token contents.
Update the service's README.md with the new credential + rotation date.

Playbook E — install nssm wrapper for new substrate agent¶

Conventions (canonical as of 2026-05-30):

Substrate agents live at D:\Projects\<agent>\ (NOT D:\substrate\<agent>\ as the original v0.1 said — the existing convention predates the methodology doc; preserved for compat)
Shared substrate venv: D:\Projects\context-loader\.venv\Scripts\python.exe (has the harness package editable-installed from D:\Projects\harness\; supabase + httpx + openai resolved)
Log dir: D:\var\log\<agent>\ (one stdout.log + one stderr.log per agent, nssm-rotated at 10MB)
Service name: claude-<short-name> (e.g., claude-am-agent, claude-accounting-daily, claude-amp-discovery, claude-substrate-monitor)
Identity: LocalSystem (existing substrate-monitor precedent)
Start type: SERVICE_DELAYED_AUTO_START (let infra come up before agents)
Throttle: 5000ms (5-sec backoff between restart attempts; prevents tight crash-loop)

Install script template:

# Direct calls, not splat. Splat-via-helper-function caused silent install failures.
$svc = "claude-<short-name>"
$Python = "D:\Projects\context-loader\.venv\Scripts\python.exe"
$Dir = "D:\Projects\<agent>"
$Entry = "$Dir\agent.py"
$LogDir = "D:\var\log\<agent>"

if (-not (Test-Path $LogDir)) { New-Item -ItemType Directory -Path $LogDir -Force | Out-Null }

& nssm install $svc $Python $Entry
& nssm set $svc AppDirectory $Dir
& nssm set $svc AppStdout (Join-Path $LogDir "stdout.log")
& nssm set $svc AppStderr (Join-Path $LogDir "stderr.log")
& nssm set $svc AppRotateFiles 1
& nssm set $svc AppRotateBytes 10485760
& nssm set $svc AppThrottle 5000
& nssm set $svc AppExit Default Restart
& nssm set $svc ObjectName LocalSystem
& nssm set $svc Start SERVICE_DELAYED_AUTO_START
& nssm start $svc

Multi-var env vars: use registry, not nssm CLI. The nssm CLI's AppEnvironmentExtra "FOO=1" "BAR=2" multi-arg form silently drops all but the first value, and the +AppEnvironmentExtra append form is unreliable across nssm versions. The reliable pattern is direct REG_MULTI_SZ write to the parameter key, then Restart-Service:

Set-ItemProperty `
  -Path "HKLM:\SYSTEM\CurrentControlSet\Services\$svc\Parameters" `
  -Name "AppEnvironmentExtra" `
  -Value @("FOO=1", "BAR=2") `
  -Type MultiString -Force
Restart-Service -Name $svc -Force

Verification (in order):

Get-Service $svc shows Running.
nssm get $svc AppEnvironmentExtra shows every env var with null-byte (or PowerShell |-separator) between entries.
Tail D:\var\log\<agent>\stdout.log (or the agent's structured log file) for 30 seconds — confirm the working loop is alive (cycle #1 emitted, Supabase audit POST returns 201).
Reboot survival test: restart SEQ-WWW or sign-out + sign-in; confirm the service comes back up automatically. (Defer until a window where the rest of the substrate can tolerate the restart.)
Add the service to Uptime Kuma — for substrate agents, a Windows-side "Service is Running" probe is more direct than an HTTP probe since most agents don't expose a status endpoint.

Pitfalls (codified from the 2026-05-30 substrate-formalization session):

Em-dashes in PowerShell scripts crash the parser. Same failure mode as FreePBX form fields. Run scripts through [char]0x2014 → '-' sanitization before commit.
$ErrorActionPreference = "Stop" plus nssm start interacts badly because nssm writes the informational "SERVICE_START_PENDING" line to stderr on slow service starts, and Stop escalates it to a terminating error. Use "Continue" for installer scripts and check the post-state via Get-Service instead of nssm's exit code.
Forgetting agent deps in the shared venv. Each new agent's imports must be installed in the context-loader venv (or wherever the chosen substrate venv lives) before service start, or the agent runs in silent partial-data mode without crashing. accounting-daily's duckdb dependency was missing on first install, so the agent ran cycle #1 with entities=0/6 instead of 5/6 — no crash, no warning at the service level, only a WARNING: No module named 'duckdb' line in the structured log. Check the agent's first 2-3 cycles for WARNING/MISS lines, not just "is the service Running."
UAC matters for nssm install/set/start/restart. All of those require Administrator. Either run the install script from an elevated terminal or use Start-Process powershell -Verb RunAs to trigger a single UAC prompt.

5. Canonical examples¶

strategy.copperstatetruckparts.com — MkDocs at D:\claude_www\projects\enterprise\, built to D:\www\www-strategy\, IIS site strategy, CF CNAME proxied, Access-gated with brandon@ allow policy. Reference architecture for "MkDocs + IIS + Access."
PBX trunk on LXC 108 — FreePBX 17 + VoIP.ms trunk wired manually through the UI (the voipms_trunk_setup.sh SQL script is broken for FP17; see Failure mode below). Canonical procedure in D:\claude_www\framework\runbooks\runbook_voipms_trunk.md.
Cloudflare Email Routing on cactustruckparts.com, ironmesa.com, imusa.com, copperstatetruckparts.com — catch_all → Brandon's inbox. Reference for "new entity mail" provisioning. seq.com deliberately excluded (Google Workspace tenant).
Four substrate-native NSSM services on SEQ-WWW — canonical pattern for substrate agent wrapping. All run from D:\Projects\context-loader\.venv\ python, with logs at D:\var\log\<agent>\, throttle 5000, delayed-auto start:
claude-am-agent (Brandon-facing MM bot; 60s cycle production cadence via AM_AGENT_SHADOW=0 AM_AGENT_DEMO=0)
claude-accounting-daily (qb-warehouse reader; 4h cycle via ACCT_DEMO_MODE=0; depends on duckdb in the venv)
claude-amp-discovery (synthetic lot evaluation; 300s sleep between cycles)
claude-substrate-monitor (self-observer; 60s tick)
.secrets/voipms/README.md — canonical pattern for per-vendor secrets index (DID inventory + rotation cadence + sub-account routing notes).
.secrets/cloudflare/wdm-cactus-token.txt — canonical pattern for a per-manager, per-zone, minimum-privilege CF token (Cache Purge + DNS Edit + Zone Settings Edit, scoped to a single zone). Provisioned via CF dashboard "Create Custom Token" — programmatic mint via my omni-token is blocked (omni lacks API Tokens:Edit permission). Reference for "WDM/other-manager scoped credential."
PJSIP trunk cross-region failover (FP17 specific) — set aor_contact keyword in the pjsip table to a comma-separated list (e.g. sip:[email protected]:5060,sip:[email protected]:5060). FreePBX's autogen of pjsip.aor.conf honors this verbatim; Asterisk qualifies all listed contacts and routes around any that go Unavail. The _custom.conf / _custom_post.conf override approach does NOT work — Asterisk PJSIP duplicate-section handling keeps only the autogen-defined contact.
CF Access org bootstrap (2026-05-27) — Zero Trust Free plan activated; team domain copperstatetruckparts.cloudflareaccess.com. Reference for "first-time ZT setup."
C4000BZ gateway audit pattern (2026-06-01) — CenturyLink C4000BZ admin UI at https://192.168.1.1/ (self-signed cert; bypass with thisisunsafe in Chrome). Admin password at D:\claude_www\.secrets\network\c4000bz-admin.pw.txt. Authoritative pages for exposure surface review: /advancedsetup_advancedportforwarding.html, /advancedsetup_dmzhosting.html, /advancedsetup_remotegui.html, /advancedsetup_remotessh.html, /advancedsetup_applications.html, /advancedsetup_upnp.html. Reference for "periodic public-exposure audit."
DC-hop pattern for UAC-free local admin on SEQ-WWW (2026-06-05) — to perform an admin action on SEQ-WWW from a non-elevated session, instead of triggering UAC: Invoke-Command -ComputerName SEQ-DC01 -Credential $daCred then nested Invoke-Command -ComputerName SEQ-WWW.ad.... -Credential $daCred. The DC→WWW hop is normal WinRM (not hairpin), and SEQ-WWW receives the command running as DA with full local admin. Works for cloudflared config edits, IIS reconfigs, scheduled-task registration as alternative identities. No interactive UAC prompts.
Truck-photos canonical library pattern (2026-06-04) — master copy on TrueNAS (Pool_1/truck-photos, SMB share truck-photos), Brandon uploads via \\seq-truenas\truck-photos\trucks\<stock_id>\, hourly local-cache via robocopy to D:\www\www-photos\ on SEQ-WWW (or manual "Sync Truck Photos.bat" on desktop), IIS site photos serves the local cache fronted by CF Tunnel + DNS at photos.copperstatetruckparts.com. ZFS snapshots daily 3am 90-day retention on Pool_1/truck-photos. Reference for "shared media library across multiple brand sites."
Estate drive-map auto-heal pattern (2026-06-05) — replaces flaky GPP Drive Maps. Scheduled task Claude-Map-Drives-AtLogon registered on every AD-joined host via D:\stage\drive-maps\deploy-logon-task.ps1; runs the net use script at every user logon. Idempotent; self-heals drift. Deploys: BRANDON1 + BRANDON2 + QBHOST + SEQ-WWW (LAPTOP1 pending online). Reference for "ensuring estate-wide user state across all interactive sessions."

6. Failure modes¶

Failure: voipms_trunk_setup.sh SQL script broken on FreePBX 17 (2026-05-27)¶

What went wrong: Attempted to use the community VoIP.ms trunk-bootstrap SQL script on FreePBX 17 + Asterisk 22.8.2. The script assumes a legacy schema where pjsip table rows have an auto-increment integer key. FP17's actual schema is a composite primary key (trunkid, tech, channelid) with no auto-increment. Inserts failed silently and left the trunk in a broken half-configured state.

When it happened: 2026-05-27, during VoIP.ms DID 602-217-0488 provisioning.

Why it happened: The script was authored for FreePBX 15/16. I trusted the GitHub README without sanity-checking schema compatibility against the current FP version.

The fix: Drive the FreePBX UI instead — the trunk wizard handles the composite-key insert correctly. Runbook updated at D:\claude_www\framework\runbooks\runbook_voipms_trunk.md with the ⚠️ warning at the top and the full canonical UI procedure below. Any future PBX trunk work goes through the UI, not the SQL script.

Failure: CF Access 403 without active Zero Trust org (2026-05-27)¶

What went wrong: Tried to create the first Access application via API before the Zero Trust organization was activated on the account. Every POST /accounts/<acct>/access/apps returned 403. I assumed a token scope problem and burned cycles widening token scope.

When it happened: 2026-05-27, during strategy.copperstatetruckparts.com auth-gate buildout.

Why it happened: Zero Trust is a separate product activation on the CF account, not just a token capability. A token with Access:Apps:Edit can't write Access apps if the org doesn't exist yet — there's nothing to write into. The activation has to happen through the dashboard checkout flow (Free plan, but still a flow).

The fix: Brandon manually completed the ZT Free-plan activation through the dashboard. After activation, the existing token scopes worked. Going forward: when standing up Access on a fresh CF account, the order is (1) activate ZT in the dashboard checkout flow, (2) then create apps via API.

Failure: VoIP.ms DID inbound routing defaulted to main account (2026-05-27)¶

What went wrong: Provisioned DID 602-217-0488 + wired the PJSIP trunk + verified outbound calls worked. Inbound test from Brandon's cell rang "user busy" and the FreePBX inbound routes never fired.

When it happened: 2026-05-27 during the marathon PBX session.

Why it happened: VoIP.ms portal's "Routing" field for a DID defaults to the main account, not whichever sub-account you've configured as the SIP trunk endpoint. The PJSIP trunk on FP17 is auth'd as sub-account 543869_seq-pbx, but the DID was still routing to the main 543869 account — which has no live registration.

The fix: setDIDRouting&did=6022170488&routing=account:543869_seq-pbx via VoIP.ms API. For every new DID provisioned: immediately set routing to the intended sub-account, don't trust the portal default. Codified in gotchas.md + runbook_voipms_trunk.md.

Failure: CF Email Routing catch_all is PUT not DELETE (2026-05-28)¶

What went wrong: Tried to disable a zone's catch-all forwarding rule by DELETE /zones/<zone>/email/routing/rules/catch_all. API returned 405. I assumed the rule was special-cased to undeletable and worked around it weirdly before finding the real path.

When it happened: 2026-05-28, during bulk Email Routing setup across 5 domains.

Why it happened: The catch-all is a singleton rule on every Email Routing zone — it's not deletable, only re-configurable. The API path is PUT /zones/<zone>/email/routing/rules/catch_all with an updated {enabled, actions, matchers} body. (Or set enabled: false to disable without removing.)

The fix: Use PUT not DELETE for catch_all. Codified in gotchas.md Email Routing section.

Failure: Wazuh ntfy.sh integration spammed ossec.log with 4248 errors (2026-05-30)¶

What went wrong: Wazuh manager's ntfy.sh integration was attempting curl POSTs to a ntfy.sh endpoint that's not reachable from the LXC. Every alert event generated a curl timeout + error log line; ossec.log grew to several MB/hour of pure error noise.

When it happened: Observed 2026-05-30 morning; root cause was an upstream config landed earlier.

Why it happened: ntfy.sh was set up as the alert sink before Mattermost webhook was decided as the canonical route. The integration was never disabled when MM became the standard.

The fix: Same day, two-phase: 1. Bleed-stop AM: XML-commented the <integration> block in /var/ossec/etc/ossec.conf (backup .bak-2026-05-30-pre-ntfy-disable), restarted wazuh-manager. Log spam stopped at 14:01. 2. Proper re-wire PM: replaced with the built-in slack integration pointed at the MM #it incoming webhook (chat.superiorequipmentinc.com/hooks/<token>, URL stored at D:\claude_www\.secrets\mattermost\incoming-webhook-it.url.txt). Initial level=7 threshold flooded #it at ~12.8 alerts/min from Windows logon-noise (level 9). Bumped to <level>10</level> — daily volume from 18,385 → 62 (~2-3/hour, all actionable). Confirmed end-to-end with synthetic alert + direct MM ping returning HTTP 200.

Lesson: when changing the alerting route, (a) disable the old sink in the same change so it doesn't keep noisy-failing, and (b) tune the level threshold separately for the new sink — what's appropriate for a push-notification service (level 7) is unusable for a chat channel where humans read the messages (level 10+).

Failure: CF dashboard SPA hydration 30-60s under MCP browser automation (2026-05-27 through 2026-05-30)¶

What went wrong: Multiple sessions where Claude in Chrome was driving the CF dashboard and clicked the next element before the SPA had hydrated. Click registered on the old DOM, navigation lost.

When it happened: Repeatedly across the v21 marathon — Zero Trust checkout, DID backorder, token scope expansion.

Why it happened: CF's dashboard is a React SPA with route-level code-splitting. After login or after a navigation, the visible UI renders but interactive handlers aren't bound for 30-60 seconds, especially on the /checkout/free flow.

The fix: After any CF dashboard navigation, wait 30-60 seconds (or Ctrl+Shift+R hard reload for checkout flows specifically) before issuing the next click. Codified in gotchas.md Browser Automation section.

Failure: TrueNAS Pool fills, samba tears every SMB session down with misleading error (2026-06-05)¶

What went wrong: Pool_1 on SEQ-TRUENAS hit 96.9% used (28 GB free of 928 GB). At this fill level, ZFS slop-space protection blocks writes. Samba responds by dropping all active SMB sessions and refusing new ones. Windows surfaces this as System error 64 — The specified network name is no longer available (STATUS_NETWORK_NAME_DELETED), NOT as a disk-full error. Took down ALL shares on Pool_1 simultaneously: groupshare (breaking AP daily cron), truck-photos (breaking sync), Profiles$ (would have broken FSLogix for any user not already cached).

When it happened: observed 2026-06-05 ~02:00 PT. Probably accumulated over weeks.

Why it happened: 4-band snapshot retention on Pool_1/backups — 24h + 14d + 8w + 12m — combined with backup workflows that rotate their own files (WSB, vzdump). Each rotation frees blocks in the live dataset, but ZFS snapshots hold onto the prior blocks. After months, the snapshot overhead exceeded the live data: dc01 showed 71 GB live + 189 GB in snapshots. Across all backup datasets, 366 GB locked up as snapshot overhead.

The fix: POST /pool/dataset/destroy_snapshots with body {name: <dataset>, snapshots: {all: true}} per backup dataset. This is a TrueNAS Scale 25.x endpoint; the per-snapshot delete (POST /zfs/snapshot/delete) returns 404 in newer versions. Also killed the 8w and 12m snapshot tasks; kept 24h + 14d.

Lesson #1: Layering ZFS snapshots on top of backup workflows that have their own rotation is mostly redundant — the backup files ARE the point-in-time copies. Reserve snapshots for: live working datasets (Group File Share), datasets where files change in-place (databases), or short-window rollback. NOT for write-once-rotate-out backup destinations.

Lesson #2: Error 64 / "network name no longer available" is the canonical symptom of TrueNAS pool-full. When SMB to TrueNAS fails with this error and ping/DNS/445-TCP all succeed, check Pool_1 free FIRST, not auth/creds. Codified in this doc.

Lesson #3: Bulk snapshot delete API in TrueNAS Scale 25.x:

requests.post(f"{BASE}/pool/dataset/destroy_snapshots",
              data=json.dumps({"name": dataset, "snapshots": {"all": True}}))

Failure: Scheduled task with stored credentials can't auth SMB to TrueNAS reliably (2026-06-05)¶

What went wrong: Tried to set up an hourly Claude-Photos-Sync-Hourly scheduled task on SEQ-WWW that robocopies \\seq-truenas\truck-photos\trucks → D:\www\www-photos\trucks. Task ran as AD\Brandon with stored password (RunLevel Limited and Highest both tested). Every invocation returned "ERROR 64 (0x00000040) The specified network name is no longer available" — both via net use, PSDrive with explicit credential, NetBIOS name, FQDN, and IP. The IDENTICAL net use + robocopy works perfectly in an interactive AD\Brandon session.

When it happened: 2026-06-04/05 truck-photos Phase 2 buildout.

Why it happened: non-interactive logon type used by scheduled tasks with stored passwords doesn't establish the same SMB session context as interactive logon. TrueNAS (or the Windows SMB client when in non-interactive mode) rejects the connection. Not a credential problem — credential file works fine interactively, and the task itself logs as the right user.

The fix (partial): Pivoted to manual sync via desktop shortcut C:\Users\Public\Desktop\Sync Truck Photos.bat that Brandon double-clicks after uploads. Robust because runs in interactive context. Photos uploaded before sync stay only on TrueNAS until Brandon clicks the button. Acceptable for current cadence (a few uploads per week).

Future-proper fixes (not done): - TrueNAS-side cron + rsync over SSH push — TrueNAS pushes to SEQ-WWW via Linux rsync, no Windows SMB context involved. Cleanest. - IIS App Pool identity = AD\Brandon + virtual directory to UNC — eliminates sync entirely; IIS reads UNC directly. Tried; got 500 due to App Pool identity vs virtualDirectory credential interaction. Solvable with more time on App Pool config. - DFS-Replication — overkill for one share.

Codified as a known limitation pattern: scheduled-task→SMB-to-Linux is fragile; prefer interactive sync OR Linux-side push.

Failure: Hand-off PowerShell script with unresolved external command (2026-06-05)¶

What went wrong: Wrote D:\stage\vault\vw-dedup.ps1 for Brandon to run, invoking bw (the Bitwarden CLI installed via npm install -g). The CLI installs to %APPDATA%\npm\ which is on User PATH — but that PATH variable is only refreshed for NEW terminal sessions. The terminal I installed the CLI in had its PATH manually reloaded; Brandon's existing terminal didn't. Script crashed on bw : command not found. Made him run a non-working script. Twice (the first failure was unrelated — PS7 ?? operator in a PS5.1 script).

When it happened: 2026-06-05 Vaultwarden dedup session.

Why it happened: I parse-validated the script's syntax against PS 5.1 but never verified that the external commands (bw in this case) would resolve in Brandon's runtime context. Two distinct correctness checks were collapsed into one.

The fix: Before handing any PowerShell (or batch, or shell script) to a user, run BOTH checks:

Syntax parse in the target shell version:

$errors = $null
$null = [System.Management.Automation.Language.Parser]::ParseFile($scriptPath, [ref]$null, [ref]$errors)
if ($errors) { $errors | ForEach-Object { Write-Host $_.Message } }

External-command resolution for every binary the script invokes:
If installed via npm -g / pip --user / similar, the executable's parent dir may not be on PATH in pre-existing sessions
Use full paths in the script: $bw = "$env:APPDATA\npm\bw.cmd" with Test-Path guard at the top
OR refresh PATH at the script's entry: $env:PATH = [Environment]::GetEnvironmentVariable("PATH","Machine") + ";" + [Environment]::GetEnvironmentVariable("PATH","User")

Standing principle codified: never hand off a script without confirming every external invocation succeeds in a fresh shell of the user's target environment. Parse-clean is necessary but not sufficient.

Also: don't waste the user's time with hand-offs that fail on basic environment issues. The 30 seconds it takes to verify saves them frustration and saves the trust budget.

Failure: C4000BZ admin UI drops radio-state changes between form sections (2026-06-01)¶

What went wrong: During the C4000BZ port-forward audit, attempting to disable both UPnP and UPnP NAT-T in one Apply cycle — clicked Disable on UPnP, clicked Disable on NAT-T, clicked Apply. UPnP saved as Disabled; NAT-T reverted to Enabled.

When it happened: 2026-06-01 C4000BZ public-exposure audit + cleanup.

Why it happened: The C4000BZ admin UI is multiple semi-independent form sections per page. Programmatic radio clicks via Chrome's accessibility-tree click API don't always fire the form's internal change-detection handler for sections beyond the first interaction. The first section's change is captured; subsequent section changes can be lost.

The fix: When the C4000BZ form-state appears to drop a change, set the value directly via JavaScript + dispatch a synthetic change event before clicking Apply:

var r = document.querySelector('input[name="natt-state"][value="off"]');
r.click();
r.checked = true;
r.dispatchEvent(new Event('change', {bubbles: true}));
r.dispatchEvent(new Event('input', {bubbles: true}));

Then click Apply once. Verify by reload + re-read radio states. Codified in §5 as part of the C4000BZ audit reference.

Failure: FSLogix bypass via local Enabled=0 alone is GPO-overwritten (2026-06-01)¶

What went wrong: SEQ-LAPTOP1 was set to HKLM:\SOFTWARE\FSLogix\Profiles\Enabled = 0 to stop FSLogix from roaming Brandon's profile over Wi-Fi (the laptop is a road-warrior; mounting a 30GB VHDX over fluctuating wireless was the root cause of "the entire laptop is slow"). Next gpupdate /force overwrote the value back to 1.

When it happened: 2026-06-01 SEQ-LAPTOP1 finish-out session.

Why it happened: The WS-FSLogix GPO uses Group Policy Preferences (GPP) rather than ADMX-based Administrative Templates. GPP writes directly to the standard FSLogix registry key (HKLM:\SOFTWARE\FSLogix\Profiles) — not to the policies-key (HKLM:\SOFTWARE\Policies\FSLogix\Profiles). So a local override at the standard key gets re-stomped every gpupdate cycle (default 90 min + offset).

The fix: For one-machine exclusion from a GPP-driven GPO, the durable path is explicit deny-apply ACE on the GPO container for that machine's computer account. Pattern (run as Domain Admin via Invoke-Command to a DC):

$gpoGuid = "<guid>"  # the GPO's ObjectGUID
$gpoDn = "CN={$gpoGuid},CN=Policies,CN=System,DC=<domain-dn>"
$applyGpExtRight = [Guid]"edacfd8f-ffb3-11d1-b41d-00a0c968f939"  # well-known
$targetSid = (Get-ADComputer "TARGET-MACHINE").SID

$obj = Get-ADObject -Identity $gpoDn -Properties nTSecurityDescriptor
$acl = $obj.nTSecurityDescriptor
$ace = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
  $targetSid,
  [System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight,
  [System.Security.AccessControl.AccessControlType]::Deny,
  $applyGpExtRight
)
$acl.AddAccessRule($ace)
Set-ADObject -Identity $gpoDn -Replace @{nTSecurityDescriptor = $acl}

Then gpupdate /target:computer /force on the target machine; verify via gpresult /R /SCOPE COMPUTER that the GPO appears under "GPOs were not applied because they were filtered out — Filtering: Denied (Security)".

Codified in §3 as a new convention: road-warrior laptops are deny-applied from any LAN-only GPO (FSLogix roaming, file-share-dependent printer mappings, etc.). The cleaner long-term pattern (untaken in this turn) would be a separate OU=Laptops outside the OU=Workstations GPO scope, but the per-machine deny-ACE is correct for a one-off and obvious to other admins inspecting the GPO.

Failure: NSSM CLI multi-arg env-var silently drops values (2026-05-30)¶

What went wrong: When formalizing the four substrate agents into nssm services, set AppEnvironmentExtra with two env vars via nssm set <svc> AppEnvironmentExtra "AM_AGENT_SHADOW=0" "AM_AGENT_DEMO=0". Only the first var landed. AM-agent came up running at AM_AGENT_DEMO=1 (default-on demo mode) which is 30-second cycle cadence instead of the production 60-second cadence. No error from nssm. Verified by nssm get + by the agent's structured log: cycle interval: 30s (demo) vs the expected 60s (production).

When it happened: 2026-05-30 substrate-formalization session.

Why it happened: The nssm version on SEQ-WWW handles AppEnvironmentExtra with multiple positional args by storing only the first. The +AppEnvironmentExtra (append) form has cross-version reliability issues. Neither documented; both observed empirically.

The fix: Skip the nssm CLI for multi-var env. Write the registry value directly as REG_MULTI_SZ then restart the service:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\<svc>\Parameters" `
  -Name "AppEnvironmentExtra" -Value @("FOO=1","BAR=2") -Type MultiString -Force
Restart-Service -Name <svc> -Force

nssm get reads the value correctly afterwards, and the agent inherits the full env on restart. Codified in Playbook E.

Failure: AD\Brandon is NOT Domain Admin — DC ops need AD\Administrator (2026-06-08)¶

What went wrong: Tried to Invoke-Command SEQ-DC01 with AD\Brandon credentials. Access Denied. Same for DC02, same for SMB admin$ and WMI. Logged as a regression task because the same pattern worked for cloudflared edits two weeks earlier.

Why it happened: At some point between v17 (2026-05-17) and 2026-06-05, Brandon's account was deliberately moved from Domain Admins to a custom Domain-Admins-Restricted group. Tier-0 hardening — Brandon retains full local-admin reach on every Windows member server (via Restricted Groups GPO), but cannot administer the DCs themselves. The sole member of Domain Admins is now the built-in Administrator account.

Diagnostic chain that surfaced it (use this pattern for any "credentials work some places, fail others" problem):

1. LDAP bind as the suspect user — succeeds → password is current
2. SMB admin$ to the host — fails → not in BUILTIN\Administrators on the host
3. WMI to the host — fails → confirms admin denial, not WinRM-specific
4. LDAP query for the user's `memberOf` — empty/short → group membership stripped
5. LDAP query for Domain Admins `member` — small set → confirms who's in

The fix: Saved AD\Administrator password to .secrets/ad-users/administrator.pw.txt. DC-hop pattern lives — it just needs AD\Administrator for the SEQ-DC01 leg, not AD\Brandon. Built D:\stage\dc-hop-runner.ps1 as a reusable library: wraps Invoke-Command → SEQ-DC01 (AD\Administrator) → target.fqdn (AD\Administrator) so any admin action on any member server runs unattended. Standing rule: don't undo the tiering — it's good design. Rotate the Administrator password under stricter controls than Brandon's.

Failure: vzdump rsync via CIFS-mounted tmpdir fails for LXCs with containerd/venv content (2026-06-06 → 2026-06-08)¶

What went wrong: Friday's vzdump fix moved Proxmox's rsync staging tmpdir from /var/tmp (root partition, 5G free) to a NAS-mounted /mnt/pve/truenas-backup/dump/.vzdump-tmp. Worked for small LXCs. Monday's nightly hit LXC 107 (frigate) and 112 (sd) — both have many small files (containerd snapshots, Python venvs) — and spammed Operation not supported (95) errors for 9 hours before vzdump finally gave up. Other LXCs got skipped because the job wedged.

Why it happened: CIFS doesn't support the POSIX syscalls rsync uses for full fidelity backup — specifically utime (set mtime), setacl, and setxattr. For LXCs with mostly large files (few hundred), rsync skips these errors and proceeds. For LXCs with thousands of small files (containerd layers, Python site-packages), the per-file overhead of error-handling each one creates the 9-hour wedge. Proxmox's tmpdir: config IS being respected — the failure is at the filesystem-protocol layer.

The fix: Reverted /etc/vzdump.conf tmpdir, added a SECOND vzdump job at 03:30 with --mode stop for LXCs 107 + 112 (excluded from the 02:30 snapshot-mode job). Stop-mode shuts the LXC down briefly (~30s each), tar-archives the rootfs block-level — no rsync syscalls involved, just a stream-to-tar that CIFS handles fine.

Standing rule: when adding a new LXC, if its rootfs is going to contain containerd OR many-small-files Python venvs, default it to the stop-mode job. The brief downtime is worth the reliability. Use snapshot mode only for LXCs whose content rsync handles cleanly over CIFS.

Failure: Kuma DB 9.4 GB — runaway push monitor, NOT slow heartbeat growth (2026-06-06)¶

What went wrong: Found Kuma silently wedged (3^rd recurrence). DB at 9.4 GB. First instinct was "retention isn't enabled — set 30-day, VACUUM." DB size didn't change.

Why it happened: Three accounting push monitors (IDs 26/27/28) had retry_interval=0. When the AM-agent stopped pushing, each monitor logged "no heartbeat in time window" 3 times per second. 6.9M heartbeat rows in 26 days — one runaway producer was 99% of the DB. Retention was already set; it just wasn't culling anything because nothing was 30 days old yet.

The fix: Disabled the 3 monitors, deleted accumulated heartbeats, VACUUM → DB went 9.4 GB → 13 MB. Set retry_interval=60 so re-enabling them later won't reintroduce the runaway. Codified the diagnostic in feedback_kuma_runaway_was_data_not_growth.md.

Standing rule: when investigating any DB bloat in any system, profile the producer side before tuning the consumer. GROUP BY the natural producer dimension (monitor_id, agent_id, user_id, customer_id) sorted desc. If one source has ≥80% of rows, that's the runaway. Retention is the wrong lever when the producer is broken.

Failure: vzdump nightly job + new Kuma watcher silently broken by joined cron line (2026-06-06)¶

What went wrong: probe_pool1.sh (TrueNAS Pool_1 fill watcher we deployed 2026-06-05) had never fired from cron. Pool went to 96.9% before manual catch.

Why it happened: /etc/crontab had two cron entries joined onto one line without a newline. Cron interpreted the whole mess as one schedule running probe_kuma.sh with bogus extra args, and probe_pool1.sh never ran.

The fix: Rewrote crontab via base64 to split the joined entries. Both watchers now fire on schedule.

Standing rule: any script that appends to /etc/crontab MUST verify with cat -A after to confirm the trailing newline is in place. Or use proper crontab -e syntax.

Failure: SYSTEM-context scheduled task cannot DC-hop on Server 2025 (2026-06-08)¶

What went wrong: Built a SEQ-LAPTOP1 onboarding watchdog that runs every 10 min as SYSTEM, using DC-hop to install Wazuh + drive-map task when the laptop comes online. Task reported 0xFFFD0000 (still-running) forever — never finished.

Why it happened: SYSTEM-context PowerShell calling Invoke-Command → SEQ-DC01 -Credential AD\Administrator hangs because NTLM is hardened on Server 2025 (defaults to disabled in new domains), Kerberos requires a TGT for the calling identity (SYSTEM has no AD identity), and explicit -Credential doesn't override the underlying auth flow cleanly when the target is a DC. Negotiate silently waits.

The fix: Rewrote the watchdog to use direct WinRM as AD\Brandon (no DC-hop). The target (SEQ-LAPTOP1) is a member server where Brandon is local admin via Domain-Admins-Restricted. Direct WinRM works fine. Removed the dc-hop-runner.ps1 auto-smoke that was hanging when the file was dot-sourced (added $MyInvocation.InvocationName -ne '.' guard).

Standing rule: DC-hop is for tasks that genuinely need DC admin context (GPO edits, AD object changes, schema mods). For everything else — installs/configs/scheduled-task creation on member servers — use direct WinRM as AD\Brandon. SYSTEM-scheduled-tasks should avoid DC-hop entirely; use a user-context principal if elevation is needed at the DC level.

Failure: PBX LXC 108 thrashing 13 days on undersized memory (2026-05-27)¶

What went wrong: When I first SSH'd in to wire the VoIP.ms trunk, the LXC was load-average 33 with 441MB swap on a 2GB total. The container had been silently degraded for ~13 days; calls were dropping intermittently.

When it happened: Discovered 2026-05-27; degradation onset ~2026-05-14.

Why it happened: Original LXC was provisioned at 2GB RAM + 512MB swap when FreePBX 17 actually needs 4GB+ for a healthy install. Uptime Kuma was monitoring the SIP registration, which kept registering, so no alert fired. The host CPU graphs showed the LXC pinned, but nothing was reading them.

The fix: pct set 108 -memory 4096 -swap 2048 + reboot. Load dropped to 1-2, swap to 0. Standing rule: every LXC gets a memory + swap monitor in Wazuh (not just a service-up monitor in Uptime Kuma) so silent resource starvation surfaces.

7. When to escalate¶

Most IT work doesn't escalate. The playbooks handle deploys, auth gating, credential provisioning, service wrapping. Escalate only for:

Money:

New domain registration or transfer-in (CF Registrar fees, premium TLDs)
New Supabase project past Free tier (Pro upgrade $25/mo per project)
DID purchases beyond the parked inventory at VoIP.ms
Any vendor plan upgrade (CF Pro/Business, Resend Pro, Tailscale teams, Wazuh Cloud)
Hardware purchase (server, switch, firewall, phone, runtime license)

Irreversible / blast-radius:

Deleting a CF Access application or policy that's actively gating production traffic
Deleting a production DNS record (apex A, MX, primary CNAME)
Decommissioning a domain (vs letting it lapse at renewal)
Phone number port-out from VoIP.ms
Deleting a Supabase project (data loss)
Removing a Windows service that other services depend on
Estate-wide password rotation (gated on Vaultwarden being fully operational)

Compliance / trust boundary:

Adding a new email to a CF Access allow policy (not just brandon@ — any new identity)
Granting cross-arm access to a credential or system
Anything that touches financial data, customer PII, or banking
TOS acceptance for any new vendor (even free-tier)
SSO/OAuth flow for any account

Operational unknowns:

Multi-vendor cutover where the rollback path isn't pre-validated (port-in to Flowroute is the live example)
Any change to FreePBX dialplan that affects outbound CID or inbound routing for live numbers
Any change to mail records on a domain with active mailflow (SPF/DMARC tightening that might block legit senders)

Out-of-scope architecture decisions:

New entity provisioning that doesn't have a documented OM-side charter
Substrate-agent deployment that doesn't have a documented author/owner
Adding a new monitoring vendor when Uptime Kuma + Wazuh already cover the gap

Everything else: execute the playbook. Don't ask Brandon to confirm what's already in Section 3 or Section 4. Trust the playbook.

Living document. Last updated 2026-05-30 by claude-it-manager (v0.1). Revisions land as operational reality reveals patterns not yet captured here.