Kolable data gap escalation pack - job f76485ea

acceptance-tests.md

E2E Acceptance Tests

A. Data Request Creation

1. Given Kolable order/payment export is missing,
2. When this job completes,
3. Then PLS should have enough artifact evidence to create kolable_data_requests with Wade owner and 24h due.

Expected evidence: people_sync has data_owner=Wade, due date, and required schema.

B. No Repeated Strategy Pack

1. Given previous reconciliation pack exists and no new data file exists,
2. When PLS dispatches the next job,
3. Then it should route to data request / people sync / repo_change, not another generic project_runner pack.

Expected evidence: next job contains either uploaded data, target_repo_url, or explicit blocker.

C. Upload Validation

1. Given Wade uploads CSV/XLSX,
2. When validation runs,
3. Then required columns are checked and missing fields are returned row/file-level.

Expected evidence: schema status is accepted or schema_failed with missing fields.

D. Revenue Recognition Guard

1. Given no accepted import exists,
2. Then Kolable revenue for 5/12-5/21 remains unverified.

Expected evidence: PLS summary does not claim paid revenue totals.

E. Anti-Fake PR / Deployment

No GitHub PR or deployment may be claimed unless a verified repo/deployment URL exists.

Current Verification

• Primary Gist returns HTTP 200.
• Gist includes HTML control, production brief, data model, acceptance tests, decision record, learning memory, sources, and artifact URL/PR note.
• PLS upload-files reports all files uploaded.

artifact-url-or-pr.md

Artifact URL / PR Status

Primary artifact URL: https://gist.github.com/esz135888/7c08318b6a78ae1778b65808d30fc47e

No GitHub PR or deployment was created in this job.

Reason: PLS context still does not provide Wade's real export, Kolable repo URL, local repo path, branch, deployment target, or API credentials. Claiming github_pr, deployment, or revenue totals would be fake success.

Next valid step: create P0 Wade data request, receive CSV/XLSX, or provide Kolable API/repo for repo_change.

data-model.md

Data Model / API / Sync / Permission Spec

New Tables

kolable_data_requests

column	type	note
id	uuid	request id
project_id	uuid	Kolable project
requested_dataset	text	2026-05-12..2026-05-21 order/payment export
data_owner_profile_id	uuid	Wade if profile exists
requested_by_profile_id	uuid	Louis/PLS
due_at	timestamptz	24h escalation
status	text	open/uploaded/schema_failed/accepted/escalated
artifact_ref	text	uploaded file URL/id
missing_fields	jsonb	schema validation errors
audit_note	text	decision trail

kolable_reconciliation_imports

column	type	note
id	uuid	import id
data_request_id	uuid	FK
row_count	int	total rows
paid_count	int	paid rows
pending_count	int	pending rows
refunded_count	int	refund rows
duplicate_count	int	duplicate rows
status	text	accepted/failed/partial
scorecard_ref	text	dashboard/doc URL

API / Sync

• POST /api/kolable/data-requests
  • creates Wade data request with owner, due, required schema.
• POST /api/kolable/data-requests/:id/upload
  • accepts CSV/XLSX and validates required fields.
• POST /api/kolable/reconciliation/import
  • runs classification once upload passes schema.
• GET /api/kolable/reconciliation/latest
  • returns current scorecard and exceptions.

Permissions / Audit

• Louis can create/close data request and approve revenue recognition.
• Wade can upload/export and fix schema errors.
• Huber can resolve 28,000 training order evidence.
• PLS can create reminders, import append-only data, and write audit logs.
• Shared artifacts use hashed customer_key; no raw PII, payment token, card number, or production credentials.

Failure / Rollback

• No file by due date: status becomes escalated; PLS sends Louis a blocker card.
• File schema fails: status becomes schema_failed; PLS sends Wade missing field list.
• Data mismatch: status remains partial; revenue recognition remains blocked for affected rows.

decision-record.md

Decision Record

Decision

Adopt Kolable Data Gap Escalation Pack for this round.

Problem

PLS re-dispatched a production pack for the same Kolable order/payment blocker after a reconciliation template was already created. Context still lacks the actual Wade export, Kolable API, repo, or payment settlement file.

Options Considered

