PLS job 97616b0e Kolable refund rebuy reconciliation production pack

acceptance-tests.md

Acceptance Tests

Pass / Fail

1. Primary HTML artifact opens with HTTP 200.
2. Every required appendix exists: production brief, data model, acceptance tests, decision record, artifact URL record.
3. D1 / D7 / D14 / D30 path exists.
4. Purpose-to-purpose E2E is testable from order export to decision.
5. Owner, due, and acceptance are explicit.
6. Data model contains schema, API, sync, permissions, and audit.
7. Market maturity has at least two external sources.
8. People sync includes a LINE-ready ask.
9. Learning memory exists.

E2E Scenario

Given Wade imports 5/12-5/21 orders and payment events, when Huber marks each order with reconciliation_status, then the scorecard must show:

• paid valid count,
• refunded without rebuy count,
• refunded and rebought count,
• dispute pending count,
• data gap count,
• next action owner and due date.

Financial Acceptance

Each non-closed order must have one of: collect, close, dispute, refund, or wait for data. No active row may have an empty next_action.

artifact-url-or-pr.md

Artifact URL or PR

Primary artifact URL: https://gist.github.com/esz135888/a51c566d29e0132c28352c0c119d3381#file-kolable-refund-rebuy-control-room-html

Artifact type: public Gist production pack.

data-model.md

Data Model

kolable_order_reconciliation

• id: uuid primary key.
• order_id: text.
• student_id: text nullable.
• student_name: text nullable.
• course_version: enum n8n_6_modules, vibe_coding_12_chapters, unknown.
• order_amount: numeric.
• discount_code: text nullable.
• order_created_at: timestamptz.
• payment_status: enum paid, failed, refunded, disputed, partial_refund, unknown.
• rebuy_status: enum not_needed, rebought, not_rebought, unknown.
• reconciliation_status: enum paid_valid, refunded_no_rebuy, refunded_rebought, dispute_pending, data_gap, closed.
• owner_id: text.
• due_at: timestamptz.
• next_action: text.
• evidence_packet_id: uuid nullable.

payment_events

• id: uuid primary key.
• order_id: text.
• provider: enum stripe, shopify, manual_transfer, other.
• event_type: enum charge, refund, dispute, rebuy, payout, fee.
• amount: numeric.
• currency: text.
• provider_ref: text.
• event_at: timestamptz.
• raw_payload: jsonb.

student_comms

• id: uuid primary key.
• order_id: text.
• channel: enum line, email, phone, manual.
• message_ref: text.
• topic: enum course_upgrade, refund, rebuy, dispute, support.
• student_response: enum accepted, declined, pending, no_response.
• sent_at: timestamptz.

evidence_packets

• id: uuid primary key.
• order_id: text.
• contains_payment_log: boolean.
• contains_refund_log: boolean.
• contains_course_access_proof: boolean.
• contains_comms_screenshot: boolean.
• contains_policy: boolean.
• ready_for_dispute: boolean.

API / Sync

• POST /kolable/orders/import: Wade uploads order and payment CSV.
• POST /kolable/payment-events/import: import provider events.
• GET /kolable/reconciliation/scorecard: returns status counts and next actions.
• POST /kolable/orders/:order_id/decision: Louis marks collect, close, dispute, or refund.
• POST /kolable/evidence-packets/:id/verify: verifies evidence completeness.

Permissions / Audit

Wade can import data. Huber can reconcile and attach evidence. Louis can decide collect, close, dispute, or escalate. Every status change writes actor, timestamp, previous state, next state, reason, and source evidence.

decision-record.md

Decision Record

Decision

Use project / project_management_pack for this round.

Why

The blocker is not only payment reconciliation. It combines overdue owners, order export, refund/rebuy status, course upgrade communication, and repo/project cadence. A project management pack is the smallest production path that aligns people, data, and decisions without prematurely building a full payment system.

Options Considered

• Spreadsheet only: fast, but weak on API, permission, evidence, and adoption path.
• Full system: too large before the export fields and status taxonomy are confirmed.
• Project management pack: best first move because it defines RACI, schema, gates, and next tool upgrade.

Adoption Status

Recommended. D7 should convert the pack into an actual scorecard with Wade export data.

Feedback Needed If Rejected

Specify whether rejection is due to missing data access, unclear owner authority, payment provider mismatch, or course upgrade communication risk.

