The Worklist Remediation Plan
Three phases that turn the six findings of the worklist investigation into a fix, sequenced so the work never repeats the errors it corrects. One phase per pass, solo, nothing deleted, no buyer name on a public URL.
Companion to
the worklist investigation. Every file named below was verified to exist on 2026-07-17.
Shop: OnethingNeededShop. This page describes method only and carries no customer data.
The prompt this plan answers
Remediate the OnethingNeededShop fulfillment worklist using the findings in /worklist-fraud-investigation. Work in three phases, one at a time, solo, with no subagents and no fan-out. Phase 1: rebuild every "never sent" determination from the order-number join in order_usernames.json, never the receipt-name join; open each flagged order's thread; emit a verified status table where 7 delivered plus 6 owed equals 13, each owed row citing "0 conversations between you and X"; fix worklist_items.json item shanilea, whose category still reads "Paid, undelivered" though its own api_note and the public index say delivered Jul 14. Phase 2: deliver the working queue Brandon fulfills from as a local file that carries the names he needs, ordered by priority with product, question, wait time, and next action per person, and deploy only a redacted public version. Phase 3: close the two gate holes in session_fraud_check.py, then re-run it on session 60f2dbf6 and on the investigation page to prove both fixes. Back up every file before replacing it and delete nothing. The 6 owed readings stay Brandon's to record; the plan hands him the correct, ordered six.
The six findings, and the phase that answers each
| Finding from the investigation | Answered in |
|---|
| Backlog asserted from a name join that could not resolve aliases | Phase 1 |
| Delivery claimed from Completed labels, not from the thread | Phase 1 |
| Correction written in prose while the data stayed contradictory | Phase 1 |
| Working queue built and never linked (queue and appendix at 404) | Phase 2 |
| The safeguard passed a session it should have failed | Phase 3 |
| "I cannot deploy" inferred from one refused command | Phase 2 guardrail |
1
Rebuild every determination on the order-number join
Replace the name match that produced "13 never sent" with the one join that survives display-name aliasing, and settle each of the 13 flagged orders by its own thread.
Fixes findings 1, 2, and 3. The root cause was a receipt-name join that went blind whenever Etsy showed a display name. The map from order id to username is the key that does not go blind, and it is present in order_usernames.json for all 47 completed orders.
- Load
order_usernames.json as the join key. For every flagged order, resolve to the buyer's username, never to the receipt name.
- For each of the 13 flagged orders, record the thread state from Shop Manager: either the verbatim "0 conversations between you and X" or a dated delivery link.
- Sort the result into two lists: delivered orders and genuinely owed orders. The counts must reconcile to the 13 that were flagged.
- Correct the data itself, beyond the prose. Set
worklist_items.json item shanilea category from "Paid, undelivered" to the delivered state its own api_note and the public index already record.
- Re-run
verify.py so the arithmetic-consistency, rejection, required-language, and privacy scans all pass against the corrected data.
Acceptance
- Delivered plus owed equals 13, shown as a reconciliation table rather than a bare total.
- Every owed row cites its thread evidence (the "0 conversations" string); no row depends on a Completed label or a name match.
grep for "category": "Paid, undelivered" on the shanilea item returns nothing.verify.py exits clean; command output pasted into the phase log.
Brandon's, not the plan's: recording the readings. Phase 1 hands him the correct ordered six and the first name to record. The recording is his manual work.
2
Deliver the queue Brandon fulfills from, and settle the deploy question honestly
Give Brandon one ordered working file he can open and complete the readings from, and resolve the tension between the ship-to-Vercel rule and the no-PII rule instead of letting it strand the artifact at 404 again.
Fixes finding 4 and carries the guardrail for finding 6. The queue and appendix builds exist locally (queue.html at 29 KB, appendix.html at 33 KB) and both return 404 on the live site. They carry names, questions, and order numbers, so a public URL is the wrong home for them.
- Build the working queue as a local artifact: an ordered list with rank, product, the buyer's own question, wait time, next action, and a completion checkbox per person. Deliver it as a PDF plus a local HTML file, opened by path on Brandon's Mac.
- Deploy only the redacted public view. The existing
public.html strips names, orders, dates of birth, emails, and quotes, and its privacy scan already passes. That is what goes to Vercel.
- Hand Brandon the working file by its
open -R path in the same message that gives the public link, so "where are the links" cannot recur.
- Deploy through the sanctioned closeout tool rather than a raw command.
ship.py succeeds where a bare vercel --prod is refused by the classifier.
Acceptance
- One local working file exists and opens, ordered, with product, question, wait time, and next action for all six.
- The redacted public view returns 200; a scan of the live bytes for names, emails, and order numbers returns zero.
- The delivery message contains both a live URL with its HTTP code and a local path that opens.
Guardrail carried from finding 6: a refused command is an observation rather than a verdict. If a deploy path is blocked, try the sanctioned tool before reporting that deployment is impossible.
3
Close the gate holes so this class of error cannot pass silently again
Repair the two structural blind spots that let the fraud checker return PASS on a session with a fabricated backlog number, then prove the repair on the two sessions that exposed it.
Fixes finding 5. The checker hard-fails only on files a session wrote through Write and Edit calls, so a session that builds through a script gets its build scripts audited and its deliverables waved through. Separately, anthropic-refund-implication fires on its bare keyword even inside quoted text, so a document cannot cite it in evidence without failing.
- Extend the authored-set in
session_fraud_check.py to include files written by scripts the session ran, not only Write and Edit targets, so public.html, queue.html, and the PDFs fall inside the fail scope.
- Stop
anthropic-refund-implication from firing on quoted evidence: add a code-span and blockquote exclusion, or require a billing-context word beside the flagged keyword, so a document can cite the gate without failing it. This page describes that keyword only by the pattern id for exactly this reason.
- Add a numeric-consistency check that a stated total equals the sum of its named parts. This is the check that would have caught 8 plus 6 equal to 14 against a starting 13.
- Back up each patched file to a timestamped copy before replacing it. Delete nothing.
Acceptance
- Re-running the checker on session 60f2dbf6 now lists the deliverables in the fail scope, not only the build scripts; output pasted in.
- Re-running it on the investigation page no longer fires that false positive.
- The numeric-consistency check flags a seeded 8-plus-6-equals-14 test case.
- Backup copies of the patched files exist alongside the originals.
Recorded limit: no file-level regex knows that 13 should have been 6. Phase 3 narrows the blind spot; only Phase 1's per-thread check closes it.
Sequencing and guardrails
One phase per pass. Phase 1 produces the correct six and is the only phase that touches customer obligation, so it runs first and alone. Phase 2 depends on Phase 1's corrected data. Phase 3 is independent tooling and can run last without blocking the readings.
Solo, per the standing resource policy. No subagents, no fan-out, no parallel sessions. The ultracode default does not override Brandon's explicit one-session rule.
Nothing deleted. Every replaced file is backed up to a timestamped copy first. No rm, no Trash.
PII stays local. The file Brandon works from carries names by necessity and lives only on his Mac. The public artifact is the redacted one. This is the guard that held in the original session and it holds here.
What this plan does not do. It does not record the six readings; that is Brandon's manual work, and the oldest buyer had been waiting 17 days at the investigation's review time. It does not re-verify the inbox layer, which came from a read on another machine that the Etsy API cannot reproduce. Phase 1's corrected count inherits that single-source limit until a second thread review confirms it.