1. Produce another reconciliation template.
   • Rejected: previous pack already provides schema and control flow.
2. Invent revenue totals or claim deployment.
   • Rejected: no source data or verified URL.
3. Produce data-gap escalation logic and artifacts.
   • Recommended: converts repeated project_runner work into owner/due/action and tells PLS what to do next.

Recommendation

PLS should create a P0 data request for Wade and stop marking this project as production-progress until the file arrives. If Louis provides API/repo, PLS should dispatch repo_change.

Adoption Status

Proposed. Acceptance requires the next signal to be Wade upload, Louis repo/API, or explicit decision to pause revenue recognition.

Landing Path

Owner: Louis. Data owner: Wade. Verification owner: Huber. Due: 2026-05-24. Acceptance: accepted import or explicit blocker card.

Feedback If Not Adopted

Return the real order system of record, export owner, and why PLS should continue creating project_runner packs without data.

kolable-data-gap-escalation.html

<!doctype html>
<html lang="zh-Hant">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Kolable 訂單付款資料缺口升級包</title>
  <style>
    :root { --ink:#1f2937; --muted:#667085; --line:#d0d7e2; --bg:#f6f8fb; --panel:#fff; --bad:#b42318; --warn:#a15c07; --ok:#067647; --blue:#175cd3; }
    body { margin:0; font:14px/1.55 -apple-system,BlinkMacSystemFont,"Segoe UI",sans-serif; background:var(--bg); color:var(--ink); }
    header { padding:28px 32px 18px; background:var(--panel); border-bottom:1px solid var(--line); }
    h1 { margin:0 0 6px; font-size:26px; letter-spacing:0; }
    h2 { margin:0 0 12px; font-size:17px; }
    main { max-width:1180px; margin:0 auto; padding:22px 18px 42px; display:grid; gap:16px; }
    section { background:var(--panel); border:1px solid var(--line); border-radius:8px; padding:18px; }
    .grid { display:grid; grid-template-columns:repeat(4,minmax(0,1fr)); gap:12px; }
    .card { border:1px solid var(--line); border-radius:8px; padding:14px; min-height:104px; background:#fbfcff; }
    .label { color:var(--muted); font-size:12px; text-transform:uppercase; }
    .value { font-weight:700; font-size:22px; margin-top:4px; }
    .bad { color:var(--bad); } .warn { color:var(--warn); } .ok { color:var(--ok); } .blue { color:var(--blue); }
    table { width:100%; border-collapse:collapse; }
    th,td { text-align:left; vertical-align:top; border-bottom:1px solid var(--line); padding:10px 8px; }
    th { color:var(--muted); font-size:12px; }
    code { background:#eef2f7; border-radius:4px; padding:1px 5px; }
    .flow { display:grid; grid-template-columns:repeat(4,1fr); gap:10px; }
    .step { border:1px solid var(--line); border-radius:8px; padding:12px; background:#fbfcff; }
    .small { color:var(--muted); font-size:12px; }
    @media (max-width:900px){ .grid,.flow{grid-template-columns:1fr;} header{padding:22px 18px;} }
  </style>
</head>
<body>
  <header>
    <h1>Kolable 5/12-5/21 訂單付款資料缺口升級包</h1>
    <div class="small">Job f76485ea-723b-4ae1-ac72-180d977a357a · owner Louis · data owner Wade · verification owner Huber · due 2026-05-24</div>
  </header>
  <main>
    <section>
      <h2>本輪狀態</h2>
      <div class="grid">
        <div class="card"><div class="label">資料狀態</div><div class="value bad">未回收</div><div class="small">Context 仍無 Wade CSV/XLSX 或 API/repo。</div></div>
        <div class="card"><div class="label">上一輪成果</div><div class="value ok">對帳工具箱</div><div class="small">已建立匯入模板與分類規則。</div></div>
        <div class="card"><div class="label">本輪升級</div><div class="value warn">Escalation</div><div class="small">資料未到時，PLS 應追資料，不再重做策略包。</div></div>
        <div class="card"><div class="label">驗收</div><div class="value blue">Next Signal</div><div class="small">Wade upload 或 Louis repo/API。</div></div>
      </div>
    </section>
    <section>
      <h2>D1 / D7 / D14 / D30</h2>
      <div class="flow">
        <div class="step"><b>D1</b><br>建立 P0 escalation：Wade 交檔；Huber 標 28,000 退刷/重買；Louis 判定是否停算營收。</div>
        <div class="step"><b>D7</b><br>PLS 自動偵測 overdue export，未交即每日追資料，交檔即跑 reconciliation import。</div>
        <div class="step"><b>D14</b><br>接 Kolable API/repo，讓訂單付款狀態每日同步並產出 exception owner list。</div>
        <div class="step"><b>D30</b><br>形成直播商業儀表板：GMV、實收、退款、重買、折扣碼轉換、素材合規。</div>
      </div>
    </section>
    <section>
      <h2>PLS 下一步自動化規則</h2>
      <table>
        <tr><th>條件</th><th>PLS 應做</th><th>不得做</th></tr>
        <tr><td>無 CSV/XLSX</td><td>建立 Wade P0 data request，due 24h，通知 Louis。</td><td>不得再產 generic strategy pack。</td></tr>
        <tr><td>有檔案但缺欄位</td><td>回傳 row/schema error 給 Wade。</td><td>不得人工猜欄位或補假資料。</td></tr>
        <tr><td>有 paid/refunded/pending</td><td>跑 revenue recognition scorecard。</td><td>不得把 pending/refunded 算進實收。</td></tr>
        <tr><td>有 repo/API</td><td>派 <code>repo_change</code> 實作 import endpoint。</td><td>不得 claim deployment/PR without URL。</td></tr>
      </table>
    </section>
  </main>
</body>
</html>

learning-memory.json

{
  "job_id": "f76485ea-723b-4ae1-ac72-180d977a357a",
  "project": "AI 自建專案：Kolable - 直播銷講工具平台",
  "learned_at": "2026-05-24T05:45:00+08:00",
  "market_context": [
    {
      "source": "Shopify order/payment status practice",
      "lesson": "電商 production 對帳必須區分 order status、payment status、refund/return status，不能只看單一訂單文字。"
    },
    {
      "source": "TikTok Shop settlement practice",
      "lesson": "直播電商的營收要分開看下單、付款、交付、結算；未結算或退款不得計入實收。"
    },
    {
      "source": "YouTube Shopping live/source attribution",
      "lesson": "內容/直播商務要保存 source_event 與商品/折扣碼歸因，才知道哪場直播帶來轉換。"
    }
  ],
  "pls_next_checks": [
    "同一 Kolable order/payment loop 若已存在 reconciliation pack，先查是否有 Wade export。",
    "沒有 export 時建立 data request，不要再派 generic project_runner。",
    "有 API/repo 時才派 repo_change；沒有 verified URL 不得 claim PR/deployment。"
  ],
  "assumptions_overturned": [
    "重複 production pack 不會讓資料自動出現。",
    "Kolable 的核心進度此刻不是產品敘事，而是付款證據回收。",
    "沒有付款檔之前，所有收入都是待驗證。"
  ],
  "next_iteration_condition": "下一輪必須出現 Wade CSV/XLSX、Kolable API/repo，或 Louis 明確暫停 revenue recognition。"
}

production-brief.md

Production Brief：Kolable 資料缺口升級與下一輪派工

場景

上一輪已交付 Kolable 訂單付款對帳工具箱與 CSV 匯入模板；本輪 PLS context 仍未提供 Wade 2026-05-12 至 2026-05-21 真實訂單付款檔，也沒有 Kolable API/repo。此時專案要推進，不能再重做策略或假算營收，必須把 PLS 行為升級成「資料缺口追蹤與派工」。

30 天路徑

• D1：PLS 建立 Wade P0 data request，要求 24 小時內交 CSV/XLSX；Huber 回填 28,000 訂單退刷/重買；Louis 決定未交檔時 Kolable revenue 暫停認列。
• D7：PLS 將匯入模板接成 daily import；未交檔則每日提醒 owner，交檔則自動分類 paid/pending/refunded/duplicate。
• D14：若 Louis 提供 repo/API，派 repo_change 實作 /api/kolable/reconciliation/import 與 scorecard endpoint。
• D30：形成 Kolable 直播營收治理 dashboard，追 GMV、實收、退款、重買、折扣碼轉換與素材合規。

目的到目的 E2E

原始目的：把 Wade 匯出任務從文字追問變成 PLS 可驗收資料流。 產出物：資料缺口升級控制台、資料模型、驗收測試、決策紀錄與採用訊息。 人採用：Wade 交檔；Huber 驗 28,000 訂單；Louis 決定營收是否認列；PLS 自動追蹤缺口。 指標改善：避免把 pending/refunded 計入實收，減少 Louis 手追成本，讓 Kolable 有可信的直播轉換數字。

價值/錢路徑

• 營收：只認列 paid 且無退款的訂單。
• 成本：用 PLS action 自動追資料，取代反覆人工提醒。
• 風險：防止未交檔仍產 strategy pack，造成完成假象。
• 轉換：收到真實資料後，才能計算直播場次與折扣碼的轉換。
• 釋放人力：Wade/Huber 交資料，PLS 自動分類與推 action。

提升人的能力

Louis 不需要在訊息裡猜 Kolable 有沒有賺錢；Wade 不再只被問「有沒有匯出」，而是有明確欄位與驗收；Huber 對 28,000 訂單只需標 evidence/refund/rebuy；PLS 可以判斷何時該追資料、何時該派 repo worker。

Solution Stack

• 脈絡框架：data request → import validation → reconciliation → owner exception → revenue decision。
• 作業流程：PLS 每輪先查是否有真實檔案；沒有就升級 P0 data request，不再重做 production pack。
• 資料/DB 模型：見 data-model.md。
• 可操作工具：kolable-data-gap-escalation.html。
• 驗收指標：見 acceptance-tests.md。
• 採用與下一輪升級：Wade 檔案或 Louis API/repo 任一到位後，進入實作或對帳。

People Sync / LINE 草稿

Louis：Kolable 目前不是缺更多策略，而是 Wade 的 5/12-5/21 訂單付款檔仍未回收。建議 PLS 直接升級成 P0 data request：Wade 24 小時內交檔，Huber 補 28,000 訂單退刷/重買 evidence；未交檔前 Kolable revenue 暫停認列。

Wade：請在 24 小時內交 2026-05-12 到 2026-05-21 訂單付款 CSV/XLSX，欄位不可少 order_id、created_at、customer_key、program_id、amount、payment_status、payment_ref、discount_code、source_event、owner_note。

Huber：請補 28,000 培訓訂單狀態，標為 paid/refunded/rebought/unresolved，並附 payment/refund/evidence ref。

不足資料

• 無 Wade 真實匯出。
• 無 Kolable API/repo。
• 無金流平台 settlement 檔。

上一版問題 → 本輪修改 → 驗證結果 → 下一輪建議

上一版問題：已提供對帳模板，但 PLS 又派同題 production pack，代表資料缺口沒有被轉成追蹤 action。 本輪修改：建立 data-gap escalation pack，明確規定無資料時的 PLS 行為。 驗證結果：本輪成果含可開啟控制台、資料模型、驗收、decision record。 下一輪建議：若仍無檔案，PLS 應派 data request/people_sync，不要再派 project_runner。

sources.md

Market Context Sources

Current practice check date: 2026-05-24 Asia/Taipei.

1. Shopify Help Center, "Understanding your order statuses". URL: https://help.shopify.com/en/manual/orders/manage-orders/order-status Use: mature ecommerce separates order, payment, fulfillment, and return status.

2. Shopify Admin REST Order API documentation. URL: https://shopify.dev/docs/api/admin-rest/latest/resources/order Use: financial status and order fields support API reconciliation.

3. TikTok Shop Seller Blog, "Settlement periods for TikTok Shop sellers: explained". URL: https://seller.tiktok.com/blog/settlement-periods-for-tiktok-shop-sellers-explained/10023278 Use: settlement periods matter for recognizing real seller funds.

4. YouTube Help, "Buy products on YouTube". URL: https://support.google.com/youtube/answer/9162845 Use: live/video commerce should preserve product and source attribution.

5. Previous PLS artifact for Kolable reconciliation pack. URL: https://gist.github.com/esz135888/f780d15b8d22a76cb950e4da189075ee Use: prior template exists; this round escalates missing data instead of duplicating it.