AI Location + Per-Project Data Source + Step 4a Template — Tech Spec
How the plan turns into 9 checklist boxes across 3 clusters · 2026-07-08
How the plan turns into 9 checklist boxes across 3 clusters
Master summary — the gist in 30 seconds
TL;DR3 small, independent fixes to the Lab pipeline: the data-source switch stops leaking between projects, the AI now picks the search-location automatically (rep can still override), and the website template becomes visible + editable right on the page where it's used.
Input: today's 3 known gaps (global switch, invisible location logic, invisible template). Output: a 9-item checklist (V1-V2, G1-G4, T1-T3), one ADR, and a project QA skill — ready for a fresh chat to build.
Why this mattersEach gap independently costs Mátyás or a rep real time or real mistakes (a setting change on one client silently breaking another; guessing a location by hand every time; editing a shared template blind). None require redesigning the pipeline — each slots into an existing pattern already proven elsewhere in the code.
flowchart LR
A["3 reported gaps"] --> B["Per-project data source"]
A --> C["AI location detection"]
A --> D["Step 4a template visible"]
B --> E["9-box checklist"]
C --> E
D --> E
E --> F["Instance 3 executes"]
1 · Volume-source becomes per-project
TL;DRSwitching DataForSEO ⇄ Google Ads for one client's project no longer touches any other client.
Input: a rep flips the radio button on one project's keywords card. Output: only that project remembers the choice (stored on the project itself); every other project keeps its own setting, defaulting to DataForSEO for anyone who's never touched it.
Why it mattersToday it's one shared light-switch for the whole house — flip it for one client and every other client's next research run silently uses the same source. This is exactly the kind of quiet cross-client bug that erodes trust in the numbers a proposal is built on.
flowchart TD
S["Shared global switch (today)"] -->|"changes"| P1["Project A"]
S -->|"changes"| P2["Project B"]
S -->|"changes"| P3["Project C"]
N["Per-project switch (after)"] --> N1["Project A: DataForSEO"]
N --> N2["Project B: Google Ads"]
N --> N3["Project C: DataForSEO (default)"]
2 · The AI decides the search location — and shows its work
TL;DRRight after the site is scraped, the AI reads it and decides: is this business tied to one county, or is it nationwide? It sets the filter itself, and a rep can always override it.
Input: the scraped site content (address, service area language, etc.). Output: either a specific Hungarian county pre-selected on the keywords card, or 'whole country' — plus a one-line reason the rep can read. A rep's own manual pick, if made first, is never overwritten.
Why it mattersToday a rep has to notice this setting exists and set it by hand every single run, or the research silently defaults to the whole country even for a corner bakery. Automating the judgment call — while always deferring to a human override — removes a step reps regularly skip, without taking away control.
flowchart TD
A["Site scraped"] --> B{"Already has a
manual location?"}
B -->|"yes"| C["Keep it — AI never runs"]
B -->|"no"| D["AI reads the site"]
D --> E{"Tied to one place?"}
E -->|"yes"| F["Pick that county"]
E -->|"no"| G["Whole Hungary"]
F --> H["Shown to rep + reason"]
G --> H
3 · Why the AI step runs in the background, not instantly on the page
TL;DRThe AI call happens as a small background job, the same way every other research step already does — never inside the page load itself.
Input: this app's own house rule that only ONE process is allowed to touch the database, so it can never be blocked waiting on a slow AI call. Output: the location decision is queued as a background step (like the existing 'find rankings' or 'find search volumes' steps) instead of holding up a rep's click.
Why it mattersIf the AI call ran synchronously the moment the page loaded, one client's multi-second Gemini call would freeze the whole app for every other rep using it at that exact moment. This is the same reason the app already handles rankings/keyword-volume lookups as background jobs — the new step just follows the established pattern (this is worth its own written decision record — ADR-0002 — so future similar AI steps don't have to re-litigate it).
flowchart LR
W["The one web process\n(handles every rep's clicks)"] -.->|"never blocks on AI"| G["Background worker\n(the AI location step)"]
G -->|"reports back when done"| W
4 · Step 4a — the website template becomes visible and editable
TL;DRThe HTML template that seeds the new website is currently invisible on the page where it's used — it lives on a totally separate, disconnected tab. Now it shows up right on Step 4a, with an inline editor.
Input: the rep opens Step 4a (where the new site gets generated). Output: a dropdown to pick which shared template to start from, a text box showing its actual HTML, and a save button that stores THIS project's tweaks without touching the shared template every other client also uses.
Why it mattersThe backend for managing templates already existed — it was just stranded on an unrelated 'Building' tab nobody thinks to check while working Step 4a. Surfacing it in the right place removes a guessing game; keeping edits project-local (never touching the shared copy) avoids the exact 'one client's edit breaks everyone else's site' bug the per-project data-source fix (callout 1) already had to solve once.
flowchart TD
T["Shared template library\n(Building tab — unchanged)"] -->|"pick one"| P["Step 4a dropdown"]
P --> E["Rep edits inline"]
E -->|"saves as"| O["This project's own copy\n(never touches the shared template)"]
O --> G["Feeds the site generator"]
5 · How the plan gets verified
TL;DR9 checklist boxes across 3 work clusters, each provably tested before being ticked — 6 by automated backend tests, 3 by a manual live look since this app has no automated on-screen test harness.
Input: the checklist's 9 items (V1-V2 data source, G1-G4 AI location, T1-T3 template). Output: a purpose-built QA skill (studio-ai-loc-qa) that runs the 6 backend checks as real automated tests and prints a live-verification recipe for the 3 on-screen checks.
Why it mattersThis repo's usual 'build a fully-automated on-screen test' tool was retired in a recent cleanup, so the plan mirrors this repo's actual current QA pattern (used by the comment-editor feature) instead of assuming a tool that no longer exists — a small but important correction caught while researching, not guessed at.
pie showData
title 9 checklist boxes by verification method
"Automated backend test" : 6
"Manual live check" : 3