DEV Community: Edy Cu

When a model writes the maths, make it sit the booklet's own exam first

Edy Cu — Sun, 01 Nov 2026 02:59:39 +0000

A draft surveyor weighs a bulk cargo by reading the painted draft marks on a hull, and the sea never holds still across them. I built DraftMark for the Meta AI Developer Hackathon to do two things: time-average that moving waterline from a short video, and let a model write the per-ship survey program. This post is about the second part, because the interesting problem is not "can a model write the program" but "why would you believe it".

Live: https://draftmark.edycu.dev · Repo: https://github.com/edycutjong/draftmark

The problem with a per-ship program

After the draft is read, a survey converts it to displacement through that ship's hydrostatic booklet: interpolate a table, apply trim corrections, correct for water density, subtract ballast and fuel. Every booklet states its own conventions. The usual answer is a spreadsheet per vessel, built by hand.

I gave Muse Wonder 1.0 a public trim and stability booklet (a Ro-Ro/passenger ship, not a bulk carrier) and asked for the survey program. A program written by a model is a claim. I wanted an exam it could not talk its way through.

The exam is the booklet's own printed examples

The booklet prints 22 worked loading conditions with the displacement it expects. So the acceptance rule is: a program passes a row if it lands within 0.1 % of the printed number, and it is accepted only if at least 20 of 22 rows pass, both out-of-range probes raise, and 200 randomized cases agree with a reference program within 0.05 %.

verdict = "PASS" if (n >= 20 and pc >= math.ceil(0.9 * n) and all(probes) and len(probes) == 2
                     and fails == 0 and dmax is not None and dmax <= 0.05) else "FAIL"

The program runs in a sandbox: an AST gate, a python -I -S subprocess, resource limits, an audit hook, no network. The model's code never runs in the server process.

What happened

Program	Printed conditions reproduced
Generic textbook template	0 of 22
The booklet's section 3.1 procedure implemented verbatim	14 of 22
Muse Wonder 1.0, 3rd attempt (2 regenerations)	22 of 22
Our own reference program	22 of 22

The attempt log is more instructive than the result. Attempt 1 was rejected by the static gate (it used globals). Attempt 2 ran and passed 14 of 22, failing at the same intermediate step on eight rows (conditions 2.2, 3.1, 3.2, 6.2, 7.2, 8.2, 9.1, 9.2: a second trim correction). Those failing ids were fed back to Wonder, and attempt 3 passed 22 of 22. The three calls cost about $0.48 at list price.

The verbatim procedure scoring 14 of 22 is the point. Section 3.1 omits the second trim correction, and without it the high-trim rows miss by up to 0.38 %. The mark formulas divide by 140 although Lpp is 150, because the marks sit 140 m apart. The MTcm column is per degree by its heading although the legend says per cm. Following the text exactly is not enough (our verbatim implementation scores 14 of 22); graded against the printed numbers, Wonder found the missing convention on its third attempt.

On condition 4.1 the finished survey gives 17825.8 t against the printed 17827.7 t, a difference of -0.0106 %. That row is one of the 22 used to accept the program, so it is an in-sample check, not a held-out one.

The rest of the pipeline, briefly

SAM 3.1 tracks the painted numerals ("white number") and the sea ("water") on a 2x crop of the mark column; the crop and scale are needed because 18 px numerals on a full frame returned nothing. On a real third-party clip it found the marks in 60 of 60 frames, giving a draft of 12.761 m with a repeatability uncertainty of 0.086 m. Muse Spark 1.3 reads which box is which label, and five code checks (monotone, pitch, fit residual, two-frame agreement, a wide-glyph anchor) must pass before any label is used.

Where it refuses

Both real-ship clips certify as REFUSE OUT_OF_TABLE (a third clip, eeLL, was refused earlier by the label checks). The only booklet I have covers drafts of 0.5-9.3 m, and those ships sit at 12.8 m and 20.8 m. The program raises rather than extrapolate, and the certificate says so. An edited measurement is refused as unsigned. I think a tool that refuses to guess is the better default for a document that decides what a buyer pays.

Honest limits

The weight check is on a rendered synthetic barge. It validates the arithmetic and the error model, not the models, and SAM does not detect rendered water.
The real clips are third-party test footage with no ground truth, so they show repeatability and refusal, not accuracy.
The test booklet is not a bulk carrier.
Uncertainty is wave-averaging repeatability only. One clip reads one mark; the other positions are entered by hand.
It is a prototype, not a surveyor's document.

Every figure above is in evidence/ or docs/DX-REPORT.md in the repo, and 124 tests pass. If you want to see it, the self-test re-runs live on the site with no login.

Airlock: a veto window for your POT, built on Portaldot's Proxy pallet

Edy Cu — Sat, 31 Oct 2026 13:53:05 +0000

A leaked hot key should not empty a wallet in one block. A multisig fixes that, but it needs a second signer for every payment, which is heavy for one person.

The Portaldot runtime already has a better primitive. The Proxy pallet can make a delegate announce a call, wait a set number of blocks, and only then execute it. Another delegate can reject the announcement in between. In my search (not a market survey) I did not find a product built around it, so I built one for the Portaldot Hacker House 2026.

How it works

airlock create makes a keyless vault (proxy.create_pure) controlled by two keys:

Hot key, your daily key, registered with a delay (10 blocks = 60 s in the demo). It cannot move funds directly: the chain answers Proxy.Unannounced. It can only announce a call hash and wait.
Cold key, instant. It can veto an announcement (reject_announcement, dispatched as the vault) or retire the hot key (airlock panic).

A watcher reads every Proxy.Announced event for the vault and matches the hash against the owner's intent registry. A spend you registered is YOURS. Anything else is NOT YOURS, printed with the amount at risk, the veto deadline and a paste-ready airlock veto … line.

Six Proxy-pallet calls are the whole product: create_pure, add_proxy, announce, proxy_announced, reject_announcement and remove_proxy. There is no contract and no runtime change; the security is Portaldot's consensus, not my server.

What happened on the V3 testnet

On 2026-10-24, the run in the demo video (evidence/final-video-run-v3-2026-10-24.md):

A thief holding the hot key announced a sweep of the whole vault (166811-1).
The watcher printed NOT YOURS: 11.4200 tPOT at risk, "Veto must land by #166820".
The owner pasted the veto line. It landed in block #166816, four blocks early (166816-1).
After the delay the thief executed (166825-1) and then called the proxy directly (166831-1). Both failed Proxy.Unannounced.
airlock status before and after: the same 11.4200 tPOT.

Earlier, on 2026-10-19, a 12.92 tPOT sweep was vetoed the same way, and scripts/verify_onchain.py re-fetched all 44 V3 proof rows by id: 44/44 matched.

On two local interim chains (not V3), a benchmark ran 20 thief drains per chain: 20/20 alerted and vetoed, 0 planck moved. A control vault with no delay lost 100 UNIT in one extrinsic.

Things I learned

Inclusion is not finality. V3 has two validators and can fork, so off the interim chains every send waits for finality before Airlock reports it.
Pin the chain. Chain profiles are pinned by genesis and runtime code hash; an unknown chain fails loudly instead of signing.
An announcement exposes only a hash. That is why the intent registry exists: anything not registered is treated as NOT YOURS.

Honest limits

If the owner ignores the alert for the whole delay, the spend executes: the delay must be longer than your response time. The benchmark has not run on V3. There is no hosted UI; the CLI and watcher are the owner interface. Testnet only.

Ballast: freezing a test dollar on Portaldot when its reserve runs short

Edy Cu — Sat, 31 Oct 2026 13:52:56 +0000

A custodial wrapped token fails silently: reserves leave, the token keeps moving, and holders learn last.

Ballast is a safety layer for the first dollar on Portaldot. It is built around a clearly labelled test asset, pUSDC-test, whose roles are enforced by the Portaldot V3 runtime itself (the native Assets pallet plus Multisig), with the reserve held in a ReserveVault contract on Ethereum Sepolia.

One flow, four guarantees

Mint needs a 2-of-2 multisig whose mandatory co-signer, the reserve bot, signs only if finalized reserves cover supply plus the amount.
Reserves are attested on chain: BALLAST/1 remarks, mirrored into a ReserveOracle contract on Revive. ballast verify re-checks both chains and rejects a forged remark.
A watcher set (a 1-of-2 multisig) can only freeze.
Only the 2-of-3 admin multisig can thaw.

Because these are runtime roles, not app logic, a watcher that tries to thaw is refused by the chain itself.

What happened on the V3 testnet

Role drill, 2026-10-24. The custodian drained 31.20 of 104.00 from the vault (local anvil reserve). Watcher W2 froze asset 4401 in extrinsic 170112-1, 12.22 s after the drain. The next transfer failed Assets.AssetNotLive (170114-1), a watcher's attempt to thaw failed Assets.NoPermission (170115-1), and the bot co-signed the thaw only after finality passed the drain (170133-1).

Real Sepolia drill, 2026-10-30. ReserveVault deployed on Ethereum Sepolia (0x7ceB7c3EBDBCC75e585599e5dd944286F009357b, 100.00 Circle test USDC). The drill passed 8/8 steps and 18/18 checks: Sepolia release → freeze 258434-1 on V3 10.26 s later → transfer refused → refill → the bot refused to thaw until both providers' finalized head passed the drain (1,026 s of real waiting) → co-signed thaw 258627-1.

Benchmarks, 35 freeze drills (docs/BENCHMARKS.md): drain → freeze included at p50 / p95 = 12.31 / 16.71 s with the local anvil reserve (n = 26) and 10.61 / 11.25 s on real Sepolia (n = 6). The fee is about 0.03 tPOT per freeze.

