等候名單入口網站是做什麼的？

使用此技能將「我們需要一個等候名單」轉化為誠實的產品承諾、適當的系統邊界以及可建構的交付計劃。感興趣的人員列表、公平的服務順序、流量閘門和預約是不同的東西。永遠不要讓精美的登陸頁面默默地決定語義。

何時載入

當使用者正在設計、審查、實作或比較用於早期存取、產品發布需求、稀缺商品、預約、會員資格、活動、Beta計劃或高流量入場的入口網站時，請載入此技能。

何時不該使用

僅針對文案、視覺設計、SEO或無障礙性，請使用相關的前端或內容技能，並僅在涉及列表行為時引入此技能。
針對一般API、資料庫、電子郵件、安全性或支付實作，請使用對應的專家技能；此技能僅提供等候名單特有的合約和故障模式。
針對即時等候室供應商或佇列資料儲存，請閱讀其目前的官方文件。此技能是一種設計方法，不能替代供應商操作手冊或法律建議。
針對獨立的CRM遷移或電子郵件/SMS行銷活動，請使用對應的整合技能。僅當CRM是等候名單驗證聯絡人生命週期的下游時，才載入此技能。

核心工作流程

預設姿態與行銷人員體驗

對於新的行銷等候名單，請使用一個靜態HTML頁面、Alpine.js（CSP建置）、Vite打包、自訂CSS、基於Vercel Node.js執行環境的TypeScript API函式，以及受管理的Neon Postgres。使用Twilio Verify驗證碼進行電子郵件（搭配SendGrid）和可選的SMS驗證；透過伺服器端執行階段設定使CRM可選擇。避免使用Python後端和Rails。Go或Rust則是在既有託管或需求允許的情況下，作為明確的替代方案。這些是預設值，而非替換現有正常整合的理由。

在開始建置或部署前，請先閱讀 references/default-stack.md。它定義了供應商姿態、Vercel限制、儲存庫形狀、工作者執行和逃脫機制。對於所有新的入口網站，請閱讀 references/brand-and-marketer-workflow.md：收集行銷活動簡報、品牌指南、標誌、參考圖片和可選影片；在連接正式環境之前顯示品牌預覽。使用 templates/campaign-brief.md 作為白話的輸入範本。代理程式會填寫技術記錄；請不要要求行銷人員選擇ORM、框架、重試演算法或資料庫架構。對於高級、電影式、動態豐富或參考主導的行銷活動，也請閱讀 references/engagement-and-visual-system.md 並記錄其相關的體驗簡報、備援、效能和視覺測試決策。將參考網站視為可觀察互動原則的來源，而非複製其品牌、資產、原始碼、版面、稀缺性語言或產品聲稱的許可。對於行銷活動的主視覺、產品場景和編輯插圖，請使用經核准的提供資產或原創圖片生成藝術品。在發佈前預覽生成的藝術品以獲得核准。除非使用者明確要求此類美學，否則請勿使用CSS形狀或漸層、內聯SVG繪圖、Canvas草圖、表情符號、ASCII或圖示拼貼來替代行銷活動藝術品。當幾何圖形本身就是資訊時，例如圖表、圖解、控制項和狀態指示器，程式化圖形仍然是合適的。使用 templates/campaign-config.example.json 作為伺服器端設定範例；其未設定的正式環境選擇必須在啟用即時發送前解決。

預設行銷活動：需要電子郵件確認的電子郵件興趣收集，關閉電話收集，關閉推薦，不顯示排名，不暗示預約，CRM等待連接。如果在未指定互動的情況下啟用SMS，則偏好受管理的OTP。明確的SMS魔法連結需求會覆蓋此預設值；請保留它並解釋提供者能力的限制。

此技能在實作入口網站時可以建立部署和發送訊息。在執行前請確認目標、範圍和回滾路徑。唯讀探索可以無需確認地進行。使用既有的授權（如果已涵蓋這些細節）；首先準備本地工件和預覽。絕不要將模擬表單描述為收集真實註冊資訊。

1. 在選擇技術之前先寫下承諾

用白話回答以下問題：

