Cyan Eclipse Boomerang

Vendor: Cyan Eclipse Technologies · Platforms: MCP over stdio

What it does

• Novel mechanism — return mandate cryptographically bound to the original order receipt, with condition/serial attestation at return initiation (SPEC §3): register_purchase seals order_ref + serial + amount + the full mandate record + the full receipt record together and derives receipt_hash + mandate_hash inside the sealed purchase; initiate_return authorizes only when the sealed purchase exists and its seal recomputes, the presented serial equals the sealed serial, the sealed mandate's scope explicitly includes returns, and a well-formed condition attestation {condition, attested_by, ts} is present. The sealed return record carries receipt_hash + mandate_hash + purchase_seal copied from the sealed purchase, so the return → receipt + mandate binding is recomputable by verify_return without trusting caller assertions. Bench: bindings independently recomputed from fixture data (purchase_id, both hashes, purchase HMAC seal, return HMAC seal — all match server values); seal-transplant forgery onto altered amount/serial/hashes/attestation rejected INVALID x8.
• A receipt-free return can never authorize: no purchase record → DENIED / NO_PURCHASE_RECORD, and there is no override tool, no manual-approve path, and no way to mint a return except through the check chain (existence → seal → serial → mandate scope → attestation, in spec order). Bench N-check: wrong/case-variant/whitespace/empty serial → SERIAL_MISMATCH x4; mandate without returns scope → MANDATE_SCOPE_NO_RETURNS (including smuggled returns-mandate + force flags in the initiate args — the sealed mandate governs); missing/malformed attestation → ATTESTATION_MISSING x9; tampered purchase store (amount edited, mandate edited to ADD returns scope, receipt_hash edited) → SEAL_INVALID, never authorized. Denial is a result, not an exception, with a closed reason-code set (NO_PURCHASE_RECORD · SERIAL_MISMATCH · MANDATE_SCOPE_NO_RETURNS · ATTESTATION_MISSING · SEAL_INVALID); every denial is logged for list_denials. Override audit: tools/list = exactly the 5 spec tools; 10 override-shaped calls (admin_authorize, force_return, manual_approve, refund_now, …) all NO_SUCH_TOOL.
• Process hardening (v0.1.1 fix for bench defect D1, MEDIUM): strict argument-type validation at dispatch against the advertised inputSchemas (ids must be strings; amount must be an integer, booleans rejected; mandate/receipt must be objects) plus store-level backstops and a catch-all tools/call path — no malformed input of any shape may terminate the process. Re-bench: 6/6 original crash vectors clean in fresh processes, 56-case wrong-type fuzz sweep + 15 protocol-garbage cases, server alive and answering tools/list (5 tools) after every case. Spec'd domain semantics preserved under the hardening: a malformed condition_attestation is still DENIED / ATTESTATION_MISSING (not a dispatch error) and null ids keep their §5 domain outcomes.
• Response-shape conformance (v0.1.1 fix for bench defect D2, LOW): every response on every branch — including all verify_return INVALID paths and list_denials (response + stored denial entries) — now carries scope: "LOCAL/fixture" and seal_type: "HMAC-SHA256 demo (local key)" uniformly, per SPEC §5. Re-bench D2 audit reached and checked every INVALID branch via independently re-sealed records.
• Honest scope: LOCAL/fixture only — v0.1.1 operates on caller-supplied fixture purchase records (receipt + mandate); no network calls; no merchant, carrier, payment, or logistics system is contacted. Authorization is a sealed local record, NOT a real-world returns/logistics action: it does not ship, receive, refund, restock, or instruct any third party. Seals are HMAC-SHA256 with a local demo key (runtime-generated into gitignored keys/demo.key, mode 0600; bench hygiene: demo key value absent from tree + full git history). Python 3 standard library only; MCP over stdio; exactly 5 tools; no payment or checkout code — the $1.00/return term is a pricing statement only.

Tools

Problems it addresses

• My buying agent needs to return a purchase — I need the return authorized only against the original purchase receipt and the mandate that governed the purchase, never on a bare claim
• A receipt-free or wrong-serial agent return, or a mandate that never included returns, must be denied with a machine-readable reason — and there must be no override or manual-approve path around the check
• If the purchase record or the return record is tampered with after the fact, I need verification to fail — the return's binding to the receipt hash, mandate hash, and purchase seal must be independently recomputable

Not tested

• Real-world returns, logistics, refund, or restock action — not in v0.1.1 by design (SPEC §7 non-goals): no merchant, carrier, payment, or logistics system is contacted and no third party is instructed; authorization is a sealed local record only
• Hosted or remote serving — v0.1.1 is local stdio only, operating on caller-supplied fixture purchase records
• Payment, checkout, or per-return metering enforcement — none exists in v0.1.1 by design: the $1.00/return term is commercial metadata (Procure per-order pattern); no payment or checkout code is in the server
• Production key custody — seals use an HMAC-SHA256 demo key generated locally (gitignored keys/demo.key); no production key claim is made