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.

clients/glaztech/reports/2026-06-05-tom-message-draft.md

@@ -6,32 +6,42 @@
 
 ---
 
-**Subject:** Glaztech site — what we're handling, and the one spot we'd love your help
+**Subject:** Glaztech site — we're in this with you
 
 Hi Tom,
 
-First off — thanks for everything you've kept running on the site over the years. It's a lot, and the
-last thing we want is to pile onto your plate. So here's the plan: **we're taking the heavy lifting on
-the security side ourselves.**
+We know the last few days have been stressful — the security scan dropped a real bomb in your lap, and
+we don't take that lightly. Believe me when I say we're here to help: to keep Glaztech safe, and to help
+**you** with the security side of the network and the site. You've kept this running for a long time — we're
+not here to second-guess any of that. We're here to take the security weight off your shoulders and work
+it *with* you.
 
-On our side — you don't need to touch any of this:
+Here's the reassuring part, now that we've had time to dig in: **this doesn't have to be a fire drill.**
+What the deeper look showed is that the site, the GTIware tools, and the database all tie together pretty
+tightly — and *because* of that, the right move is a calm, staged plan, not a rushed scramble. We handle
+the urgent, self-contained pieces on our side right away, and work through the rest methodically,
+together, without disrupting your day-to-day or your billing.
+
+So here's what we're proposing.
+
+The heavy infrastructure security is squarely our lane, and we'll carry it:
 - Locking down the server and tightening the database permissions
 - Putting a web application firewall in front of the site
 - Tightening the network/firewall around the database server
 
-There's **one** place where your hands are really the right ones. There's a specific set of **~59 older
-SQL queries** in the site that build their statements by stitching text together. We'd like to switch
-those to use parameters instead — it's the single highest-value code change for hardening the site, and
-it's a contained, repetitive update (no redesign, no new frameworks). **We'll hand you the exact list —
-the files and line numbers — so you're not hunting for them.** If it's easier, we'll hop on a quick call
-and walk the list together.
+And there's one place where your knowledge of the app is exactly what's needed — and where we'd be working
+side by side with you. There's a specific set of **~59 older SQL queries** in the site that build their
+statements by stitching text together; switching those to use parameters is the single highest-value code
+change for hardening the site. It's contained and repetitive — no redesign, no new frameworks. **We'll
+hand you the exact list — files and line numbers — and walk it with you on a call if that's easier**, so
+it's a real collaboration, not a hand-off.
 
-There is a bigger item further down the road — modernizing how saved cards/payments are handled — but
-that's a project we'll plan and scaffold **with** you when there's bandwidth. No rush, and we'll do the
-legwork around it; it's not something we're asking you to take on right now.
+Down the road there's a bigger item — modernizing how saved cards/payments are handled — but that's a
+project we'll plan and scaffold **with** you when there's bandwidth. No rush; we'll carry the legwork.
 
-That's really the whole ask for now: the 59 queries (with the list in hand), and we cover the rest.
-Let me know what works for the walkthrough.
+Bottom line: you're not on the hook to become a security expert overnight, this isn't a five-alarm
+scramble, and you're not in this alone. We've got the infrastructure side, we'll hand you a clear, bounded
+list for the code piece, and we'll work it together at a sane pace. Let me know a good time to connect.
 
 Thanks,
 Mike / Arizona Computer Guru