應徵紀錄（My Applications）Mockup PRD（給後端 API 規格產生器使用）

此範本專門給 gen-storybook-mockup-gen 產出的 mockup PRD 使用。 backend-api-spec-generator 會讀取這份文件與 Storybook mockups 來產生後端 API 規格。 產出 persona：CEO with PM Background（SaaS / HR tech lens）。

1. 文件資訊

• 文件類型：Mockup 需求規格書（前後端共用視圖）
• 適用對象：前端開發、後端開發、產品、QA
• 最後更新：2026/07/16
• 版本：1.3.0
• 變更摘要（v1.3.0）：納入求職信 deep link（跳轉 /user/message-notification?room=）；新增 §2.1 實作狀態、§12.5 Delta 增量清單；站內信完整整合仍 out / v1.1+
• 對應 Storybook：storybook/src/stories/mockups/user/ApplicationRecords.stories.ts（已產出）
• Storybook 連結：https://storybook.wport.me/?path=/docs/mockups-user-applicationrecords—docs
• 建立日期：2026/06/23
• Coda backlog：應徵紀錄
• AI / codegen 指引：本文件為累積規格。v1.0–v1.2 已上線（§2.1）；僅實作 §12.5 v1.3 Delta。勿重產 v1 既有 API；HINT-GET-1 僅擴充 enc_room_id、application_message 欄位。

2. 開發進度與設計來源

開發進度

• 前端 PR #：[TBD]
• 後端 PR #：[TBD]

設計來源

• Figma 連結：[待補上]
• Pixsole / 既有畫面：求職者既有「會員中心」C 端框架（沿用 user app 樣式 profile；見實作備註）

2.1 實作狀態（2026/07/16）

閱讀指引：v1 已交付部分勿重複實作。AI、RD、FE 請以 §12.5 v1.3 增量清單 為工作範圍；完整語意規格仍見各章，但 codegen 僅產出 Delta。

3. 模擬頁面摘要（Mockup Summary）

3.1 功能概述

• 功能名稱：應徵紀錄（My Applications）
• 主要使用者角色：Job Seeker（求職者，含僑外生 / 外籍）
• 核心目標：
  • 讓求職者在單一頁面掌握「我投過哪些職缺、能不能再投、下次可投時間」。
  • 降低投遞後焦慮與重複投遞無效操作，提升投遞後 7 日回訪與再次應徵品質。
  • 與 BR-011 的 72 小時再投冷卻一致地呈現「下次可投時間」。

3.2 範圍界定

• 包含範圍（v1.0–v1.2，已上線）：
  • 應徵清單（同職缺多次合併一列；顯示公司、職缺、最近應徵日、已投 N 次）。
  • 「再次應徵」按鈕（冷卻中 disabled 並倒數；見 BR-011）。
  • 職缺已關閉 / 已刪除：卡片灰階、職缺連結停用、顯示「此職缺已關閉」boundary（見 BR-009）。
  • 求職信區塊靜態顯示（application_message 摘要；不含點擊跳轉）。
• 包含範圍（v1.3 增量，待做）：
  • 求職信區塊可點擊，deep link 跳轉至訊息通知頁並開啟對應對話（§9.1、§12.5）。
• 排除範圍（v1 不做，Storybook 可展示完整願景）：
  • 狀態 badge 與狀態篩選 tab（全部 / 審閱中 / 面試邀約 / 婉拒）→ v2（待 HR 流程）。
  • 面試邀約 / 婉拒狀態（HR 端流程尚未實作）→ v2。
  • pm_44 封鎖公司互動（再投隱藏 / is_blocked_by_me）→ v2（pm_44 上線後）。
  • 完整多次應徵時間軸（逐次列出）→ v2；v1 僅顯示最近應徵日與 apply_count。
  • 站內信完整整合（頁內嵌對話、未讀即時、最新訊息摘要）→ v1.1+ / 另案；v1.3 僅求職信入口 deep link 跳轉（§9.1）。
  • 卡片顯示「最新一則訊息 + 發送者」→ v1.1（靜態 API 摘要，非 WebSocket 即時）。
  • 應徵附加問卷的填寫流程（Coda：投遞附加問卷，另案）。
  • 履歷編輯（另案 edit-resume）。

