Studio HTML Report

Studio / expert HTML report

Two tracks. Pick the one that matches the mission. Never put Three.js on a PPT or Word page.

File naming

Also keep working files in native formats next to it when useful: .md, .csv, .xlsx, .json, images, etc. The report is the summary surface, not a replacement for data files.

Track A - Studio / GTM UI (convert UI, not PDF)

Missions: RiskLens, SEO, Marketing, Montage, Ads, Leads, Meeting, Scraping.

The report is an interactive UI. Do not design for Export PDF. File Preview print is not the close path.

Stack (required)

Vite + React + one official DS (MUI / Fluent / Carbon) + framer-motion + three + @react-three/fiber + @react-three/drei. Follow ui-ux-pro-max and make-interfaces-feel-better.

Before the scene:

python3 "$SEARCH" "<report theme> spatial dashboard" --stack threejs

Use the drei helpers the search returns: OrbitControls (damping), Environment, ContactShadows, PresentationControls when the hero is a product. Optional @react-three/postprocessing only if that hero needs bloom.

Scene quality (required)

• One R3F Canvas / one renderer; pixelRatio capped at 2; antialias at construct
• PBR materials + AmbientLight + DirectionalLight (never a black unlit mesh)
• shadowMap on; cast/receive on the hero and the ground
• FOV 45-75; explicit camera position + lookAt
• Designed object or environment the user can read, HTML overlay for the report
• prefers-reduced-motion: freeze the scene, show the still
• Canvas role="img" and a real aria-label
• Never wallpaper particles, never a blank canvas, never GSAP/Spline/Lottie spam

Layout (overlay on the scene)

1. Header - mission name, report title, subject / scope / path, timestamp
2. Executive summary - 3-6 bullets or short cards (what matters first)
3. Body sections - one clear section per theme; working controls only
4. Deliverables - table: file path | format | what it contains. Only what the user asked for; render scripts, scrapers and intermediates live under build/ and never appear in this table
5. Footer - generated by Navin, timestamp, short disclaimer if needed

After writing

Start the app and call open_preview (web). Click the primary nav yourself. Do not paste the full HTML into chat. Do not close with Export PDF.

Track B - Expert File Preview report (no JavaScript)

Missions: Review (/inspect), Security (/fortify), Debug (/debug).

File Preview sandboxes scripts - no JS interactivity. Self-contained file: all CSS inline in a style block. No external fonts, no javascript, no CDNs.

For Review / Security / Debug tool reports (code_review report, security_scan write_report, debug_repair report), File Preview opens automatically in the WebUI. Otherwise call open_file_preview on the HTML path immediately (Download HTML). Print CSS is optional. PDF is not the design target. Do not paste the full HTML into chat.

Layout

