glaztech: staged-remediation pacing strategy + Steve approval + softened Tom message

Adds the "from emergency to deliberate staged objectives" pacing strategy
(severity unchanged, tempo deliberate - the depth of the Glaz tools estate makes
rushing the bigger risk) and records Steve's blanket approval (Tier A
execution-cleared). Softens the Tom outreach to a partnership / not-a-fire-drill
tone per Mike.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>

clients/glaztech/reports/2026-06-05-segmentation-minimal-tom-path.md

@@ -12,6 +12,18 @@ Tom built and has owned this application for ~20 years; it is his baby. He is **
 3. **Real, not cosmetic** — the minimal-Tom path must actually cut the C0 blast radius.
 4. **Protect the relationship** — don't hand Tom the threat model as a to-do list; frame it as "we'll handle the hard parts; we need your help on these few specific things."
 
+## Strategy & pacing — from "emergency" to deliberate staged objectives (2026-06-05)
+
+Up to now this engagement has been framed as RED-FLAG / EMERGENCY — which was right when we believed it was a *website* problem. The deeper recon changed the calculus: this is the whole **Glaz tools ecosystem** — the public website **+ GTIware/portal + the in-process card engine + a centralized SQL estate wired into accounting and payroll across 10 offices.**
+
+**Reframe: severity is unchanged; tempo changes.** The findings are still genuinely critical (stored CVV, plaintext PANs, SQLi running as sysadmin) — we are not downplaying the risk. But **precisely because the system is this deep and interconnected, hair-on-fire speed is the thing most likely to cause real damage.** A rushed fix risks breaking live billing, accounting, payroll, and customer payments — the 06-05 outage from a "simple" hardening change is the proof. If this were *just* a website, the emergency tempo would still be right; it isn't, so getting it right matters more than getting it fast.
+
+**We split the work by blast radius:**
+- **Move fast (emergency-appropriate) on the CONTAINED, reversible, ACG-owned items** — the E-bucket (disable `xp_cmdshell`, rotate the `msdb` domain-admin password, disable `sa`, de-priv the Agent), WAF, SQL network segmentation. These shut the worst escalation paths quickly with low risk to the business.
+- **Go deliberate and staged on the DEEP app/data work** — the DB de-priv proof-out, the 59-query fix, tokenization, engine decoupling. Each one staged, validated, and reversible — not rushed.
+
+This is the **defensible** posture for a critical-but-complex environment: identify the risk, contain the immediate escalation fast, then remediate the structural issues in careful, validated stages rather than risk an outage that takes the business down. **Client-facing messaging should reflect this calm, in-control, staged tone — not perpetual alarm.** (It also serves the "don't break Tom" goal: a staged plan is something an overwhelmed dev can engage with; a five-alarm fire is not.)
+
 ## Authorization & status (2026-06-05)
 
 - **Steve Eastman has given ACG blanket approval to execute whatever remediation actions are necessary — no per-action re-authorization required.** So the ACG-owned **Tier A** work below (E-bucket, DB de-privilege, WAF, SQL network segmentation) is **authorized to proceed**, applying the engineering discipline the 06-05 outage reinforced (backup + real-binding health check + one-step rollback; no in-place hotfixes). Risky DB/AD steps still get done carefully — Steve's approval covers authorization, not the care.