feat(receipts): Receipts tab, missing-receipt chaser, Chat cards, nightly QBO bank pull (pipeline v2 phase 2)

[Clarion1631]

What

Receipt Pipeline v2, Phase 2 (docs/plans/PHASE-2-QUEUE-AND-MEMOS-SPEC.md), plus the prerequisite the spec flagged as its own risk 1.

• Receipts tab on /automation (?tab=receipts) — six groups over ReceiptIntake plus open missing-receipt issues, behind the same financialReports gate as the register. Row actions are server actions in src/lib/actions.ts, each with the permission gate and a compare-and-swap on state.
• Missing-receipt chaser — MISSING_RECEIPT joins the closed reason-code set; src/lib/receipt-requests.ts (pure) opens exactly one ReviewIssue per unmatched bank debit older than 3 days, auto-closes on match, reopens on unmatch. Nightly at 13:00 UTC.
• Per-owner weekday Chat card — one message per owner per day to the Receipts Need Review space, three reply options, sign handoff via the Beverly affidavit-threads.json / chat-job-answers.json contract. Ships behind RECEIPT_REQUEST_CARDS_ENABLED.
• Nightly QBO bank register pull (the prerequisite) at 02:00 UTC, before the chaser runs.

No PDF is ever emailed. A test rejects a mail-helper import in any Phase 2 module.

Why

The chaser's truth is BankLine, which until now only filled from monthly statement imports plus a laptop-run scripts/post-qbo-register.mjs. A "3-day" chase was in practice a 30-day one. The pull closes that, and per Justin's decision 3 (the QBO bank feed is bank truth) QBO register rows can now mint canonical lines themselves.

Documented minting limitation

BANK_LINE_MINT_FROM_QBO defaults OFF, and the src/lib/bank-line-mint.ts header states why:

• a QuickBooks restatement after minting leaves stale figures on a line whose amountCents is immutable by trigger — a human resolves it;
• a QBO row deleted in QuickBooks leaves its minted line behind, honest but unreaped;
• split postings (one QBO row, two bank lines, or the reverse) will not adopt, so the statement mints its own and the QBO line lingers.

Minting is paired with adoption: a statement line matching a QBO-minted line exactly attaches to it and flips sourceOfRecord to STATEMENT rather than minting a twin. Both write paths take pg_advisory_xact_lock(hashtext('bank-line-identity')) and plan inside that transaction.

Review history

Three Codex rounds, all findings addressed on this branch.

Round 1 (6 blockers, 5 real issues). Server-Action bypass on the machine endpoints; freshness (minting); card idempotency; signed memos reopening nightly; void/mark-duplicate racing the worker; thread retention. Plus: qbTxnId content comparison, one-to-one evidence assignment, the query window, the retry list, and card-selection starvation.

Round 2 (5 blockers, 7 real issues). The action guard had to cover every machine bypass and run before the dev bypass; minting had to be cardinality-aware and lock-protected; the card outbox needed a token CAS with cards[] written before posting; the resolution merge had to re-read per issue; the BOOKED write had to be fenced. Plus the schema/index parity, evidence-unit folding, evidence date coverage, the owner scan's exit condition, legacy card seeding, a telemetry counter that never fired, and column-type verification.

Two holes were found by tests while writing them, not by review: the card resume path let a concurrent run re-post an in-flight card (fixed with a claim lease, then the token CAS), and the first evidence-unit key did not fold the email-fallback path.

Tests

• npm run test:unit — 938 pass, 0 fail (8 new suites wired in, plus test:receipt-requests).
• npm run build — compiled successfully, tsc 0 errors, eslint 0 errors.
• Highlights: convergence in both bank-line arrival orders and re-runs; two concurrent mint runs producing one line (and two same-key transactions producing two); the outbox claim under two simultaneous runs; a memo signed mid-sweep surviving it; void-during-BOOKING never booking; booked-after-void parking the orphaned Purchase.
• e2e/receipt-requests.spec.ts — ADMIN sees every group; both bridge endpoints answer JSON 401 (never a /login redirect) for anonymous, bogus-session-cookie, and wrong-secret callers.

Nothing was run against production.

Deploy order