1. Header - mission name, report title, subject / scope / path, timestamp
2. Executive summary - 3-6 bullets or short cards (what matters first); for Review/Security/Debug: severity counters (Critical / High / Medium / Low)
3. Body sections - one clear section per theme
4. Remediation plan (Review / Security / Debug) - numbered choices the user can pick in chat (Start with #1, #2, …). Each choice: title, severity, effort (S/M/L), risk if delayed, first concrete step
5. Deliverables - table: file path | format | what it contains. Only what the user asked for; render scripts, scrapers and intermediates live under build/ and never appear in this table
6. Footer - generated by Navin, timestamp, short disclaimer if needed

Finding cards (Review / Security / Debug) - required

For every confirmed finding, render a card with:

Real example (pick what fits; at least one per finding):

• Vulnerable or buggy code excerpt (10-40 lines max, redact secrets)
• Payload / PoC (' OR 1=1--, XSS string, curl with headers)
• HTTP request/response snippet proving the flaw
• Failing test / stack trace / scanner output (trimmed)
• Before → after snippet for the recommended fix

Never fill with a generic OWASP paragraph and no project-specific proof.

Remediation plan UI (no JavaScript)

Use numbered choice cards styled like selectable options:

<section class="plan">
  <h2>Remediation plan - choose where to start</h2>
  <p class="hint">Reply in chat with the number, e.g. "Start with #1".</p>
  <article class="choice">
    <header><span class="num">#1</span> <span class="sev">Critical</span> Title</header>
    <p>Effort: S · Risk if delayed: …</p>
    <p>First step: …</p>
  </article>
  …
</section>

Order choices by severity × exploitability (or by dependency for Debug). Do not auto-start fixes until the user picks a number (unless they already asked for Auto-fix / fix everything).

Roadmap & strategy (audits / Review / Security / Debug) - required

A remediation list alone is not a plan. After the choices, add a Roadmap section with 3-4 phases, each rendered as a card:

Each phase must list: objective (one sentence), the numbered tasks it contains (reference the remediation choice numbers), effort in person-days per task, dependencies between tasks ("needs #3 first"), and an exit criterion that is verifiable ("CI blocks merge when tests fail", "gitleaks scan returns 0 findings"), not vague ("better security").

Close the roadmap with a short Strategy block (5-10 lines of prose, not bullets):

• Target state in one paragraph: what the project looks like when the roadmap is done, with 2-3 measurable KPIs (test coverage %, mean time to patch, Lighthouse score, error budget)
• Quick wins vs structural work: name which items buy the most risk reduction per day of effort and why
• Verification loop: how each fix is proven (test added, scanner re-run, CI gate) so regressions cannot silently return
• Top 2 risks of the plan itself (e.g. key rotation breaks a deploy, strict TS flags block the team) and the mitigation for each

Every recommendation in the report must be actionable as written: name the exact file/command/config to change and what to change it to. "Add rate limiting" is filler; "add slowapi Limiter on POST /api/auth/login, 5/min per IP, see snippet" is a recommendation.

Visual system

• Prefer a clean dark report shell: background #0a0e1a, cards #121826, text #e8eefc, muted #9aa8c7, accent #5b8cff, success #3ecf8e, warning #f0b429, danger #f07178
• System UI / sans stack: ui-sans-serif, system-ui, sans-serif
• Generous spacing, 12-16px card radius, subtle 1px borders
• Severity / score chips with color, not emoji spam
• Code / PoC blocks: monospace, #0d1117 background, wrap long lines
• Tables: readable zebra or row separators; wrap long URLs
• Print-friendly: @media print with white/black fallbacks so a print dialog stays legible if the user asks

Content rules

• Specific numbers, URLs, paths, and code - no filler
• Mask secrets in examples (sk-***, password hashes truncated)
• Link workspace file paths as plain text paths (not file://)
• Keep the HTML under ~300 KB when possible so Preview is not truncated
• French or English to match the user brief

Mission-specific emphasis

• RiskLens - synthesis (most likely / most dangerous / hidden assumption), failure cards, revised plan, checklist (Track A UI)
• SEO - impact-ordered findings, keyword clusters, content actions, schema / meta snippets when relevant (Track A UI)
• Marketing - message / persona, channel plan, asset inventory with paths (Track A UI)
• Leads - ICP snapshot, ranked accounts/people, signals, outreach next steps (source URLs mandatory) (Track A UI)
• Ads - evidence paths, kill/scale, no invented ROAS (Track A UI)
• Scraping - crawl stats, ok/error, export paths, sample rows (Track A UI)
• Meeting - decisions, owners, actions (Track A UI)
• Review - Approve / Request changes verdict; findings by layer (correctness, SQL/data, API, frontend, tests, perf); remediation choices
• Security - phase coverage (injection, front, authz, network, secrets, privacy); PoC per finding; hardening plan choices
• Debug - root-cause statement with evidence; related latent bugs; fix plan choices ordered by unblock value

Chat close

Studio / GTM: three to six sentences max: headline result + the Preview UI path + the other key file formats. Expert Review / Security / Debug: ask which remediation number to start with.