3.3 成功條件

• 求職者能在 1 頁看到全部應徵紀錄，且冷卻中職缺明確顯示「下次可投時間」。
• 已關閉 / 已刪除職缺以灰階呈現，不會破圖或死連結，顯示「此職缺已關閉」。
• 應徵後 7 日回訪率、再次應徵轉換率可被埋點量測。

3.4 背景與決策（v1.3.0 Deep Link）

前因（Why now）

• 應徵紀錄卡片右側顯示求職信（application_message 靜態快照），使用者投遞後常需繼續與 HR 對話，但目前無法從此入口一鍵進入對話。
• 訊息通知頁（/user/message-notification）已有 chat 模組與 GET /api/chat/rooms；後端 job_applications.chat_room_id 與 chat list 的 enc_room_id 為同一 id（一求職者 × 一職缺 = 一 room）。
• pm-32 email/push deep link 已確立「以 enc_room_id 開啟對話」模式；應徵紀錄頁需對齊同一契約，避免各頁各做一套。

後果（What changes）

• v1.3 納入：求職信區塊可點擊 → 跳轉 /user/message-notification?room={enc_room_id}。
• v1.3 仍排除：應徵紀錄頁內嵌對話 UI、WebSocket 即時更新、卡片最新訊息摘要（→ v1.1 backlog）。
• 後端依賴：pm_42 清單 API（HINT-GET-1）每列須回傳 enc_room_id（來源 job_applications.chat_room_id）；不需新 chat API。
• 前端依賴：訊息通知頁須支援讀取 ?room= query 並自動開啟對話（若尚未實作，列為聯動項）。

4. 商業規則對齊（Business Rules Alignment）

4.1 本功能使用到的業務規則

4.2 補充說明

• 本功能不新增 business rule，僅在 UI 層忠實呈現 BR-011/BR-009。
• 與 pm_44（封鎖公司）互動：v2；v1 不實作封鎖相關 boundary 與 is_blocked_by_me。

5. 資料實體與欄位（Data Entities & Fields）

描述「需要追蹤什麼資料、為什麼」，不規定 API 欄位命名 / 雜湊 / DB schema（由 OpenAPI Spec 決定）。

5.1 實體列表

5.2 實體欄位定義（TypeScript 介面，語意用途；命名待與 Storybook 對齊）

// v1 清單所需欄位（語意用途；命名由 OpenAPI Spec 決定）
interface ApplicationRecord {
  enc_id: string;
  job: JobSnapshot;
  company: CompanySnapshot;
  applied_at: string;             // ISO8601 最近應徵時間
  resume_enc_id: string;
  apply_count: number;            // 同職缺累計有效應徵次數（≥1）
  reapply: ReapplyEligibility;
  enc_room_id: string;            // 對應 job_applications.chat_room_id；供 deep link（與 GET /api/chat/rooms 的 enc_room_id 相同）
  application_message?: string;   // 求職信摘要（投遞時快照，靜態顯示）
  // v2 再納入：
  // status_code: ApplicationStatus;
  // status_name: string;
}

// v2：HR 處理狀態 + tab 篩選（全部 / 審閱中 / 面試邀約 / 婉拒）
type ApplicationStatus =
  | 'submitted'
  | 'reviewing'
  | 'invited'
  | 'rejected';
// 註（Eric 2026/06/24）：冷卻不是 status enum，由 reapply.cooldown_until 驅動按鈕倒數。
// 註（Eric 2026/07/03）：v1 不顯示狀態 badge / tab；Storybook mock 可保留完整願景供設計參考。

interface JobSnapshot {
  enc_id: string;
  title: string;
  lifecycle_code: 'published' | 'unpublished' | 'closed' | 'deleted'; // 對齊 BR-009
  area_name?: string;
}

interface CompanySnapshot {
  enc_id: string;
  name: string;
  logo_url?: string;
  // is_blocked_by_me: boolean;  // v2 + pm_44
}

interface ReapplyEligibility {
  can_reapply: boolean;
  cooldown_until?: string;        // ISO8601；冷卻中時提供，供按鈕倒數
  reason_code?: 'cooldown' | 'job_closed' | 'job_deleted'; // v2 再加 company_blocked
}

