Reviewed document: RFP-003: review map for M1, M3 and M6, review draft dated 22 September 2026, section “Test cases for review”.
Review candidate named by the gist: Gateway v0.2.4,
98f492adff67bf62c22e04609f0810c196d6a0dc.
RFP baseline: logos-co/rfp@4e9b3c3d
Review date: 2026-09-23
The question is whether the twelve test cases in the gist cover the hard requirements of RFP-003, which requirements they cover, and how well.
Each RFP hard requirement was mapped to the gist cases whose goal, steps or
expected result exercise it. The mapping used the RFP text, the gist text, and
the e2e driver in this repository at the review candidate commit
(deploy/scripts/node-e2e.py) to confirm what each case actually asserts.
Requirement IDs follow docs/requirements-traceability.md: F1–F9
Functionality, U1–U10 Usability, R1–R8 Reliability, P1 Performance,
S1–S13 Supportability, D1 Demos.
The twelve test cases defined in the gist, referred to by their gist IDs throughout this document:
| Case | What it checks | Result recorded in the gist |
|---|---|---|
| MAC-NATIVE-001 | Maker and Taker v0.2.4 packages load in native Basecamp and reach their Nodes | PASS within stated versions |
| MAC-NATIVE-002 | Clean quit and reopen of both packages | Local patched build PASS; released build crash retained |
| MAC-NATIVE-003 | App shows no “connected” state before a real Node response | Local patched build PASS; released build failure retained |
| ZEC-APP-001 | Transparent LEZ/ZEC swap in the apps with shield-after-swap guidance | BLOCKED, feature absent |
| BTC-HAPPY-001 | Complete BTC swap in both directions | PASS, both directions |
| BTC-REFUND-001 | First locker refunds when the second locker never locks | NOT RUN in the 22 September register; PASS locally in both directions in the gist’s 23 September follow-up |
| BTC-REFUND-002 | Both locked, Taker never reveals, second locker refunds first | PASS, reverse direction only |
| BTC-RESTART-001 | Either role Node restarts between first lock and claim | PASS, reverse direction only |
| BTC-CONCURRENT-001 | Two overlapping swaps keep isolated state and effects | PASS, reverse direction only |
| BTC-CLAIM-001 | Claim included before cutoff but first observed after it | PASS, reverse direction only |
| BTC-CLAIM-002 | Admitted claim never becomes canonical, both sides refund | PASS, reverse direction only |
| BTC-TIMING-001 | Public-profile refund ordering for the both-lock timeout | NOT RUN, tools ready |
The gist also carries a follow-up dated 23 September 2026
(04-followup-2026-09-23.md). It records BTC-REFUND-001 passing locally in
both directions and a new case, MAC-NATIVE-005, a Bitcoin-to-LEZ swap driven
through the native Mac screens on locally patched packages. MAC-NATIVE-005 is
not one of the twelve cases above and is not graded here; it would move U5 and
U6 from lifecycle-only towards a functional case once it runs on unpatched
released packages.
Coverage grades:
Grades describe the test cases only. They are not a statement about whether the implementation meets the requirement, and they do not replace the gist’s own result register.
The twelve cases cover the Bitcoin leg (F2, F5, F6, R1, R4, R5) and the Basecamp package lifecycle (U5 and U6, load and shutdown only). They cover nothing else in the RFP.
| Grade | Count | Requirements |
|---|---|---|
| Covered | 4 | F5, F6, R4, R5 |
| Partial | 10 | F1, F2, R1, R6, U1, U5, U6, S5, D1, R7 |
| Not covered | 29 | F3, F4, F7, F8, F9, U2, U3, U4, U7, U8, U9, U10, R2, R3, R8, P1, S1, S2, S3, S4, S6, S7, S8, S9, S10, S11, S12, S13, soft ZEC adaptor |
The gist is explicit about this limit. It scopes itself to M1, M3 and M6, and its S4 row says that full F/U/R/P coverage “is not yet established”. Judged against the whole RFP, the case set does not cover it. Judged against the BTC-leg and app-packaging scope it claims, it is reasonable, with the defects listed in section 4.