加入意味著什麼：興趣、排隊位置、邀請資格、抽籤機會，還是服務時段請求？
如果有任何保證，那是什麼？明確說明加入並不等於保留庫存、付款優先權、預約或入場，除非有單獨的已確認動作這樣做。
什麼事件會推動人員前進：驗證、容量、預定發佈、取消、分數、推薦、抽籤，還是營運者決定？
哪些聯絡證明是可選的、必需的或不存在？已驗證的電子郵件或電話實際上授權了什麼、多長時間，以及當邀請過期、人員取消訂閱或重複出現時會發生什麼？
在發佈時必須滿足什麼條件：峰值到達數、可接受的損失、公平規則、地區、可及性、語言、資料駐留、整合和回滾路徑？

將假設記錄為假設。當營運者可能根據細分或適合度進行選擇時，請勿使用「當前位置」；改稱之為興趣列表或估計排名。

2. 選擇一個主要模式

使用能使承諾成真的最小模式。僅在邊界和轉換明確時才組合模式。

模式	記錄系統	良好預設	主要陷阱
興趣列表	關聯式資料表、CRM或ESP	靜態/SSR頁面加上伺服器端表單端點和非同步電子郵件	這不是佇列；不要顯示虛構的位置
已驗證早期存取佇列	資料庫加上事件/發件匣記錄	獨特計畫 + 正規化聯絡人，適當時雙重選擇加入，邀請狀態	已驗證的電子郵件並非人員或購買的證明
推薦優先權	資料庫事件分類帳	不可變的到達金鑰加上已驗證的推薦事件和版本化政策	自我推薦、購買流量和「病毒式」聲稱可能會破壞公平性
虛擬等候室	邊緣/閘道加上持久佇列	已簽署的入場令牌、Cookie持續性、原子入場、有界輪詢	入場到頁面並非庫存授權或結帳序列化
預約填補	排程/容量服務	將人員與已釋出的時段、偏好和到期視窗匹配	全域FIFO佇列可能不公平或操作上無用
配額、抽籤或預購	庫存/支付/分配服務	分離資格與配額、預約、支付和履行	將配額稱為「等候名單」會隱藏超賣和退款義務
無頭/嵌入式API	獨立API和事件邊界	具有範圍憑證、CORS、冪等性和Webhook的公開寫入合約	瀏覽器持有的祕密並非伺服器祕密

對於簡單的預啟動頁面，請從興趣列表模式開始。對於發佈日的流量高峰，請從虛擬等候室或邊緣產品開始。對於稀缺資源是真正問題的產品或服務，請先設計庫存或排程邊界，然後將列表附加到其上。

在比較模式、建模規模或決定是否需要佇列、推薦迴圈、預約或供應商時，請載入 references/architecture-patterns.md。

3. 定義狀態機和資料合約

在實作時，請閱讀 references/implementation-contract.md 以了解具體的端點、持久性、驗證、CRM和故障合約。

使用不透明ID，並將聯絡資料排除在URL、日誌、分析標籤和公開排名頁面之外。一個有用的基準是：

已提交 -> 驗證待處理 -> 活躍 -> 已邀請 -> 已領取
                                  \-> 已抑制/已移除
已邀請 -> 已過期

對於等候室，使用單獨的佇列/入場狀態：

已識別 -> 已排隊 -> 已入場 -> 已消耗
                     \-> 已放棄/已過期

如果入口網站驗證聯絡人，請獨立建模每個管道，而不是使用一個過載的 verified 標誌：

電子郵件：未請求 -> 已發送 -> 已點擊/已驗證 | 已過期/已撤銷
電話：未請求 -> 已發送 -> 已點擊/已驗證 | 已過期/已撤銷

「已驗證」意味著在指定的方法和時間戳記下，管道的證明已被接受。它不證明法律身份、提供的人員擁有該帳戶、該號碼適用於行銷，或該聯絡人將保持準確。當涉及聯絡證明或CRM交付時，請載入 references/contact-verification-and-crm.md。

對於每個轉換，定義參與者、前置條件、副作用、重試行為、審計事件和對使用者可見的訊息。至少儲存：

