andreagrandi / andreagrandi/draftomen

Represent and persist multi-card logical picks

未關閉
#260 0 則留言 0 個 reaction 已指派 0 人 在 GitHub 檢視
draftomen enhancement size: L
主要語言
Python
星號
0
分支
0
平均合併
1 小時 21 分鐘
30 天內合併 PR
188

描述

## Problem

`PickMadeEvent`, `DraftPick`, pool persistence, idempotence, recovery, and completion reconciliation store one `chosen_grp_id`. Pick-Two selects two cards at one pack/pick coordinate, so logical-pick count and selected-card count are different invariants.

## Proposed change

Cleanly replace singular chosen-card contracts with an immutable collection of selected card IDs across events, draft state, and persistence. Migrate every direct caller in the same change. Preserve coordinate-level idempotence and add every selected card to the pool exactly once.

## Acceptance Criteria

- [ ] A logical pick stores one or more selected card IDs and rejects an empty selection.
- [ ] Quick/Premier/Traditional picks store one card; Pick-Two stores two cards at one coordinate.
- [ ] Logical-pick count and selected-card count are explicit and cannot be confused.
- [ ] Duplicate delivery of an identical multi-card pick is idempotent; conflicting replay is rejected consistently.
- [ ] Pending-pack recovery and completion reconciliation preserve every selected card exactly once.
- [ ] Existing persisted Quick Draft state has a tested clean migration or explicit compatibility strategy.
- [ ] All singular call sites are migrated; no deprecated alias remains.
- [ ] Focused pool/state tests and the changelog cover the new contract.

## Scope notes

No human pick-message parsing, ratings changes, or UI presentation.

貢獻指南

這個儲存庫沒有索引到貢獻指南

研究方向

Trace PickMadeEvent and DraftPick through pool persistence, pending-pack recovery, and completion reconciliation to map every singular chosen_grp_id caller. Run the focused pool/state tests while checking coordinate idempotence, migration compatibility, and selected-card counts. Done means all acceptance criteria pass and the changelog documents the new contract.

由索引模型根據 Issue 內容生成。

評估

技術堆疊
python
領域
backend, database
Issue 類型
重構
難度
5/5
預估耗時
一週以上
活躍度
活躍
描述清晰度
基本清楚
新手友好度
35/100

把新 issue 寄到你的電子郵件信箱

精選適合新手參與的 GitHub issue 摘要。