From ZIP to report

As soon as payment clears you get two e-mails: one with the order details and the link to your order, another with the kit attached (SVO-<project>.zip). Keep the link: that is how you download the kit again whenever you want, without hunting for the e-mail. We install nothing on your machine — you unzip it yourself.

Create a folder for this audit and unzip the ZIP inside it. Each ZIP is one audit — including the same project at different levels (ONE and Deep), which go in separate folders:

audit\
  ├─ mysite_deep\
  │   └─ svoaudit\     <- this audit's kit
  └─ mysite_one\
      └─ svoaudit\

What separates one audit from another is the folder above. Two audits in the same folder would share one workspace — and one would see the other's material.

Your project does not go inside svoaudit — it stays where it already is, in any folder on your computer, and the audit gets read permission to reach it. With the code inside the kit, any instruction files it carries (CLAUDE.md, AGENTS.md) would enter the context and the audited code would start instructing the auditor.

The ALVO.md is already in the folder, filled in by us: project, owner, token, report language, main language, the scope you declared when measuring, and the path to your code folder — which came from the manifesto.json you sent.

🔴 Check the path. It is the one from when you measured; if the folder has moved since, fix it there. It is the one field that decides what gets read — and the kit does not let it slide: if the folder does not match what was measured, the audit stops and says why.

What is still blank is optional and yours to decide: folders that are a copy/version of the same code, and what is that way on purpose. We do not guess those — a guess of ours would be accepted without being read.

Inside the svoaudit folder there is a file called AUDITAR.bat. Double-click it and that is it — it opens the Claude Code session in the right folder and starts. There is no terminal to set up and no path to type. Linux or macOS: bash auditar.sh, from the same folder.

The AI bundled with your editor — Copilot, Gemini — does not work: it does not talk to our server and does not carry the kit's locks.

Claude asks once whether you trust this folder (the svoaudit you have just unzipped). Say yes: it is not a formality — that answer is what switches on the locks shipped in the kit, including the one that stops it writing into your code. After that it goes on its own.

It can take hours. A ~18k-line project at the Deep level took about 2 hours. You do not need to watch the screen: every step is written to disk as it closes. If it has to stop — your account usage limit, a dropped connection, a power cut — you open AUDITAR.bat again and it carries on where it stopped. Nothing is lost and nothing is redone.

The report is written inside svoaudit, with the AI model that produced it recorded in the header. It stays with you — SVO gets no copy. All that reaches us is the names of the finished steps, which is what allows resuming instead of starting over.

Same as the code flow: kit and token arrive by e-mail after payment. The difference starts at the next step — here the kit goes to the server, not to your machine.

An infrastructure audit runs inside the audited server — that is where the containers, services and real configuration live. This requires Claude Code installed and authenticated on the server. The LEIA-PRIMEIRO-MODELO2.md guide inside the ZIP covers the install step by step.

Pick a folder that is not served by the web. It will hold your token and the report with the file and line of every finding — if published, it would be downloadable from the internet under a predictable name. That would be the audit creating the worst finding in its own report.

What decides is the path, not the curl. Inside the folder, run pwd: if the path starts with the root your site publishes (/var/www/html/…, public_html/…), it is already published — move it to your $HOME now.

Only then, for outside confirmation, request the file at the URL matching where the folder actually is: curl -sI https://yourdomain/<path>/ALVO.md. A 200 convicts; a 404 does not acquit — the curl only tests the URL you typed, and a wrong guess returns 404 while the folder stays exposed elsewhere. Got a 200? Stop, move the folder and ask for a new token: the old one may have been read. The audit itself repeats this check before writing the report.

Here the target is not a code folder: it is the host — or, in model 3, your slice of it (your containers, your services). The scope bounds what may be observed. And the declaration is still mandatory: you declare the server is yours, or that you have written permission to audit it.

The same command, in the session opened on the server:

"read the ALVO.md and run the audit"

Here the read-only rule weighs even more: in production there is nobody to ask in the middle of the night, so a command that is not a read is not executed — it goes into the report as a recommendation.

The report is written in the audit folder on the server, and it is yours. Download it through the channel you already use to administer the machine. SVO gets no copy — only the step progress.