e2e-verification.md

E2E Verification

Status: pass.

Verified target:

• Primary artifact URL: https://gist.github.com/esz135888/a51c566d29e0132c28352c0c119d3381#file-kolable-refund-rebuy-control-room-html
• Gist pack URL: https://gist.github.com/esz135888/a51c566d29e0132c28352c0c119d3381

Checks:

• Primary artifact URL returns HTTP 200.
• Gist includes primary HTML and required appendix files.
• Upload-files succeeds for the deliverable id.
• Completion writeback uses stable cloud URL artifacts.

kolable-refund-rebuy-control-room.html

<!doctype html>
<html lang="zh-Hant">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Kolable 28,000 訂單退刷重買核對作戰台</title>
  <style>
    :root {
      --ink: #18212f;
      --muted: #607080;
      --line: #d9e1e8;
      --paper: #f5f7fa;
      --card: #ffffff;
      --blue: #1d4ed8;
      --green: #0f7f5c;
      --amber: #a16207;
      --red: #b3361d;
      --teal: #0f766e;
    }
    * { box-sizing: border-box; }
    body {
      margin: 0;
      font-family: Inter, ui-sans-serif, system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
      background: var(--paper);
      color: var(--ink);
      line-height: 1.5;
    }
    header {
      background: #fff;
      border-bottom: 1px solid var(--line);
      padding: 28px clamp(20px, 4vw, 56px);
    }
    main { padding: 24px clamp(20px, 4vw, 56px) 48px; }
    h1 { margin: 0 0 12px; font-size: clamp(30px, 4vw, 52px); line-height: 1.05; max-width: 1000px; }
    h2 { margin: 0 0 12px; font-size: 22px; }
    h3 { margin: 0 0 6px; font-size: 16px; }
    p { margin-top: 0; }
    code { background: #eef3f8; padding: 1px 5px; border-radius: 4px; }
    .sub { max-width: 1020px; color: var(--muted); font-size: 17px; }
    .grid { display: grid; gap: 16px; }
    .kpis { grid-template-columns: repeat(4, minmax(0, 1fr)); margin-top: 22px; }
    .two { grid-template-columns: 1.1fr .9fr; }
    .three { grid-template-columns: repeat(3, minmax(0, 1fr)); }
    .card {
      background: var(--card);
      border: 1px solid var(--line);
      border-radius: 8px;
      padding: 18px;
      box-shadow: 0 1px 2px rgba(24, 33, 47, .04);
    }
    .metric { font-size: 34px; font-weight: 780; }
    .label { color: var(--muted); font-size: 13px; }
    .pill {
      display: inline-flex;
      align-items: center;
      border: 1px solid var(--line);
      border-radius: 999px;
      padding: 4px 10px;
      font-size: 12px;
      background: #fff;
      margin: 0 6px 8px 0;
      white-space: nowrap;
    }
    .ok { color: var(--green); }
    .warn { color: var(--amber); }
    .bad { color: var(--red); }
    .info { color: var(--blue); }
    table { width: 100%; border-collapse: collapse; font-size: 14px; }
    th, td { text-align: left; padding: 10px; border-bottom: 1px solid var(--line); vertical-align: top; }
    th { color: var(--muted); font-size: 12px; text-transform: uppercase; }
    .timeline { grid-template-columns: repeat(4, minmax(0, 1fr)); }
    .day { border-left: 4px solid var(--teal); }
    .flow { grid-template-columns: repeat(5, minmax(0, 1fr)); }
    .step {
      border: 1px solid var(--line);
      border-radius: 8px;
      padding: 12px;
      min-height: 126px;
      background: #fbfdff;
    }
    .step strong { display: block; color: var(--teal); margin-bottom: 6px; }
    .source a { color: var(--blue); word-break: break-word; }
    @media (max-width: 920px) {
      .kpis, .two, .three, .timeline, .flow { grid-template-columns: 1fr; }
      h1 { font-size: 34px; }
    }
  </style>
</head>
<body>
  <header>
    <span class="pill info">PLS production delivery pack</span>
    <span class="pill ok">Solution: project / project_management_pack</span>
    <h1>Kolable 28,000 培訓訂單退刷重買核對作戰台</h1>
    <p class="sub">把「huber 核對 28,000 培訓訂單退刷與重買狀態」從逾期 action item 變成可執行的專案作戰台：Wade 匯出訂單/付款、Huber 核對退刷/重買、Louis 決策風險與補收款節奏，最後回到 repo/專案進度、owner、驗收與下一輪交付。</p>
    <section class="grid kpis">
      <div class="card"><div class="metric">28,000</div><div class="label">待核對培訓訂單金額或批次標的</div></div>
      <div class="card"><div class="metric warn">5/12-5/21</div><div class="label">Wade 需匯出訂單與付款狀態區間</div></div>
      <div class="card"><div class="metric">3</div><div class="label">核心角色：Louis / Huber / Wade</div></div>
      <div class="card"><div class="metric ok">D7</div><div class="label">完成可對帳 scorecard 與補收款清單</div></div>
    </section>
  </header>
  <main class="grid">
    <section class="grid two">
      <div class="card">
        <h2>本輪問題定義</h2>
        <p>Kolable 已有培訓連結、折扣碼、課綱升級訊息與訂單付款訊號，但目前退刷、重買、補收、課綱變更溝通與 repo 交付節奏沒有被同一張表綁住。結果是：付款狀態不清、學員溝通不一致、收入與退款風險無法被 Louis 快速決策。</p>
        <span class="pill">Owner: Louis</span>
        <span class="pill">Ops: Huber</span>
        <span class="pill">Data: Wade</span>
        <span class="pill">Due: D7 scorecard</span>
      </div>
      <div class="card">
        <h2>最小可落地解法</h2>
        <p><strong>project / project_management_pack</strong>。不是先蓋完整付款系統，而是先把已逾期的核對任務產品化成作戰節奏：資料匯出、狀態判定、補件清單、付款/退刷風險、LINE 對外話術、repo/交付同步。</p>
      </div>
    </section>

    <section class="card">
      <h2>D1 / D7 / D14 / D30 路徑</h2>
      <div class="grid timeline">
        <div class="card day"><h3>D1</h3><p>定義訂單核對 schema、狀態碼、RACI、驗收表；拿到 Wade 匯出欄位或先用空表跑流程。</p></div>
        <div class="card day"><h3>D7</h3><p>完成 5/12-5/21 訂單付款狀態、退刷、重買、待補收、待客服溝通名單。</p></div>
        <div class="card day"><h3>D14</h3><p>把付款狀態對回課綱升級溝通、學員接受/退款原因、素材/Logo 風險，形成週節奏。</p></div>
        <div class="card day"><h3>D30</h3><p>升級成 Kolable revenue ops dashboard：付款、退款、爭議、課程交付、repo/deploy 進度同表決策。</p></div>
      </div>
    </section>

    <section class="card">
      <h2>Purpose-to-Purpose E2E</h2>
      <div class="grid flow">
        <div class="step"><strong>原始目的</strong>確認 28,000 培訓訂單退刷與重買狀態，避免收入與學員溝通失控。</div>
        <div class="step"><strong>輸入</strong>Wade 訂單/付款匯出、Huber 核對結果、LINE 溝通、Stripe/金流紀錄、repo 交付節奏。</div>
        <div class="step"><strong>作戰台</strong>狀態碼、補收清單、爭議證據、owner/due、驗收條件與升級規則。</div>
        <div class="step"><strong>採用</strong>Louis 看待決策清單；Huber 補核對；Wade 補資料；客服用一致話術。</div>
        <div class="step"><strong>改善</strong>現金缺口下降、退款/爭議處理加速、學員溝通一致、專案節奏可追。</div>
      </div>
    </section>

    <section class="grid two">
      <div class="card">
        <h2>狀態碼與下一步</h2>
        <table>
          <thead><tr><th>Status</th><th>判定</th><th>下一步</th></tr></thead>
          <tbody>
            <tr><td><strong>paid_valid</strong></td><td>付款成功且無退刷/爭議。</td><td>納入交付名單，確認課綱升級接受度。</td></tr>
            <tr><td><strong>refunded_no_rebuy</strong></td><td>已退款或退刷，沒有重買紀錄。</td><td>Huber 補原因；Louis 決定是否追補或關閉。</td></tr>
            <tr><td><strong>refunded_rebought</strong></td><td>退刷後重買成功。</td><td>標記收入已恢復，保留證據避免重複追款。</td></tr>
            <tr><td><strong>dispute_pending</strong></td><td>金流爭議尚未結案。</td><td>蒐集課程交付、溝通、退款政策、登入/使用證據。</td></tr>
            <tr><td><strong>data_gap</strong></td><td>訂單、付款、LINE 或學員識別缺欄位。</td><td>Wade 於 D1 補匯出欄位；逾期升級 Louis。</td></tr>
          </tbody>
        </table>
      </div>
      <div class="card">
        <h2>資料 / API / 權限</h2>
        <p><strong>核心表：</strong><code>kolable_order_reconciliation</code>、<code>payment_events</code>、<code>refund_rebuy_decisions</code>、<code>student_comms</code>、<code>evidence_packets</code>。</p>
        <p><strong>API：</strong><code>POST /kolable/orders/import</code>、<code>GET /kolable/reconciliation/scorecard</code>、<code>POST /kolable/refund-decisions</code>。</p>
        <p><strong>權限：</strong>Wade 可匯入付款資料；Huber 可標記核對結果；Louis 可決策補收/關閉/升級；所有狀態變更寫 audit log。</p>
      </div>
    </section>

    <section class="grid three">
      <div class="card">
        <h2>價值 / 錢路徑</h2>
        <p>把 28,000 訂單風險拆成可追的現金缺口、可補收名單與可關閉案件，直接降低漏收、重複退款與爭議損失。</p>
      </div>
      <div class="card">
        <h2>人的能力提升</h2>
        <p>Louis 不用追散訊息；Huber 知道每筆要補什麼；Wade 的匯出欄位有標準；客服能用一致話術處理課綱升級。</p>
      </div>
      <div class="card">
        <h2>下一輪升級</h2>
        <p>接真實訂單 CSV / 金流 API / LINE thread，產生可篩選的補收與爭議證據 queue。</p>
      </div>
    </section>

    <section class="card source">
      <h2>Market Maturity Inputs</h2>
      <p>Stripe dispute best practices emphasize structured evidence, refund details, and payment logs for dispute response: <a href="https://docs.stripe.com/disputes/best-practices?locale=en-GB">Stripe dispute evidence best practices</a>.</p>
      <p>Shopify refund operations document how refunds and repayment collection are handled after mistaken refunds or negative balances: <a href="https://help.shopify.com/en/manual/payments/shopify-payments/payouts/refunds">Shopify Payments refunds</a>.</p>
      <p>Stripe dispute lifecycle also notes disputes can remain open and require timely response before escalation: <a href="https://docs.stripe.com/disputes/how-disputes-work">Stripe how disputes work</a>.</p>
    </section>
  </main>
</body>
</html>

learning-memory.json

{
  "project": "AI 自建專案：Kolable - 直播銷講工具平台 的最大化推進",
  "job_id": "97616b0e-e5f6-4552-8502-b74e1ae4b380",
  "selected_solution": "project/project_management_pack",
  "learned_signal": "Kolable has overdue order/payment reconciliation around 28,000 training orders, Wade export for 5/12-5/21, Huber reconciliation, and course upgrade communication risk.",
  "market_learning": "Payment dispute and refund operations require structured evidence, refund logs, payment processor logs, status tracking, and timely response.",
  "next_run_bias": "Prefer revenue ops scorecard, payment status schema, and evidence queue before building a full payment workflow app.",
  "must_check_next": [
    "Does Wade export include order_id, student_id, amount, payment_status, refund_status, dispute_status, provider_ref?",
    "Can Huber mark every row with one reconciliation status?",
    "Has Louis decided collect/close/dispute rules?",
    "Are course upgrade communications linked to order rows?"
  ]
}

market-maturity.md

Market Maturity

Comparable Practices

• Stripe dispute evidence best practices emphasize structured evidence, refund details, payment processor logs, and merchant records: https://docs.stripe.com/disputes/best-practices?locale=en-GB
• Stripe dispute lifecycle documentation explains dispute timing, escalation, and the importance of timely evidence response: https://docs.stripe.com/disputes/how-disputes-work
• Shopify Payments refund documentation shows the need to handle refund status, negative balance, and collecting payment again after mistaken refunds: https://help.shopify.com/en/manual/payments/shopify-payments/payouts/refunds

PLS Gap

Kolable currently has scattered LINE messages, overdue action items, order/payment export needs, and course upgrade communication. The missing maturity layer is a structured reconciliation and decision cadence.

This Round Upgrade

This pack defines order status taxonomy, data model, API/sync path, evidence requirements, owner/due/acceptance, and a D30 path toward a revenue ops dashboard.

people-sync.md

People Sync

LINE Draft

Louis，這輪我把「Kolable 28,000 培訓訂單退刷與重買狀態」整理成可執行作戰台。D1 需要 Wade 匯出 5/12-5/21 訂單與付款狀態，Huber 用 paid_valid / refunded_no_rebuy / refunded_rebought / dispute_pending / data_gap 五個狀態核對；D7 給你一張補收、關閉、爭議、待資料的決策清單。

Ask

請確認：退刷未重買的案件，Louis 要先追補收、先關閉，還是依金額/學員狀態分層處理？

If No Reply

若 D1 沒拿到 Wade 匯出，先用現有 LINE 訊號建立 data_gap 清單，並把 Wade 匯出欄位列成 blocker。

production-brief.md

Production Brief

場景

專案：AI 自建專案：Kolable - 直播銷講工具平台 的最大化推進。

本輪訊號：Kolable: huber 核對 28,000 培訓訂單退刷與重買狀態；Wade 需匯出 5/12-5/21 訂單與付款狀態；課綱從 n8n 六大模組升級成 Vibe Coding 十二章節，已有學員購買，需要一致溝通。

本輪產出

建立「Kolable 28,000 訂單退刷重買核對作戰台」，把逾期 action item 轉成 project management pack：RACI、D1/D7/D14/D30、資料模型、付款狀態碼、驗收條件、people sync、learning memory。

D1 / D7 / D14 / D30

• D1: Wade 補匯出欄位，Huber 用狀態碼核對第一版，Louis 確認補收/關閉原則。
• D7: 完成 5/12-5/21 訂單、付款、退款、退刷、重買、待溝通名單。
• D14: 接 LINE 課綱升級溝通與學員接受狀態，建立 weekly revenue ops 節奏。
• D30: 升級為付款/退款/課程交付/repo 進度同表的 Kolable revenue ops dashboard。

Owner / Due / Acceptance

• Owner: Louis.
• Data owner: Wade.
• Ops owner: Huber.
• Due: D7 完成核對 scorecard。
• Acceptance: 每筆訂單有狀態碼、金流證據、下一步 owner、due、是否補收/關閉/爭議處理。

production-readiness.md

Production Readiness

Ready Now

• Openable control room artifact.
• Required production appendix pack.
• RACI and D1/D7/D14/D30 path.
• Data model, API, sync, permissions, and audit boundary.
• Acceptance tests and people sync.

Required Integration

• Wade exports 5/12-5/21 orders and payment status.
• Huber maps each row to reconciliation status.
• Louis approves collect/close/dispute rules.
• PLS backend stores scorecard and audit history.

Rollback / Failure Mode

If payment provider export is incomplete, mark rows data_gap and escalate to Wade. If student identity cannot be matched, keep the row out of collection actions until evidence is complete. If dispute evidence is incomplete, do not submit contest package.

skill-usage.md

Skill / Tool Usage

Selected Tools

• PLS session helper: doctor, touch, claim, context, progress, upload-files, complete.
• Web search: checked Stripe dispute evidence, Stripe dispute lifecycle, and Shopify refund practices.
• GitHub CLI: publishes the artifact pack as a public Gist.
• curl: verifies the primary artifact URL returns HTTP 200.

Why These Tools

The task requires production delivery evidence, not only text. The helper commands provide job state and writeback. External payment operations references provide maturity context. Gist and curl provide an openable artifact and verification evidence.

solution-selection.md

Solution Selection

Selected route: project / project_management_pack.

The job is an operating cadence problem around a financial action item. It needs owner, RACI, milestone, risk register, status schema, weekly cadence, and a dashboard spec. It should not be reduced to a LINE reminder because the payment state and evidence path are material. It should not jump directly to a full system until Wade's export fields and Huber's reconciliation workflow are confirmed.

Production stack:

• Context framework: Kolable revenue ops and course upgrade risk.
• Workflow: export -> reconcile -> evidence -> decision -> collect/close/dispute -> weekly review.
• Data model: orders, payment events, student comms, evidence packets.
• Tool: openable HTML control room.
• Acceptance: pass/fail reconciliation gates.
• Upgrade: real CSV/API ingestion and dashboard.