README

quote_bids 狀態變動

目的

這裡整理 quote_bids 的狀態流與資料表關聯，讓新手工程師能快速理解「一筆報價」從建立、展示、聯絡、扣款、訊息到 activity / queue 的變化。

quote_bids 不是單純的報價資料表。它同時連到：

• quote_requests：案件與消費者。
• quote_services：專家服務。
• users：requestor / provider。
• transactions：扣款與付款紀錄。
• messages / message_contents：聊天室訊息。
• quote_activities：案件活動紀錄。
• task_event_queue / task_event_queue_log：非同步統計、簡訊、badge。

建議閱讀順序

1. 狀態欄位總覽
2. 流程/search_add
3. 流程/want_to_contact_provider
4. 流程/consumer_want_provider_quote
5. 流程/provider_accept_narrow_match
6. 欄位/is_want_to_contact_provider
7. 欄位/narrow_status_id
8. 欄位/quote_user_subscription_log_id
9. 欄位/報價內容欄位

核心觀念

一筆 quote_bids 通常不是「一次 API 呼叫就完成所有狀態」。常見流程是：

search_add 建立 quote_request
-> 系統配對 provider
-> 建立 quote_bids
-> consumer 看見 quote card
-> consumer 聯絡 provider
-> quote_bids.is_want_to_contact_provider = 1
-> 扣款 / transaction / activity / queue

因此排查時不要只看 quote_bids。至少要一起看：

• quote_requests
• transactions
• messages
• quote_activities
• task_event_queue / task_event_queue_log
• monolog table

文件擴充原則

新增狀態或流程時，優先補在：

• 流程/：描述一段流程對 quote_bids 的影響；完整 business flow 放在 業務流程。
• 欄位/：描述單一欄位的意義、可被哪些流程修改、如何驗證。
• 案例/：放實測資料、curl、SQL、response。

不要把所有細節塞進同一篇，否則後續會很難維護。