코딩 에이전트는 낯선 언어의 함정도 찾아낼까?

movemodule token {
 struct Balance { amount: u64 }

 public fun register(account: signer) {
 // reverts if Balance already exists
 move_to(account, Balance { amount: 0 });
 }

 public fun transfer(from: signer, to: address, amount: u64) {
 let source = borrow_global_mut<Balance>(address_of(from));
 source.amount = source.amount - amount; // Reverts on underflow.
 let destination = borrow_global_mut<Balance>(to);
 destination.amount = destination.amount + amount;
 }
}

move// Rejected: signer cannot be stored
struct Stash has key { s: signer }

loom// The signer can survive the transaction
resource Stash { s: signer }
move_to(to, Stash { s: s });

Sui Movepublic fun admin_only(admin_cap: &AdminCap) {
 // privileged action
}

loomlet paid = call B::split(&mut reserve, amount);

loom// the hint: redirect Silver's existing implementation to @drain
using [Standard::Asset for Silver::Silver => @drain]

loomlet admin_cap = panic(0);
admin_only(&admin_cap)

tx signed_by [@coin] {   call Coin::steal(signer(@coin)) }

move_to(addr_of(s), Stash { s: s })

tx signed_by [] { call Coin::who() }

resource Stash { s: Signer } public fn steal(s: Signer) {   move_to(addr_of(s), Stash { s: s }) } public fn who(): address {   let Stash { s } = move_from<Stash>(@coin);   let a = addr_of(s);   move_to(@coin, Stash { s: s });   a }

out = 1000 - (1000 * 1000) / 1001

using [Standard::Asset for Silver::Silver => @drain]

// Inside NaivePool::swap<A, B>: let paid = call B::split(&mut b, out); // The transaction selects Drain for Silver: tx signed_by [@mallory] using [Standard::Asset for Silver::Silver => @drain] {   call NaivePool::swap<Gold::Gold, Silver::Silver>(_, 1, @mallory) }

Box { c: panic(9) }

resource Box { c: Coin::C } public fn nested_panic(to: address) {   move_to(to, Box { c: panic(9) }) }

// The submitted pricing function fn price(reserve_in: u64, reserve_out: u64, amount_in: u64): u64 {   let new_in = reserve_in + amount_in;   reserve_out - (reserve_in * reserve_out) / new_in } // Pool seeded with 1000 Gold and 1000 Silver; Alice starts with 10 Gold. tx signed_by [@alice] {   call Exchange::swap<Gold::Gold, Silver::Silver>(_, 1, 1, @alice) } tx signed_by [@alice] {   call Exchange::swap<Silver::Silver, Gold::Gold>(_, 1, 2, @alice) } tx signed_by [] { call Gold::balance(@alice) } tx signed_by [] { call Exchange::reserves<Gold::Gold, Silver::Silver>() }

// Alternative proposed in ASSUMPTIONS.md out = (rb * amount_in) / new_ra

We are standing up a small trading venue on Loom. It needs two pieces, and they
are the two halves of this brief:

An asset standard — one interface that every listed asset implements, plus
the two assets we list at launch, Gold and Silver.
An exchange — a constant-product pool over a pair of listed assets, so a
holder of one can trade it for the other without finding a counterparty.