All 261/261 V3 extrinsics from 23 runs were re-queried and final at head #261558; failed and errored runs stay listed in docs/PROOF.md.

Things I learned

Wait for finality on both chains. The thaw path deliberately waits until both providers' finalized head is past the drain; on Sepolia that was 1,026 s of real waiting.
A watcher on GitHub Actions is not real time. Run 41150496088 froze the asset with the primary watcher off, but the */5 cron is best-effort, so it is a backup, not the main line.

Honest limits

pUSDC-test is a labelled test asset, not a stablecoin. The reserve gates are bot code; the runtime enforces the roles and multisig thresholds, but this is not a trustless bridge. One person holds every key in this build.

Forklift: rehearse a Portaldot transaction on a fork, then send the same bytes

Edy Cu — Sat, 31 Oct 2026 13:52:42 +0000

Your transaction runs twice. The first time is a rehearsal.

Forklift pins a Portaldot block, lifts the chain's real state at that block, forks it on your machine and checks the fork against the live chain key by key. Then forklift rehearse signs a transaction once, applies those exact bytes on the fork as the prediction, and with --send sends the same bytes to the V3 testnet and lists every field that differs.

What is measured on the V3 testnet

Lift at #118,061: 5,508 keys. verify --sample 200 exits 0: 200/200 draws identical, key set 5,508 = 5,508.
Rehearse: three real V3 transactions, each predicted on a fork first, then sent: 118555-1 System.remark, 118621-1 Balances.transfer_keep_alive, 118669-1 Utility.batch. Each had the same tx hash, success and event sequence as predicted, and the same recipient delta where there is one.
What differed: the fee-bearing event amounts, the fee (3,660 to 8,269 planck), the signer delta and the inclusion height. Forklift lists every one and exits 7, never a quiet fix.
Replay re-runs a V3 extrinsic on a fork of its parent block: 118555-1 10/10, 118621-1 14/14, 118669-1 16/16 fields equal.
Fork Receipt v2, a Revive contract on V3 at 0x52f0edd92af9ff410ca63ccc83735552e1b2abc7 (84 bytes): the emitted event and the stored receipt() equal the #118,061 manifest.

Mainnet, too

Three mainnet extrinsics replayed field-equal on a fork of their parent block (24/24, 25/25, 24/24). runtime-diff and migrate-report compare mainnet spec 1002 with V3: of a 16,324-key lift, 10,499 keys carry over, 5,443 re-encode and 382 have no home on V3.

Things I learned

A fee difference is not a bug, but it must be said. Each transaction landed a few blocks after its prediction, so the fee moved. Listing it, with an exit code, is more useful than hiding it.
Sampling is honest only if you say it is a sample. verify checks 200 random keys, not every key, and Forklift says so.

Honest limits

A V3 fork is Chopsticks, not a V3 node (no public V3 node binary exists). Forklift reads mainnet and V3; the only writes to a real chain are rehearse --send and receipt --target v3, and only to V3. The PyPI package is not published yet.

Asked for real places, an LLM got 7 of 17 wrong. My agent isn't allowed to name one.

Edy Cu — Sat, 31 Oct 2026 13:52:14 +0000

A therapist treating depression often knows the next step: schedule a few things the patient enjoys, then have them rate how it went. The catch is that a depressed patient often can't name one thing they would enjoy this week. So I built Rekindle, a planning agent for clinicians that starts from what the patient used to love (an artist, a show, a food) and turns it into a week of real, open, nearby activities, built on Qloo's taste API, for the Qloo Agentic Hackathon on Devpost.

The first design question was the obvious one: why not just ask an LLM for the week? I measured it. Then I made one rule that shaped the rest of the code: the model chooses where to look; Qloo and deterministic code decide what is true. The model never names a venue.

Live app (no login, fictional cases only): https://rekindle.edycu.dev · code (MIT): https://github.com/edycutjong/rekindle

The number, measured on October 7

I gave the same model (qwen3.8-flash) the same 20 fictional patient profiles in two arms. Arm A: asked for named places for the week. Arm B: Rekindle. A random 20 outing venues per arm were then checked one by one against public listings (venue sites, city listings, review and delivery listings) for three things: does it exist at that address, is it open at the planned hour, and, for a patient in recovery, does it serve alcohol.

Measured on October 7: the LLM alone got 7 of 17 places wrong (41.2%): 4 not found, 2 closed at the planned hour, 1 serving alcohol to a patient in recovery. Rekindle got 0 of 14. The other rows were inconclusive (3 of the LLM's 20, 6 of Rekindle's 20) and are left out of the denominator rather than guessed.

Before you quote that, here is what it is not:

It was not blind. The hand check of that run's venues (finished the next day) was done by my build agent, Claude, an AI. It ran the bench, so it could have inferred the arm from the address style. No external human auditor has returned a result yet.
It is small. 17 and 14 checked venues.
It predates later work. The October 7 run came before 30 later changes to the plan path, all listed in the repo's DEMO.md. A re-run on the final deploy is planned for late October.

There is also an automated checker over all 20 profiles. It flags 58 of the LLM's 79 venues, but I don't lead with it: it grades with Qloo, which flatters Rekindle by construction, and it over-flags. In the audit sample, 4 of the 10 venues it couldn't match were real and open (it matches by street address and misses large venues such as parks). So the smaller, hand-checked number goes first.

The rule, in code

The tools the model can call carry no constraints at all. Here is the outing tool's input schema from lib/agent.ts:

findOutings: tool({
  description: "Fill a solo slot with a verified place: open at the hour and checked by the server against the case row (the model cannot see or change those checks).",
  inputSchema: z.object({ day: dayEnum, hour: z.number().int().min(8).max(21).optional(), narrowMeters: z.number().int().min(300).max(5000).optional() }),
  // ...
}),

The model can pick a day, an hour and a tighter radius. Distance limit, budget, "in recovery", "quiet" and "wheelchair entrance" are read from the stored case on every request; narrowMeters can only tighten. Qloo returns candidates, and a pure TypeScript verifier with no I/O (lib/verify.ts) decides each one: open at the slot, near, within budget, an activity rather than a shop, alcohol-free in recovery, quiet or accessible when asked, and not rated low before. Refused candidates stay on the clinician's sheet, struck through, with the rule that refused them.

The model's only free text is one coaching line per card, and that goes through a boundary too:

