docs(bond): spec cancel_action handling for WaitingTakerBond status

[grunch]

Summary

Closes a latent gap in the Phase 1.5 spec. §6.5.1 already widens the take handlers to accept orders in either `Pending` or `WaitingTakerBond`, but the equivalent change for `cancel_action` was never spelled out. Without it, a cancel issued during the bond window (between take and bond lock) would fall through `cancel_action_generic`'s status match and hit the default `_ => NotAllowedByStatus` arm — a silent regression vs. Phase 1, where both the maker self-cancel and the taker self-cancel work today because the order is still in `Pending`.

The two flows that would break:

• A taker who took the order, was DM'd `pay-bond-invoice`, and changed their mind before paying it (legitimate self-cancel — they should be able to back out cleanly).
• A maker who decided to cancel their own order while a prospective taker is mid-bond (legitimate, e.g. price moved, conditions changed).

Both work today because Phase 1 keeps the order in `Pending`. After Phase 1.5 flips the DB status to `WaitingTakerBond`, neither would work without the spec'd widening.

Changes

• §6.5.1 gains an explicit `cancel_action` bullet alongside the existing take-handlers bullet:
  • `Status::Pending` guard widens to `Pending | WaitingTakerBond` in `cancel_action_generic`.
  • Cooperative-cancel logic does NOT apply (trade flow has not started).
  • Both routes inside the branch (`cancel_pending_order_from_maker` for maker self-cancel; `cancel_order_by_taker` for taker self-cancel) stay unchanged. Bond release hooks are already wired into both paths from Phase 1.
• §6.5.3 adds three tests:
  • Taker self-cancel during `WaitingTakerBond` → `Ok`, order returns to `Pending`, observers see no NIP-33 transition (was `pending` throughout).
  • Maker self-cancel during `WaitingTakerBond` → runs `cancel_pending_order_from_maker`, releases prospective taker's bond, publishes `s = canceled`.
  • Third-party pubkey (neither maker nor a bonded taker) → `IsNotYourOrder`. Widening must not weaken authorisation.

Test plan

• Reviewer to confirm the `Pending` / `WaitingTakerBond` aliasing is the right semantic and that we are NOT routing these through the cooperative-cancel flow used by `WaitingPayment` / `WaitingBuyerInvoice`.
• Reviewer to confirm the third-party rejection test is the correct authorisation contract (matches today's Phase 1 behaviour for `Pending` orders with a bond outstanding).

🤖 Generated with Claude Code

[coderabbitai]

Warning

Rate limit exceeded

@grunch has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 48 minutes and 15 seconds before requesting another review.

You’ve run out of usage credits. Purchase more in the billing tab.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: a9acef0d-6f42-486b-8792-fd2faf525bdd

📥 Commits

Reviewing files that changed from the base of the PR and between 9abc500 and e8dbe21.

📒 Files selected for processing (1)

• docs/ANTI_ABUSE_BOND.md

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch docs/bond-cancel-waiting-taker-bond

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}