digigrow-atlas

- [Zach Profile](user_profile.md) — Vibe coder, DigiGrow co-founder (with Austin), ships fast via Claude Code
- [Atlas V2 Decisions](project_atlas_v2_decisions.md) — Category-based permissions, magic link auth, clean user model, Python engine extraction
- [GHL Migration](project_ghl_migration.md) — Replacing HubSpot with Go High Level; research docs in docs/plans/
- [GHL Decisions](project_ghl_decisions.md) — Clean cut, API-based booking, sync only on meeting booked, GHL is source of truth
- [GHL Account Map](project_ghl_account_map.md) — Location, pipeline, calendar, custom field IDs from live API scan
- [Calendar Config UX](feedback_calendar_config.md) — Calendar selector lives in developer settings, fetches live from GHL
- [Audit Decisions](project_audit_decisions.md) — Dead endpoints→remove, banking plaintext→leave, dev flag→intentional, HubSpot→drop
- [Design Skills — Use Aggressively](feedback_design_skills.md) — Invoke impeccable + frontend-design skill suite up front for ALL Atlas UI work, including internal/ops surfaces
- [Lead Landing Pages](project_lead_landing_pages.md) — 16 per-lead closing-call mockup sites; template + Stripe deposit widget (£397.50 internal, never displayed); schema drift in 3 leads
- [Engine MiniMax Live](project_engine_minimax_live.md) — Engine LLM is MiniMax-M2.7-highspeed via Token Plan as of 2026-05-01. Hard cutover, no Claude fallback, verified working.
- [Engine v1.4 Shipped](project_engine_v14_shipped.md) — Scrapling + VLM + web search + structured extraction landed 2026-05-13; 4945 leads reenriched; engine STOPPED pending operator po…

---
name: autonomous-execution-on-atlas
description: "For Atlas infra work where Zach has authorized execution (\"DO IT URSELF you have infra access\"), stop asking confirmation between steps — push, deploy, run scripts, fix issues inline, surface only at hard checkpoints (data destruction, prompt sign-off, completion)."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: acae237b-8d3f-4681-88fc-3c228db98b7d
---

When working on Atlas infra (Coolify deploys, scripts, migrations, env var changes) and the user has explicitly authorized autonomous execution, drop the "ready to commit?" / "should I deploy?" checkpoints and just do the work. Verbal triggers: "just do the damn fixes bro", "DO IT URSELF you have infra access", "stop asking me stuff from now on, just get it sorted".

**Why:** During the v1.4 engine quality pass rollout (2026-05-12 → 2026-05-13), I kept surfacing "want me to commit?" and "should I push?" between every code-and-deploy chunk. The user shut that down twice in the same session. They were happy to grant scope upfront and wanted me to execute end-to-end — push code, configure Coolify, run scripts, fix issues as they surfaced, just keep moving.

**How to apply:**

