Clone Audit Mrlv3nl4

Clone Audit

Audit the requested website-clone workspace and produce an evidence-based

deployment-readiness report. Inspect the current target; never reuse findings

from an earlier project or run.

Establish scope

• Confirm the target root and the intended output language.
• Identify any supplied source site, screenshots, design tokens, or other

fidelity references. If none are available, mark visual fidelity as not

checked instead of guessing.

• Inventory relevant HTML, CSS, JavaScript or TypeScript, assets, metadata,

configuration, and dependency manifests. Respect explicit exclusions.

• Prefer static inspection. Do not execute untrusted project code, install

packages, or make network requests unless the user authorizes it.

Treat references/source-1-CLONE_AUDIT.md only as historical provenance. Do

not copy its paths, counts, or findings into a new audit unless the current

target independently confirms them.

Run the checks

Inspect each category and record the evidence used:

• Fidelity assets and styles — compare against supplied references for

missing or substituted fonts and images, broken asset paths, incorrect

colors, and materially different layout or styling.

• Tracking scripts and pixels — find analytics, tag managers, advertising

pixels, telemetry beacons, and unexpected third-party scripts.

• Source-brand residue — find source brand names, domains, metadata,

social links, asset paths, comments, and copy that should have been replaced.

• Language residue — find unintended text in languages outside the target

locale, excluding code identifiers and legitimate proper nouns.

• TODOs and placeholders — find TODO or FIXME markers, lorem ipsum,

template copy, dummy links, test credentials, and unfinished states.

• External dependencies and link risk — inspect remote URLs, CDNs,

localhost or development endpoints, external fonts and media, package

downloads, and dependencies that may fail, leak data, or violate deployment

constraints.

Open the surrounding context before reporting a match. Deduplicate repeated

instances that share one root cause, but list every affected file or meaningful

location.

Classify evidence

For every finding, include:

• severity: blocker, high, medium, or low;
• a repository-relative file:line location when available;
• the matched identifier or a short, non-sensitive excerpt;
• why it matters; and
• a concrete recommended action.

Keep these states distinct:

• Confirmed finding — directly supported by inspected evidence.
• Checked; none found — the category was inspected and no issue was found.
• Not checked / unverifiable — required context, reference material, or

access was unavailable.

Never turn an unverified suspicion into a confirmed finding. Do not expose

machine-local absolute paths, secrets, tokens, or personal data in the report.

Produce the report

Use this structure:

# Clone Audit

## Scope and coverage
- Target: <portable project label or repository-relative path>
- Fidelity reference: <provided, not provided, or unavailable>
- Exclusions or limitations: <items or none>

## Findings
### <category>
| Severity | Evidence | Why it matters | Recommended action |
| --- | --- | --- | --- |
| <level> | `<relative/file:line>` — <identifier> | <impact> | <action> |

## Checked; none found
- <category>

## Not checked / unverifiable
- <category>: <reason>

## Deployment readiness
<Ready, ready with follow-ups, or not ready> — <brief evidence-based reason>

Use not ready when confirmed unresolved findings can break the deployed

experience, expose tracking or sensitive data unexpectedly, or leave material

source-brand or placeholder content. Otherwise state any follow-ups and explain

why they do or do not block deployment.