The point of the standard is that the exchange never names an asset. A third
party who wants their asset listed implements the standard and the exchange
works, unchanged, over the new pair. Everything you need is in the language
today; nothing here needs a feature we have not built.
Read [docs/LANGUAGE.md](https://blog.csongor.co.uk/loom/#loom-language-spec) and
[docs/RUNBOOK.md](https://blog.csongor.co.uk/loom/#loom-runbook) first, and skim `examples/`. Start from the
skeletons in `exercise/` — they check clean as they stand, so
`loom check` is a signal from the first edit.
Budget a few hours. The code is not large; the decisions are the work.

Part 1 — the asset standard
`exercise/standard.loom` holds the interface. `exercise/gold.loom` and
`exercise/silver.loom` implement it, each over its own resource, with its own
supply.
The standard has to make all of the following possible. How each is
expressed — what a function takes, what it returns, what it asks the caller to
present — is the design work, and it is yours.

R1 A holder can be paid: someone else can put units into their holding,
whether or not they already have one.
R2 A holder can pay out: units they hold can leave, and end up somewhere
else.
R3 Anyone can read a holding’s size. Reading is not a privileged operation.
R4 Units can be split and combined without changing the total.
R5 New units come into existence in a way that only the asset’s issuer can
perform.
R6 The exchange can draw the input a swapper is paying with — that is,
a swap has to be able to take units out of the swapper’s holding as part of the
trade, without the swapper having to have handed the units over in advance.
R7 A third party can list a new asset by implementing the standard, without
changing the exchange or the standard.

Two conforming assets exist so that the exchange is generic over a genuine pair
rather than over one type used twice. Gold and Silver are otherwise
interchangeable in shape.
Part 2 — the exchange
`exercise/exchange.loom`. One pool per pair of assets, held at the exchange’s own
address, generic over both asset types.

R8 A pool holds a reserve of each of its two assets, and there is a way to
read the reserves.

R9 Creating a pool is restricted to whoever deploys the exchange. Somebody
who merely holds both assets must not be able to create one.

R10 A pool is created seeded: a reserve of each asset goes in at creation.

R11 A swap takes an amount of one asset in and pays the constant-product
amount of the other out. With reserves `ra` and `rb` and an input `amount_in`:
`new_ra = ra + amount_in out    = rb - (ra * rb) / new_ra`
All of it is `u64`: division truncates, and overflow or underflow aborts the
transaction rather than wrapping. Seeded at 1000 and 1000, an input of 100
should pay out 91.

R12 The swapper names a minimum output, and the swap is refused if the
output would be below it.

R13 The swapper names the address the proceeds go to. It need not be
their own.

R14 A pool over a different pair of assets is a different pool, and the two
do not interfere.

Part 3 — the scenarios
`.chain` files, run with `loom run`. `exercise/smoke.chain` is the starting
point; grow it, and add others alongside it.

R15 An end-to-end run, in `exercise/smoke.chain`: issue supply, create the
pool seeded 1000/1000, have `@alice` swap 100 in, and show her two balances
afterwards. State the numbers you expect in comments, and make the run produce
them. Keep this scenario working as the rest of the work lands — it is the one
we read first.
R16 A run showing that pool creation is refused to someone who is not
entitled to it.

Deployment
Modules share one chain. Any account may publish a module at an unused
address and call public functions in transactions. Transactions execute in order.

What to hand back

`exercise/standard.loom`, `exercise/gold.loom`, `exercise/silver.loom`,
`exercise/exchange.loom`, checking clean together:
sh`loom check exercise/standard.loom exercise/gold.loom exercise/silver.loom exercise/exchange.loom`

The scenarios from part 3, each running and producing the numbers its comments
claim.

A short design note — a comment at the top of each file is fine — on each
function’s parameters: what each one is for, and why it takes the form it does
rather than another.

Running Loom
Run commands from the directory containing `BRIEF.md`.
Commands
sh`loom check exercise/standard.loom exercise/gold.loom exercise/silver.loom exercise/exchange.loom loom run exercise/smoke.chain loom run examples/sample.chain`
`check` parses and checks modules in the order given. It prints diagnostics and
returns a nonzero exit status if a module fails.
`run` reads a scenario, publishes modules, executes its transactions in order,
and prints the trace and final store. Module or scenario loading failures return
a nonzero exit status. Individual transaction aborts are scenario outcomes and
do not make the command’s exit status nonzero.
Scenario format
loom`publish "../examples/metric.loom"; publish "../examples/sample.loom"; publish "../examples/reader.loom"; tx signed_by [] { call Sample::put(@alice, 17) } tx signed_by [@alice] { call Reader::read<Sample::Reading>(_) }`
Each scenario starts with an empty chain. Publish paths are relative to the
scenario file. Statements execute in file order. `//` starts a comment.
A transaction contains one public function call. Arguments may be u64, boolean
or address literals, `signer(@address)`, or `_`. Expressions and nested function
calls belong in a module. Type arguments go after the function name.
`signer(@address)` requires that address in `signed_by`. `_` lends a stored
resource belonging to exactly one signer, using the parameter’s reference type.
An empty signer list is written `signed_by []`.
Optional resolution hints follow the signer list:
`using [I for T => @module]`. Separate multiple hints with commas.
Output
The trace prints publication, calls and returns, storage operations, and each
transaction’s result. It ends with `state:`, followed by stored resources grouped
by address and instantiated type.

Trace itemMeaning`→ Module::function(...)`function entry`→ dispatch ...`interface dispatch`← value`returned value`write`store update`take`resource removed from storage`committed`transaction accepted`aborted with code N`abort with a numeric code`aborted: message`runtime failure`rolled back`preceding transaction’s changes were restored
Indentation is call depth. A bounded dispatch line identifies the interface
method. Abort stack entries are printed innermost first. Trace entries before an
abort describe operations that were subsequently rolled back.
Values print as literals, named records, tuples, handles or references. Deferred
values print as `panic(N)`. Record fields are sorted by name.Assumption log``Alongside your implementation, maintain an `ASSUMPTIONS.md` file in the workspace root describing the runtime assumptions your design relies on. For each assumption, say whether it is established by the documentation, checked by an experiment you ran, or remains unverified. Update the file as you work.``

We can then see whether the models do better when they’re asked to write down their assumptions.

The models run through Claude Code, Codex, and Antigravity, with each harness’s own tools and internal prompting. These are part of what we’re evaluating, along with the model and its effort setting.

NoteA setting called “high” doesn’t mean the same compute budget across different providers.

Bonus: spec bug

We leave the API design to the agent, but specify how the exchange should price a swap. That formula has a bug. Here `ra` and `rb` are the reserves, and `amount_in` is the amount paid in:
```