Client Feedback Evidence CLI
Collects chats, voice notes, emails, and attachments into one local workflow for clear, traceable client feedback.
Project overview
Client Feedback Evidence CLI overview
A short overview of the problem, solution, and result.
Starting Point
Useful client feedback was spread across WhatsApp chats, voice notes, and domain Gmail threads, which made it hard to assemble a reusable evidence packet without manual copying and fragile exports.What Shipped
Built a Rust CLI with `doctor`, WhatsApp `probe/search/pull`, and Gmail `search/pull` commands, all available with stable JSON output for automation.Why It Mattered
Turned scattered client feedback sources into a repeatable local workflow that writes `run.json`, `messages.json`, `evidence.md`, attachments, audio files, WAV files, and transcript artifacts.Summary
Client Feedback Evidence CLI is a local collector for client feedback and supporting evidence.
It pulls from the places where useful feedback actually shows up: WhatsApp chats, WhatsApp voice notes, domain Gmail threads, Gmail attachments, and local transcripts.
The situation
Client feedback only helps later if the source is still attached to it.
Before this tool, useful evidence lived in scattered chats, audio notes, emails, attachments, and screenshots. I needed a reliable way to assemble a packet without copying private text around by hand or losing the source path behind a claim.
System shape
The product is a CLI, so the durable interface is the workflow contract: commands in, local artifacts out.
How it works
Keep sensitive evidence local by default.
Run outputs live under the local client-feedback evidence directory unless the user chooses another output path. The public repo contains source code and docs, not captured messages, audio, browser storage, or OAuth tokens.
Use source-specific rails.
WhatsApp work goes through a dedicated Agent Browser profile and visible WhatsApp Web state. Gmail work goes through gws, message or thread IDs, Gmail payloads, and attachment bodies.
Make ambiguous selections explicit.
WhatsApp and Gmail searches can return multiple candidates. The CLI fails loudly unless there is a single safe selection or the user has reviewed candidates and passed --select-first.
What I built
A CLI that mirrors the collection steps.
The commands follow the workflow: doctor checks local dependencies, whatsapp probe confirms linked browser state, whatsapp search finds chat candidates, whatsapp pull writes message and audio artifacts, gmail search previews messages, and gmail pull writes thread evidence.
WhatsApp voice notes as auditable files.
The tool opens the visible message context menu, downloads voice notes, normalizes Agent Browser directory-shaped downloads into .ogg files, records file sizes and SHA-256 hashes, converts audio to 16kHz mono WAV, and writes transcript text and JSON when local transcription is enabled.
Gmail attachments in the evidence packet.
The Gmail path resolves a query, message ID, or thread ID, reads message metadata and bodies, recursively finds attachment parts, decodes base64 payloads locally, sanitizes filenames, materializes files, and records hashes in the structured message output.
Stable machine output.
With --json, successful commands emit structured JSON to stdout and errors emit { ok: false, error: "..." }. Dependency diagnostics stay on stderr, which keeps the CLI usable from scripts without hiding failures.
What shipped
This is a small workflow system: source-specific collection, explicit approvals, local evidence handling, structured manifests, and tests around the parts most likely to break.
WhatsApp rail
A linked browser session became a repeatable evidence source.
The CLI can probe WhatsApp Web, search chat candidates, pull visible messages, and require explicit `--select-first` approval when a search is ambiguous.
Voice notes
Audio evidence stays local and traceable.
Visible voice notes can be downloaded through the WhatsApp context menu, normalized from Agent Browser download wrappers, hashed, converted to WAV, and transcribed locally with whisper-cpp.
Gmail rail
Domain email threads produce reusable packets.
The Gmail workflow searches through gws, resolves message or thread selections, decodes attachment payloads locally, and writes messages, attachments, hashes, and evidence Markdown.
Stable outputs
Automation gets manifests instead of ad hoc files.
Pull runs write `run.json`, `messages.json`, `evidence.md`, and source-specific artifacts so later review can find the exact messages, files, transcripts, and hashes from the run.
Tests
The brittle parsing points are covered.
Unit tests cover WhatsApp metadata parsing, download references, search candidates, date and time markers, download normalization, command-output JSON parsing, Gmail attachment decoding, and safe filenames.
Why it matters
The important part is not that the tool can scrape a page.
The important part is that it turns private, scattered feedback into a repeatable evidence workflow. The source boundaries are visible, the artifacts stay local, and the evidence can be reused later without guessing where it came from.
Public repo
The project is open source, including the Rust CLI, command contracts, local evidence manifest types, browser workflow wrappers, Gmail attachment handling, and unit tests.
View GitHub repo →
Tech Stack
Find what's slowing your operations down.
A Business Systems Audit maps the workflow, identifies where the process gets stuck, and gives you a first build plan.