6. 畫面區塊與資料需求（UI Sections & Data Needs）

6.1 區塊列表

6.2 各區塊資料需求

SEC-1 應徵清單

• 顯示實體：ApplicationRecord[]
• 資料需求：分頁（page, page_size）、排序（預設 applied_at desc）
• 顯示規則：同職缺多次應徵合併為一列（已投 N 次），時間顯示最近應徵日
• 職缺終態（closed / deleted）：整卡灰階（opacity 降低或灰階濾鏡）；職缺標題連結停用；顯示 boundary「此職缺已關閉」；隱藏「再次應徵」
• 空狀態：顯示「你還沒有應徵任何職缺」＋「去找工作」CTA
• 求職信區塊（v1.3）：
  • 顯示 application_message 摘要（truncate，例如 3 行）。
  • 整區可點擊；cursor/hover 提示「查看對話」。
  • 點擊 → router.push('/user/message-notification?room=' + enc_room_id)（§9.1）。
  • 求職信內容不即時更新；對話內容以訊息通知頁為準。

SEC-2 狀態篩選列（v2）

• v2 實作 tab + 狀態 badge（全部 / 審閱中 / 面試邀約 / 婉拒）。
• Storybook mock 可保留完整 tab 作為設計願景；production v1 不實作。

SEC-3 單筆詳情

• 內容（v1）：職缺標題（非終態可連結職缺頁）、公司、最近應徵日、apply_count、再次應徵 按鈕
• 內容（v2）：狀態 badge、完整多次應徵時間軸、pm_44 封鎖 boundary
• 職缺終態：同 SEC-1 灰階 +「此職缺已關閉」、停用連結、隱藏再投
• 「再次應徵」按鈕的三態：
  • 可投：enabled，文案「再次應徵」→ 導投遞流程。
  • 冷卻中（BR-011）：disabled，按鈕本身顯示倒數計時（剩 <1 天用 HH:MM:SS，≥1 天用「N 天 H 時後可再投」）；hover/title 顯示「下次可投：{cooldown_until}」；到期自動恢復可投。
  • 終態（BR-009）：隱藏按鈕，灰階 + boundary「此職缺已關閉」。
• 倒數來源：前端依後端 reapply.cooldown_until 換算並每秒 tick，避免時鐘漂移（§12）。

7. 使用者動作與後端需求（User Actions & Backend Needs）

8. API Hints（提示用，非最終 API 設計）

8.1 資料讀取需求（Read）

• HINT-GET-1：取得我的應徵清單（分頁 + 排序）→ SEC-1；語意見 §5.2、§12.4 欄位映射（實作由 backend-api-spec-generator 產出）

8.2 資料寫入需求（Write）

• HINT-MUTATION-1：再次應徵 → 沿用既有 apply 端點語意（job_enc_id, resume_enc_id）；須能讓 UI 呈現 BR-011 冷卻（清單/詳情之 reapply.cooldown_until）。

9. 導航 / Storybook Map

• Storybook 標題：Mockups/求職者/應徵紀錄
• Stories 路徑：storybook/src/stories/mockups/user/ApplicationRecords.stories.ts
• Storybook 連結：https://storybook.wport.me/?path=/docs/mockups-user-applicationrecords—docs
• 情境控制（實際 args）：scenario（empty / mixed / has-cooldown / job-closed）——封鎖情境併入 mixed，無獨立 company-blocked（對齊實際 Storybook）
• Storybook 與 v1 關係：Storybook 為完整願景 mock（含 tab、四種狀態）；production v1 範圍以 §3.2、§12.2 為準，兩者並存不視為 PRD 不一致。
• 對應 production 路由：求職者會員中心下（僅參考，不在此新增路由）

9.1 求職信 Deep Link（v1.3.0）

10. Flowcharts

10.1 User Flow

