docs: clarify dispute status taxonomy in DISPUTE_SYSTEM.md - #41
Conversation
- Add Status taxonomy distinguishing four status layers: order public (kind 38383), order internal/DMs, dispute protocol (kind 38386), and v1 local UX - Add protocol-to-UX mapping table showing resolved/closed are app-only labels - Clarify Dispute.status is a free-form string overwritten by OrderState.updateWith(), not a protocol enum - Split status normalization into order status mapping vs local UX dispute status mapping - Clarify Status.dispute is a real protocol order status sent via DMs but never published in kind 38383 - Expand resolution paths to show protocol and v1 app effects separately
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughUpdated DISPUTE_SYSTEM.md: added a "Status taxonomy" (four dispute-related status layers), clarified that Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In @.specify/v1-reference/DISPUTE_SYSTEM.md:
- Line 233: The section heading "Cross references" should use a hyphen for
consistency — change the heading text to "Cross-references" in the
DISPUTE_SYSTEM.md file by locating the header line that currently reads "## 9)
Cross references" and updating it to "## 9) Cross-references" so the term
matches other hyphenated headings.
- Line 66: The Dispute.status taxonomy is inconsistent about whether "initiated"
is a client-only UX value; update the doc so both places agree: either add
"initiated" to the local-UX status list in the table for Dispute.status
(alongside in-progress, resolved, seller-refunded, closed) and keep the
explanatory note that these are never sent to Mostro and that resolved/closed
are not protocol values, or remove "initiated" from the UI gating sentence and
explicitly state it is a protocol-only status; make the corresponding change
wherever OrderState.updateWith() and the local-status gating sentence reference
"initiated" so the two descriptions match.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5e6127f3-07a0-4c6b-a154-2f3a88168d28
📒 Files selected for processing (1)
.specify/v1-reference/DISPUTE_SYSTEM.md
| | **Order status (public)** | Kind 38383 event, tag `s` | **Does not change** when a dispute opens. Updates to `success` (admin-settle) or `canceled` (admin-cancel) only at resolution. | The public order book never shows `dispute`. | | ||
| | **Order status (internal + DMs)** | Mostrod database + gift-wrapped DMs to users | Changes to `dispute` when a dispute is opened (`setup_dispute()` in mostro-core). Then to `success` or `canceled` at resolution. | This is a real protocol order status — mostrod checks `Status::Dispute` before allowing admin-settle or admin-cancel. It reaches clients via gift wraps but is never published in kind 38383 events. | | ||
| | **Dispute status (protocol)** | Kind 38386 event, tag `s` | `initiated` → `in-progress` → `settled` \| `seller-refunded` | Authoritative source: `mostro-core::dispute::Status` enum. | | ||
| | **Local UX dispute status (v1 app)** | `Dispute.status` string field set by `OrderState.updateWith()` | `in-progress`, `resolved`, `seller-refunded`, `closed` | **Never sent to Mostro.** Client-side labels for UI rendering. `resolved` and `closed` do not exist in the protocol. | |
There was a problem hiding this comment.
Clarify whether initiated is a local UX status or protocol-only.
There’s a docs inconsistency: Line 66 defines local UX Dispute.status as in-progress/resolved/seller-refunded/closed, but Line 145 lists initiated as another local status that can appear in UI gating. Please either include initiated in the taxonomy as a transient local value or remove it from the local-status gating sentence.
Also applies to: 145-145
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In @.specify/v1-reference/DISPUTE_SYSTEM.md at line 66, The Dispute.status
taxonomy is inconsistent about whether "initiated" is a client-only UX value;
update the doc so both places agree: either add "initiated" to the local-UX
status list in the table for Dispute.status (alongside in-progress, resolved,
seller-refunded, closed) and keep the explanatory note that these are never sent
to Mostro and that resolved/closed are not protocol values, or remove
"initiated" from the UI gating sentence and explicitly state it is a
protocol-only status; make the corresponding change wherever
OrderState.updateWith() and the local-status gating sentence reference
"initiated" so the two descriptions match.
Summary by CodeRabbit