Prompt: have an AI agent set up ClickHouse and audit your server logs

You are helping me audit the server access logs of my website for SEO. I want to know which bots really crawl the site, which ones are fake, where crawl budget goes and which requests fail. You work in a terminal on MY machine. Follow every rule below.

HARD RULES
1. Read-only. Change nothing on the web server or the website: no edits to nginx or Apache config, robots.txt, .htaccess, redirects, CMS, DNS or firewall. No deletes, and no writes outside the work folder defined in step 1. Never use sudo.
2. Privacy. The logs contain my visitors' IP addresses. Never paste, print or summarise raw log lines or individual IP addresses in this chat. Do not upload the logs, or any file made from them, anywhere: no web tools, no pastebins, no online "analyse this file" services. You may show me aggregates: counts, percentages, URL paths, bot names.
3. Official sources only. Download or install only from the addresses named in this prompt. Do not install anything on the web server.
4. Show before you run. Before each command that downloads or installs something, tell me what it does. Before any command that deletes files, list the exact paths and wait for my "yes".
5. If something is unclear, or a command fails twice, stop and ask me. Do not guess numbers: if the report has no figure for something, write "not in the report".

STEP 0 - ASK ME FIRST (one message, then wait for my answers)
a) The domain of the site, as written in its sitemap URLs.
b) Where the access logs are. A folder on this machine, or a server I must copy them from (then give me the copy command to run myself; do not log in to the server on your own).
c) The log format. Is it nginx or Apache "combined"? If I am unsure, tell me how to check one line myself without pasting it here.
d) My own IP addresses: the server itself, uptime monitors, cron jobs, my office.
e) Whether the site sits behind a CDN or proxy (Cloudflare and similar) and whether the logs record real visitor IPs.
f) How many days the logs cover.

STEP 1 - WORK FOLDER AND CLICKHOUSE
Create ~/log-audit-work (ask me if I want another place). Check for ClickHouse with `clickhouse local --version`, then `~/.local/bin/clickhouse local --version`, then `~/bin/clickhouse local --version`. If none works, do it after step 2: run `bash install.sh --dry-run`, show me the download size and the command, and only after my "yes" run `bash install.sh --yes`. It uses ClickHouse's official installer (curl https://clickhouse.com/ | CLICKHOUSE_ONLY=1 sh). On Windows, work inside WSL; if that is not possible, tell me and stop.

STEP 2 - GET THE KIT
Download https://adlab.ee/dl/log-audit-kit into the work folder with `curl -fL -o log-audit-kit.zip https://adlab.ee/dl/log-audit-kit` and unzip it. The kit is in beta and the address may not answer yet. If the download fails or the file is not a zip, ask me to attach the kit files and continue from those. Read README.md, run.sh, install.sh and ranges.sh before running anything, then tell me in three lines which network calls they make. Expected: clickhouse.com and builds.clickhouse.com for the install, the crawler operators' official IP-range files, and my site's robots.txt and sitemap.

STEP 3 - RUN THE AUDIT
Work on copies: link or copy the logs into the work folder and never edit the originals. Then, from inside the unzipped kit folder, run:
  bash run.sh -d DOMAIN -i OWN_IPS LOG_FILES_OR_FOLDER
with DOMAIN and OWN_IPS from step 0. Put SKIP_SITEMAP=1 in front if the sitemap is behind a login or the machine is offline. If fewer than 95 % of the lines parse, stop, tell me the format the kit expects and ask me; do not print log lines. The result is report.txt in the work folder. From here on read ONLY report.txt. Do not open the raw logs, logs.parquet or enriched.parquet.

STEP 4 - FINDINGS TABLE
Build one table from report.txt with the columns: Signal | Value from the report | Threshold | Status (OK, CHECK, ACT NOW, not in report) | Report section. Use these thresholds. They are rules of thumb from ADLAB audits, not official Google thresholds; the reasons are in the resource log-audit-thresholds (https://adlab.ee/dl/log-audit-thresholds).
- Requests that call themselves Google but fail IP verification (section 3): any. From here on use verified hits only.
- 5xx for verified Googlebot (sections 4, 5, 14): more than 1 % of its requests.
- Redirects for verified Googlebot (sections 4, 5): more than 10 %.
- Sitemap URLs Googlebot did not request in the window (section 6): more than 20 %.
- Googlebot page requests outside the sitemap (section 7): more than 30 %.
- A path with more than 1,000 unique URLs with parameters (section 9).
- Useful share of a crawler's requests (sections 8, 10): under 50 %.
- Pages opened by ChatGPT-User (section 11): list them, no threshold.
- 404s for user-triggered AI bots (section 11): any.
- 404s with an internal Referer, and 404s with an external Referer (section 13): any.
- /.env or /.git/* answered with 200 (section 17): any. If you see one, tell me FIRST, before the table.
Also state the window length (section 1), whether a sitemap was loaded (section 0) and, for each AI bot, verified hits against total hits (section 10). If the window is shorter than 7 days, say that the "not requested" figures are weak.

STEP 5 - CHECK FOR FALSE POSITIVES BEFORE CALLING ANYTHING A PROBLEM
- 404s with an internal Referer on a Next.js site, or any site with a catch-all router: scanners often put the site's own address into the Referer. Check with a plain GET (curl) whether the URL really appears in the HTML of a few pages before calling it a broken link.
- A 200 on /.env may be the app's normal HTML for any path. Compare the byte sizes in section 17 with the size of the homepage, then check with `curl -s -o /dev/null -w '%{http_code} %{size_download}' https://DOMAIN/.env`. Never print the response body.
- A high "not requested" share on a short window or on a young site is weak evidence.

STEP 6 - SUGGESTED CHANGES, NOT APPLIED
Give a separate list titled "Proposed changes - not applied". For each finding: what to change, where (a file or setting, only if I told you), the risk, and how to confirm it worked (rerun the kit on logs written 7 to 10 days after the change). Run none of them and write no patch files to the server. If I then ask you to apply something, remind me that this session is read-only and give me the change as text to apply myself.

STEP 7 - CLEAN UP
The work folder holds files with visitor IPs. At the end list the exact paths (log copies or links, input-logs/, logs.parquet, enriched.parquet, report.txt) and ask "Delete these now?". Wait for my "yes". Delete only the listed paths, with `rm -r` on the work folder and nothing else. Keep report.txt only if I say so.

DONE WHEN
- report.txt exists and the audit ran on a copy of the logs, and no raw log line or visitor IP was shown in this chat;
- I have the findings table, the false-positive checks and the list of proposed changes (not applied);
- I have confirmed or declined the clean-up.

SAFE COMMANDS (anything else: ask me first)
ls; cat and head on files in the work folder, except raw logs and parquet files; wc; unzip; mkdir inside the work folder; curl -fL for the addresses in this prompt; curl GET on my own site; bash run.sh; bash install.sh --dry-run; bash ranges.sh; clickhouse local on files in the work folder.