makea-cli 0.1.1__tar.gz

makea_cli-0.1.1/.claude/skills/payment-revenue-report/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: payment-revenue-report
+description: Report payment received and platform revenue (service fee + transaction fee) across a date range. Use when the user asks about platform totals, or wants a drill-down by user / product / product category. Backed by the makea-cli `get-cumulative-payment-and-platform-revenue` command and existing order-listing commands.
+---
+
+# Payment & platform revenue report
+
+Use this skill when the user asks a question like:
+
+- "How much payment did we receive in March?"
+- "What was our platform revenue last week?"
+- "Break down service fee vs transaction fee for Q1."
+- "How much revenue did user `<id>` generate between Feb 1 and Mar 31?"
+- "Which product category brought in the most revenue last month?"
+
+There are two fundamentally different modes, and the right approach depends on
+the question the user is asking:
+
+| Mode | When | How |
+| --- | --- | --- |
+| **A. Platform totals** | User wants the whole-platform aggregate over a time range. | One direct admin API call: `makea-cli get-cumulative-payment-and-platform-revenue`. |
+| **B. Per-user / per-product / per-category drill-down** | User wants revenue attributed to a specific designer, product, or category. | The admin cumulative endpoint does **not** support these filters. Fetch the relevant orders with the existing list commands and aggregate the fees client-side. |
+
+Always confirm which mode is needed before running anything. If the user is
+ambiguous, ask: *"Do you want the whole-platform total, or a breakdown for a
+specific user / product / category?"*
+
+## Definitions (match the server)
+
+- **Payment received** — the total money collected from designers (sampling
+  payments + production deposit + production final + misc). Broken down in the
+  response under `result.payment_received.payment_breakdown`.
+- **Platform revenue** — what the platform keeps, equal to **service fee +
+  transaction fee**.
+  - **Service fee**: per-product fee configured on each `Product` document.
+  - **Transaction fee**: a hard-coded **2.8%** of the payment subtotal (see
+    `garmentby_service/common/FeeCalculationHelper.py`,
+    `TRANSACTION_FEE_PERCENTAGE = 2.8`).
+- **Order type filter** — the endpoint accepts `all`, `sampling`, or
+  `production`. It filters both `payment_received` and `platform_revenue`
+  consistently.
+- **Granularity** — `day` (default), `week`, or `month`; controls the bucket
+  size of the `data[]` series, not the overall totals.
+- **Currency** — converted server-side. **Always default to `GBP`** unless the
+  user explicitly asks for a different currency. If the user asks for a
+  non-GBP currency, pass it through `--currency` and call it out in the
+  report so the user is aware the values have been converted. Do not silently
+  switch currencies based on heuristics (e.g. user location, order origin) —
+  only on an explicit request.
+
+## Mode A — Platform totals
+
+### 1. Collect the inputs
+
+Required from the user, or inferred and confirmed back to them:
+
+- `start_date` (YYYY-MM-DD, inclusive)
+- `end_date` (YYYY-MM-DD, inclusive)
+
+Optional (use the defaults unless the user says otherwise):
+
+- `granularity`: `day` | `week` | `month` — default `day`
+- `currency`: **default `GBP`**; only change it when the user explicitly names
+  another currency
+- `order_type`: `all` | `sampling` | `production` — default `all`
+
+Interpret natural-language ranges against today's date. If the user says "last
+month" or "Q1", convert to absolute `YYYY-MM-DD` values and state the range
+back to them before you run the command, so they can catch timezone / fiscal
+boundary mistakes.
+
+### 2. Run the command
+
+```bash
+makea-cli get-cumulative-payment-and-platform-revenue \
+  --start-date 2026-01-01 \
+  --end-date   2026-03-31 \
+  --granularity month \
+  --currency   GBP \
+  --order-type all
+```
+
+The command prints JSON with this shape:
+
+```jsonc
+{
+  "success": true,
+  "result": {
+    "payment_received": {
+      "data": [{ "date": "...", "cumulative_amount": 0, "period_amount": 0 }],
+      "start_amount": 0,
+      "end_amount": 0,
+      "total_amount": 0,
+      "period_total": 0,
+      "currency": "GBP",
+      "order_type_filter": "all",
+      "payment_breakdown": {
+        "sampling": 0,
+        "production_deposit": 0,
+        "production_final": 0
+      }
+    },
+    "platform_revenue": {
+      "data": [{ "date": "...", "cumulative_amount": 0, "period_amount": 0 }],
+      "start_amount": 0,
+      "end_amount": 0,
+      "total_amount": 0,
+      "period_total": 0,
+      "currency": "GBP",
+      "order_type_filter": "all"
+    }
+  }
+}
+```
+
+### 3. Report back
+
+The two fields that answer "how much in this window" are:
+
+- `result.payment_received.period_total` — payments collected in the window.
+- `result.platform_revenue.period_total` — what the platform earned in the window.
+
+Report those as the headline numbers with the currency. Then, if it helps:
+
+- Echo `result.payment_received.payment_breakdown` to split sampling vs
+  production deposit vs production final.
+- Note the chosen `order_type_filter` so the user is not surprised by what is
+  included.
+- Only show the full `data[]` time series when the user asks for the trend.
+
+**Do not break out service fee vs transaction fee separately** — this
+endpoint does not return them separately. If the user asks for that split,
+tell them the combined `platform_revenue.period_total` is what the admin API
+exposes, and offer the drill-down path in Mode B if they need per-order detail.
+
+## Mode B — Per-user / per-product / per-category drill-down
+
+The admin cumulative endpoint only returns platform-wide aggregates. For any
+drill-down you need to fetch the underlying orders with the existing CLI and
+aggregate client-side.
+
+Choose the entry point based on what you are drilling into:
+
+### By user (designer)
+
+1. List the designer's product orders:
+
+   ```bash
+   makea-cli list-product-orders --user-id <user_id>
+   ```
+
+2. For each product order's `product_reference_id`, pull the sampling and
+   production orders:
+
+   ```bash
+   makea-cli list-sampling-orders-by-product   <product_reference_id>
+   makea-cli list-production-orders-by-product <product_reference_id>
+   ```
+
+3. Filter the returned orders to those whose **payment timestamp** falls in
+   the requested `[start_date, end_date]` window. Do this in-memory on the
+   tool output; the list endpoints do not take date params.
+
+4. For each qualifying payment, compute:
+
+   - `payment_subtotal` (from the order payload)
+   - `service_fee` (from the order's fee records)
+   - `transaction_fee` = `payment_subtotal * 0.028`
+   - `platform_revenue` for that order = `service_fee + transaction_fee`
+
+5. Sum per user and report.
+
+### By product
+
+Skip step 1 and go straight to `list-sampling-orders-by-product` /
+`list-production-orders-by-product` with the known `product_reference_id`.
+
+### By product category
+
+There is no admin list-products-by-category CLI command today. Do this:
+
+1. Confirm with the user which category and which product IDs belong to it —
+   either they provide the IDs, or you list their products and filter by the
+   category field the user names.
+2. For each product in the category, follow the "By product" path above.
+3. Sum per category and report.
+
+### Caveats to tell the user up front
+
+- **Results will not exactly match the Mode A totals.** The admin cumulative
+  endpoint includes misc payments and does currency conversion server-side;
+  client-side aggregation from the order list commands is a close but not
+  identical reconstruction. Say this explicitly when you report numbers.
+- **Transaction fee is hard-coded at 2.8%.** If that constant changes in
+  `FeeCalculationHelper.py` it will silently diverge from this skill. Keep
+  the magic number centralized in one place in any scratch script you write.
+- **Pagination.** `list-product-orders`, `list-all-sampling-orders`, and
+  `list-all-production-orders` page with `--limit` / `--offset`. For a time
+  window that could contain many orders, loop until `has_more` / the returned
+  page is empty before aggregating — do not silently truncate.
+- **Timezones.** Date ranges are interpreted by the server as calendar dates.
+  If the user's "last week" has to be precise, confirm the start and end they
+  mean before you run anything.
+
+## Operational notes
+
+- The CLI requires an authenticated admin session. If the command errors with
+  a 401/403, tell the user to run `makea-cli auth login` first.
+- For large windows, prefer `--granularity week` or `month` — the `data[]`
+  series gets long quickly at `day` granularity and is noisy to summarize in
+  chat.
+- Always prefer one call with the final parameters over several exploratory
+  calls. If you are unsure about inputs, ask the user first.
+
+## Related commands already in the CLI
+
+- `list-users` — find a user id to drill down on.
+- `list-product-orders --user-id <id>` — product (SKU) rows for one designer.
+- `list-all-sampling-orders` — global sampling order list.
+- `list-all-production-orders [--type PRODUCTION|RESTOCK]` — global 大货 list.
+- `list-sampling-orders-by-product <id>` — sampling orders for one product.
+- `list-production-orders-by-product <id>` — production orders for one product.
+
+## Upstream reference
+
+Endpoint: `GET /admin/business-metrics/cumulative-payment-and-platform-revenue`
+Defined in `garmentby-service` at:
+
+- Route: `garmentby_service/urls/admin.py`
+- Handler: `garmentby_service/admin/api/AdminApi.py`
+- Service: `garmentby_service/admin/service/AdminBusinessMetricService.py`
+  (`_build_fee_records_parallel` in particular).
+- Transaction fee constant: `garmentby_service/common/FeeCalculationHelper.py`
+  (`TRANSACTION_FEE_PERCENTAGE`).

makea_cli-0.1.1/.claude/skills/supplier-user-id-migration/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: supplier-user-id-migration
+description: >-
+  Migrates supplier data when DynamoDB supplier_id does not match Cognito user sub.
+  Admins use makea-cli backfill-supplier-id (calls garmentby-service admin API).
+  Server-only modes (S3-only, delete-old-partition-only) and reconcile_quote_request_stage_status
+  still run from garmentby-service with manage.py. Use when the user mentions supplier migration,
+  wrong supplier_id, supplierReferenceId, backfill_supplier_id, quote request stage/status,
+  or aligning supplier profile with Cognito sub.
+---
+
+# Supplier user_id ↔ supplier_id migration
+
+## Context
+
+Production expects **`supplier_id` == Cognito `sub` (user_id)**. If a profile was created under a random UUID (`old_supplier_id`), migrate using the consolidated flow—not ad-hoc Dynamo patches.
+
+## Admin workflow (makea-cli) — preferred for operators
+
+Requires an admin Makea account and existing `makea-cli` browser login (same as other admin commands).
+
+**CLI command:** `makea-cli backfill-supplier-id`
+
+It calls **`POST /admin/supplier/backfill_supplier_id_with_quote_requests`**, which wraps the same logic as `manage.py backfill_supplier_id` on the server (profile, Cognito, optional S3/DOCUMENT#, product links, link→quote-request backfill, orders, optional delete old partition at end).
+
+### Examples
+
+```bash
+# Always dry-run first (default)
+makea-cli backfill-supplier-id \
+  --user-id "<cognito_sub>" \
+  --old-supplier-id "<wrong_supplier_uuid>"
+
+# Apply writes
+makea-cli backfill-supplier-id \
+  --user-id "<cognito_sub>" \
+  --old-supplier-id "<wrong_supplier_uuid>" \
+  --apply
+
+# Full run but defer S3/documents (server will skip step 2b)
+makea-cli backfill-supplier-id \
+  --user-id "<cognito_sub>" \
+  --old-supplier-id "<wrong_supplier_uuid>" \
+  --apply \
+  --skip-s3-documents
+
+# Only link→quote-request backfill (profile/Cognito/links already fixed)
+makea-cli backfill-supplier-id \
+  --user-id "<cognito_sub>" \
+  --old-supplier-id "<wrong_supplier_uuid>" \
+  --apply \
+  --quote-request-only
+```
+
+### Response
+
+The API returns JSON including `output` (captured stdout from the server command) and `errors` (stderr). Inspect `success` and any error text before re-running with `--apply`.
+
+### Flags not exposed over this API
+
+These exist only on **`manage.py backfill_supplier_id`** in **garmentby-service** (run from that repo with venv):
+
+- `--s3-documents-only`
+- `--delete-old-supplier-only` (with `--confirm-delete-old-supplier`)
+
+If you need those, use the server commands below.
+
+---
+
+## Server workflow (garmentby-service) — full flag set & repair
+
+**Primary implementation:** `garmentby_service/management/commands/backfill_supplier_id.py`
+
+Run from **garmentby-service** repo root with project venv; target table follows env / `SingleTableAccess`.
+
+### Dry-run then apply
+
+```bash
+.venv/bin/python manage.py backfill_supplier_id <user_id> <old_supplier_id> --dry-run
+.venv/bin/python manage.py backfill_supplier_id <user_id> <old_supplier_id>
+```
+
+### Optional: delete old `SUPPLIER#{old_id}` partition
+
+```bash
+.venv/bin/python manage.py backfill_supplier_id <user_id> <old_id> \
+  --delete-old-supplier-at-end --confirm-delete-old-supplier
+```
+
+Or verify first, then delete only:
+
+```bash
+.venv/bin/python manage.py backfill_supplier_id <user_id> <old_id> \
+  --delete-old-supplier-only --confirm-delete-old-supplier
+```
+
+## What the migration covers
+
+| Area | Handled |
+|------|---------|
+| New supplier METADATA under `SUPPLIER#{user_id}` | Yes |
+| Old METADATA marked `is_migrated` / `migrated_to` | Yes |
+| Cognito `custom:supplierReferenceId` → `user_id` | Yes |
+| S3 + `DOCUMENT#` (unless skipped) | Yes |
+| Product `supplier_links` | Yes |
+| Quote requests from links | Yes (migration sets `is_archived=true` on touched QRs; step 5b archives stragglers under `old_supplier_id`) |
+| Sampling / production orders | Yes |
+
+### Quote request `current_stage` / `status`
+
+Backfill uses `compute_backfill_stage_status` in `backfill_quote_request_for_supplier_quote`. If stages still look wrong after migration, run **`reconcile_quote_request_stage_status`** for the **new** `supplier_id` (dry-run first) from **garmentby-service**:
+
+```bash
+.venv/bin/python manage.py reconcile_quote_request_stage_status <supplier_id> --dry-run
+.venv/bin/python manage.py reconcile_quote_request_stage_status <supplier_id>
+```
+
+### Backfill-created quote request timestamps
+
+For newly created quote requests in link→QR backfill: **`created_at`** prefers supplier link **`created_at`**, else product **`created_at`**; **`due_date`** is aligned to the same value for expiry alignment.
+
+## Not covered by `backfill_supplier_id` alone
+
+`AdminService.sync_supplier_id_to_user` also moves bookmarks, price rows, financial doc associations, and all quote requests by supplier—use when those still reference `old_supplier_id` after backfill.
+
+## Agent checklist
+
+- [ ] Collect **`user_id`** (Cognito `sub`) and **`old_supplier_id`** (wrong profile id).
+- [ ] Run **dry-run** first (`makea-cli` default, or `manage.py ... --dry-run`).
+- [ ] Use **delete-at-end** only with explicit confirm and after verification.
+- [ ] If delete fails on QR check, fix remaining QRs or use **`sync_supplier_id_to_user`**, then retry delete-only on server.
+- [ ] If QR **stage/status** look wrong after migration, run **`reconcile_quote_request_stage_status`** (dry-run first) on **garmentby-service**.
+- [ ] Do not fabricate IDs; use values from Dynamo/Cognito or the user.

makea_cli-0.1.1/.claude/worktrees/elated-davinci/.claude/settings.local.json

@@ -0,0 +1,16 @@
+{
+  "permissions": {
+    "allow": [
+      "Read(//Users/hanxiao/workspace/gby/makea-cli/**)",
+      "Read(//Users/hanxiao/workspace/gby/makea-cli/.claude/**)",
+      "Bash(python -m makea_cli.main get-cumulative-payment-and-platform-revenue --help)",
+      "Bash(python3 -m makea_cli.main get-cumulative-payment-and-platform-revenue --help)",
+      "Bash(uv run:*)",
+      "Bash(python3 -c \"import json,sys; d=json.load\\(sys.stdin\\); print\\(f'Total products: {len\\(d[\\\\\"result\\\\\"]\\)}'\\); [print\\(f'{p[\\\\\"reference_id\\\\\"]}  {p[\\\\\"display_name\\\\\"]}  status={p[\\\\\"status\\\\\"]}  has_sampling={p.get\\(\\\\\"has_sampling\\\\\"\\)}  created={p[\\\\\"created_at\\\\\"][:10]}'\\) for p in d['result']]\")",
+      "Bash(python3)",
+      "Bash(git add:*)",
+      "Bash(git commit -m ':*)",
+      "Bash(git push:*)"
+    ]
+  }
+}

makea_cli-0.1.1/.claude/worktrees/elated-davinci/.claude/skills/payment-revenue-report/SKILL.md

@@ -0,0 +1,234 @@
+---
+name: payment-revenue-report
+description: Report payment received and platform revenue (service fee + transaction fee) across a date range. Use when the user asks about platform totals, or wants a drill-down by user / product / product category. Backed by the makea-cli `get-cumulative-payment-and-platform-revenue` command and existing order-listing commands.
+---
+
+# Payment & platform revenue report
+
+Use this skill when the user asks a question like:
+
+- "How much payment did we receive in March?"
+- "What was our platform revenue last week?"
+- "Break down service fee vs transaction fee for Q1."
+- "How much revenue did user `<id>` generate between Feb 1 and Mar 31?"
+- "Which product category brought in the most revenue last month?"
+
+There are two fundamentally different modes, and the right approach depends on
+the question the user is asking:
+
+| Mode | When | How |
+| --- | --- | --- |
+| **A. Platform totals** | User wants the whole-platform aggregate over a time range. | One direct admin API call: `makea-cli get-cumulative-payment-and-platform-revenue`. |
+| **B. Per-user / per-product / per-category drill-down** | User wants revenue attributed to a specific designer, product, or category. | The admin cumulative endpoint does **not** support these filters. Fetch the relevant orders with the existing list commands and aggregate the fees client-side. |
+
+Always confirm which mode is needed before running anything. If the user is
+ambiguous, ask: *"Do you want the whole-platform total, or a breakdown for a
+specific user / product / category?"*
+
+## Definitions (match the server)
+
+- **Payment received** — the total money collected from designers (sampling
+  payments + production deposit + production final + misc). Broken down in the
+  response under `result.payment_received.payment_breakdown`.
+- **Platform revenue** — what the platform keeps, equal to **service fee +
+  transaction fee**.
+  - **Service fee**: per-product fee configured on each `Product` document.
+  - **Transaction fee**: a hard-coded **2.8%** of the payment subtotal (see
+    `garmentby_service/common/FeeCalculationHelper.py`,
+    `TRANSACTION_FEE_PERCENTAGE = 2.8`).
+- **Order type filter** — the endpoint accepts `all`, `sampling`, or
+  `production`. It filters both `payment_received` and `platform_revenue`
+  consistently.
+- **Granularity** — `day` (default), `week`, or `month`; controls the bucket
+  size of the `data[]` series, not the overall totals.
+- **Currency** — converted server-side. **Always default to `GBP`** unless the
+  user explicitly asks for a different currency. If the user asks for a
+  non-GBP currency, pass it through `--currency` and call it out in the
+  report so the user is aware the values have been converted. Do not silently
+  switch currencies based on heuristics (e.g. user location, order origin) —
+  only on an explicit request.
+
+## Mode A — Platform totals
+
+### 1. Collect the inputs
+
+Required from the user, or inferred and confirmed back to them:
+
+- `start_date` (YYYY-MM-DD, inclusive)
+- `end_date` (YYYY-MM-DD, inclusive)
+
+Optional (use the defaults unless the user says otherwise):
+
+- `granularity`: `day` | `week` | `month` — default `day`
+- `currency`: **default `GBP`**; only change it when the user explicitly names
+  another currency
+- `order_type`: `all` | `sampling` | `production` — default `all`
+
+Interpret natural-language ranges against today's date. If the user says "last
+month" or "Q1", convert to absolute `YYYY-MM-DD` values and state the range
+back to them before you run the command, so they can catch timezone / fiscal
+boundary mistakes.
+
+### 2. Run the command
+
+```bash
+makea-cli get-cumulative-payment-and-platform-revenue \
+  --start-date 2026-01-01 \
+  --end-date   2026-03-31 \
+  --granularity month \
+  --currency   GBP \
+  --order-type all
+```
+
+The command prints JSON with this shape:
+
+```jsonc
+{
+  "success": true,
+  "result": {
+    "payment_received": {
+      "data": [{ "date": "...", "cumulative_amount": 0, "period_amount": 0 }],
+      "start_amount": 0,
+      "end_amount": 0,
+      "total_amount": 0,
+      "period_total": 0,
+      "currency": "GBP",
+      "order_type_filter": "all",
+      "payment_breakdown": {
+        "sampling": 0,
+        "production_deposit": 0,
+        "production_final": 0
+      }
+    },
+    "platform_revenue": {
+      "data": [{ "date": "...", "cumulative_amount": 0, "period_amount": 0 }],
+      "start_amount": 0,
+      "end_amount": 0,
+      "total_amount": 0,
+      "period_total": 0,
+      "currency": "GBP",
+      "order_type_filter": "all"
+    }
+  }
+}
+```
+
+### 3. Report back
+
+The two fields that answer "how much in this window" are:
+
+- `result.payment_received.period_total` — payments collected in the window.
+- `result.platform_revenue.period_total` — what the platform earned in the window.
+
+Report those as the headline numbers with the currency. Then, if it helps:
+
+- Echo `result.payment_received.payment_breakdown` to split sampling vs
+  production deposit vs production final.
+- Note the chosen `order_type_filter` so the user is not surprised by what is
+  included.
+- Only show the full `data[]` time series when the user asks for the trend.
+
+**Do not break out service fee vs transaction fee separately** — this
+endpoint does not return them separately. If the user asks for that split,
+tell them the combined `platform_revenue.period_total` is what the admin API
+exposes, and offer the drill-down path in Mode B if they need per-order detail.
+
+## Mode B — Per-user / per-product / per-category drill-down
+
+The admin cumulative endpoint only returns platform-wide aggregates. For any
+drill-down you need to fetch the underlying orders with the existing CLI and
+aggregate client-side.
+
+Choose the entry point based on what you are drilling into:
+
+### By user (designer)
+
+1. List the designer's product orders:
+
+   ```bash
+   makea-cli list-product-orders --user-id <user_id>
+   ```
+
+2. For each product order's `product_reference_id`, pull the sampling and
+   production orders:
+
+   ```bash
+   makea-cli list-sampling-orders-by-product   <product_reference_id>
+   makea-cli list-production-orders-by-product <product_reference_id>
+   ```
+
+3. Filter the returned orders to those whose **payment timestamp** falls in
+   the requested `[start_date, end_date]` window. Do this in-memory on the
+   tool output; the list endpoints do not take date params.
+
+4. For each qualifying payment, compute:
+
+   - `payment_subtotal` (from the order payload)
+   - `service_fee` (from the order's fee records)
+   - `transaction_fee` = `payment_subtotal * 0.028`
+   - `platform_revenue` for that order = `service_fee + transaction_fee`
+
+5. Sum per user and report.
+
+### By product
+
+Skip step 1 and go straight to `list-sampling-orders-by-product` /
+`list-production-orders-by-product` with the known `product_reference_id`.
+
+### By product category
+
+There is no admin list-products-by-category CLI command today. Do this:
+
+1. Confirm with the user which category and which product IDs belong to it —
+   either they provide the IDs, or you list their products and filter by the
+   category field the user names.
+2. For each product in the category, follow the "By product" path above.
+3. Sum per category and report.
+
+### Caveats to tell the user up front
+
+- **Results will not exactly match the Mode A totals.** The admin cumulative
+  endpoint includes misc payments and does currency conversion server-side;
+  client-side aggregation from the order list commands is a close but not
+  identical reconstruction. Say this explicitly when you report numbers.
+- **Transaction fee is hard-coded at 2.8%.** If that constant changes in
+  `FeeCalculationHelper.py` it will silently diverge from this skill. Keep
+  the magic number centralized in one place in any scratch script you write.
+- **Pagination.** `list-product-orders`, `list-all-sampling-orders`, and
+  `list-all-production-orders` page with `--limit` / `--offset`. For a time
+  window that could contain many orders, loop until `has_more` / the returned
+  page is empty before aggregating — do not silently truncate.
+- **Timezones.** Date ranges are interpreted by the server as calendar dates.
+  If the user's "last week" has to be precise, confirm the start and end they
+  mean before you run anything.
+
+## Operational notes
+
+- The CLI requires an authenticated admin session. If the command errors with
+  a 401/403, tell the user to run `makea-cli auth login` first.
+- For large windows, prefer `--granularity week` or `month` — the `data[]`
+  series gets long quickly at `day` granularity and is noisy to summarize in
+  chat.
+- Always prefer one call with the final parameters over several exploratory
+  calls. If you are unsure about inputs, ask the user first.
+
+## Related commands already in the CLI
+
+- `list-users` — find a user id to drill down on.
+- `list-product-orders --user-id <id>` — product (SKU) rows for one designer.
+- `list-all-sampling-orders` — global sampling order list.
+- `list-all-production-orders [--type PRODUCTION|RESTOCK]` — global 大货 list.
+- `list-sampling-orders-by-product <id>` — sampling orders for one product.
+- `list-production-orders-by-product <id>` — production orders for one product.
+
+## Upstream reference
+
+Endpoint: `GET /admin/business-metrics/cumulative-payment-and-platform-revenue`
+Defined in `garmentby-service` at:
+
+- Route: `garmentby_service/urls/admin.py`
+- Handler: `garmentby_service/admin/api/AdminApi.py`
+- Service: `garmentby_service/admin/service/AdminBusinessMetricService.py`
+  (`_build_fee_records_parallel` in particular).
+- Transaction fee constant: `garmentby_service/common/FeeCalculationHelper.py`
+  (`TRANSACTION_FEE_PERCENTAGE`).

makea_cli-0.1.1/.claude/worktrees/elated-davinci/.git

@@ -0,0 +1 @@
+gitdir: /Users/hanxiao/workspace/gby/makea-cli/.git/worktrees/elated-davinci

makea_cli-0.1.1/.claude/worktrees/elated-davinci/.gitignore

@@ -0,0 +1,8 @@
+.DS_Store
+.venv/
+__pycache__/
+*.py[cod]
+.pytest_cache/
+.mypy_cache/
+dist/
+*.egg-info/