See what the audit actually returns.

One paragraph. Five systems.

Add a referral program to the app.

When a user refers a friend, both of them get 500 credits. Credits work like our normal balance so people can spend them on anything. Show a trust score on the referrer's dashboard so we can spot abuse—people making fake accounts to farm credits. If the trust score is low, hold the credits.

Users can erase their account at any time, and referral history has to stay intact for the audit trail so we can prove what happened if someone challenges a payout. Log everything.

Credits should only be released once the friend actually pays for something, so we do not get farmed.

Acceptance: referral program works, abuse checks are in place, audit trail exists. Need it this week.

142 words. Reads like one task. It is five.

Read this before anything runs.

A PROGRAM WEARING A TASK'S CLOTHING

Two new stores, one scoring surface, one audit log, one dashboard surface, one release rule, and one erasure path cannot share one red test. Split the work before an agent silently chooses the order.

This packet covers A only. B through E follow one at a time, in that order.

Facts the agent is not allowed to invent.

Ten fills. Every one marks a place where an agent would otherwise invent something plausible and move on.

Four failures that survive a normal read.

3.1 · Self-contradiction — two found

“Both users get 500 credits” conflicts with “release credits only after payment.” Resolve it as two events: grant held credits at referral, release them only after a cleared payment. Held and spendable remain separate facts.

“Erase the account” conflicts with “keep referral history.” Store a pseudonymous account reference in the ledger and keep identity in a separate map. Erasure severs the map while events remain provable.

3.2 · Undefined number — found

“Trust score” has no inputs, range, threshold, formula, or zero case. Packet D must return the full formula or show the underlying signals with no invented score. A number without a formula is an agent's opinion wearing a decimal point.

3.3 · Unfalsifiable criteria — three found

3.4 · Self-reported control — found

An ordinary audit table is not proof. If the application can write it, the application can rewrite it. Make the ledger append-only at the database level. Grant INSERT and SELECT to the runtime role; revoke UPDATE and DELETE. Hash-chain each event to its predecessor so a removed row leaves a visible break.

The sweep catches what the ticket never names.

The work, stated without the hidden program.

Every change to an account's spendable amount becomes an immutable event. Compute the balance from events. Never store it as the only mutable truth.

Event types: GRANT_HELD · RELEASE · SPEND · REVERSE · ADJUST

Each row carries a pseudonymous account reference, signed amount in the approved unit, event type, cause reference, timestamp, and previous-event hash.

ledger.append_only.spec

GIVEN  a ledger row written by the runtime role
WHEN   that role attempts UPDATE on the row
THEN   the database refuses the statement
AND    when that role attempts DELETE
THEN   the database refuses the statement
AND    when a stored previous-hash changes out of band
THEN   chain verification reports the first broken row

Money Truth assertion

GIVEN  an account with at least one ledger event
WHEN   signed event amounts are summed
THEN   the sum equals the spendable balance shown to that account
AND    held value remains separate from spendable value

The loop cannot go green while those facts drift. If either test passes before the work exists, the test is wrong—fix the test first.

Written before work starts.

1. Turn ledger.enabled off. Reads return to the existing balance source named by fill 04.
2. Keep the ledger table. A rollback never destroys evidence.
3. Reverse the new runtime grants with the reviewed migration.
4. Stop dual-write at the flag so the prior balance remains authoritative.
5. Trigger: any production reconciliation mismatch. One row is enough.

READINESS — 6 / 10