Verification and Constraints

• When the executor reads back the named Generic campaign after changing the center, then exactly one enabled50km proximity, recorded landmark coordinates and PRESENCE appear in the Google Ads API receipt and actual campaign Locations screenshot, with the old center absent.
• When before/after location inventories for the same21campaignIDs are compared, then only the intended Generic proximity changes appear in the scoped diff; local eligibility and negative locations remain unchanged.

• ✕ no nationwide Generic targeting or addition instead of replacement
• ✕ no narrow radii added to local campaigns
• ✕ no unrelated campaign/asset changes.

Evidence: not yet produced. Planned work is not a pass.

• When schedule rows are read back for all21targetIDs after update, then each shows exactly those five weekday intervals, no weekend intervals and a verified Europe/Budapest account timezone in the API report and Ads schedule screenshot.
• When the post-change pacing review uses current actual spend and budget history, then the report states current exposure against190000–215000HUF, flags any risk introduced by longer hours and preserves protected bids, budget ownership and existing weekly pacing authority.

• ✕ no weekend serving or timezone/account-time mutation
• ✕ no GBP/site business-hours edits
• ✕ no increase to the agreed planning/exposure band and no bid-strategy or budget change under this contract. Minimum spend remains demand dependent. If verified exposure already exceeds the planning band, report the precise limited decision rather than rewriting unrelated budgets under schedule authority.

Evidence: not yet produced. Planned work is not a pass.

• When isolated tests perform one reveal and one widget click independently on representative home/location/service mobile templates, then each produces exactly one intended union event with phone_action=reveal or widget_click plus phone_placement in selected GTM and isolated GA4/debug evidence after D4 isolation is proven, and neither requires an actual call. Retain other genuine phone CTA diagnostics with a distinct action label. Record a dial-launch diagnostic only when runtime proves the tel: launch, and never label it a connected call. Coverage of all21adlanding pages is inventoried; representative-runtime versus full-runtime proof is labelled honestly.
• When the executor reads Ads/GA4 configuration after the scoped naming/parameter change, then the existing GA4 import remains enabled Primary, mapped to tel_szam_katt/the verified GA4 property, CountOne, same90day window and equal treatment/no unequal values; the direct Ads action remains Secondary; all21campaigngoal mappings and Manual CPC remain unchanged. Rename primary label to “Phone intent (GA4) - Primary” if still misleading. Added diagnostic dimensions must not create a second primary counting route.

• ✕ don't promote both overlapping Ads actions to Primary or duplicate legacy events
• ✕ don't demote reveal, require connected calls, alter user-approved copy or remove other existing phoneCTAs
• ✕ preserve dial/reveal/clipboard behavior and consent choices. Explain CountOne aggregation without implying both actions individually always yield two Ads credits.

Evidence: not yet produced. Planned work is not a pass.

• When a named QA run exercises reveal/widget with consent accepted and denied, then runID and action receipts show the test in its intended debugging/QA destination, with zero eligible production GA4 key-event/Ads conversion submissions or proven exclusion before import. Both GA4-import and direct Ads paths are covered, including old cookies/UTMs, repeat clicks/reloads and teardown. Any pre-existing attribution-state test uses a local fixture or intercepted request, never a borrowed real click ID or live production conversion submission. State denied-consent cookieless behavior rather than asserting no network traffic.
• When the same routing/filter rules are exercised with ordinary unmarked controls and misleading client/agency referral strings, then a reproducible check shows ordinary traffic remains eligible according to consent while explicit QA is separated. Verify event-level marker persists through the whole test session and is removed at teardown; publish evidence for the actual chosen production route. No aggregate-zero-only proof or irreversible filter activation without validated QA/control matches. Use destination interception or isolated fixtures for deliberately unmarked controls so their production-route eligibility can be inspected without transmitting synthetic conversions. Read back the deployed production mapping separately. Test-only destination/capture proves routing logic, not production paid attribution. Genuine future traffic can validate import separately without generating test conversions.