- Use the credentials at `~/.claude/credentials/digigrow-infra.md` to drive Coolify API, SSH (`digigrow-new` alias), Cloudflare, GHL directly
- Push to `origin/master` without asking — pushes don't auto-deploy (Coolify needs explicit `POST /api/v1/deploy?uuid=...`)
- Fix issues inline as they surface (e.g. missing dep like `scrapling[fetchers]` extras → single-line requirements.txt…

---
name: feedback-brainstorm-vs-gsd-quick
description: "For small well-scoped Atlas features, skip the brainstorming-skill section-by-section ceremony and route directly to /gsd-quick once the use case + key decisions are clear."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: c363d5a9-f7e8-48d7-8a13-3ac2747422c2
---

For small, well-scoped Atlas features (single-cog, single-service, clear use case), don't drag Zach through the full brainstorming-skill flow (clarifying questions → 3 approaches → architecture / data / commands / listener / errors / testing sections each gated on approval). Once the key product decisions are answered, route straight into `/gsd-quick` and let it run.

**Why:** Mid-design on the Discord forum-post-ping feature (2026-05-16), after he'd already answered the use case, ping-target, admin gating, and reason-scope questions and approved approach A, he pushed back with "bruh, it's not a complicated feature, just use /gsd-quick and make it." He treats brainstorming overhead as friction when scope is obvious.

**How to apply:**
- For Atlas tasks scoped to a single file or single cog, with a clear use case and no unresolved architectural choices, default to `/gsd-quick` (or `/gsd-fast` for trivial).
- Use the brainstorming skill's clarifying-questions phase to *lock decisions fast* — then jump to execution. Skip "Propose 2-3 approaches" + the multi-section design walkthrough unless there's a genuine architecture fork.
- If Zach genuinely wants a design conversation, he'll ask for `/gsd-plan-phase`, `/gsd-discuss-phase`, or `/shape`. D…

---
name: Calendar config UX preference
description: GHL calendar selection should be configurable in developer settings, fetched live from GHL API
type: feedback
---

The GHL calendar used for booking should be configurable in the **developer section of the main Atlas dashboard** (not in Lead Finder or CPT).

**Why:** Calendars may change, and the team wants to switch without code deploys.

**How to apply:** Build a calendar selector that fetches all calendars live from GHL API on page load + a reload button. Store the selected calendar ID in app_settings. The booking flow reads from this setting.

---
name: Design Skill Suite — Use Aggressively
description: For any frontend/UI work in DigiGrow Atlas, invoke the impeccable skill suite (and related design/copy/CRO/animation skills) up front, not as an afterthought
type: feedback
originSessionId: 6f7a69e7-ae9c-43e3-a779-d3cf65fb1e7c
---
For any frontend or UI work on DigiGrow Atlas — new components, redesigns, internal admin/ops panels, even "small" UI patches — invoke the `impeccable` skill suite at the start of the task, alongside the broader design/copy/CRO/animation skill groups documented in `~/.claude/instructions/skill-composition.md`.

**Why:** Zach explicitly asked on 2026-04-27, mid-launch, after I drafted a plain-vanilla "Live Workers" panel for the Engine Dashboard. The default is to write functional shadcn cards with no visual identity — that's "generic AI aesthetic" and doesn't match the bar he wants Atlas held to. Internal-ops surfaces (engine dashboard, admin pages, debugging tools) still need real design taste, not just functional layouts.

**How to apply:**
- Invoke `impeccable` (and `frontend-design` / `human-grade-frontend-design` / `design-taste-frontend` / `high-end-visual-design` / `ui-ux-pro-max` / `senior-ui-ux` as relevant) BEFORE writing the JSX, so the skill's rules shape the implementation rather than getting bolted on as polish.
- For polishing existing UI, layer on `polish` / `typeset` / `layout` / `colorize` / `critique` / `audit`.
- For motion / interactions, layer on `gsap-*` / `motion-dev-animations` / `delight` / `animate`.
- For any user-facing copy that lands in the UI (button label…

---
name: paid-api-cost-surfacing
description: "Before locking any decision that authorizes paid external API calls (Google Places/Maps, anything billed per-request), compute and surface the actual total £/$ cost — not the per-call abstraction. For re-enrichment, default to preserving previously-fetched fields, not re-fetching."
metadata: 
  node_type: memory
  type: feedback
  originSessionId: acae237b-8d3f-4681-88fc-3c228db98b7d
---

When proposing a decision that involves paid external APIs, compute the **total cost across the actual cohort** and surface that in the decision prompt — not "1 extra API call per lead" or other per-unit abstractions that hide the bill.

**Why:** During the v1.4 engine quality pass (2026-05-12 → 2026-05-13), decision #3 ("skip the qualification gate on re-enrichment") locked `force_place_details=True` so every keeper got fresh Place Details. I framed the cost as "~1 extra Places call per ungated lead". The real number: Google Places Details with `FIELD_MASK_ENTERPRISE` costs **$0.020/call**, and 4945 × $0.020 ≈ **$99 / ~£78** charged to the DigiGrow Google Cloud account. Zach's cost watchdog drained. The data was already in `enrichment_data.reviews_raw` from the previous enrichment run — `_enriched_lead_from_db()` discarded it and forced a refetch. He was rightly angry.

**How to apply:**

- Before locking a decision, do the math out loud: `calls/lead × cost/call × cohort size = £total`. Put the £ in the question, not just "extra API calls". Example: "Skip the gate → 4945 × $0.020 Place Details = ~£78 in Google Cloud charges."
- **Default mod…

---
name: Atlas V2 Architecture Decisions
description: Key decisions made during the Atlas platform overhaul planning session (2026-04-08)
type: project
originSessionId: 1f308f72-01d2-4bd7-8ed2-ff1b5a383535
---
Major architectural overhaul of Atlas planned. Key decisions:

**Permission Model:**
- Platform roles: developer (Zach), admin (Austin), member (everyone else)
- App categories group apps (sales, support, ops). Users assigned to categories with a role (manager/member).
- Category manager = admin in all apps in that category. Category member = standard user.
- Per-app overrides available for granular control
- Apps have adaptive views based on role (not separate admin/user apps)
- Permissions managed entirely within Atlas, NOT via Discord roles

**Auth:**
- ONLY method: email magic links via SMTP (DigiGrow's own mail server). No passwords.
- Discord OAuth removed entirely (temporarily). Zero Discord auth dependency.
- Account creation: staff adds user → invite email → magic link → mandatory profile completion → active
- Sessions: server-side tracked, 1-week expiry, device/IP tracking, revocable

**User Model:**
- Clean User table: identity + platform_role only
- App-specific data moves to profile tables (ColdCallingProfile, ContractorProfile, etc.)
- Commission tiers replaced by flat commission amounts (just a number)
- Graduation system completely removed
- Teams completely removed
- WebSocket presence completely removed (replaced by last_active on sessions)

**Migration:**
- Fresh start, NOT incremental migration
- Old DB backed up, leads migrated (paid for via LLM …

---
name: Audit decisions (2026-04-07)
description: Decisions from full-system audit — dead endpoint cleanup, banking data, developer flag, HubSpot columns
type: project
---

From the comprehensive 8-agent system audit on 2026-04-07:

1. **Dead frontend API calls** (`analyze-website`, `discover-owner`, `detect-website-type`) — REMOVE from frontend. These were planned features never built; clean up the dead code.
   **Why:** Endpoints don't exist on backend, will always 404.
   **How to apply:** Delete the functions from `frontend/src/apps/lf/api/leadsApi.ts` and any UI that calls them.

2. **Banking data in plaintext** — LEAVE as-is for now. No immediate plan to encrypt.
   **Why:** Acknowledged risk but not prioritized.
   **How to apply:** Don't create encryption migrations or vault integrations unless explicitly requested.

3. **`is_developer` flag bypassing admin hierarchy** — INTENTIONAL. Not a security hole.
   **Why:** Developer access is designed to bypass normal permission enforcement.
   **How to apply:** Don't flag this as a security issue in future reviews. Keep the bypass.

4. **HubSpot columns** — SAFE TO DROP. Create Alembic migration to remove `hubspot_contact_id`, `hubspot_company_id`, `hubspot_deal_id` from Lead model.
   **Why:** System migrated to GHL; no legacy data needs preserving.
   **How to apply:** Remove columns from model + create drop migration + clean up frontend type references.

---
name: Engine LLM is MiniMax-M2.7-highspeed (live since 2026-05-01)
description: The Atlas engine no longer uses Claude. All four LLM stages call MiniMax via the Anthropic-compat endpoint. Token Plan key, instructor tool-use mode, no fallback.
type: project
originSessionId: 9c700ddc-b1b1-4134-a40a-d141aab8f10d
---
The engine LLM swap shipped and is verified working in production as of 2026-05-01.

## Working configuration

- **Provider:** MiniMax (Token Plan, Max High-Speed business sub)
- **Endpoint:** `https://api.minimax.io/anthropic` (international)
- **Key prefix:** `sk-cp-` (Token Plan — NOT interchangeable with MiniMax pay-as-you-go API keys)
- **Model:** `MiniMax-M2.7-highspeed`
- **SDK pattern:** `anthropic.AsyncAnthropic(base_url=..., api_key=...)` wrapped in `instructor.from_anthropic(...)` at default `Mode.ANTHROPIC_TOOLS`
- **Coolify env vars on `atlas-v2-engine` (uuid `laqhqgjnaq9iz1l7l8pmhmlh`):** `MINIMAX_API_KEY` only — base URL and model are baked-in defaults in `engine/config.py`. `ANTHROPIC_API_KEY` removed.
- **Quick task:** `260501-rrl` (full artifacts in `.planning/quick/260501-rrl-swap-claude-haiku-llm-in-engine-for-mini/`)
- **Commits:** `2a891c8`, `d30b6e3`, `e9ccdd3`, `2b2a384`

## Verified end-to-end on 2026-05-01

Live trigger of `landscaping/Berkshire` produced multiple `POST api.minimax.io/anthropic/v1/messages → 200 OK` across the four LLM stages (lead_summarizer, entity_extractor, website_content_analyzer, review_analyzer), no auth errors, no ValidationErrors, other enrichment stages (Places, Companies House, PSI, socials) continuing norm…

---
name: engine-v14-shipped
description: v1.4 Engine Quality Pass — Scrapling + MiniMax VLM + web search + structured extraction + 5-phase orchestrator. Shipped 2026-05-13 after 21h re-enrichment of 4945 leads. Engine still STOPPED post-reenrich pending operator post-purge + restart.
metadata: 
  node_type: memory
  type: project
  originSessionId: acae237b-8d3f-4681-88fc-3c228db98b7d
---

v1.4 Engine Quality Pass shipped to production 2026-05-13 via 10 atomic commits to master (d26d876 → 298c20a). Emergency-mode rollout, no GSD workflow, direct execution.

## What landed

- `scrapling[fetchers]>=0.4.8` + Chromium replaces `httpx + BeautifulSoup` — JS-rendered HTML for every downstream extractor; same render produces a full-page JPEG q=85 screenshot
- MiniMax VLM (`/v1/coding_plan/vlm`) — full visual analysis on every lead with a screenshot, trust deep-dive on premium-band (score ≥ 60). Locked prompts live in `engine/sites_lead_finder/pipeline/visual_analyzer.py`
- MiniMax web search (`/v1/coding_plan/search`) — sparse-data gap-fill when entities.owner_names empty OR review_count < 5 + no review_sentiment
- `extruct` structured-data harvest (OG, JSON-LD, microdata, RDFa) — folded into a new `StructuredDataSignal`
- Garage S3 dual-endpoint upload — PUT via `http://atlas-garage:3900` internal, public URL via `https://garage.sys.digigrow.uk/atlas-screenshots/{place_id}.jpg`
- `excluded_places` table — `scripts/purge_uninteresting_leads.py` writes here, `orchestrator.py:Step 3` reads
- Re-enrich script `scripts/full_reenrich.py` — adapts burst_reenrichment shape, forces Place …

---
name: ghl-account-map
description: "Complete GHL sub-account IDs - location, pipelines, stages, users, custom fields - refreshed live 2026-05-16"
metadata: 
  node_type: memory
  type: reference
  originSessionId: cc99c45d-ba78-43a3-b9a5-2eaafce80e7f
---

**Location ID:** `4Pt3ZTcepzh7NiodFfAO`
**API Base:** `https://services.leadconnectorhq.com`
**Auth:** Bearer PIT token (see `~/.claude/credentials/digigrow-infra.md`), Version header `2021-07-28`

## Outbound - Closing Pipeline (`PUcLWudow6TSRDtYuKDx`) — 14 stages

The primary sales pipeline. Refreshed 2026-05-16 — stage names changed significantly from earlier doc snapshots. Webhook firing on this pipeline currently feeds the GHL Workflow → Atlas integration.

| Stage Name                       | Stage UUID                             |
| -------------------------------- | -------------------------------------- |
| Demo Booked, Awaiting Call       | `d4638c43-f090-4455-902e-e828a0f006f8` |
| No-Show, Closer Recovery         | `1ae827ae-d44e-46f9-a435-4a2bf9a1a925` |
| No-Show, Awaiting Lead Rebook    | `dd8d2b33-759a-4ce0-b63c-98a8ac1648d3` |
| Rebooked, Awaiting New Call      | `183cf8be-b243-422c-948b-142dd3221803` |
| Demo Done, Considering           | `bdad7fc3-fd49-416f-b410-986afdb35f25` |
| Demo Done, Day 4 Discount Sent   | `48dd984f-9aa6-4fa3-aaf2-f395abac2c78` |
| Deposit Paid, £397.50            | `8227af16-4237-488c-83c0-9d5f97c14ea9` |
| Build Complete, Awaiting Review  | `46509448-7a08-4ed8-8785-5123ffa01658` |
| Review Call Booked               | `9020770c-fa10-4654-be38-0ca0298462e4` |
| Tweaks In Pro…

---
name: GHL Migration Decisions
description: Key business decisions for the HubSpot→GHL migration - sync scope, cutover strategy, booking approach
type: project
---

**Clean cut migration** — no HubSpot backward compatibility, rip it all out.

**Sync scope:**
- Only create GHL contact + opportunity on **meeting booked** (not every call outcome)
- Only log calls to GHL when creating a contact (i.e., meeting booked)
- No existing lead migration — only new leads get synced to GHL

**Meeting booking:**
- GHL round-robin calendar already exists
- Build **API-based booking UI** (not iframe embed), using GHL Calendar API
- Must respect round-robin availability of assigned closers

**Source of truth:**
- GHL is source of truth for deal/opportunity progression
- Closers work deals inside GHL directly; only setters use Atlas
- Atlas reacts to GHL stage changes (webhooks in production, atlas.digiflow.uk is public HTTPS)
- No webhook tunnel in dev — will set up for production

**Commission:**
- Auto-commission on Closed Won stays the same logic
- GHL workflows/automations planned for future but not part of this migration

**UI:**
- "View in GHL" links for admins/staff on CPT dashboard
- Discord bot notifications updated with GHL deal stage labels
- Future: email campaigns, SMS sequences, retention — not in scope now

**GHL account:** Starter plan, single sub-account.

**Timeline:** ASAP, no phased rollout.

---
name: GHL Migration Project
description: Replacing HubSpot CRM with Go High Level (GHL) - planned migration with extensive research docs already completed
type: project
---

DigiGrow Atlas is migrating from HubSpot to Go High Level (GHL) as the CRM.

**Why:** Strategic CRM switch - extensive research already done in docs/plans/ (ghl-integration-report.md, ghl-tags-notes-research.md, ghl-custom-fields-research.md).

**How to apply:** All CRM integration work should target GHL APIs instead of HubSpot. The existing HubSpot integration spans ~38 files (backend service, sync task, router, frontend scheduler modal, deal stage badges, config, migrations). The GHL research docs contain detailed field mappings, tag registries, and a 5-phase migration plan.

---
name: project-ghl-webhook-historically-broken
description: GHL webhook ingest was broken from v1.0 ship through 2026-05-16 (never executed) — fixed by commit bc3f44b adding /api/ghl/webhook/basic with customData body parsing + live stage-name map. T-Brownplumbing test confirmed end-to-end.
metadata: 
  node_type: memory
  type: project
  originSessionId: cc99c45d-ba78-43a3-b9a5-2eaafce80e7f
---

The GHL webhook receiver was broken end-to-end from v1.0 ship until 2026-05-16. Three layered bugs prevented any production webhook from ever reaching the dispatcher:

1. **`GHL_WEBHOOK_SECRET=""` in Coolify env** — every inbound POST short-circuited at the receiver with `503 "Webhook signature verification is not configured"`. Fixed 2026-05-13 by setting the secret via Coolify API.
2. **No GHL workflow pointed at Atlas** — code shipped (commits `70eb280`, `c95eab3`) but operator-side config never landed in the GHL UI. Fixed 2026-05-16 by configuring the "Pipeline Stage Changed" workflow with the Basic webhook action.
3. **GHL Basic webhook body shape mismatch** — Atlas's first-pass receiver read `body["auth_token"]` at root, but GHL's Basic webhook nests Custom Data KV pairs under `body["customData"]`. Atlas's stage-name map was also using `pipeline_name + stage_name` against names that had drifted significantly from the 15-day-old account map memory. Fixed 2026-05-16 in commit `bc3f44b` — parser now reads from `body.customData`, lookup keys by `(pipeline_id, stage_name)`, stage map refreshed live from GHL API.

**Status as of 2026-05-16:** Webhook system is live. T-Brownplumbi…

---
name: Lead Landing Pages — Closing Call Demo Sites
description: Project to build personalised landing-page mockups for each Outbound video-call lead, shown live during the closing call with a Stripe deposit CTA
type: project
originSessionId: 5238d54a-ce06-4a6f-9829-18c3b5779066
---
**Goal:** Build a personalised "this could be your site" landing-page mockup for each of the 16 leads currently in GHL Outbound - Closing Pipeline → Video Call Booked. Closer shares the URL during the video call, walks the prospect through it, and converts via a Stripe deposit widget. All disabled buttons (nav links, internal CTAs) trigger a "this part is ready to be built once you start your project" modal that pushes them to pay.

**Project location:** `/home/zach/development/digigrow/dg-lead-closing-call-sites/`
- `lead-data/` — full Atlas enrichment dump per lead (16 JSON files keyed by GHL opp ID + index.json)
- `template/` — Next.js 16 + React 19 + Tailwind v4 + shadcn (Base UI flavour) + static export + next-image-export-optimizer. Shared shell: `payment-widget.tsx`, `coming-soon-modal.tsx`, `disabled-link.tsx`, `coming-soon-context.tsx`, plus `lib/site-config.ts` and `lib/stripe.ts` (email-prefill helper).
- 16 per-lead site folders will be duplicated from `template/` (not yet created)

**Stripe deposit:**
- Live payment link: `https://buy.stripe.com/dRmeVc2VE2Zw9cmd5Rak002`
- Email prefilled per lead via `?prefilled_email=<owner_email>`
- **Deposit amount: £397.50 (half of £795 deal value) — INTERNAL ONLY, NEVER displayed in any UI surface per the global pricing rule.** Widget copy r…

---
name: Twilio SMS Quick-Replies Live
description: Atlas SLF call workstation has Twilio SMS quick-reply buttons live in prod since 2026-05-04 — N≤4 configurable templates, UK number +447463591344, IE1 region
type: project
originSessionId: 2517ab29-12b6-46e2-9c59-fc6e37dcd661
---
Atlas Sites Lead Finder calling UI ships configurable Twilio SMS quick-reply buttons. Setters fire pre-written messages (payment links, example sites, TrustPilot URLs) one-tap during a call.

**Why:** Saves setters from leaving the dialer to copy/paste links into a separate SMS app. Massive time-on-task win during cold-call follow-ups.

**How to apply:** When Atlas SLF call workflow comes up — buttons live in `frontend/src/apps/sites_lead_finder/components/call/MessageButtons.tsx`, mounted in `CallWorkstation.tsx`. Admin config is at `pages/Admin.tsx` → Message Templates section (MANAGER+ only). New tables: `lead_message_template`, `lead_message`. Service: `backend/app/services/twilio_service.py` (mirrors `GHLService` shape). Webhook: `backend/app/routers/twilio.py` at `/api/twilio/webhook`.

**Key infra facts:**
- Twilio account SID `ACa58fb184f465246b7038350d91ea1086`, friendly name "DigiGrow Atlas"
- API Key in use (as of 2026-05-04): `SK22521737f142b4c5bf85826254a37713` — regional-locked to `ie1` (predecessor `SK66352aa3dce1ce99a2ec43ef5bcf82fe` from initial integration didn't actually exist on the account; was created via API during smoke test)
- From number: `+447463591344` (UK mobile long code)
- Region/edge: `ie1`/`dublin` (EU data residency — both SDK kwargs AND number's Voice + Messagin…

---
name: project-webshot-dropped
description: "Webshot service + screenshot_capture.py removed from engine after Scrapling+VLM v1.4 shadow-run pass (2026-05-13, commit 298c20a)"
metadata: 
  node_type: memory
  type: project
  originSessionId: cc99c45d-ba78-43a3-b9a5-2eaafce80e7f
---

Webshot is no longer used in the Atlas engine. The `engine/sites_lead_finder/pipeline/screenshot_capture.py` module and `WEBSHOT_API_URL` / `WEBSHOT_API_KEY` env vars were removed in commit `298c20a` (2026-05-13, `chore(engine): drop screenshot_capture.py + webshot env vars after shadow-run pass`) after the Scrapling + VLM + web search + structured extraction stack shipped in [[project-engine-v14-shipped]].

**Why:** Engine v1.4 replaced webshot's headless-Chromium screenshot capture with Scrapling (curl-cffi + patchright) for HTML fetching and a VLM for vision analysis. The new stack uses different storage primitives, so the Garage `atlas-screenshots` bucket + webshot service deployment + `MAX_CONCURRENT_PAGES` tuning are no longer load-bearing for ongoing engine operation.

**How to apply:**
- Do NOT propose webshot tuning, `--retry-errors webshot_*`, or `garage.sys.digigrow.uk` CSP allowlist as v1.4 follow-ups — that stack is gone.
- Phase 25's CLOSEOUT.md, LEARNINGS.md, and HUMAN-UAT carry-overs that reference webshot are historical artifacts of the v1.3 milestone (still useful for the patterns/decisions/lessons, but the operational follow-ups they describe are obsolete).
- The Phase 25 `ScreenshotViewer.tsx` frontend may still be live — verify against the current v1.4 visual signal shape…

---
name: Zach - Developer Profile
description: Zach is a vibe coder and founder of DigiGrow who uses Claude Code to build and ship production software extremely fast
type: user
---

Zach is the technical co-founder of DigiGrow. His co-founder is Austin.

- Self-described "vibe coder" — uses Claude Code to build and ship production software at speed, faster than agencies
- Comfortable deploying straight to production and rolling back if issues arise
- Has other systems that use Rust for worker systems (experienced with Rust for performance-critical workers)
- Prefers to plan meticulously then execute fast — "discuss it, plan it, and just literally do everything"
- Runs Coolify for deployment, knows how to roll back quickly
- Backs everything up (learned from past mistakes)
- Values clean, modular architecture — doesn't want to keep adding to mess

# Archive

## Week of 2026-05-05

Ph 23 shipped (4125 leads re-enriched, 3 Sentry fixes); Ph 24 completed discuss→research→plan→execute cycle w/ qual-gate; ENG-11 prod-live (SC-2/SC-3 SLAs); Ph 25 Wave 3 commenced (screenshot backfill, Alembic migration, Viewer+ENG-04).

## Week of 2026-05-12

Ph 25 shipped (1304 backfill); alembic rowcount fix (9c07f60), ENG-02 6208 leads verified. VL-05 screenshot bottleneck resolved (concurrency 3→20, shm 2g→4g), 3446 false-pos timeouts cleared, 99 leads/min sustained. LLM vision gap found (screenshots unanalyzed); lead DB cleanup + Scrapling VLM eng fix pending.
```

## 19:40 | master
Explored digigrow-atlas Discord bot (`bot/`, existing Redis-driven notification system); clarified new feature: auto-ping configurable users on new forum posts in configurable channels (Discord-only, includes configurable reason msg); created implementation tracking tasks.
## 20:30 | master
Deployed self-hosted Honcho @ honcho.lagden.dev (API+MCP Worker/zl-vps01) w/ digigrow/personal/misc/global workspaces, registered 4 honcho-* MCP servers, began Phase 3 ingest (~57 files, cred sanitisation).
## 20:40 | master
Designed forum-ping feature for Atlas Discord bot (forum_ping_config table + forum_pings cog w/ slash cmds), user pushed back on over-design, routed to /gsd-quick for impl.

# Recent

```

# Recent

## 2026-05-13

Ph 25 operationalized: ENG-02 6208 scalars✓, VL-05 4200 screenshots (9% post-tuning)✓. GCP API cost overrun (£78) halted re-enrich; phone normalization bug (spacing, +44 prefix) identified. Ph-22 env-gap (6d-creds-missing, LLM-blind-JS), CSP explicit; Scrapling+VLM+places cleanup queued; engine stopped, handoff written.

## 17:15 | master
Phase 23-02 exec: Dockerfile + social-URL fixes, 7 commits push, 2782-lead burst (3h14m conc=16), 1343-social ~753/1343 IP; Sentry auth, 6 issues id (MiniMax net/timeout/DNS, GHL 400, auth 401), 6 inv agents spawn.
## 10:30 | main
6 Sentry issues diagnosed (4 mislabeled); 3 fixes proposed (whois log suppress, Redis keepalive+retry, GHL delete); 1343-lead enrichment burst completed (2h 19m); URL population verified.

## 13:45 | main
Phase 23 planned (burst re-enrich + ENG-05); Wave 1 shipped (feat(slf-scripts): burst_reenrichment.py w/ Semaphore(8), reuse _enrich_lead_record); Wave 2 blocked PRE-01 op-gate (pending: deploy, burst run, SQL verify).
## 15:15 | master
Ph24 discuss→research→plan→execute: 24-CONTEXT.md, 24-RESEARCH.md (Pitfall 11: FIELD_MASK_ENTERPRISE_DETAILS); 2 plan revs; qual-gate code (places_new.py,orchestrator.py)→master; paused@GCP billing chkpt
## | master
ENG-11: Confirmed Atmosphere SKU live via prod probe; appended Phase 24 UAT (a017398); prepped Coolify deploy.
## 11:00-19:00 | master
Ph 23 (ENG-05) shipped/live; lead_allocation.py alloc preds (c1962f5); 4125 leads re-enrich (2 bursts, 0 fails); scalar+social-URL cols fixed (b6f3c2c, 9fe020d, 63795a8); 3 Sentry fixes (aa45415, 1412fbc, 0fb59f7; 5/6 resolved); Ph 24 pending; @60% v1.3 prog

## 16:45 | master
ENG-11 qual-gate (places_new.py:222, bd850e9); GCP alerts+Atmosphere live; prod deploy (a017398); engine live; SC-2/SC-3 +24h/+7d
## 20:22 | master
Phase 25 Wave 3: UI-SPEC → context → 4 plans → Wave 1 exec (screenshot backfill; Alembic migration; Viewer+ENG-04) done

## 15:00 | master
P25 deployed alembic rowcount fix (9c07f60); ENG-02 backfill verified (6208 leads); Phase 22 webshot env-var defect fixed (Coolify); VL-05 pending
## 14:42 | master
VL-05 screenshot backfill: webshot saturation bottleneck fixed (MAX_CONCURRENT_PAGES 3→20, shm 2g→4g); 3446 false-pos timeouts cleared (SQL); v5 sustains 99 leads/min (ETA ~10m)
## 17:00 | master
Phase 25 shipped (1304 backfill); CSP tightened; LLM vision gap found (screenshots unanalyzed); Scrapling + VLM eng fix planned; eng disabled; lead DB cleanup pending
I've received your context and compressed transcript. Ready to help with your next task.

What would you like me to work on?

## 14:18 | master
Re-enriched 4950 leads (45.4% premium band); force_place_details=True burned ~£60 GCP API; engine stopped (cost overrun)
## 18:29 | master
Halted £78 re-enrich; saved API cost-decision mem. Phone normalization bug (lookup): stored w/ spaces, no +44 prefix, poor matching—fixing.

## 22:57 | master
Phase 25 operationalized: ENG-02 6208 scalars✓, VL-05 4200 screenshots (9% post-tuning); Phase-22: env-gap (creds 6d-missing), LLM-blind-JS; CSP explicit; Scrapling+VLM+places cleanup planned; engine stopped; HANDOFF.md written.

## 12:46 | master
GHL polling debug: prod secret empty; deployed Coolify atlas-v2-backend (verified working); blocked GHL premium webhook feature.

## 14:45 | master
Refreshed atlas codebase map (4 parallel mappers); 7 docs (stack, integrations, architecture, structure, conventions, testing, concerns; 2,255 lines); e8d9e39.

## 23:42-23:45 | master
Extracted learnings phases 22 (22d/12l/11p/8s), 23 (16d/7l/8p/6s); aggregate 21-25 87d/42l/48p/34s; webshot env dropped 298c20a; GHL migration scoped. Shipped v1.4 engine (4950-lead re-enrich: Scrapling/VLM/web_search; 21h; 45% premium-band); found £78 cost bug (Places refetch, halted); fixed phone normalization (E.164+digit-strip); d26d876..f652171.

## 00:15 | master
Extracted learnings phases 25 (20d/10l/12p/9s), 21 (20d/9l/11p/9s), 24 (9d/4l/6p/2s).
## 11:35 | master
Designed GHL Basic webhook (Atlas: stage/pipeline names only, no UUIDs); planned `/api/ghl/webhook/basic` (name→ID resolver); started `/gsd-quick` hotfix.

## 13:49 | master
Deployed `/api/ghl/webhook/basic` (c1f1c59, 12+15 tests) → atlas.digigrow.uk prod; GHL workflow conf ✓; auth validation ✓.
## 14:01-14:44 | master
GHL webhook 401 (auth_token in customData not root); deployed diagnostics atlas ghl.py; fixed parser & stage map (14 Outbound/10 Inbound); e2e verified t-brown; reconciled 32 stale leads; patched dispatcher (call_list_status not flipped closed_lost/bad_lead/long-term-nurture); deployed 4 commits; debugging MyLeadsPage (contact/pipeline/status missing).

## 15:47 | master
Refreshed `.planning/codebase/` (7 docs, 2255 lines) 4 mappers; committed e8d9…