program_id、不透明的 entry_id、created_at 和穩定的打破平局金鑰；
已正規化聯絡人的唯一性，附帶記錄的正規化版本和受保護的原始資料；如果引入金鑰查詢雜湊，請規劃金鑰輪換；
同意目的、來源/UTM歸因、驗證和抑制時間；
明確狀態、政策/版本識別碼、邀請/領取到期時間，以及僅用於選擇或服務匹配所需的屬性；
推薦代碼所有權和推薦事件（如果啟用）；切勿從可變的用戶端狀態推斷計數；
每個管道的驗證方法、證明ID、verified_at、到期/撤銷以及同意目的；請勿儲存原始令牌；
CRM同步狀態、對應/版本、提供者記錄ID、冪等性金鑰和最後錯誤；將其保留為整合狀態，而非等候名單的真實來源；
僅附加的審計/事件記錄，用於狀態變更和對外影響。

使用冪等性金鑰或資料庫唯一性約束，使 POST 可以安全地重試。有目的地定義重複行為：對於已知的聯絡人，通常返回通用成功，以使端點不成為電子郵件列舉預言機。除非排序和可見性規則使該聲明為真，否則不要將原始行數公開為個人位置。

4. 建構正常請求路徑

預設路徑是：

頁面 -> 伺服器端點 -> 驗證/正規化 -> 濫用閘門 -> 持久寫入
     -> 排入通知佇列 -> 通用回應
                                      \-> 工作者/提供者 -> 交付事件

在伺服器端進行驗證。應用分層控制：結構描述和長度限制、同源表單的CSRF保護、無頭用戶端的嚴格CORS、每個IP和每個聯絡人的速率限制、蜜罐或時間訊號，以及針對高風險流量的機器人挑戰。如果使用Turnstile，伺服器必須呼叫Siteverify；僅憑瀏覽器令牌是不夠的。在針對所選提供者和故障模式進行測量之前，請勿承諾特定的延遲時間，例如「低於200毫秒」。

交易性地或透過持久發件匣寫入條目和通知意圖。使工作者可重試，並使對外Webhook具有冪等性。保持同步回應簡短，但不要在提供者不可用時默默地丟失電子郵件意圖。

當清單品質、同意證明或打字錯誤抵抗力很重要時，請使用雙重選擇加入；明確說明未驗證記錄的權限和保留期限。將交易性的驗證/邀請郵件與行銷更新分開，尊重抑制和取消訂閱狀態，驗證發送網域，並處理退信和投訴。請載入 references/operations-and-abuse.md 以了解詳細的控制檢查清單。

如果啟用了CRM交付，請僅在設定的資格閘門之後才將其排入佇列——通常是活躍的聯絡驗證和相關的同意。僅對應已核准的欄位，使用伺服器端憑證，並使適配器可重試且具有冪等性。CRM故障不得阻止確認持久的本地註冊，也不得默默地丟失本地記錄；它應留下可見的同步狀態和可恢復的發件匣項目。

5. 使排名和入場誠實

對於FIFO，在持久的原子操作中僅分配一次到達/打破平局金鑰。對於細分、評分、推薦或抽籤，請發佈選擇規則、輸入、政策版本以及結果是保證、估計還是自由裁量的。從持久的事實重新計算衍生排名；不要讓用戶端提交 referrals_count、position 或 priority。

對於推薦疊加：

產生不可猜測、可撤銷的代碼，並將其視為歸因令牌，而非授權；
僅在所需的驗證和去重視窗之後計算符合資格的下游條目；記錄點擊和轉換；
防止自我推薦和明顯的自動化，限制影響，並保留原始佇列金鑰，以便可以更改或移除政策；
顯示明確的好處，並在競爭事件可能改變排名時顯示範圍/估計。在將商業獎勵與轉發或推薦掛鉤之前，請取得法律和政策審查。

對於虛擬等候室，請在可能的情況下使用本地驗證的簽署入場令牌、Cookie/會話持續性、原子佇列轉換、抖動輪詢，以及深思熟慮的故障開放與故障關閉決策。故障開放可能會保護行銷預覽的可用性；但作為稀缺庫存的唯一控制手段是不安全的。下游的預約、結帳或分配服務仍需其自身的冪等性和並發控制。

6. 設計使用者和營運者介面

公開流程應說明加入意味著什麼（見步驟1），在沒有允許的情況下不得承諾排名、時間或結果，並…

等候名單入口網站