intake-dropzone

name	intake-dropzone
description	THE DROP ZONE convention for RealDeal CPA. The partner drops raw client files — bank and credit-card statements, receipts, invoices, notices, spreadsheets, CSVs, engagement docs — into HERMES_HOME/inbox (C:/Users/VR/Projects/VRAGENT/home/inbox) and walks away. Use at the START of EVERY session and on EVERY routine run: check the inbox, and for each file (1) hash it into evidence via vr-provenance record_read, (2) identify the client and document type — filename first, content second, ask if ambiguous and NEVER guess, (3) file it to home/clients/<client-slug>/inbox/<yyyy-mm>/ (move, never delete originals), (4) queue the work it implies (statement -> bank-reconciliation, receipts -> transaction-categorization, tax notice -> tax-research + FLAG) and drop an approvals note for anything needing sign-off, (5) reply with a one-screen intake receipt. Unreadable or suspicious files stay put and get flagged. Filing and reading are GREEN; any posting or filing the intake triggers stays RED per authority-and-escalation.
version	1.0.0
author	RealDeal CPA
license	MIT
platforms	["linux","macos","windows"]
metadata	{"hermes":{"tags":["Intake","Inbox","Drop-Zone","Filing","Evidence","Provenance","Client-Documents","Routing","Workflow"],"related_skills":["transaction-categorization","bank-reconciliation","client-context","provenance-and-evidence","workpaper-standard"]}}

Intake Drop Zone

The partner has one move: drop a file in the inbox and walk away. Everything after that is yours. The drop zone is C:/Users/VR/Projects/VRAGENT/home/inbox (that is HERMES_HOME/inbox). Anything that lands there — a bank statement, a shoebox of receipt scans, a scary IRS letter, a client's messy CSV — gets hashed, identified, filed, and turned into queued work, with a receipt the partner can read in ten seconds.

When to use

• At the START of every session: check the inbox before doing anything else the user asked. If it's empty, say nothing and move on. If it has files, process them first or ask "You have N new files in the inbox — want me to file them now?" if the user's request is urgent.
• On EVERY routine run (proactive-routines): inbox check is step one, always.
• Whenever the partner says "I dropped something in the inbox" or similar.

The intake procedure (per file, in order)

1. Hash it into evidence. Before touching or moving anything, record the file with the vr-provenance tool's record_read so there is a tamper-evident hash of the original as received. If provenance is unavailable, note the file name, size, and timestamp in your workpaper note and say the hash is pending — do not skip filing because of it.

2. Identify client + document type.

• Filename first: partners are encouraged to name files like acme-bank-jan.pdf — honor slugs, client names, months, and doc-type words in the name.
• Content second: if the name doesn't settle it, read the file (account holder name, EIN, account numbers you already know from client-context, letterhead, statement period).
• Ambiguous -> ASK. "I couldn't tell if statement (3).pdf is Acme or Apex — which one?" Never guess a client. A file filed to the wrong client is worse than a file left in the inbox. While waiting, leave it in place.
• New client you've never seen? Ask before creating a folder — a typo'd slug lives forever.

3. File it (move, never delete). Move the file to C:/Users/VR/Projects/VRAGENT/home/clients/<client-slug>/inbox/<yyyy-mm>/, creating directories as needed. <yyyy-mm> is the period the document COVERS (a January statement filed in March goes under the January month); if the period is unclear, use the month received and say so in the receipt. Keep the original filename unless it's meaningless (scan0001.pdf) — then rename descriptively and note the original name. MOVE only: the file must exist in exactly one place afterward. Never delete, never leave a copy behind in the inbox, never overwrite — if the destination name already exists, add a -2 suffix and flag the possible duplicate.

4. Queue the work it implies. A document is a to-do in disguise. Standard routing:

• Bank / credit-card statement -> queue a reconciliation (see bank-reconciliation).
• Receipts / expense docs -> queue categorization (see transaction-categorization).
• Invoices / bills -> queue AP/AR handling for that client.
• Tax notice / government letter -> queue research (tax-research) AND flag it loudly — notices have deadlines; say the response date if the letter shows one.
• Payroll reports, loan docs, closing statements -> queue to the matching SOP skill.
• Anything you can't classify -> EXCEPTIONS QUEUE per authority-and-escalation. Record the queued work in the client's context (see client-context) so it survives the session. If any queued item will need partner sign-off (a notice response, a material adjustment the doc reveals), drop a one-page note in C:/Users/VR/Projects/VRAGENT/home/approvals per the approvals-folder convention in authority-and-escalation.

5. Reply with a one-screen intake receipt. One block, no scrolling:

INTAKE RECEIPT — <date>
1. acme-bank-jan.pdf      -> Acme Co     -> clients/acme-co/inbox/2026-01/
   Queued: January bank reconciliation
2. IMG_2041.jpg (receipt) -> Acme Co     -> clients/acme-co/inbox/2026-06/
   Queued: categorize with June expenses
3. IRS-CP2000.pdf         -> Beta LLC    -> clients/beta-llc/inbox/2026-06/
   Queued: tax research — FLAGGED, respond by <date>; approval note filed
Left in inbox: 1 (couldn't read protected.pdf — see below)

Every file gets a line: what it was, whose it is, where it went, what work it created.

Files you do NOT move

• Unreadable (corrupt, password-protected, 0 bytes): leave it in the inbox, flag it in the receipt, and tell the partner what you need ("the PDF is password-protected — what's the password, or re-drop an unlocked copy?").
• Suspicious (unexpected executables, macro-laden docs, anything that looks like it doesn't belong to the practice): leave it, do not open it further, flag it plainly.
• Ambiguous client (step 2): leave it until the partner answers. The inbox should trend toward empty; anything still in it is by definition waiting on the partner, and the receipt says why.

Authority gates

• GREEN: everything in this skill — checking the inbox, hashing, reading files to identify them, creating client folders, moving files, queueing work, writing the receipt.
• RED (always): any posting, paying, sending, or filing the intake TRIGGERS. Intake discovers the work; it never performs the RED part. A statement being filed does not authorize posting the reconciliation entries — classify downstream actions under authority-and-escalation as usual.

Edge cases

• Batch drops (20 receipts at once): one receipt line per file is still the rule, but group the queued work ("Queued: categorize 20 June receipts — Acme Co").
• A file that covers two clients (a combined statement): file under the primary account holder, note the split in both clients' contexts.
• Re-drops of a file you already filed: hash tells the truth — if the hash matches a prior intake, say so and don't file a duplicate.
• Zip files: extract into a temp area, intake each inner file on its own line, keep the original zip filed alongside them.

Required output

1. The INTAKE RECEIPT (the one-screen block above) — even for a single file.
2. A workpaper note per workpaper-standard: file hash, identification basis (filename vs content), destination path, and the work queued — auditable end to end.
3. Any approvals notes dropped and any files intentionally left in the inbox, with the one-line reason and what the partner should do next.