• ✕ no fakegclid, self-clicking paid ads, realcalls, conversion uploads or fabricated business events
• ✕ no broad source/IP/referrer exclusion that catches customers
• ✕ no changing consent default to inflate measurement. Keep raw identifiers/private telemetry local. Do not expose test routes that inject conversions into another client/property. Prefer a reversible routing/marking solution
• ✕ if an Active GA4 exclude filter is used, first prove QA-only matching and disclose its irreversible incoming-data exclusion. Legacy data is not rewritten
• ✕ supply a reporting exclusion rule for known historic QA.

Evidence: not yet produced. Planned work is not a pass.

Isolation and test order

Execution order and isolation proof: inventory every phone conversion sender in the deployed site and GTM, including imported GA4 and direct Ads, before interacting. Establish a reversible QA route or outbound interception first, verify it on each sender, and only then run C5/C7/C8. The explicit marker must be available before any conversion sender evaluates, survive same-session navigation/reload, have a bounded lifetime, and clear at teardown. A marker arriving after the first event is a failed test, not partial success. Keep a private run ledger with run ID, timestamps, destination and evidence hashes.

A GA4 filter in Testing is not an exclusion. Never rely on Testing or debug_mode alone to prevent imported conversions. If selecting a filter-based route, validate matches with non-key QA probe events or a separate QA destination while suppressing business conversion submissions, account for propagation delay, and retain sender suppression until actual exclusion is independently evidenced. An Active filter is optional, not required when routing meets the outcome. Do not activate irreversible filtering merely because it appeared in the earlier recommendation.

Implementation freedom: use explicit short-lived QA flag/runID, dedicated QA property or route, validated traffic_type filter, or other supported method that meets both coverage and nonpollution criteria. A separate stream in the same GA4 property alone is not sufficient isolation. No new login/security layer, no broad platform infrastructure. The test mechanism is measurement routing, not an access-control system.

• When skill validation and discovery checks run against the installed canonical package, then valid metadata, resolving dependencies and a Codex discoverable entrypoint are shown in the saved validation receipt; package has no secrets/client account IDs/domains hardcoded. Preserve existing tracking-verification and other skills. Use a discovery link rather than a divergent copied package if needed.
• When a fresh agent applies the skill to two isolated fixtures (Csupi-like reveal/widget and a second client/property with different conversion mappings), then its report/config selects the supplied identity, separates markedQA from ordinarycontrols, protects GA4import and directAds paths, cleans up teststate and marks unsupported proof UNKNOWN. A mismatch fixture must stop before cross-client writes. Tests must exercise behavior, not merely match instruction wording. No real second-client provider mutation.

• ✕ no replacing existing skills, Claude-specific installation or modifying unrelated clients
• ✕ no global permission to publish/mutate accounts
• ✕ no sprawling framework. Preserve per-client configuration, consent semantics, exact identity checks, rollback and source qualification. Invoke skill-creator and writing-for-agents during implementation, and document how to apply it in one concise example.

Evidence: not yet produced. Planned work is not a pass.

• When each changed provider object and scoped code/version is compared with its pre-change snapshot, then the final report lists exact intended changes, zero unexplained changes and an actionable narrow rollback; reproducible checks and changed-interface screenshots support every passed criterion.
• When the bare review URL is opened unauthenticated after publication, then the sanitized board, exactly two diagrams, criteria counters, blue live updates and comment layer render; private evidence links are not publicly exposed. The same handoff preserves the already-verified unsent client draft URL and references the parent-owned receipt of recipient, thread, stable body evidence and unsent state, without recreating or sending it. Future current traffic/import validation is stated separately from implementation completion. If reporting latency prevents essential exclusion proof, remain pending with exact resume check rather than claim COMPLETE.

• ✕ no acceptance from worker claims alone, no exposing sensitive correspondence/telemetry, no new security gate
• ✕ no automatic clientsend or extra audio infrastructure. One combined parent recap.

Evidence: not yet produced. Planned work is not a pass.