Both scripts are additive and idempotent, and must run before merge (CLAUDE.md pre-deploy rule #2 — the new build selects these columns immediately):

1. node scripts/apply-receipt-intake.mjs --yes --expect-db <db> --expect-host <host>
2. node scripts/apply-phase2-receipt-queue.mjs --yes --expect-db <db> --expect-host <host>

Then enable flags one at a time, and only after step 2.

Env vars a human must set

• RECEIPTS_CHAT_WEBHOOK — incoming webhook for spaces/AAQAKhvMYtg. Unset ⇒ {skipped:"no-webhook"}, fails soft.
• RECEIPT_OWNER_CHAT_USERS — {"CJ":"users/…","Richard":"users/…"}. Still needs collecting; a wrong id locks that owner out of signing their own memo.
• RECEIPT_REQUEST_CARDS_ENABLED — leave unset for a shakedown week. Turn Beverly's own asks off in the same step.
• BANK_LINE_MINT_FROM_QBO — leave unset until step 2 above has run.
• RECEIPT_BRIDGE_SECRET — NEW, REQUIRED, and DISTINCT from the other two receipt secrets. It gates both bridge endpoints (/api/automation/receipt-requests/threads and .../answers); presenting RECEIPT_INTAKE_SECRET or RECEIPT_ARCHIVE_SECRET there is a 403, not a fallback. It must be set in two places: Vercel production, and the Apps Script bridge that sends the x-receipt-intake-secret header. Change both together — until they agree, the bridge is refused and signed memos stop being recorded. Beverly's bridge runs outside our repos, which is exactly why its key must not be able to book anything.
• RECEIPT_INTAKE_SECRET, RECEIPT_ARCHIVE_SECRET, CRON_SECRET — existing. The intake and archive keys are not reused for the bridge; each key's complete MAY / MAY NOT list is in src/lib/receipt-intake/intake-auth.ts and .env.example, and any two of the three sharing a value is refused at runtime.

The full sequence, including which order to flip the flags in, is the operator checklist in §9 of docs/plans/PHASE-2-QUEUE-AND-MEMOS-SPEC.md.

Companion changes (neither is in this repo)

• qbo-clasp: mirrorReceiptRequestThreads() and an answers forwarder.
• Beverly's runner: the "post the sign card on request" trigger.

Until both ship, photo and job-name replies work; sign N is recorded but no sign card appears.

🤖 Generated with Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
probuild	Ready	Preview	Sep 2, 2026 10:04pm UTC

[github-actions]

Required changes

1. P0 — Voiding during the QBO send still creates a ProBuild Expense. book.ts creates/reuses the Expense before the state = BOOKING fence at line 364. When that fence loses to VOID, the transaction still commits the Expense, polluting job costs for a purchase explicitly meant to be voided. Fence or lock the intake before creating the Expense, and test that booked-after-void creates zero Expenses.

2. P0 — Ordinary QBO Expenses falsely count as receipt evidence. receipt-requests/route.ts loads every date-matching Expense without requiring receiptUrl or an attachment. QBO sync creates Expenses without receipts, so the chaser will close precisely the missing-receipt cases it should detect. Require actual receipt evidence; add a test where a matching QBO Expense with receiptUrl = null remains open.

3. P0 — QBO and statement identities do not converge reliably. bank-register-pull.ts appends qbType, producing normalized payees such as LOWES EXPENSE; statements normally normalize to LOWES. Since bank-line-mint.ts requires exact normalized-payee identity, reconciliation/adoption misses and QBO minting creates twins. Even successful adoption only flips sourceOfRecord in ingest/route.ts; it never replaces the QBO descriptor, so the statement’s C#8516/C#6098 owner evidence remains lost and the item stays office. Use one canonical identity representation and copy statement-authoritative descriptor fields during adoption. Test with real-shaped QBO and statement descriptors.

4. P0 — Signed memos remain race-unsafe. answers/route.ts knowingly clears the issue even when its resolution CAS loses. That leaves no resolution, so the next sweep reopens it. Conversely, the sweep reads details at receipt-requests/route.ts outside the lifecycle transaction; a signature landing after that read can be overwritten by the subsequent touch/retry. Make resolution recording and clearing atomic or use a CAS retry-and-merge loop, and make every display-details writer preserve concurrently added resolutions.

5. P1 — The cron “claims” do not lock the jobs. claim() in receipt-requests/route.ts and the bank pull acquires a transaction advisory lock and immediately commits, releasing it before any work. Overlapping receipt sweeps can therefore apply contradictory snapshots, with a stale open winning after a newer close. Use a durable lease/claim covering the run, or recompute source truth when lifecycle OCC retries. Add full-route concurrent-run tests.

6. P1 — Successful uploads can become permanently stuck. After storage succeeds, publishing STAGING → RECEIVED occurs separately at intake/route.ts. If that update fails, a retry sees STAGING and only returns 202 at line 316; later the sweeper incorrectly labels the row file-missing despite the object existing. Reconcile staged rows against storage and promote them on replay/sweep.

7. P1 — Pipeline health reports green during serious failures. pipeline-health.ts considers both “never pushed” and “stalled for more than seven days” healthy, so an outage automatically becomes green after day seven. Database probe failures are also converted to null/0 at lines 111–133, allowing a total DB outage to return “Pipeline OK.” Represent probe failure as unhealthy/unknown and never treat missing telemetry as successful quietness.

8. P1 — Cron/headless authentication is inconsistent and partly broken. pipeline-digest/route.ts authenticates only when VERCEL_ENV is truthy; /api/cron/* bypasses the proxy, so another production environment can trigger email/chat and read health data anonymously. Use isCronAuthorized. Meanwhile /api/health/pipeline claims to support CRON_SECRET, but proxy.ts does not bypass that path, so headless callers are redirected before its handler sees the header. Add an exact machine bypass plus the Server Action guard.

9. P1 — The new sensitive tables omit Supabase RLS. Both ReceiptIntake migration and ReceiptRequestCard migration create public-schema tables containing financial/user metadata without enabling RLS or explicitly revoking Data API roles. Existing sensitive tables such as ReviewIssue do enable RLS. Add the same protection to both migrations and rollout scripts.

10. P1 — The reduced QBO route deadline can kill valid work mid-write. qbo-receipts/create/route.ts sets maxDuration = 30, but one creation can sequentially perform the idempotency query, customer/vendor resolution, account verification, purchase creation, and attachment upload—each with a 20-second timeout. Use a realistic overall budget or shorter coordinated per-call budgets; otherwise Vercel can terminate after QBO created the purchase but before the response/attachment completes.

11. P2 — Owner filtering happens after the 100-row cap. receipts-data.ts fetches only 100 issues and then filters by owner in memory. A valid Richard/CJ item outside that newest page renders as an empty filtered queue. Page through issues until the requested owner’s display cap is filled or the queue is exhausted, as the card scan already does.

VERDICT: REQUEST_CHANGES

[github-actions]

Required changes:

1. A QBO purchase created after a manual void/duplicate is effectively hidden. book.ts records postVoidQbPurchaseId but preserves VOID/DUPLICATE; the loader excludes VOID, and the duplicate UI never renders the warning. Put every orphaned purchase into a visible exception queue with its QBO link.

2. The receipt-request advisory lock is released when claim() returns, before reconciliation begins. Worse, the OCC retry at route.ts recomputes one line in isolation, violating one-to-one evidence assignment. Two concurrent first runs over two identical charges and one receipt can create then incorrectly clear the second issue. Use a durable run lease or recompute the complete competing set, and add that concurrency test.

3. Signed resolutions remain race-prone. receipt-request-cards/route.ts replays stale codes/details through evaluateReviewIssue, which can reopen a just-cleared issue and erase its resolution. Conversely, answers/route.ts discards a delayed signed memo whenever an issue was already auto-closed, so it later reopens if the original receipt disappears. Persist card history with a fresh CAS that preserves answers, and always record valid signed evidence even on cleared issues.

4. Card delivery can be marked successful without a usable bridge identity. receipt-request-cards.ts returns success when the webhook body lacks thread.name or message.name; the cron then sets postedAt, while the threads endpoint silently excludes the card. Also, failed pre-post attempts leave cards[], causing everCarded ordering to deprioritize work that was never delivered. Validate the required response fields and distinguish pending attempts from delivered card history.

5. The nightly bank pull fails open operationally. bank-register-pull.ts swallows reconcile/mint failures without making the summary unsuccessful, and bank-register-pull/route.ts returns HTTP 200 for any non-conflict ingest failure. Additionally, pipeline-health.ts converts database failures to null/zero, which can report “Pipeline OK” during a total database outage. Propagate failures into both HTTP status and health verdict.

6. The new QBO timeout budget contradicts the route duration. qbo-receipts/create/route.ts permits only 30 seconds, but token refresh plus the multiple sequential 20-second QBO calls in createQBReceiptPurchase can exceed that. Vercel can kill the request before the new retryable timeout response is produced. Use a shared end-to-end deadline or restore a duration exceeding the cumulative budget.

7. The “fresh” QBO path cannot populate the per-owner chaser. bank-register-pull.ts constructs descriptors solely from vendor name and transaction type, while resolveReceiptOwner only recognizes C#<tail> and otherwise assigns office. Since cards only target CJ and Richard, QBO-minted lines remain page-only until a statement supplies the card tail—the same monthly delay this prerequisite claims to remove. Preserve an owner/card signal from the fresh source or provide another explicit attribution mechanism.

8. The 2,000-line cap silently violates “one issue per unmatched debit.” receipt-requests/route.ts takes the newest lines, so older never-seen lines can remain behind the cap until they age out of the 60-day window. Paginate to completion, process oldest-first with a durable cursor, or fail visibly rather than silently abandoning candidates.

VERDICT: REQUEST_CHANGES

[github-actions]

Required changes

1. The component replan still uses stale issue state. receipt-requests/route.ts retries with the original openIssues, resolvedIssueKeys, and detailsByKey. A sibling memo signed after the initial snapshot can therefore still consume evidence and falsely open another issue. Reload all component inputs from the locked transactional snapshot before every replan; add a sibling-resolution race test.

2. The evidence fence is not actually atomic. receipt-requests/route.ts locks existing issues/intakes, but ordinary reads of Expense and BankLine remain vulnerable to updates and phantom inserts before verdict writes. Worse, componentVersionOf() hashes only expense identity/receipt presence even though planning depends on amount, date, and vendor. Use serializable retries or a shared advisory-lock protocol and fingerprint every decision-driving field.

3. The open-issue cursor skips failed orphan cleanup. In receipt-requests/route.ts, orphan evaluation errors increment openPass.errors, but the cursor still advances unless line processing also fails. A later continuation can finish and clear the cursor, permanently stranding that issue. Any page-local failure must prevent checkpoint advancement.

4. The scheduled card retry cannot recover from an incomplete chaser. The first card run exits before creating claims when the sweep marker is incomplete, while retry mode later skips every owner without an existing card in receipt-request-cards/route.ts. If the sweep completes between 14:30 and 16:30, no card is sent that day. Retry mode must perform initial selection when no daily claim exists.

5. The supposedly idempotent rollout script does not converge stale constraints. apply-phase2-receipt-queue.mjs checks constraint names only. An earlier named ReceiptRequestCard_status_check lacking UNCERTAIN, or a stale source-of-record check, survives reruns and passes verification. Compare pg_get_constraintdef plus owning table, then replace mismatched definitions; test upgrading an earlier schema revision.

6. A failed/stalled chaser is invisible to pipeline health. pipeline-health.ts does not evaluate receiptRequestsPhase or chaserCompletedAt. The card cron then returns a successful HTTP response with skipped:"chaser-incomplete", so the entire feature can silently stop. Add freshness/completion monitoring and surface it in the digest before cards are due.

7. The owner action’s CAS does not protect against stale UI intent. setMissingReceiptOwner() reads the current version after the click instead of accepting the version/reason hash rendered to the user. A close/reopen or changed issue can receive an assignment from an obsolete page. Pass the expected generation from the row and reject stale submissions atomically.

VERDICT: REQUEST_CHANGES

[github-actions]

I applied the repository’s Supabase/Postgres concurrency and migration guidance when evaluating the transaction fences and DDL.

1. [P0] New unmatched bank lines can never finish reconciliation. The planned fingerprint omits BankLine.updatedAt, while the transactional fingerprint includes it (route.ts, receipt-requests.ts). For a new line with no issue or intake, planned.newest is empty and current.newest is not, so all three attempts replan and no chase opens. Include updatedAt in BatchLine and every planned fingerprint; add a regression test for a brand-new unmatched line.

2. [P0] “Atomic component” writes commit partially. applyReceiptRequestPlan() catches per-target failures instead of throwing (route.ts), even when invoked inside the claimed all-or-nothing component transaction (route.ts). If the second lifecycle update fails, the first still commits. Make failures abort that component transaction, then report/retry outside it. Test that an error on the second verdict rolls back the first.

3. [P0] The freshness fence does not cover concurrent evidence writers. The transaction locks only existing issues and already-discovered intake rows (route.ts). Expenses are not locked, new evidence can be inserted after the fingerprint read, and receipt/expense writers do not take this component advisory lock. A receipt can therefore arrive immediately before a stale missing-receipt issue commits. Use a serializable transaction with retries or a shared fence honored by every evidence writer, and add concurrent attachment/insertion tests.

4. [P1] Undecided components are reported as a clean, completed sweep. Exhausting replans returns undecided without an error (route.ts); sweepPhaseAfter() ignores undecided work (route.ts); the caller advances the cursor and stamps chaserCompletedAt (route.ts). Cards may then be sent from an unreconciled issue set. Undecided work must prevent completion and remain resumable.

5. [P1] Expense dates are matched in UTC instead of the company timezone. Both planning paths convert Expense.date with toISOString().slice(0, 10) (route.ts, route.ts), despite querying those timestamps using company-local boundaries. Near Pacific midnight this shifts the evidence date and can falsely open or close a chase. Convert using the resolved company timezone and test midnight/DST boundaries.

6. [P1] QBO continuation skips changes before its cursor. resumeAfter() discards every row at or before the saved (postedDate, qbTxnId) before ingest can compare its content (bank-register-pull.ts). A restated transaction or newly inserted backdated row can evade the advertised conflict detection—potentially permanently once outside the deep-sweep window. Revalidate overlap/prefix rows or persist a content-aware snapshot; test restatement and insertion before the cursor.

7. [P1] The bridge can attach an unrelated URL to a verified artifact ID. It verifies pdf_id, then accepts any syntactically durable caller-provided pdf_url without proving that URL represents that ID (answers/route.ts). This corrupts the audit trail and UI link. Store the probed Drive URL or require the URL’s file ID to match pdf_id.

8. [P2] The supposedly idempotent migration rebuilds its checks on every run. pg_get_constraintdef() preserves quotes around camel-case identifiers, but the expected strings omit them (migration.sql). The equality test therefore fails and drops/re-adds constraints, taking table locks and revalidating data. Compare normalized definitions or inspect constraint semantics structurally, and test a second application performs no DDL.

VERDICT: REQUEST_CHANGES

[github-actions]

Request changes. The advertised concurrency and artifact-integrity guarantees are not actually met.

1. Contended components are checkpointed past and may never be retried. After three failed replans, processBatchWithReplan() returns contended > 0 but summary.errors === 0. Both the open pass (line 1329) and line pass (line 1455) stop cursor advancement only for errors, so they persist a cursor beyond the contended page. A later invocation can finish the remaining pages, forget the prior invocation’s contention, stamp the sweep complete, and send cards from unreconciled state. Treat contention as an uncheckpointable page result and add a multi-invocation regression test.

2. The optimistic fingerprint excludes fields that determine evidence identity. evidenceUnitKey() uses Expense.qbPurchaseId, ReceiptIntake.qbPurchaseId, and ReceiptIntake.expenseId to decide whether two rows are one receipt. componentVersionOf() hashes none of them, and the transactional reread omits them too (route line 981). A link change between planning and commit can therefore pass the version check while changing one-to-one receipt allocation. Include every planner-read identity field in both snapshots and cover link changes during planning.

3. The component fence cannot detect newly inserted competitors. Components join same-amount lines up to four days apart, but the transactional BankLine reread is limited to the component’s ±2-day evidence range (route line 895). A line inserted three or four days beyond an edge after the initial scan belongs to the same competition component but is absent from the fingerprint; an earlier insertion also changes the advisory-lock key. The stale allocation can commit and the cycle can be certified complete. Recompute the full transitive component under an appropriate shared fence, or introduce a ledger-wide/versioned mutation fence; test an adjacent insertion between snapshot and transaction.

4. “Verified signed memo” currently means only “some accessible Drive object exists.” probeDriveFile() requests only id, name, trashed, and webViewLink. The answers endpoint then accepts that object as evidence without checking PDF MIME type, affidavit provenance, target fingerprint, or whether the same file was already used for another charge. A bridge bug—or possession of the bridge secret plus any accessible Drive ID—can permanently suppress arbitrary receipt chases. Bind artifacts to their target using trusted metadata or a manifest, require the expected MIME/provenance, and reject cross-target reuse.

VERDICT: REQUEST_CHANGES

[github-actions]

Request changes. Five material gaps remain.

1. [P0] The “bank truth” source is not the bank feed. qbo-bank-register.ts pulls the QBO GeneralLedger report, and its own honesty contract admits it cannot see pending, excluded, or unmatched Banking-feed transactions and does not prove clearance. Yet bank-line-mint.ts treats these rows as bank truth and mints canonical lines. Consequently, the unreviewed feed charges this feature is supposed to chase still may not appear until the monthly statement, while manual journals or uncleared checks can become fake canonical bank transactions. Use an actual feed/settlement source or require independent bank evidence before minting. Add tests for an unreviewed feed debit and an uncleared/manual GL posting.

2. [P0] The component freshness fence does not fence concurrent evidence writers. The advisory lock in route.ts is taken only by this sweep. Expense, ReceiptIntake, and BankLine writers do not take it; Expenses and BankLines are not even row-locked. Evidence can therefore be inserted, deleted, or updated after the reads at route.ts but before commit, producing a stale open/close decision that survives until the next sweep. Make every relevant writer participate in a shared lock/generation fence, or use an equivalent transaction protocol that actually prevents phantoms. Test inserts and deletes occurring after the fingerprint read.

3. [P1] Continuation permanently skips changes before its cursor. resumeAfter() discards every fetched row at or before (postedDate, qbTxnId) before ingestion or conflict comparison, and the run applies that filter at bank-register-pull.ts. A QBO restatement or newly inserted backdated row before the cursor is invisible. Once the window advances—and especially near the deep-sweep boundary—it can be missed permanently. Revalidate the prefix or persist and compare content identities before skipping writes. Add multi-invocation tests for both restatement and backdated insertion before the cursor.

4. [P1] Any accessible Drive file can masquerade as the signed affidavit for any charge. The answers route verifies only that pdf_id exists, then records memo-signed at answers/route.ts. probeDriveFile() fetches only ID, name, trash status, and URL—no MIME type, expected folder/provenance, transaction fingerprint, signer, or uniqueness. A bridge bug, replay, or credential compromise can reuse an unrelated file to silence arbitrary chases. Bind the artifact cryptographically or through trusted Drive metadata to the target fingerprint, require a PDF, and reject cross-target reuse.

5. [P2] A malformed stored card permanently loses that owner’s card for the day. After successfully claiming a row, route.ts simply continues when itemsJson parses to zero items. The claim remains, the unique owner/date row prevents replacement, and every expired-lease retry repeats the same failure. Quarantine/delete the invalid outbox row or release it in a state that permits a fresh selection, and cover malformed and legacy payloads.

VERDICT: REQUEST_CHANGES

[github-actions]

Three blocking correctness issues remain.

1. The sweep’s “atomic component” fence is illusory. It locks existing issues/intakes, but reads Expense and BankLine without locks, and no evidence writer takes the component advisory lock. An expense can gain a receipt—or a new intake/bank line can be inserted—after the fingerprint read at line 990, while the stale open/touch verdict still commits. The morning card only rechecks issue state, so it can chase a receipt already submitted. Establish a locking protocol shared by every relevant writer, or re-run the actual component matcher before delivery. Add a real concurrent database test covering evidence committed between fingerprint and verdict.

2. Same-identity statement-first transactions never converge. For two identical statement lines followed by two identical QBO observations, reconciliation classifies the 2×2 group as ambiguous and links nothing. Minting then consumes both existing-line counts as statementLineExists and also does nothing. Every subsequent run repeats this state. Worse, the nightly caller discards result.ambiguous, reports the run complete, and stamps a successful freshness heartbeat. Provide a durable convergence/manual-resolution path and treat unresolved ambiguity as incomplete; add the missing statement-first same-key regression test.

3. “Verified PDF” currently means “any non-trashed Drive object exists”. The probe requests no mimeType, parents, or identifying metadata, yet the answers route records memo-signed for every found result. A folder, spreadsheet, unrelated photo, or arbitrary known Drive file can permanently silence a chase. Verify at least PDF MIME type and bind the object to the expected memo/fingerprint or configured memo folder before clearing the issue.

I treated the first two as blockers under the repository’s Supabase/Postgres concurrency and integrity guidance.

VERDICT: REQUEST_CHANGES