flowchart TD
    U1[登入後進入會員中心] --> U2[開啟應徵紀錄]
    U2 --> U3{有應徵紀錄?}
    U3 -- 否 --> U4[空狀態 + 去找工作 CTA]
    U3 -- 是 --> U5[顯示清單 + 最近應徵日]
    U5 --> U6[點求職信]
    U6 --> U12[跳轉 message-notification?room=]
    U12 --> U13[自動開啟對話]
    U5 --> U7[開啟單筆詳情]
    U7 --> U8{職缺狀態 / 冷卻?}
    U8 -- 可再投 --> U9[再次應徵 -> 投遞流程]
    U8 -- 冷卻中 --> U10[再次應徵按鈕 disabled + 倒數計時]
    U8 -- 已關閉/已刪除 --> U11[灰階 + 此職缺已關閉, 停用連結]

10.2 System Flow

sequenceDiagram
    participant User
    participant FE as Frontend
    participant BE as Backend
    User->>FE: 開啟應徵紀錄
    FE->>BE: GET 應徵清單(page)
    BE-->>FE: ApplicationRecord[] (含 reapply/cooldown)
    FE-->>User: 渲染清單
    User->>FE: 點「再次應徵」
    FE->>BE: POST 再次應徵(job,resume)
    BE->>BE: 檢核 BR-011 冷卻 + BR-009 狀態
    alt 通過
        BE-->>FE: 成功
        FE-->>User: 導投遞流程/成功提示
    else 冷卻中或終態
        BE-->>FE: 業務錯誤或 reapply 欄位
        FE-->>User: 顯示原因與下次可投時間
    end

10.4 Edge Case Coverage

11. Mock Data Schema

• 資料來源：僅 mock，不呼叫真實 API。
• 願景 vs v1：mock 可含 tab 與四種狀態（完整願景）；v1 production 範圍見 §3.2。

12. 實作備註（Implementation Notes）

• 禁止事項：❌ 不在此定義最終 API path/method；❌ 不直接改 business-rules.md。
• 注意事項：
  • 欄位命名與 Storybook/TS interface 一致。
  • C 端頁面 → 走 user CSS profile（見 gen-storybook-mockup-gen 的 Dual CSS Profile Contract）。
  • 冷卻倒數以後端 cooldown_until 為準，前端僅做顯示換算，避免時鐘漂移。

12.1 四致性表（Stage 6）

欄位對照表

常數表

事件字典

術語字典

12.2 版本凍結表

12.3 PRD 問題清單

12.4 後端參考備忘（W101-TalentSearchHub）

性質：供 RD / backend-api-spec-generator 參考，非 PRD 缺陷清單。PRD 已標「需要後端」之處，由後端依本節產 API。
SoT repo：W101-TalentSearchHub（C 端應徵）；W101-AMS 非本功能實作主體。
稽核日期：2026/07/03。

可沿用

RD 實作 backlog（不計入 PRD P0）

欄位映射草案（清單 API）

12.5 v1.3 增量清單（Delta — 僅此需新增）

v1.0–v1.2 已上線（§2.1）。本節為 patch 工作範圍；AI / backend-api-spec-generator 請以此為準，勿重產 v1 全量 spec。

實作優先序：D1 → D4 → D3 → D2（D2 可與 D3 並行，視卡片是否已顯示求職信）→ D5。

13. 下一步（Next Steps）

• v1.3（本 patch）：依 §12.5 Delta 執行；BE 擴充 HINT-GET-1 欄位，勿新建 v1 清單 API。
• 送 RD：backend-api-spec-generator 依 §12.5 + §12.4 產增量 spec（enc_room_id、application_message）。
• 前端 v1.3（應徵紀錄）：求職信可點 + 帶 enc_room_id 跳轉訊息通知頁（§9.1、D3）。
• 前端 v1.3（訊息通知頁，聯動）：支援 ?room= 自動開窗（D4）。
• v1.1 backlog：卡片最新訊息摘要欄位。
• v2 backlog：狀態 tab、HR 狀態機 PRD、pm_44、完整時間軸、狀態變更通知。
• 補 i18n key（冷卻提示、「此職缺已關閉」、「查看對話」、「找不到對話」）。
• Storybook mock 更新（非 blocking）：求職信可點擊樣式。
• Coda：回寫 應徵紀錄 列 PRD 欄＝pm_42。

14. 待補與決策事項（RD 規格前審查，2026/07/06）

