Client deliverable & branding — high-level pointers (local fallback)

pelipper rolls up every tool’s verdict into one branded report + PDF. The detailed, current client-deliverable standards — cover copy conventions, brand asset requirements, how to word an executive summary, and when a finding is client-ready vs. needs an internal fix first — live in the team wiki (set OUTLINE + OUTLINE_API_URL and the report links them directly). This file is the minimal high-level fallback for when the wiki isn’t configured: direction only, deliberately not step-by-step, so there’s no detailed content to drift out of sync with the wiki.

• Brand the cover before sending — pass --brand-name and --brand-logo (or set PELIPPER_BRAND_NAME / PELIPPER_BRAND_LOGO); an un-branded “Quality report” cover reads as unfinished to a client.
• Run the audits first — pelipper packages what’s already on disk; a stale or partial roll-up looks the same as a fresh one, so re-run the underlying tools before a client send.
• Overall verdict is worst-of-graded — a single FAIL tool sinks the whole deliverable; decide whether that FAIL should be fixed before the report goes out, not explained after.
• INFO-only tools never fail the report — xatu and shrinkita are informational; don’t hold a deliverable back waiting on them.
• Unadapted tool output is flagged, not silently dropped — if pelipper logs a “no adapter” warning for a new skill’s JSON, add the adapter before treating a roll-up as complete.
• Keep the tool subfolders alongside the deliverable — per-tool report links are relative paths; moving just report.html breaks every “full report” link in it.
• The work list is for the agent, the cards are for the client — don’t paste the raw Fix with your agent block into a client-facing summary; it’s meant for internal follow-up.

Full playbook → the team wiki’s client-deliverable & branding standards.