需求冻结1 周
发起方与参与方联合下单，以达到单独下单无法获得的低价。
本 Portal 集中呈现 Anchor / Joiner / 管理员三类角色的完整流程，便于整体浏览与确认。
| 周 / 日期 | 当周核心内容 |
|---|---|
| W14/22 周二 | 原型内部走查 → 客户评审 1 轮（4/24）→ OQ 清单整理 |
| W24/27 周一 | 4/28 需求冻结节点 ★ 同日 UI 启动 · 开发基盘先行（ER 图 / migration / API 契约） |
| W35/4 周一 | UI W2：核心 4 画面高保真 开发 W1：Anchor 流程 |
| W45/11 周一 | UI W3：其余 5 画面 开发 W2：Joiner 流程 |
| W55/18 周一 | UI W4：Admin + 5/22 UI 冻结 开发 W3：Admin 流程 QA：用例设计开始 |
| W65/25 周一 | UI W5：polish / 设计 QA 开发 W4：横串 + 高保真 UI 集成 QA：分段测试启动 |
| W76/1 周一 | 全体 E2E 测试 UAT 启动：Anchor 流程（6/1-6/3）/ Joiner 流程（6/4-6/5） |
| W86/8 周一 | UAT：Admin 流程（6/8-6/10）+ 回归（6/11-6/12） Critical bug 修复 |
| W96/15 周一 | ★ 6/15 本番部署 内测启动（限定 3-5 社，Hypercare 体制） |
| W106/22 周一 | 内测持续 实邮件 / 支付流程最终验证 公开前 go / no-go 判断（6/26） |
| W116/29 周一 | ★★ 7/1 周三 一般公开 随后 2 周 Hypercare 延续 → 7/13 转入常规运维 |
| 角色 | 人数 | 投入期间 | 工作内容 |
|---|---|---|---|
| PM（乙方） | 1 | 全周期 | 项目推进、客户对接、风险监控 |
| 设计师 | 1 | 4/28 – 5/29（5 周） | UI 高保真化、设计 token、画面交付、设计 QA |
| BE 工程师（Rails） | 2 | 5/1 – 6/12 | Model / 状态机 / API / Mailer / Admin API |
| FE 工程师（Next.js） | 2 | 5/1 – 6/12 | 13 画面实装、高保真 UI 集成、API 连接 |
| QA | 1 | 5/18 – 6/12 | 用例设计、执行、bug triage |
| Infra（部署 / 监控） | 0.5 | 6/10 – 6/20 | Kamal 配置、监控告警、dry-run |
| 客户 PO | 1 | 全周期 | 决策、UI Review、UAT 统筹（周 6h+） |
沿生命周期 5 个阶段，展示 3 角色各自的关键动作与协作点。橙色高亮 = 状态机关键转换点。
complete_public_procedure!title / 数量 / 目標 / 一言)；其他 spec 自 published_at 起 lockrecruitment_ends_at までキャンセル可 (OQ-19)contract_pending → published、published_at = now。同一遷移内で発生（D1 で first_contracted_at 列削除済み）。
recruitment_ends_at 到達 → cron job → finalize! 自動推進。残 draft Participation → applied。anchor-only 成団も許容 (OQ-28)。
orders は通常注文一覧から非表示（OQ-20 方案 C2）。
| 内部状态 | UI 显示 | Anchor Tab | 管理员 Tab |
|---|---|---|---|
pending_review | 规格确认中 | 公开前 | 公开前 |
contract_pending | 契约① 待签 | 公开前 | 公开前 |
published | 招募中 | 招募中 | 招募中 |
ordered | 制造准备 | 制造准备 | 制造准备 |
rejected / cancelled | 已取消 | 已取消 | 已取消 |
5 个主状态 + 3 个 terminal 状态、关键转换事件、guard 与触发源（cron · admin · anchor）。
"招募中" tab 就展示支付状态和确定单价，还是只在"制造准备"及以后的 tab 显示？招募中单价尚未确定，是否有展示的意义？
募集中 状态下不显示支払 / 契約 / 確定単価 这 3 列。这些列只在 製造準備 起的 tab 才有意义（成団 / Order 生成后单价和合同状态才存在）。当前 UI 行为已与此一致。AI 文案生成、热门尺寸排行、3D 预览、内部立项书 PDF 输出 —— 这些是 v1（7/1 必达）还是 v1.1（7 月中旬以后）？
成团后为每个参与方生成的订单，是 "=通常订单"（方案 A · 统一）、"≠通常订单"（方案 B · 隔离）、还是 "=通常订单 + 共同注文由来标记"（方案 C · 混合）？影响：(a) 普通注文一览是否显示这些订单；(b) 发票 / 物流 / 文件系统是否复用既存 Brixa 功能；(c) 两个入口（マイ案件 / 通常注文）的数据一致性。
orders，打上 source='group_order' + group_order_participation_id，默认从通常注文一览隐藏。发票 / 物流 / 文件复用既存 Brixa 基础设施。管理员审核前，Anchor 是否可以编辑或取消自己的项目？Sheet 规格说允许，但 Canva 原型的弹窗说"发起后不可取消"，文字存在矛盾。
pending_review（仕様確認中）阶段 Anchor 可以编辑和取消自己的提案。Canva 原型 "発起後不可取消" 的提示以客户答复为准 ignore。强化（05-11）：审查段阶 Admin 也可以直接编辑 spec 全项目后 approve，与 Anchor 并行可编辑（race condition 用 last-writer-wins + group_order_edit_histories audit log 处理）。Admin 编辑过的项目在 contract① 同意画面 Anchor 最终确认，确保 Anchor 不会被无知地变更混入。Anchor 发案表单（§2 袋仕様 / §3 素材構成 / §4 形状加工）目前按 brixa-fe 的通常注文画面 全量沿用：袋タイプ 9 种 / 素材構成 8 种 / 加工选项 9 种 + 特殊印刷 / 角加工 / ノッチ / チャック / SKU 数 / 内容物 / 全面印刷有無 / シール幅 / バリア。
共同注文是否也需要同一套 full set？还是精简为常用子集以降低发案门槛？
group_order context）。袋タイプ / 素材構成 沿用通常的选项集。特殊印刷 / 特别印刷只允许 UV / 箔印刷，其他选项在 UI 隐藏 + 后端拒收。全面印刷有無 不展示且不接受（payload 须 normalize 为 nil / false）。招募成团后与 Joiner 的单独合约（契约②），是逐个电子签名还是批量方式？何时发送？支付何时跟进？
Anchor 最大 15% OFF / 最低保证 5% OFF 是最终值吗？Joiner 为 0 家时的最低保证触发条件具体是什么？
min_disc = joiner_count == 0 ? 0.05 : 0.15; max_disc = 0.42。Anchor 首次订货 500 个 / Joiner 最小参与 300 个 —— 这两个数值在所有项目类型下都适用，还是按产品类别差异化？
product_type / package_type / 素材的差异化分支。browse 页显示为 "株式会社 J*****"，保留几位？是前 X 个字符 + 星号，还是别的规则？主要用于避免被同行识别。
Anchor / Joiner / Admin 各自场景约 7-8 封邮件的文案，由客户提供最终话术，还是乙方出草案后客户校对？
Canva 原型在每张案件卡上放了「参加する（Joiner View）」+「管理する（Anchor Demo）」2 个按钮。本番环境下是否同时显示？还是按登录用户身份动态切换（自家案件显示"管理"，别家案件显示"参加"）？
Anchor 一个案件对应 2 个详情页：案件管理（运营视角 · 价格梯度 / 参与方 / 削減额）+ 募集情況確認（自家订单视角 · SKU / 纳品先 / 文件）。确认这种双视图设计是否符合实际使用预期？信息边界是否清晰？
anchor/case-detail.html + anchor/participation-detail.html 双页面。Joiner 仮申込后的"取消期限"是否固定为募集截止日前 15 天？还是按产品类别 / 案件规模 / 生产前置时间不同而可配置？超过期限后"金額確定と製造準備に入るためキャンセル不可" —— 这个 15 天窗口是否足够覆盖所有商品的制造前置期？
cancellation_deadline = recruitment_ends_at。不采用 recruitment_ends_at − 15 天 截断。到 recruitment_ends_at 时剩余的 draft participations 自动推进到 applied，之后金額確定 / 製造準備开始，不再允许取消。支持预付款 / 月结 / 发票后付 的哪些组合？各 Joiner 的支付方式是否可以独立设置？
prepayment（先付）：同既存通常订单，配置后参与者上传付款凭证；monthly（月结）：不卡付款凭证，校了后可直接进入生产；invoice_afterpay（请求后払）：若 Brixa 既存正单设置含此项则复用，v1 不做新流程。每个 Anchor / Joiner 参加可独立设置 payment_method。v1 不新建在线收款引擎，仅复用既存付款凭证上传 + 确认。Canva 原型说"发起后仅可编辑：标题 / 数量 / 目标 / 寄语，其他不可改"。数量也能改吗？改后已参与的 Joiner 如何通知？
title / Anchor 自身数量 / target_quantity / joiner_message。数量允许编辑。不给 Joiner 发邮件通知（不 enqueue notification job）。规格 / 制造字段在 published_at 后锁定。所有允许的编辑写入 group_order_edit_histories。支持的文件格式（AI / PDF / PSD）、大小上限（50MB）、印刷色数要求 —— 沿用 Brixa 现有规范？还是共同订单有特殊要求？
A 高保真化 / B 局部重构 / C 完全重设计？
6/15-7/13 Hypercare 故障响应 SLA？
"给 Joiner 的寄语" 和 "内部立项报告" 的 AI 文案 —— 用 Gemini？prompt 由谁设计？生成后人工修改还是直接使用？
① 是否需要此功能？ ② 需要的话：展示位置（项目详情页 / 稿件提交时 / 两者）、数据来源（Brixa 现有 3D 素材库 / 根据稿件动态渲染 / 其他）、展示精度要求？
① 是否需要此功能？ ② 需要的话：展示位置（Anchor 预申请表单 / browse 列表 / 独立的统计页）、统计维度（按产品类别 / 按时间窗口 / 按成团率）、Top N 数量？