RD 在產出後端 API 規格前，對本 PRD 做了一輪完整性審查。§14.1 PM 裁決已於 2026/07/06 回覆；§14.2 為 RD 自行決定僅知會。Storybook 仍可展示完整願景（§9），production v1 以 §3.2 為準。

14.1 PM 裁決（已定案，Eric 2026/07/06）

以下回覆 RD 審查時提出的五項；多數與 §3.2、§12.2、§12.3 既有裁決一致，此處正式收斂以免重複提問。

A. v1 應徵狀態 / tab（原：狀態流轉未定義）

• 裁決：v1 不實作應徵狀態機、清單 API 不暴露 status_code / status_name、不做 tab / badge。
• 頁面語意：全部應徵紀錄（flat list）；求職者看到的就是「我投過哪些職缺」。
• v2：reviewing / invited / rejected 連同狀態流轉定義 → 另開 HR 流程 PRD，不在本案 v1 scope。
• 依據：§3.2 L49-51、§12.2 L320、§12.3 #2。
• Storybook 提醒：mixed 情境的狀態卡為靜態願景 mock，≠ production v1 行為。

C2. SEC-3 單筆詳情 / 多次應徵時間軸

• 裁決：完整多次應徵時間軸 → v2；v1 清單列已含最近應徵日 + apply_count（§6.2 SEC-3、§3.2 L53）。
• 詳情抽屜：v1 可選、不 blocking（ACT-3：清單欄位已足夠）；不強制補 mockup。
• RD 審查備註：§14.1 原引用「§6.1 SEC-3 描述時間軸」與現行正文不符——§6.2 已明確分列 v1 / v2 內容，時間軸從未列入 v1。

B1. 狀態變更後要不要通知求職者？

• 裁決：v1 無狀態變化 → 不做狀態變更通知（信件 / 推播皆不含）。
• v2：待 HR 流程與狀態上線後，若需通知 → 另案（不擴本案 scope）。
• 依據：§3.2 L54（站內信已排除）；狀態單純是紀錄，沒有狀態變化就不需要通知。

D1. 要不要有「已投遞」篩選 tab？

• 裁決：不需要。
• v1：無 tab，不適用。
• v2：若未來做 tab，不需獨立「已投遞」tab——頁面即應徵紀錄，有紀錄即代表已投遞，「全部」已涵蓋。

B3. pm_44（封鎖公司）與本案的上線先後？

• 裁決：pm_42 先上線；pm_44 封鎖互動 v2 接上。
• 技術：RD graceful degrade 維持 §14.2 既定（is_blocked_by_me 當 false、不顯示封鎖 boundary）。
• 依據：§3.2 L52、§12.2 L321。

14.2 RD 自行決定（知會，不需 PM 回覆）

以下屬顯示規則 / 技術契約 / 文件對齊，RD 於 spec 階段自行定案並記錄於此，PM 無需處理：

• B2 合併列顯示哪一次狀態（v2）：v1 清單不含 status，本項不適用；待 v2 狀態上線時 RD 定：合併列顯示最新一次應徵的狀態，與時間一致。
• D2「再次應徵」端點語意（資格檢查 vs 完整投遞）：§8.2 與 §10 流程圖描述不一。RD 定：於 spec 階段對齊既有投遞流程實作決定，不另擴新語意。
• C1 Storybook 情境與命名不一致：§9 / §11 列 5 情境（含獨立 company-blocked），實際只有 4 個（mixed / has-cooldown / job-closed / empty）且命名為 mixed（非 mixed-status）。RD 定：以實際 Storybook 為準，回頭對齊 §9 / §11 文字與命名。
• D1-技術面 status 參數合法值：RD 定：v1 清單 API 不含 status 參數；v2 若實作 tab 篩選，status query 收 §5.2 四個 enum 值，不需獨立「已投遞」tab（§14.1 D1 已定）。
• B3-技術面 pm_44 fallback：RD 定：pm_44 未上線時 graceful degrade（is_blocked_by_me 當 false、不顯示封鎖 boundary）。

一句話總結：v1 可開工——清單 API + 冷卻（BR-011）+ 終態（BR-009）；狀態/tab/通知/封鎖/時間軸均不 blocking。§14.1 五項 PM 裁決已定案；§14.2 僅知會。

文件結束