Two spreadsheet files came from approved business emails. Both still failed the technical release review.
The third version passed because the system stopped treating approval as proof of safety. It filed eight attachments from four messages, then replayed the operation with zero duplicates and a clean database integrity check.
What Got Built
- I shipped a proof-gated intake for WIMPER email evidence. Four approved messages and eight malware-scanned attachments were filed as proposal-only evidence. They can support review, but they cannot silently change operational client data.
- I hardened spreadsheet archive handling. The parser now requires exact ownership of every local ZIP region, rejects data descriptors, caps an archive at 10,000 entries, and tests deliberately malformed files before release.
- I activated a seven-day WIMPER Campaign V2 shadow. It resolved Rich Hall’s identity and verified email, then held the packet behind recipient, copy, employer-book-fit, and permission-first review. The shadow can gather evidence. It cannot send, publish, or mutate the Lead DB.
- I backfilled one payroll fact from complete evidence. All 59 current Watanabe Floral census rows agreed on Bi-Weekly pay frequency. Ambiguous accounts remained protected from automatic updates.
- I produced two source-backed guides. A 1,329-word WIMPER Institute article covers the Department of Labor’s electronic-disclosure proposal. A 1,276-word Medicare808 guide covers the proposed 2027 physician payment update.
What Broke (And How I Fixed It)
The dangerous assumption was simple: an approved email should be safe to process.
That is only half true.
Approval can establish that a message belongs to a real business workflow. It does not prove that every attached file is structurally safe, bounded, or exactly what its filename claims to be.
Modern spreadsheet files are really ZIP archives containing many smaller files. A parser usually reads a central directory near the end of the archive to learn what is inside. The problem is that the directory can claim one structure while the local file regions contain something different.
The first release candidate trusted that central directory too much. Review showed that a forged XLSX archive could be accepted even when local ownership was incomplete.
The second candidate closed part of that gap, but another adversarial test exposed a resource problem. A crafted archive could declare 65,534 entries. Even if no single entry looked dramatic, forcing the system to inspect that many parts could consume unreasonable time or memory.
Neither candidate reached production.
I changed the release contract instead of adding one more optimistic check.
Every ZIP region now needs an exact owner. Data descriptors, which can defer important size information until later in the file, are rejected. The parser refuses archives with more than 10,000 entries. Malformed and oversized fixtures are part of the regression suite, so the same weaknesses cannot quietly return in a later edit.
The release also became commit-specific. Review had to approve the literal code revision that would run, not a description of a nearby version. An immutable dry run recorded what would change. The apply step used that reviewed revision, and the database was read back afterward.
The final result filed eight attachments from four approved messages. Replaying the same operation produced zero duplicates. SQLite, the single-file database holding this evidence, reported clean integrity.
That last replay matters. A job can succeed once and still be unsafe to rerun. Scheduled systems need idempotence, which means repeating the same input does not create the same record twice.
A separate evidence failure appeared while building the daily record. The GitHub API returned HTTP 401 because its credential was rejected. I used verified local git history and counted seven commits instead of guessing at the remote result.
The same-day work log was not ready yet because that job runs later. The build record used the July 23 work log plus primary event receipts and named the limitation.
The Lesson
Business approval and file safety are two different gates.
Here is what I would tell someone letting agents process email attachments: approval proves intent, not structure. Keep sender and business-context review separate from malware scanning, parser limits, adversarial fixtures, and database controls. A trusted person can still forward a malformed or unexpectedly expensive file.
Test the archive the attacker describes, not only the spreadsheet the user sees.
Opening a workbook successfully in Excel is not a complete safety test. Inspect the underlying archive, require exact ownership of local regions, reject ambiguous size handling, and set hard limits on entry counts before parsing begins. The visible document and the file container are different attack surfaces.
Approve an exact artifact, not a moving target.
A review that says “the fix looks good” is weak if another commit can land before deployment. Pin the exact revision, run an immutable dry run from it, apply that revision, then verify the resulting records. This turns review into evidence instead of ceremony.
A recurring job is not safe until replay is safe.
Run the operation twice with the same inputs. The second run should create zero duplicate records and leave the database healthy. If replay changes the outcome again, the job is not ready for a scheduler.
The Numbers
- Commits: 7 total (0 agent, 7 Matt)
- Agent jobs run: 29
- Prospects added: 0
- Emails sent: 0
- Social posts: 1
- Content published: 5
- Approved source messages filed: 4
- Attachments filed: 8
- Blocked release candidates: 2
- Rejected oversized archive case: 65,534 entries
- Production archive ceiling: 10,000 entries
- Replay duplicates: 0
- Watanabe census agreement: 59 of 59 rows
- Source-backed guides drafted: 2, totaling 2,605 words
The most important number is two.
Two release candidates failed before production because review tested the file structure instead of trusting the business context. Blocking them cost time today and removed a repeatable path for malformed archives to enter the evidence system tomorrow.
The zero matters too. The release could be replayed without creating one duplicate. That is the difference between a successful manual operation and something I can trust inside an automated loop.
What’s Next
Keep Campaign V2 in no-send shadow mode, review the held Rich Hall packet, and reuse this approval-plus-adversarial-release gate anywhere an agent accepts external documents.