test: Receipt text projections need regression coverage

[nishuzumi]

Problem

Ordered leaf text strings are the only thing the MCP layer projects to Agents (mcp-server/src/server.ts receiptTexts), and the Agent safety rules require comparing every ordered text with user intent. Yet no protocol package asserts its text formats in tests today — erc20, Kuru, PancakeSwap V3, and the newly merged PancakeSwap V2 (#22) all test outcomes, ordering, and rejection paths, but never the text projections themselves.

A silent formatting regression (dropped field, reordered interpolation, wrong unit) would pass every existing test while changing exactly the evidence Agents read.

What to add

For each Receipt-producing package (erc, kuru, pancakeswap V2+V3, and every future protocol):

• assert the exact leaf text for each Change class the parser produces (ERC20 transfer/approval, native transfer, protocol events such as Sync/Swap and WMON Deposit/Withdrawal);
• assert the top-level Receipt text format;
• in at least one flow test, assert the complete ordered leaf-text sequence as flattened by receiptTexts-equivalent traversal, so order and completeness are locked together.

Notes

• Raw base-unit amounts and address (or NATIVE sentinel) rendering are the accepted convention; the assertions should lock that convention, not change it.
• Package template should gain a text-assertion example so new protocols inherit the practice.

[pillowtalk-Qy]

Hi Box,

I would like to take #115 if the scope is appropriate.

I would keep it test/template-only:

• exact deterministic leaf and top-level Receipt text assertions for current ERC, Kuru, and PancakeSwap V2/V3 fixtures;
• one complete ordered flattened text-sequence assertion per representative flow;
• a template example for future Protocol packages;
• no changes to Receipt formats, rendering behavior, public APIs, or live-output conventions.

The tests would lock the current raw base-unit and address/NATIVE rendering convention described in the issue.

Would you like me to proceed with this focused scope?

[nishuzumi]

For anyone picking this up — worth two minutes first.

Moss is one of the pool repos in MOST, the Monad Open Source Track, which the Monad Foundation runs to back people doing public, original open-source work on Monad. It pays in AI credits toward the tools you build with, and the amount grows the longer you sustain the work.

Taking a scoped issue like this one and carrying it through review is precisely what it counts. What it looks for is public repos, original code, a steady cadence across the month, and contributions that get merged — the merge is the bar, and every one is reviewed by a human. It reads your public GitHub activity, so there is no separate log to keep.

Applying takes a form: email, GitHub handle, a short note on what you are building and why, and a Telegram handle so they can reach you. Applications are reviewed manually, so a real sentence about your work is worth more than a filled field.

Apply here: https://most.devnads.com/

[ayushsingh82]

@nishuzumi I'd love to take this on and add the regression coverage — could I get assigned?

[nishuzumi]

@nishuzumi I'd love to take this on and add the regression coverage — could I get assigned?

Yeah!

[codeswithroh]

I'd like to take this.

Plan, matching the issue's own scope:

• For each Receipt-producing package (erc, kuru, pancakeswap V2+V3), assert the exact leaf text for every Change class its parser produces: ERC20 transfer/approval, native transfer, protocol events like Sync/Swap, WMON Deposit/Withdrawal.
• Assert the top-level Receipt text format for each.
• In at least one flow test per package, assert the full ordered leaf-text sequence as flattened the same way receiptTexts does, so ordering and completeness are locked together, not just individual strings.
• Lock the existing convention (raw base-unit amounts, address or NATIVE sentinel) rather than changing it.
• Add a text-assertion example to the package template so new protocols inherit the practice.

Holding off on code until assigned. Will post progress here, and the PR will close this issue.

[portdeveloper]

@codeswithroh the claim is registered and the issue is assigned to you. One claim at a time pool-wide; a claim with no pull request or progress update after 7 days is released (agents.md, https://most.devnads.com). Good luck!

[codeswithroh]

PR is up: #204.

Since #178 already covered erc20, Kuru, PancakeSwap and the template, I audited every Receipt-producing package and locked the ones still missing exact text: ERC721, ERC1155, WMON, Aave, aPriori, Clober, Kintsu, Morpho, Pendle and Uniswap. Tests only, no format changes. It also adds one line to the onboarding tests list, the Protocol Definition of Done and the PR template so new adapters do the same.