for (const { entity_id, line } of submitted) {
  const s = byId.get(entity_id);
  if (!s) {
    dropped.push({ rule: "R-ID", entity_id, detail: "coaching line references an ID no tool returned this run" });
    continue;
  }
  // ...
  const fault = lineFault(s.card!, text, names);
  if (fault) {
    dropped.push({ ...fault, entity_id });
    continue;
  }

A line keyed to an ID no tool returned is dropped and logged. So is a line over 25 words, a line that names another place from the run, a line that states a fact the card owns (a distance or a price), and a line that mentions drinking, on every case, because the model never sees the recovery flag.

The wall: "exclude alcohol" is not one filter

The demo moment is a toggle. The clinician clicks In recovery, and places that carry an alcohol tag or keyword are struck in place and their slots refilled live. In a live run on October 8 that was "3 outings struck in place and 3 slots refilled live · 2.2 s". Getting there took three wrong turns.

Wrong turn 1: trusting the exclusion filter. Qloo's insights endpoint takes filter.exclude.tags. I sent Maya's Thursday place query (Maya is a fictional case, Williamsburg, Brooklyn) three times in a live probe on October 7 and counted what came back:

`filter.exclude.tags`	Places returned	Still alcohol-tagged
none	25	19
4 bar tags	25	17
14 alcohol tags	25	2 (plus 2 ambiguous)

Excluding the four obvious bar tags removed 2 of 19. The alcohol vocabulary is spread over at least six tag namespaces (category:place, amenity:qloo, beverage_offering:qloo and others), so excluding a concept means listing every tag that expresses it. Even with 14 tags excluded, a coffee shop tagged beverage_offering:qloo:specialty_alcoholic came back.

Wrong turn 2: a substring screen. The fix seemed to be "refuse any tag containing pub, bar, wine…". A probe showed it would refuse espresso_bar and independent_publishing. The screen now matches exact deny-listed tag IDs first, then whole tokens of each tag's last segment, with an allow list:

const tokens = seg.split("_");
const isBar = seg === "bar" || BAR_SERVICE.has(seg) || (seg.endsWith("_bar") && !BAR_ALLOW.has(seg));
// `bar_<x>` segments describe furniture or ordering (bar_stools, bar_area), and `happy_hour` alone is a price deal:
// a signal for the clinician, not proof of alcohol
const furniture = (seg.startsWith("bar_") && !BAR_SERVICE.has(seg)) || seg === "happy_hour";
const tokenHit = tokens.some((tok) => ALC_TOKENS.has(tok)) || isBar || furniture;

The furniture case is why there is a third verdict. "Bar stool seating" doesn't prove alcohol, so it goes to the clinician in a dashed REVIEW box instead of being silently passed or refused.

Wrong turn 3: a beer hall got through. The bench placed "TeKu Tavern + Café" for a profile not in recovery, because its cafe category passed the activity check. Drinking-establishment categories are now refused for every case.

Does the screen earn its place? The October 7 bench ran an ablation on the 10 in-recovery profiles: with the screen on, 0 of 30 outing cards carried an alcohol tag or keyword. Screen off with the 14-tag exclusion kept: 3 of 28. Screen off with only the 4 bar tags excluded: 21 of 28. It counts tags and keywords, not menus, which is its limit (below).

Opening hours are day-level

filter.hours=thursday keeps places open on Thursday, not at 18:00. In the same October 7 probe, a Thursday query returned 25 places, 12 of them closed at 18:00 by their own listed hours, and some places have no hours at all. So the verifier checks the slot itself and returns OPEN, CLOSED or UNKNOWN. UNKNOWN is refused, never assumed open. A card closed at 18:00 but open earlier that day moves to an open hour and says so on the card ("moved from 18:00 (closed then)").

Week two learns, and says how sure it is

The patient rates pleasure and mastery 0–10. A rating of 7 or more becomes a Qloo signal for week 2, 3 or less an exclusion, and the top-rated activity comes back in its slot after a live re-check. Qloo's explainability weights say which input led each new card; Rekindle draws an "ember thread" from a rated activity only when it leads the patient's best original love by at least 0.02, and labels narrower leads as ties. It is Qloo's attribution, not causation, and the app says so on the screen. On live re-plans most leads are still ties.

In the bench (re-plan check, same October 7 run), 16 of 16 eligible profiles passed: week 2 had at least one new card whose top input was a highly rated activity, and none of the low-rated ones came back. Four profiles were excluded because week 1 had too few verified outings to rate.

What it costs

Grounding is slower. In the October 7 bench, a Rekindle plan took p50 17.43 s and p95 20.61 s on the hosted app, with about 9.4 Qloo calls per plan. The LLM alone answered in p50 7.2 s. It meets the 30 s budget I set but misses the 15 s I wanted; the coaching step dominates.

Honest limits

It is clinician support, not a clinical tool: no diagnosis, no efficacy claims, no patient logins. Every case in the app, Maya included, is fictional, and no clinician has endorsed it.
The alcohol screen is a deny list. A venue that serves alcohol and carries none of the tags or keywords would pass.
Opening hours come from Qloo; if they are wrong upstream, the check passes a closed door.
In thin areas, outing slots stay empty with a reason. It doesn't guess.
The headline audit was done by an AI build agent, not blind, on 17 and 14 venues.

Try the click path (plan Maya's week, toggle In recovery, approve, rate three cards, re-plan): https://rekindle.edycu.dev · every live Qloo request behind the latest plans: https://rekindle.edycu.dev/integrations/qloo · code and bench files: https://github.com/edycutjong/rekindle · Devpost entry: https://devpost.com/software/rekindle-xw53nk

Plumbline: Portaldot's docs list Balances.transfer. On V3 it doesn't exist.

Edy Cu — Sat, 31 Oct 2026 13:51:54 +0000

Portaldot's mainnet docs list Balances.transfer. On the V3 testnet that call does not exist.

V3 is a new chain: the testnet reports portaldot-v3 spec 3002 with 69 pallets and 480 calls, where mainnet spec 1002 has 31 pallets. The written sources disagree with it, too: the V3 guide names the token tPOTv3, while the chain reports tPOT. From the docs alone, nobody can say which documented call runs on the chain.

Plumbline answers with transactions, not opinions: documented call → verdict → proof.

Four commands

plumb reads runtime metadata through Portaldot's Python SDK (substrate-interface) and parses the documented surfaces: the 22 mainnet extrinsic doc pages (196 calls), the V3 guide's 46 sample-code compose_call sites and its FAQ module table (12 modules). Every entry gets a verdict on V3: PROVEN, UNPROVEN, ABSENT, ARG_DRIFT, DRIFTED or UNDOCUMENTED. That is 549 verdict rows, each stamped with the spec and metadata hash, and byte-identical on re-run.
canary proves calls. A call is PROVEN only by a real transaction read back from its block. Three were signed on V3 (System.remark_with_event, Balances.transfer_keep_alive, Utility.batch_all, blocks 106424–106426), and plumbline readback re-reads them from a fresh connection: 3/3 match.
diff lists the pallet, call, argument and constant changes from mainnet 1002 to V3: 516 rows, with 40 pallets added and 2 removed (Proxy.anonymous → create_pure among the renames).
check flags call sites in your own dApp that will not run: the example dApp has 0 blocking findings on V3 and 5 on mainnet spec 1002, with exit code 1 on blocking so it can gate CI.

Findings on V3

The 79 calls whose docs and runtime disagree on mainnet 1002 become 2 on V3: Balances.transfer is absent, and ElectionProviderMultiPhase.governance_fallback takes different arguments. Five of the 12 modules the V3 guide's FAQ lists are not on the testnet.

Deterministic code decides every verdict, a metadata set-difference plus a transaction receipt. There is no model in the loop.

Things I learned

The metadata hash is not a stable identity. On V3 it varied by one byte between blocks, so Plumbline records the runtime :code hash as the identity instead.
"Exists in metadata" is not "works". Only a receipt read back from a block upgrades a call to PROVEN; everything else stays UNPROVEN.

Honest limits

No Plumbline contract is deployed: the on-chain evidence is the 3 canary transactions, and every other documented call that exists on V3 stays UNPROVEN until a transaction is sent for it. Runtime APIs (ReviveApi) are not checked yet.

An API that misses its deadline should pay you back: a bonded pay-per-call escrow on Arc

Edy Cu — Sat, 31 Oct 2026 04:48:46 +0000

Your agent paid an API 0.01 USDC and the API never answered. Unless the provider decides to refund you, that money is gone, and your only recourse is a refund policy, a support ticket or a chargeback. The provider had nothing at stake.

I wanted the opposite default: if the API misses its deadline, it pays you back, plus a penalty, without you having to ask. ReplyBond is a small Solidity escrow on Arc mainnet that does exactly that, and this post walks through the five design choices that make it work, what the AI coding agent (Arc Studio) built, what I did by hand, and where it stops being honest to call it "guaranteed".

Live: https://replybond.edycu.dev (Arc mainnet, chain 5042, native USDC)
Repo: https://github.com/edycutjong/replybond (MIT)
Contract: 0x2a0f4aeF8E5379d8E4606F40846cf97716fe749f, Sourcify exact match

Job 24 on mainnet: the provider stays silent, the 45 s clock (sped up x8) hits zero, timeout pays the buyer 0.010 back + 0.005 from the bond, and the explorer shows the same transaction moving 0.015 USDC.

The shape of a job

A provider posts an offer with a bond. A buyer accepts it by paying the price, and the clock starts on acceptance. Every job ends in exactly one of four terminal states:

Ending	Who triggers it	Who gets price + bond
`Paid`	buyer calls `acknowledge` after an answer	provider
`Claimed`	anyone calls `claim` after the answer + a grace window	provider
`TimedOut`	anyone calls `timeout` after the deadline, no answer	buyer
`Withdrawn`	provider withdraws an offer nobody took	provider (bond only)

There is no owner and no upgrade path. On the demo, the price is 0.010 USDC, the bond 0.005 USDC, the response window 45 s and the grace window 120 s.

1. The bond goes in before the buyer pays

The order matters. The provider locks the penalty first, as msg.value on postOffer; only then can a buyer accept by paying exactly price:

function postOffer(
    bytes32 requestHash,
    address buyer,
    uint256 price,
    uint64 responseWindow,
    uint64 graceWindow
) external payable nonReentrant returns (uint256 id) {
    if (msg.value == 0) revert InvalidBond();
    if (price == 0) revert InvalidPrice();
    if (responseWindow == 0) revert InvalidResponseWindow();
    ...

Because USDC is Arc's native balance, the bond, the price, the penalty and the gas are all the same asset. There are no ERC-20 approvals in the flow at all: one payable call locks the bond, another locks the price.

2. "Answering" means writing the output on-chain

A deadline is meaningless if "I answered" is just the provider's word. So an answer only counts if the provider calls respond with the output itself, between 1 and 1,024 bytes, at or before the deadline:

function respond(uint256 id, bytes calldata output) external nonReentrant {
    Job storage job = _requireJob(id);
    if (msg.sender != job.provider) revert NotProvider(id);
    _requireStatus(id, job, Status.Accepted);
    if (block.timestamp > uint256(job.deadline)) revert ResponseDeadlinePassed(id);
    if (output.length == 0 || output.length > MAX_OUTPUT) revert InvalidOutputLength(output.length);

    job.responseHash = keccak256(output);
    job.respondedAt = uint64(block.timestamp);
    job.status = Status.Responded;
    emit ResponseCommitted(id, job.responseHash, output, job.respondedAt);
}

The contract stores only the keccak256 and emits the bytes in the ResponseCommitted event, so delivery is provable from the chain alone, and MAX_OUTPUT bounds the gas. The boundary is deliberate: respond is valid up to and including the deadline, timeout only strictly after it, so there is no second where both are possible.

3. Nobody has to ask for the refund

timeout is permissionless. Anyone can call it once the deadline passes, and the money always goes to the buyer, never to the caller:

function timeout(uint256 id) external nonReentrant {
    Job storage job = _requireJob(id);
    _requireStatus(id, job, Status.Accepted);
    if (block.timestamp <= uint256(job.deadline)) revert DeadlineNotPassed(id);

    uint256 amount = job.price + job.bond;
    job.status = Status.TimedOut;
    emit JobTimedOut(id, job.buyer, msg.sender, amount);
    _pay(id, job.buyer, amount);
}

The mirror case needed the same treatment. If the provider did answer and the buyer simply goes quiet, the provider must not be stuck: after respondedAt + graceWindow, anyone can call claim, and the provider gets price + bond. A silent buyer cannot take the answer and keep the money.

4. A payout must never block another job

Pushing native value to an arbitrary address is the classic way to brick an escrow: one payee that reverts (or burns gas, or returns a huge blob) and settlement is stuck. ReplyBond sends with a 100,000-gas cap and a zero-length return area, so it never copies return data:

function _pay(uint256 id, address payee, uint256 amount) internal {
    totalLocked -= amount;
    if (!_sendNative(payee, amount)) {
        owed[payee] += amount;
        totalOwed += amount;
        emit PayoutOwed(id, payee, amount);
    }
}

/// @dev Bounded gas and zero-length return area: never copies returndata.
function _sendNative(address payee, uint256 amount) private returns (bool success) {
    assembly ("memory-safe") {
        success := call(PAYOUT_GAS, payee, amount, 0, 0, 0, 0)
    }
}

If the send fails, the amount is credited to owed[payee] and the payee pulls it later with withdrawOwed(). State changes happen before any payout, and every entry point sits behind OpenZeppelin's ReentrancyGuard. The contract's doc comment writes down the invariants the Foundry suite checks, including conservation (balance >= totalLocked + totalOwed) and "each job reaches exactly one terminal state, once".

5. Read the payout from the chain's own Transfer log

This is the part only Arc gives you, and the one I liked most. On Arc, a native USDC movement out of a contract shows up in the receipt as an ERC-20-style Transfer log emitted by a system address (EIP-7708), right next to the contract's own events. From a real testnet timeout receipt:

log#25 emitter=0x1234fb0f...2458 [ReplyBond] JobTimedOut(id=1, amount=15000000000000000)
log#26 emitter=0xfffffffffffffffffffffffffffffffffffffffe [ARC SYSTEM EMITTER]
       Transfer(from=<contract>, to=<buyer>, value=15000000000000000)

So the app does not trust its own contract's event to say "paid". classifyReceipt only returns PAID when the receipt carries the settle event and a system-emitter Transfer from the contract to that payee for that exact amount:

export const SYSTEM_EMITTER = '0xffffFFFfFFffffffffffffffFfFFFfffFFFfFFfE'
const TRANSFER_TOPIC = '0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef'

const transfer = receipt.logs.find(
  (l) =>
    l.address.toLowerCase() === SYSTEM_EMITTER.toLowerCase() &&
    l.topics.length === 3 &&
    l.topics[0].toLowerCase() === TRANSFER_TOPIC &&
    topicAddress(l.topics[1]) === contract.toLowerCase() &&
    topicAddress(l.topics[2]) === settle.payee.toLowerCase() &&
    BigInt(l.data as Hex) === settle.amount,
)
if (!transfer) return none('no USDC Transfer log to the payee', base)

The UI stamps "INDEMNITY PAID" only on a PAID result. One bug here is worth naming: an early version stored a rate-limited RPC read as a permanent failure. Unreadable receipts now retry with backoff instead of being recorded as unreadable for good.

What the AI agent built, and what I did by hand

The contract, its Foundry tests, the API routes and the React app came from Arc Studio turns, driven with the Studio CLI (arc-studio run / pull) and committed in order; each commit subject names its turn. Studio wrote the contract in turn 1, deployed it to Arc testnet and ran the Foundry suite there. Later turns built the app, the demo-provider and demo-buyer routes, the receipt classifier, and fixes such as Vercel's file tracer folding BigInt math on a null binding and breaking the build.

What Studio did not do: mainnet. Studio deploys to testnet only, so I deployed the unchanged Studio source with forge create from my own keystore. contracts/ReplyBond.sol has not changed since Studio turn 1, and Sourcify reports an exact match, which is the check that the bytecode on mainnet really is that source.

The numbers: forge test on the pinned forge 1.7.1 gives 66 passed, 0 failed (63 unit and fuzz tests plus 3 invariants at 256 runs); bun test tests/ gives 116 passed, 0 failed across 16 files. One run through the live app on mainnet covered all three settlement paths, each moving 0.015 USDC: acknowledge, timeout and claim.

Where it stops being a guarantee

Delivery, not correctness. The contract proves an output was delivered on-chain on time. It does not prove the output is right. Outputs are public and capped at 1,024 bytes.
The demo provider is an echo service. It answers with your input in capitals, so the demo proves timing and payment, not useful answers.
Permissionless is not automatic. Someone has to send timeout or claim. The server does it for demo jobs.
No always-on worker. The demo provider answers only while some request runs the sweep (a page load, an API call, or the daily cron). A buyer who accepts a job and never calls the API can time it out and collect the bond. That is the timeout path working as designed against a provider that is not always on, and the demo bounds it with 20 new offers per hour, 80 per day and a 0.1 USDC wallet floor.
Unaudited, and the demo fixes price, bond and windows rather than letting the buyer choose them per call.

Next on the list: an always-on provider worker, per-call deadlines and bonds, and a way to check answers so that correctness, not only delivery, can back a payout.

Try it

Press "Settle a missed deadline now" on https://replybond.edycu.dev: no wallet needed, it sends a real timeout on Arc mainnet and stamps only once the receipt shows the 0.015 USDC Transfer. Or open https://replybond.edycu.dev/app, connect a wallet on Arc mainnet and "Pay & call" for 0.010 USDC.

Code: https://github.com/edycutjong/replybond · BUIDL: https://dorahacks.io/build/50635

My AI agent's trade broke the limit. The refusal told it what would fit.

Edy Cu — Sat, 31 Oct 2026 02:20:25 +0000

I gave an AI agent a trading key, a $25 limit, and a Bitcoin short that was too big. The interesting part is not that my guardrail said no. It is what the agent did next.

Codex CLI asked to short 0.0005 BTC on a perps testnet. That was about $40, over my $25 cap. The refusal it got back did not just say "denied". It said:

the position this order leaves would be $40.11 notional, above the $25 cap per market
next safe action: reduce size to at most 0.00031 BTC

Six seconds later Codex planned exactly 0.00031 BTC, the plan passed, and it filled on chain: 0x385c1486…8080, block 31576050. Nobody told it that number. Its prompt said "stay under the policy"; the refusal supplied the rest.

That is Pilot, an MCP server I built for the dreamDEX perps bounty on Somnia testnet. Repo: github.com/edycutjong/dreamdex-pilot · 72 s demo: youtu.be/WpH8jww1u-g

The problem: a key is all or nothing

If you hand an agent an exchange SDK and a private key, it can send any order the exchange accepts. The usual fix is a wrapper that checks each order and throws when one breaks a rule. That stops the bad order, but it leaves the agent stuck: it knows it failed, not what would have worked. So it guesses, retries, or gives up and asks you.

An agent can only act on what a tool returns. So I treated the refusal as the product, and gave it three jobs:

say which rule broke, in numbers,
name a next safe action the agent can call as-is,
say plainly when no order fits, so the agent stops instead of looping.

The rule is a pure function

Every limit check in Pilot goes through one pure function: facts in, violations out. Each violation carries a rule, a detail and a next. From src/policy.mjs:

// Pure: facts in, violations out. Each violation names the rule and the next safe action.
export const evaluate = (policy, facts) => {
  const v = [];
  if (!policy.allowedMarkets.includes(facts.market))
    v.push({ rule: "allowedMarkets", detail: `${facts.market} is not on the allowed list (${policy.allowedMarkets.join(", ")})`, next: `pick one of ${policy.allowedMarkets.join(", ")}` });
  if (facts.notionalUsd > policy.maxNotionalUsd)
    v.push({ rule: "maxNotionalUsd", detail: `the position this order leaves would be $${facts.notionalUsd.toFixed(2)} notional, above the $${policy.maxNotionalUsd} cap per market`, next: facts.capNext ?? `reduce size to at most ${facts.maxSizeUnderCap ?? "the cap"}` });
  if (facts.liquidationDistancePct != null && facts.liquidationDistancePct < policy.minLiquidationDistancePct)
    v.push({ rule: "minLiquidationDistancePct", detail: `liquidation would sit ${facts.liquidationDistancePct.toFixed(2)}% from mark, closer than the ${policy.minLiquidationDistancePct}% minimum`, next: "use a smaller size (less leverage)" });
  if (facts.ordersToday >= policy.dailyOrderCap)
    v.push({ rule: "dailyOrderCap", detail: `${facts.ordersToday} orders already sent today (UTC), cap ${policy.dailyOrderCap}`, next: "wait for the next UTC day or raise the cap in policy.json yourself" });
  return v;
};

Because it is pure, the same function runs twice per order: once when the agent plans, and again right before the send, on a fresh read of the policy file. Limits you tighten after a plan still apply.

"At most 0.00031" has to be a real number

A next step is only useful if the agent can send it unchanged. Two details made that true.

The cap is on the position the order leaves, not the order. Otherwise five $10 orders walk straight past a $25 cap. So the room under the cap is computed from the current position, and the suggested size is that room, floored to the market's lot size.

The cap is priced at the worst fill. A buy pays at most its limit price. A sell fills from the top bid down, so valuing a short at its limit would let it pass the cap and then fill above it. From src/trader.mjs:

// Notional (the cap, notional_usd sizing) is valued at the highest price the order can fill at:
// a buy pays at most its limit, but a sell fills at the bids from the top bid down to its limit,
// so at its limit a short would pass the cap and then fill above it.
const capPx = isBid || touch.bid < price ? price : touch.bid;

The re-planned short came back at $24.86 notional, under the cap, with liquidation 189.78% from mark.

When nothing fits, say so

The harder case is when the room left is real but useless. In another run, 0.2 SOL was already open and Claude Code was told to plan a 0.1 SOL add, about $10 and under $25 on its own. Pilot refused it:

the position this order leaves would be $30.80 notional, above the $25 cap per market
next safe action: no SOL order fits under the cap: the room left is 0.04 SOL, below the SOL minimum 0.1; close_position or a reducing order frees room

"Reduce size to at most 0.04 SOL" would have been a trap: the exchange minimum is 0.1, so the agent would plan it, get refused again, and loop. The code checks for that and switches the message:

// Room under the cap that is below the market minimum is no next step at all: say no order fits.
capNext: room < minQ
  ? `no ${mk.baseSymbol} order fits under the cap: the room left is ${u.qty(room > 0n ? room : 0n)} ${mk.baseSymbol}, below the ${mk.baseSymbol} minimum ${u.qty(minQ)}; ${leaning > 0n ? `close_position or a reducing order frees room` : `pick another market or raise maxNotionalUsd in policy.json yourself`}`
  : undefined,

Note the last branch. When the only fix is a bigger limit, the message says you raise it in policy.json. No Pilot tool can write that file, so the agent cannot talk itself into more room. (In that run the prompt also scripted the close, so I don't claim the agent chose it.)

Plan, then a one-shot ticket

The refuse → re-plan loop only works if what gets sent is what got checked. So plan_order never sends anything. An ok plan returns a plan_id that lives 60 seconds and works once. place_order takes only that id, and claims it before any await, so two parallel calls cannot both use it:

if (!p) return refuse(deps, "unknownPlan", /* ... */ "call plan_order first", { plan_id });
if (p.used) return refuse(deps, "planAlreadyUsed", `plan ${plan_id} was already used: ${p.outcome}`, "call plan_order for a new plan", { plan_id });
// Claimed synchronously, before any await: two parallel calls with one plan_id cannot both pass.
p.used = true;

Even these refusals carry a next. A reused id is told what became of the first use ("it was sent as tx 0x…"), which stops an agent from resending an order that already landed. At send time Pilot re-reads the live book, the position, and the SDK's liquidation and margin previews, and the limit price can only tighten.

The numbers

The recorded runs, every transaction re-read from the RPC and listed in DEMO.md:

9 orders opened and 9 closed through the MCP tools, plus 2 brackets and 2 cancels
15 refusals with nothing sent, across 7 distinct rules
215 tests, plus one opt-in live integration check
two different agents, Claude Code and Codex CLI, on the same server code

Honest limits

Testnet only. Nothing has run on mainnet. Use a burner key.
Pilot guards its own tools, not the whole agent. Claude Code and Codex both have shell and file tools. An agent that keeps those could edit the policy file or read the key from its environment. For a trading session, turn those tools off.
Plans live in memory. Restarting the server drops them.
The next safe action reflects the book at plan time. The run above was on an older commit. Pilot now prices shorts at the top bid, so the same order would read about $40.51, and the suggested size would be slightly smaller.
A close is a plain IOC order. If something else shrinks the position mid-close, it can flip. Pilot reads the position back and reports flipped.

The takeaway

If an agent is going to work within your limits, a refusal is half of the interface. A refusal that names a size the agent can send unchanged turns a dead end into one more tool call. And a refusal that says "nothing fits, a human has to change this" stops the loop before it starts.

The code is MIT: github.com/edycutjong/dreamdex-pilot. node bin/pilot.mjs journal --card prints your own receipts if you try it.

Ghosts in my Mac: the apps are gone, but five root helpers stayed

Edy Cu — Fri, 30 Oct 2026 20:51:53 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

There are five programs on my Mac that are set up to run as root, for apps I no longer have. The oldest one's plist was last modified more than four years ago. I found them by writing a ghost hunter.

Here's how that happens. Some apps ask for your admin password once and install a small privileged helper, plus a launchd plist that tells macOS how to start it. Drag the app to the Trash, and the helper and its plist can stay. Nothing on screen tells you they're there.

hantu (Indonesian for ghost) is a read-only command-line scanner for macOS. It reads every launchd plist in the three folders where apps put them, works out which program each one would start, and asks two questions: is that program still on disk, and does any installed app still claim it?

The theme is Ghost in the Machine, and I wanted ghosts I could count. This is one read-only run on my own Mac, on October 31:

What	Count
Launch plists scanned	58
Ghosts	5
Ghosts that are launch daemons with no `UserName`, so launchd starts them as root	5 of 5
Oldest ghost	1549 days since its plist was last modified
Plists pointing at a missing program	0
Couldn't tell either way	9

I expected the opposite: a pile of dead links, plists pointing at programs that no longer exist. Harmless clutter. There were none.

Every ghost still had its program on disk, in /Library/PrivilegedHelperTools, with a plist in /Library/LaunchDaemons that tells launchd how to start it as root. Only the apps were gone. Three of the five come from vendors you'll know: a proxy helper from Charles (com.xk72.charles.ProxyHelper, 1188 days) and two Adobe helpers, one of them com.adobe.ARMDC.Communicator (695 days).

hantu is for anyone who has used a Mac for a few years and tried apps they later removed. That's most of us.

Demo

Five root helpers that no installed app declares, and Gemma explaining the two the tool may name: a 23-second clip of real runs on my Mac, with the CLI's own --redact on. The opening and closing cards are printed by the recorder; the opening card's numbers come from a live scan made a moment before. The only cut is 6.9 seconds of waiting for Gemma, labelled on screen. Links: recorder script, every line the clip shows, MP4.

The same scan as text you can copy. A wide terminal prints full paths; the clip's narrow one folds a helper named after its label to (same name):

pipx install git+https://github.com/edycutjong/hantu
hantu scan --ghosts --redact

--redact names labels only from a short list of well-known vendors, one per vendor, so three are withheld:

HALF-GHOST  1549d  [label withheld]
HALF-GHOST  1188d  com.xk72.charles.ProxyHelper  ->  /Library/PrivilegedHelperTools/com.xk72.charles.ProxyHelper
                  privileged helper still on disk, but no installed app declares it (SMPrivilegedExecutables)
HALF-GHOST  1096d  [label withheld]
HALF-GHOST   695d  com.adobe.ARMDC.Communicator  ->  /Library/PrivilegedHelperTools/com.adobe.ARMDC.Communicator
                  privileged helper still on disk, but no installed app declares it (SMPrivilegedExecutables)
HALF-GHOST   695d  [label withheld]

58 plists: 0 orphaned, 5 half-ghost, 44 alive, 9 unknown. Nothing was changed.

Then hantu explain sends each ghost's plist to Gemma 4 31B (with --redact, only the two it may name) and gets back one sentence and a risk score from 1 to 5. These are from the earlier run I saved. Gemma's wording and scores change between runs: the clip above is a later take that scored both 4/5. And "trying to run" is Gemma's phrasing, not a fact hantu checked: it never asks launchd whether these root daemons are loaded.

Charles, risk 3/5: "This belonged to Charles Proxy and is trying to run a privileged network proxy helper."
Adobe, risk 3/5: "This belonged to Adobe software and is trying to run a privileged communication service."

The run's redacted write-up is in evidence/gemma-run.md.

Code

github.com/edycutjong/hantu: MIT, standard-library Python (tested on 3.11), 86 tests.

The verdict is plain code. Here's the check for a privileged helper nobody claims, from hantu/scan.py:

elif target.startswith(HELPER_DIR) and os.path.basename(target) not in index.helpers:
    ag.associated_installed = False
    ag.verdict = HALF_GHOST
    ag.reason = "privileged helper still on disk, but no installed app declares it (SMPrivilegedExecutables)"
    return ag

index.helpers is built from every installed app's Info.plist: the helpers it declares in SMPrivilegedExecutables and the ones it ships in Contents/Library/LaunchServices. So if a helper sits in /Library/PrivilegedHelperTools, its plist names no owning app, and no installed app declares or ships it, hantu calls it a ghost.

The 79 pytest tests run against fixture plists, and the suite fails any test that tries to reach the network.

How I Built It

Code decides, the model explains. I didn't want a language model deciding whether a root daemon is abandoned. A file check and an Info.plist lookup can answer that, and they can be tested. What a model is good at is reading a plist full of MachServices, Sockets and RunAtLoad keys and saying in one sentence what the thing was for. So there are four verdicts, all set in code:

ORPHANED: the program launchd would start is missing.
HALF-GHOST: the program is there, but no installed app claims it.
ALIVE: the program is there and nothing shows its owner is gone.
UNKNOWN: a malformed plist, a relative path, a disk that may just be unmounted. Never counted as a ghost.

Gemma 4 31B, open weights. hantu explain calls google/gemma-4-31b-it through OpenRouter with a small standard-library HTTP client. The prompt says the classification is already made and not to question it. The reply has to be strict JSON: an id, one sentence, a risk from 1 to 5, a short reason. hantu checks every item (id in range, risk an integer from 1 to 5, text not empty, length capped) and drops what fails. Nothing in the reply can change a verdict.

What came back was honest and a little flat. Gemma gave one ghost 4 out of 5: the oldest, and the only one set to run at load. Its reason: "Privileged daemon that runs at load and creates a system socket." The other four got 3 out of 5 with the same reason, word for word: "Runs as a privileged daemon with root-level access." That isn't much of a ranking. But the one outlier it found is a real difference.

The free Gemma endpoints answered HTTP 429 ("temporarily rate-limited upstream") every time I tried them that night. hantu backs off, retries, and falls back from the 31B model to the 26B one, and both stayed busy. So I ran hantu explain --model google/gemma-4-31b-it, the same weights through OpenRouter's paid listing. It took about 13 seconds and cost $0.00046.

An early version of the half-ghost rule, before the first commit, flagged macFUSE. It isn't a ghost: macFUSE keeps its app inside a filesystem bundle under /Library/Filesystems. hantu looks there now. That's why the README calls HALF-GHOST a rule, not a proof, and why cleanup never touches half-ghosts.

Safety and privacy. A plain hantu scan never writes and never sends anything anywhere. Nothing changes unless you pass both --clean and --yes. Even then, hantu only moves ORPHANED plists out of your own ~/Library/LaunchAgents into a quarantine folder with a manifest, and runs launchctl bootout if the agent was loaded. Undo is mv. That path is tested on fixture plists in temp folders; I haven't run it on a real machine. My five ghosts are root daemons under /Library, so hantu won't touch them at all. Removing them is a decision for a human with sudo.

explain does send data off your Mac: each ghost's plist (capped at 1200 characters), file name, age, verdict and reason go to OpenRouter and the Gemma host. Before sending, your home folder becomes ~, environment variable values are masked, and identity keys such as UserName are dropped.

What it doesn't do. It doesn't scan Login Items, which needs privileges or a permission prompt. It can't tell whether a ghost daemon is loaded right now; that needs root too. And an app installed somewhere hantu doesn't look will make its helper look like a ghost, so read the line before you delete anything.

Why Does Open Innovation Matter?

A tool that inspects root daemons should be readable. hantu is under a thousand lines of standard-library Python, MIT-licensed, with no dependencies. You can read every line that touches your system before you run it. I didn't want to clean up after closed apps with root helpers by installing another closed app with a root helper.

Open weights turned the rate limit into a detour. When the free endpoint was busy, I changed one flag and the same Gemma answered from another listing. When I checked that night, OpenRouter listed 13 providers serving those weights. That only works because the weights are public: any host can serve them, so one busy endpoint isn't the end of the road.

Open weights are also what make the next step possible: running Gemma on the Mac itself, so the plists never leave it. hantu doesn't do that yet; today explain uses a hosted endpoint, and the README says so. But the model only ever receives text and returns JSON, and the code makes every decision, so any open model can be swapped in and the verdicts stay exactly the same. The whole chain from plist to verdict is code you can read and tests you can run.

My Agent Session

I built hantu with Claude Code as my coding agent, under a few hard rules: only ever read the real machine, never delete or unload anything on it, test the cleanup on fixtures only, and put no number in the README that a committed run didn't produce. This post was drafted the same way, and every number in it was checked against the repo before posting.

There's no DevRelay session to embed. The commit history shows the order of the work: the read-only scanner, then the Gemma step and the quarantine-only cleanup, then the CLI and report, then the README checked against a real run, and last the real Gemma output. It shows the order, not the timing: the first four commits were made together.

The Spirit of It

Halloween and Día de los Muertos are both about what stays after something is gone. On my Mac, what stayed was five root helpers, each with a plist that still tells launchd how to start it, for apps that are no longer installed.

The moment it landed was one summary line: 0 orphaned, 5 half-ghost. I had expected broken links. I got real programs, set up to run as root, with nobody left to own them.

It's Halloween. Run hantu and see who still lives in your house. A plain scan only reads.

Prize Categories

Best Use of Gemma. Gemma 4 31B is the model behind hantu explain. It reads each ghost's plist and returns validated JSON, one plain-English sentence and a coarse risk score, and hantu sorts the list by that score. On my Mac it picked out the one ghost set to run at load from four ties. The code decides what is a ghost; Gemma tells you what it was.

My Mac was 99% full, so I let Gemma judge my junk (on a short leash)

Edy Cu — Sun, 25 Oct 2026 23:49:22 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

One evening this week, df -h said my MacBook had 11Gi available out of 926Gi. 99% full. About twenty minutes earlier, a full real run of my new tool had found 118.5 GB of caches, build folders and temp files, marked 34.2 GB of it safe to delete, and deleted none of it. That last part is on purpose.

I knew roughly where the space had gone: node_modules everywhere (the scan counted 63 node_modules folders and kept 42 of them), a Gradle cache, browser caches, .next builds, and a pnpm store the size of a small country. Cleaning that by hand is an afternoon of du -sh * | sort -h and second-guessing every rm -rf. My inner sloth said no. It also wouldn't install a "cleaner" that guesses: guess wrong and you rebuild real work, which is the opposite of lazy.

So I built sweep, for developers whose laptops quietly fill up with node_modules, target/, .venv and package caches. One command finds the regenerable junk on a Mac, asks an open-weight model (Gemma 4, 31B) which of it is safe to delete, and prints a plan. It is a dry run by default. sweep --apply deletes only the SAFE items, and only after you type the size back to it, like DELETE 34.2 GB.

That real run on my Mac:

Measurement	Value
Items found	167
Found	118.5 GB
SAFE (by `du`)	45 items · 34.2 GB
ASK	20 items · 33.6 GB
KEEP	102 items · 50.7 GB
Wall time	202.6 s
Deleted	nothing (dry run)

Demo

A second real dry run on the same Mac, about 50 minutes later: df -h ~, then sweep --redact --top 5 (--redact swaps the names under your home for labels like <project-007>). Most of the 3 min 17 s scan and of the 13 s of Gemma calls are cut, and each cut is labelled. This run found 111.7 GB in 145 items, not 118.5 GB in 167: the two scans saw different sets of items; this run's numbers.

The plan groups items under SAFE, ASK and KEEP, each with its size and a one-line reason (the top 15 per group by default), and --json lists every item with who decided. Some real verdicts from that run (project names are redacted in the published evidence):

Size	Item	Verdict	Decided by	Why
10.5 GB	`~/.gradle/caches`	SAFE	Gemma	"Gradle build caches are regenerable."
2.0 GB	`~/Library/Caches/BraveSoftware`	SAFE	Gemma	"Very old browser cache."
14.9 GB	`~/Library/pnpm/store`	ASK	Gemma	"Large pnpm store; deleting may require re-downloading many dependencies."
1.4 GB	a project's `node_modules`	ASK	Gemma	"Relatively recent activity (32 days ago) and large size; user should confirm if still needed."
14.0 GB	Docker	ASK	rule	never deleted by sweep; it prints `docker system prune` for you to run
3.8 GB	a project's `node_modules`	KEEP	rule	its repo has uncommitted changes

sweep --json gives the same plan as data. Two real entries from its items list:

[
  {
    "path": "~/.gradle/caches",
    "kind": "build-cache",
    "bytes": 10546253824,
    "verdict": "safe",
    "reason": "Gradle build caches are regenerable.",
    "decided_by": "model"
  },
  {
    "path": "~/<dir>/<project-001>/node_modules",
    "kind": "node_modules",
    "bytes": 3778359296,
    "verdict": "keep",
    "reason": "its repo has uncommitted changes",
    "decided_by": "rule"
  }
]

The full report, with every number: evidence/dry-run-2026-10-25.md.

Code

edycutjong / sweep

A lazy disk-cleanup agent for macOS: an open-weight model (Gemma) judges what is safe; nothing is deleted without your OK.

sweep 🧹

A lazy disk-cleanup agent for macOS. It finds the junk, asks an open-weight model what is safe, and never deletes without your typed OK.

macOS only for now — adding Linux or Windows is a small pull request, PRs welcome. Every cache location lives in one file, src/sweep/catalogue.py; a port also touches rules.py (protected paths) and reminder.py (launchd).

📸 See it in Action

A second real dry run on the same Mac, about 50 minutes after the evidence run below: df -h ~, then sweep --redact --top 5 (--redact swaps the names under your home for labels like <project-007>). Most of the 3 min 17 s scan and of the 13 s of model calls are cut, and each cut is labelled. This run's numbers: demo-run-2026-10-25.md.

sweep is a dry run by default. This is the real result on the author's own MacBook…

View on GitHub

Repo: github.com/edycutjong/sweep (MIT, Python 3.11+, 64 tests)

You need uv, macOS, and an OpenRouter key in OPENROUTER_API_KEY.

uv tool install git+https://github.com/edycutjong/sweep

sweep            # dry run: prints the plan, deletes nothing
sweep --json     # the same plan as JSON (never deletes)
sweep --apply    # delete the SAFE items after a typed confirmation

How I Built It

The model never gets the last word on danger

A language model next to rm -rf is a scary combination, so sweep splits the job in two.

Plain code goes first. rules.py looks at each item and either settles it or sets a ceiling. Some rules are final, and the model never sees those items:

Docker images, containers and build cache: never deleted by sweep. It prints docker system prune for you to run.
A folder macOS won't let it read: ASK, never SAFE.
Anything outside the allowed locations (Documents, Desktop, ~/.ssh, ~/.config, system folders, and more): KEEP.
A project whose git repo has uncommitted changes, or a commit in the last 14 days: KEEP.
A temp file modified in the last 24 hours: KEEP.

Everything else gets a cap. The cap is safe if the item looks regenerable, and ask if nothing next to it can rebuild it (say, a node_modules with no package.json beside it). Trash, Downloads and simulator data are capped at ASK no matter what.

Then Gemma judges what's left. The final verdict is the more cautious of the rule's cap and Gemma's answer, and a missing or invalid answer counts as ASK:

CAUTION = {"safe": 0, "ask": 1, "keep": 2}

def more_cautious(a: str, b: str) -> str:
    return a if CAUTION[a] >= CAUTION[b] else b

The model can pull a SAFE down to ASK or KEEP, but it can never lift a KEEP to SAFE. A timeout, a garbage reply or a skipped item becomes ASK. So a model failure costs me a question, never a folder. A wrong SAFE inside a SAFE cap is still possible, which is why every line shows its reason, and why --apply lists every target, re-checks each item right before deleting it (project folders get their git state re-read), and logs every path it removes or fails to remove.

In the real run, a hard rule settled or capped 111 of the 167 items, and Gemma's own verdict stood for the other 56.

The contract: bare JSON, or it doesn't count

Gemma sees metadata only: an id, a trimmed path (never the absolute one), the kind, size and age, and for project folders the git state (repo or not, last-commit age, dirty). Never file contents. The system prompt ends with the exact shape it must return:

{"items":[{"id":"<input id>","verdict":"safe|ask|keep","reason":"<one short plain-English sentence>"}]}

parse_verdicts is strict on purpose. A reply wrapped in a code fence doesn't parse, so the whole batch becomes ASK. An entry with an extra key, an id I never sent, a duplicate id, or a reason over 200 characters is dropped, and a dropped entry becomes ASK:

for e in entries:
    if not isinstance(e, dict) or set(e) != {"id", "verdict", "reason"}:
        continue
    if not isinstance(e["id"], str) or e["id"] not in ids or e["id"] in good:
        continue
    reason = e["reason"]
    if e["verdict"] in VERDICTS and isinstance(reason, str) and 0 < len(reason) <= 200:
        good[e["id"]] = {"verdict": e["verdict"], "reason": reason}

Calls go out in batches of 10, at temperature 0, with response_format: json_object, through plain urllib. No SDK.

Picking the model: five open models, the same 20 real items

Before writing the scanner I ran a spike: 20 real items from a read-only scan of my Mac (13 cache locations and 7 project folders), the same prompt for every model, 3 runs each. No rules ran here. This was the raw model.

Model	Valid entries per run (of 20)	p50 per 10-item call
`google/gemma-4-31b-it` (pinned)	20 / 20 / 20	7.35 s
`google/gemma-3-27b-it`	20 / 20 / 20	7.67 s
`openai/gpt-oss-120b`	20 / 20 / 20	8.01 s
`meta-llama/llama-3.3-70b-instruct`	20 / 20 / 20	10.19 s
`qwen/qwen3-235b-a22b-2507`	20 / 20 / 20	14.76 s

* "Unsafe SAFE" means SAFE on Downloads, simulator data, or a project folder whose repo is dirty or had a commit in the last 14 days. It is not a general safety score.

All five cleared the JSON bar, so the tie-break was the part a human actually reads: the reasons. Gemma 4 explained regenerability ("Rust target directory is a regenerable build artifact."). Gemma 3's reasons leaned on size ("It's a large npm cache."). Gemma 4 was also the only one that marked my Trash ASK on its own: "Trash contains files the user explicitly deleted but may want to recover." Fair point, Gemma. It also had the lowest p50 of the five.

The 64 pytest tests cover the hard rules, the JSON contract and its failure fallbacks, the CLI, and --apply against fixture folders only. They use a fake model and never call Gemma. The stack is Python 3.11, uv and rich. I built it with Claude Code as my pair programmer. The model inside the product is Gemma, and nothing closed sits in that path.

Honest limits

macOS only for now. Every cache location lives in catalogue.py. A Linux or Windows port is a small pull request that also touches rules.py and reminder.py. PRs welcome, it's Hacktoberfest.
Hosted, not local. Trimmed paths, kinds, sizes, ages and git state go to OpenRouter. File contents never do.
Not bit-deterministic. The model id is pinned and the temperature is 0, but the serving provider isn't, and a re-run of the spike flipped 2 of 20 borderline verdicts (the pnpm store and the cargo registry, SAFE to ASK). Drift can't cross a rule's cap, but inside a SAFE cap two runs can differ.
34.2 GB is a du number, not freed space. pnpm and bun hard-link files, so deleting frees less. --apply reports the measured change in free space.
It's slow. About 200 s on my Mac, for one du per folder, the git reads and the model calls. Slow and steady, as the theme says.
14 macOS-protected folders were unreadable without Full Disk Access. They stay ASK, never SAFE.
The reasons are Gemma's judgement, even when they sound like facts. --json records decided_by for every item.

Why Does Open Innovation Matter?

A tool that deletes things needs a model I can pin, re-run and swap more than it needs a clever one. Open weights gave me that.

I could compare before trusting. Five open models from four labs, one prompt, one endpoint, one evening, then a pick from a table instead of vibes. Switching is one constant, MODEL_ID. I only tested open models, so I can't tell you Gemma beats a closed one on accuracy. Here is what open gave me instead.
The judge can move onto your machine. Today sweep calls Gemma on OpenRouter, because running a 31B model on a 99%-full laptop while du crawls the disk was not the lazy option. But the weights are on Hugging Face. Serve them behind a local OpenAI-compatible server, point ENDPOINT and MODEL_ID in model.py at it (the client still expects some value in OPENROUTER_API_KEY), and not even folder names leave the laptop. A closed model can be retired or quietly updated behind its name. A weights file I keep can't, so the spike above stays re-runnable against the exact same model.
The judge can be checked. The plan footer prints the exact model id, --json marks which items it decided, and the weights are public, so anyone can run the same model on the same metadata and look. A closed API shows me a model name. Open weights let me re-run the model itself.
The safety rules are open too. They are plain Python: 130 lines in rules.py, the merge in plan.py, the delete-time re-checks in apply.py. What sweep may delete is one code review away, and changing it is one PR.

The Lazy Payoff

My total effort for that run: one command. sweep spent 202.6 s walking the disk, sizing 167 items, reading git state and asking Gemma about the rest, while I sat very still, sloth-style. It reported 34.2 GB (by du) as SAFE, each item with a reason, 20 items it wanted me to look at, and 102 it refused to touch. One of those was a 3.8 GB node_modules in a repo with uncommitted changes: exactly the folder a blanket rm -rf of every node_modules would have eaten.

Doing this by hand means du on every cache, then git status in every project before touching its build folders. I didn't time myself doing that, because I didn't do it. That's the point.

For the full sloth, sweep --install-reminder writes a launchd job for a dry run every Sunday at 10:00, with one notification. It never deletes, and it doesn't switch itself on. It prints the launchctl line that does.

Prize Categories

Best Use of Gemma: google/gemma-4-31b-it, served through OpenRouter, is the judge for every item the hard rules leave open. It was picked over four other open models on reason quality and latency (table above).

If your Mac is down to its last few gigabytes too, the dry run deletes nothing, so it's an easy thing to try (it does send trimmed paths and sizes to OpenRouter): github.com/edycutjong/sweep. On Linux or Windows? Send a PR for the catalogue.

Making PayPal refuse the wrong charge: a scooter deposit as one authorization

Edy Cu — Sun, 25 Oct 2026 05:27:33 +0000

In Bali the deposit on a rented scooter is often your passport. At return the shop points at a dent, you say it was already there, and whoever is holding the document wins the argument.

I built Jaminan for the PayPal AI Hackathon to replace the passport with something both sides can check: a PayPal authorization that can only pay for lines the renter accepted. The part worth writing about is not the AI. It is how little code it takes to make PayPal itself refuse the wrong settlement, and the places the sandbox disagreed with my first design.

Everything below ran on the PayPal sandbox. Code: https://github.com/edycutjong/jaminan. Live: https://jaminan.edycu.dev/app/judge (one tap, fresh sandbox rental). Demo video (2:56): https://youtu.be/E8r-QMLocQo. Devpost: https://devpost.com/software/jaminan.

The deposit is an authorization, not a charge

One renter approval creates an Orders v2 order with intent: AUTHORIZE for fee plus deposit ($115.00 in the demo: $15.00 + $100.00), with store_in_vault so the wallet can be charged later for fines. The fee is captured right away. The deposit is never captured unless something goes wrong:

def capture(self, authorization_id, amount_cents, final_capture, invoice_id, note, ...):
    body = {"amount": money(amount_cents), "final_capture": final_capture,
            "invoice_id": invoice_id[:127], "note_to_payer": note[:255]}
    return self.call("POST", f"/v2/payments/authorizations/{authorization_id}/capture", ...)

The fee capture goes out with final_capture=false. PayPal reads the authorization back as PARTIALLY_CAPTURED, which means the remaining $100.00 is still held.

`final_capture=true` is the whole settlement

When the renter accepts a damage line, the settlement is one capture for exactly that amount with final_capture=true. That single flag does two jobs: it takes the accepted amount and releases everything else on the authorization. A clean return is a plain void.

In the recorded sandbox run for an accepted $18.00 mirror crack, PayPal reads the authorization back as CAPTURED and $82.00 of the deposit is released. Then the script tries to capture $1.00 more:

POST /v2/payments/authorizations/59Y22025SE889191E/capture   amount 1.00
HTTP 422  AUTHORIZATION_ALREADY_CAPTURED   (debug f5799404eea63)

That refusal is the feature. A shop cannot quietly charge a second "scratch" after the renter has walked away, and I did not write a line of code to stop it; I only had to set one flag. The three recorded settlements (accepted, clean, contested) are in evidence/paypal-sandbox-run.json with every PayPal debug id.

The model never sets a price

The vision model only answers narrow questions about the shared pickup photos: is there a mark here now, is it the kind the shop named, was it visible at pickup, can the pickup photo show that spot. A plain function turns the answers into "cannot be charged" or a tariff line, and a second function builds the settlement:

capture = min(total_accepted, deposit_cents)
if fee_captured_cents + capture > authorized_cents:   # PayPal enforces too; we check first
    raise SettleBlocked("captures would exceed the authorized amount (I2)")
...
overage = max(total_accepted - deposit_cents, 0)

Accepted lines above the deposit leave as an itemized PayPal invoice instead of a bigger capture. Contested lines are never captured at all; they go out as an invoice at the published tariff price, and the hold is voided.

Because the rule that matters ("a chargeable line is new since pickup and has a tariff price") is a pure function, I could test it exhaustively: 23,040 combinations of the model's yes/no answers, serving model, confidence, a confirmed baseline mark, comparability, parts and damage classes. Every chargeable result satisfies every "new since pickup" condition. A Hypothesis property test generates up to 3,000 settlements and checks the hold never pays more than the accepted lines (plus an invoice for any amount above the deposit) and never captures more than the authorization.

Where the sandbox disagreed with my design

One vault token per buyer and merchant. I planned a pool of judge wallets. PayPal returns the same vault token for the same buyer and merchant, so the pool holds one token until I create more sandbox accounts.
No cards. The card-path authorize answered 422 without a stated reason (I believe advanced card processing is not enabled for my Indonesia-region sandbox merchant), so Jaminan is wallet-only.
Reauthorize is date-gated. PayPal allows it only from Day 4 of an authorization. I built and unit-tested the path and its refusal fallback, then waited. On day 9 the sandbox reauthorized two holds, one with its fee already captured, and refused a second attempt on the same hold with 422: "only allowed once from Day 4 to Day 29".
A stale read-back. My own live check caught the /judge page showing PARTIALLY_CAPTURED after a release, because I cached the read-back on the authorization id alone. The cache key now includes the rental state, and there is a regression test. A settle screen that stamps "released" should be stamping what PayPal says now.

What it does not do yet

Be careful with the AI claim. No vision model is benchmarked yet, because the staged scooter photo set is still to be shot and scored. Until a model is pinned, a live claim ends "comparison unavailable — nothing charged from the hold", so the live app can release a hold but cannot price a damage line. The priced path is covered by tests and by the recorded run (with scripted claim answers, labelled as scripted).

I did run two smaller checks, and the model failed both, which is exactly why nothing is pinned:

A partial check on public photos. 48 Wikimedia Commons photos (26 damaged with 37 labelled marks, 22 clean scooters; CC BY, CC BY-SA and CC0 only), each used as both the pickup and the return photo, so the only right answer was "old" or "not new". The labels were drawn by my coding agent (Claude), not an independent annotator, and committed before any model call. qwen3-vl-plus with the app's prompts called an old mark new in 71 of 105 answers and a clean spot new in 66 of 66. The bar is 0. It is not the staged-set benchmark, and it cannot test new damage between two photos.
A pair of AI-generated test images (not photographs). A pickup image and an edit with both mirrors removed. The model read both pointed claims wrong, three times each. Had that model been pinned without the bench, the rules would have priced an old scuff at $45.00.

That is the design working as intended: a model that cannot tell old damage from new never gets to move money.

Also: sandbox only, one merchant, and non-return (a scooter that never comes back) is out of scope.

Agents can book, but not pay

A small MCP server (4 tools) lets a booking agent such as Claude Code or Codex quote and start a rental. Only the renter can approve the hold on PayPal's own page; the agent's token gets 403 on all 8 money and answer routes. Both agents' bookings and the 403s are in evidence/mcp/.

Try it

Open https://jaminan.edycu.dev/app/judge, tap Start a judge rental, then Release the hold, and watch /integrations/verify list every PayPal call with its status. Or run the offline suite (234 tests, no credentials, 100% line and branch coverage) from the repo; the full 243-test run includes 8 against the real sandbox.

If you work on rental, marketplace or escrow-style flows, the thing to steal is small: model the deposit as an authorization, and let final_capture=true be the only way money leaves it.

My own gate failed (8 of 20), so I rescoped a scam-ad checker around quotes code can find word for word

Edy Cu — Sat, 17 Oct 2026 22:55:28 +0000

A job offer lands in a family WhatsApp group (a composite scene, built from patterns in published reports): "CS Kamboja, Rp 15 jt/bulan, visa turis OK, tiket ditanggung." Someone has to tell the person who is about to board whether to take it, tonight. The rules that would stop them exist. Cambodia is not an official placement country, a tourist visa is not a work permit, a fee before a contract is a police-checklist warning sign. But those rules sit on different ministry, police and embassy pages, and nobody in the group can read them all in an evening.

I built Awas for the Nebius Global AI Hackathon to answer that chat with pages instead of a score. This post is mostly about the part that went wrong, because it changed the product.

Live: https://awas.edycu.dev (the /judge page opens five recorded real runs, no login)
Code (MIT): https://github.com/edycutjong/awas
Demo video (2:37): https://youtu.be/to4VOBm_eNM

What it does

You paste the text of an ad. Awas returns an evidence file and one of three outcomes: STOP, VERIFY FIRST, or NO RED FLAGS FOUND (it says "not a guarantee", never "safe"). There is no score.

Nemotron 3 Ultra on Nebius Token Factory copies typed fields (company, destination, job, visa, fees) out of the ad. Code checks each field is literally in the ad.
Fixed rules, each quoting an official page, produce red flags.
Tavily searches for published pages about the same company, number or destination.
Nemotron 3 Super proposes evidence lines: a URL, a quote, a claim.
A quote gate in plain code keeps a line only if the quote is a verbatim substring of the page text fetched in that run.
The verdict comes from the rules and the verified lines, not from a model.
A short Bahasa Indonesia message for the family, built only from verified lines.

The wall: my own gate failed

Before the first benchmark run, I wrote a pass condition into my own plan (it only shows up in the repo's history afterwards): for at least 12 of 20 known scam cases, Tavily had to surface a relevant advisory or news item. That promise ("here are published reports about this company") was the heart of the original pitch.

It surfaced one for 8 of 20. (An agent read the results; a human has not reviewed that reading yet.) A second problem sat behind it: reports almost never name the recruiter. In the benchmark's reported cases, 1 in the development set, 0 in the first tranche and 1 in the second name a company at all. A "company-matched" rate cannot be measured on that.

I had two options: stay quiet and keep the pitch, or rescope. I rescoped and published the number. The verdict now comes from rules quoted from official pages. Web search became context for the family, never an input to a rule. The README and the demo page both say the coverage gate failed and by how much.

The part worth copying: the quote gate

The model proposes, code decides. This is the heart of src/lib/gate.ts, trimmed to the matching step:

export function gateLine(p: Proposal, corpus: Corpus, ctx: GateContext): EvidenceLine {
  const doc = corpus.get(p.url);
  if (!doc) return dropped(p, "url_not_returned");
  if (words(p.quote).length < MIN_QUOTE_WORDS) return dropped(p, "too_short", doc.purpose);
  const nq = normalise(p.quote);
  // ...
  for (const chunk of doc.chunks) {
    const nc = normaliseWithMap(chunk.text);
    const at = nc.text.indexOf(nq);
    if (at < 0) continue;
    // ... return a "verified" line with the raw quote and its offset
  }
  const joined = normalise(doc.chunks.map((c) => c.text).join(" "));
  return dropped(p, joined.includes(nq) ? "spans_chunks" : "not_in_page", doc.purpose);
}

A line whose quote is not found word for word in the page returned in that run is dropped, and the drop is shown on screen. Shown quotes can be re-checked against their pages without Awas code: on the held-out run a script re-found 33 of the 48; the rest need a browser (14 pages refuse scripts or are PDF/JavaScript pages) or had changed since fetch (1).

What the held-out run measured

The second benchmark tranche was frozen (and its files hashed) before it ran, then run once on code tagged code-freeze, as a Nebius Serverless Job against the production app. Every number is in DEMO.md and bench/ in the repo.

Licensed agencies' vacancies wrongly stopped: 0 of 10.
25 publicly reported scam-recruitment cases: 9 STOP, 15 VERIFY FIRST, 1 NO RED FLAGS FOUND. Eight of the nine STOPs come from cited rules alone. One case is a single case, not a rate.
48 of 48 evidence lines shown were gate-verified. Six of 54 proposed lines were dropped (11 %).
p50 13.7 s, p95 31.7 s from request to finished file (server-side); median cost $0.0078 in Token Factory tokens plus 1 to 3 Tavily credits.
The same verdict on 20 of 20 reruns of 10 reported cases, and 19 of 20 on 10 licensed vacancies.

Things the docs did not tell me

The structured-output guide's own json_schema example is refused with HTTP 422 on Nemotron 3 Super and Lightning; the API reference's name/schema/strict form works.
Super is a reasoning model, so I give it generous max_tokens: an earlier project of mine saw it spend them all thinking and return an empty answer (the empty answers recorded in this repo are Lightning's).
Indonesian is on none of the model cards I could read, so I measured it: field accuracy 84.8 % for Ultra, 70.7 % for Super, 59.6 % for Lightning, against labels an agent drafted and no human has reviewed yet. That caveat is on every page that quotes the figures.
Object Storage's conditional writes (If-None-Match, 412 on a repeat) were enough for a rate limit with no database.

The full list, each with a recorded call, is in FEEDBACK.md.

Limits

The coverage gate failed, so web evidence is context only. The benchmark's reported cases are reporters' descriptions of offers, not the original ads, so real ads may carry more red-flag wording. The phone-number path is unmeasured. NO RED FLAGS FOUND is never a guarantee, and no outside user has used Awas yet. It is a research prototype, not legal advice and not an official service.

If you have seen an overseas job ad in a group chat, paste the text (with phone numbers and names removed) at https://awas.edycu.dev and tell me what it got wrong.