makea-cli 0.1.9__tar.gz → 0.1.10__tar.gz

makea_cli-0.1.10/.claude/worktrees/confident-germain-a58957/.claude/settings.local.json

@@ -0,0 +1,20 @@
+{
+  "permissions": {
+    "allow": [
+      "Bash(ls -la /Users/hanxiao/.claude/ 2>/dev/null | head -30)",
+      "Bash(unzip -p makea-cli-setup.skill \"makea-cli-setup/SKILL.md\")",
+      "Bash(unzip -p link-supplier-user.skill \"link-supplier-user/SKILL.md\")",
+      "Bash(ls -la /Users/hanxiao/.claude/skills/lark-shared/ 2>/dev/null)",
+      "Bash(cat /Users/hanxiao/.claude/skills/lark-skill-maker/SKILL.md | head -80)",
+      "Bash(python3 -c \"import sys,json; d=json.load\\(sys.stdin\\); print\\(json.dumps\\(d.get\\('scripts',{}\\), indent=2\\)\\)\")",
+      "Bash(mkdir -p /Users/hanxiao/.claude/skills/gby-deploy)",
+      "Bash(npm run *)",
+      "Bash(git stash *)",
+      "Bash(git add *)",
+      "Bash(python3 -c \"import sys,json; d=json.load\\(sys.stdin\\); print\\(json.dumps\\({**d.get\\('scripts',{}\\), **{'tsx': d.get\\('devDependencies',{}\\).get\\('tsx',''\\), 'nodemon': d.get\\('devDependencies',{}\\).get\\('nodemon',''\\)}}, indent=2\\)\\)\")",
+      "Bash(aws sts *)",
+      "Bash(aws dynamodb *)",
+      "Bash(SINGLE_TABLE_NAME=garmentby-single-table-test .venv/bin/python scripts/backfill_deliverable_names.py)"
+    ]
+  }
+}

makea_cli-0.1.10/.claude/worktrees/confident-germain-a58957/.git

@@ -0,0 +1 @@
+gitdir: /Users/hanxiao/workspace/gby/makea-cli/.git/worktrees/confident-germain-a58957

makea_cli-0.1.10/.claude/worktrees/vigilant-bartik-a79dc8/.claude/skills/link-supplier-user/SKILL.md

@@ -0,0 +1,212 @@
+---
+name: link-supplier-user
+description: >-
+  Links a newly registered Makea supplier user account to an existing supplier profile,
+  then backfills all corresponding quote requests. Use this skill whenever a supplier
+  has just signed up (or re-registered) and you need to connect their new Cognito user
+  to their pre-existing profile — e.g. "Caroline just registered, link her to CHINAWING",
+  "new supplier signup, backfill quotes", "link [person] to [company] supplier profile",
+  "supplier registered but their profile isn't showing", or any time you're told a supplier
+  user_id and an old supplier_id need to be aligned. Also triggers for follow-up tasks like
+  "delete the old supplier record" or "show me all quotes for [supplier]".
+---
+
+# Link Supplier User → Existing Profile + Quote Backfill
+
+A newly registered supplier gets a Cognito `user_id` (their sub). If a supplier profile
+already exists under a different UUID (`old_supplier_id`), you need to migrate the profile
+so it lives under the user's Cognito sub — and backfill any quote requests that were created
+against the old ID. This skill walks through that end-to-end.
+
+---
+
+## Step 1 — Auth & CLI setup
+
+The makea-cli runs in a Linux sandbox, but credentials are stored on the user's Mac.
+Two things need to happen before any CLI commands will work:
+
+**1a. Refresh the token** (the stored token is often stale — the check script doesn't save
+refreshed tokens, so do it directly):
+
+```python
+import json, time, httpx
+from pathlib import Path
+
+CREDS_PATH = "/sessions/modest-brave-newton/mnt/Application Support--makea-cli/credentials.json"
+COGNITO_DOMAIN = "eu-west-1r9ghlpgky.auth.eu-west-1.amazoncognito.com"
+CLIENT_ID = "3nfj8g3et4o85kd6essas16vh0"
+
+creds = json.loads(Path(CREDS_PATH).read_text())
+r = httpx.post(
+    f"https://{COGNITO_DOMAIN}/oauth2/token",
+    data={"grant_type": "refresh_token", "client_id": CLIENT_ID,
+          "refresh_token": creds["refresh_token"]},
+    headers={"Content-Type": "application/x-www-form-urlencoded"},
+    timeout=15,
+)
+if r.status_code == 200:
+    data = r.json()
+    creds["id_token"] = data["id_token"]
+    creds["saved_at"] = time.time()
+    creds["expires_in"] = data.get("expires_in", 3600)
+    Path(CREDS_PATH).write_text(json.dumps(creds, indent=2))
+    print("Token refreshed")
+else:
+    print(f"Refresh failed ({r.status_code}): {r.text}")
+```
+
+If the refresh fails, the user's session has truly expired — ask them to run
+`makea-cli auth` in their Terminal (see the `makea-cli-setup` skill).
+
+**1b. Copy credentials to the Linux path** so the CLI can find them:
+
+```bash
+mkdir -p ~/.config/makea-cli
+cp "/sessions/modest-brave-newton/mnt/Application Support--makea-cli/credentials.json" \
+   ~/.config/makea-cli/credentials.json
+export PATH="$PATH:/sessions/modest-brave-newton/.local/bin"
+```
+
+Quick smoke-test:
+```bash
+makea-cli list-suppliers 2>&1 | head -3
+```
+If you see JSON, you're authenticated. If you see "尚未登录", the token is still broken.
+
+---
+
+## Step 2 — Find the supplier user
+
+You need the user's Cognito `user_id` (their `sub`). Search by name or email:
+
+```python
+import json, httpx
+from pathlib import Path
+
+TOKEN = json.loads(Path(CREDS_PATH).read_text())["id_token"]
+r = httpx.get("https://api.makea.co/admin/users",
+              headers={"Authorization": f"Bearer {TOKEN}"},
+              params={"limit": 50, "offset": 0}, timeout=15)
+users = r.json()["result"]
+
+search = "caroline"  # lowercase name or email fragment
+matches = [u for u in users if search in u.get("name","").lower()
+                             or search in u.get("email","").lower()]
+for u in matches:
+    print(u["user_id"], u["name"], u["email"], u["user_type"], u["created_at"])
+```
+
+Confirm with the user if there are multiple matches. The right one is typically
+`user_type: "Supplier"` and recently `created_at`.
+
+> If there are more than 50 users and you don't find a match, increase `limit` or page
+> through with `offset`.
+
+---
+
+## Step 3 — Find the old supplier profile
+
+```bash
+export PATH="$PATH:/sessions/modest-brave-newton/.local/bin"
+makea-cli list-suppliers | python3 -c "
+import json, sys
+data = json.load(sys.stdin)
+suppliers = data.get('result', [])
+search = 'chinawing'  # lowercase fragment of company name
+matches = [s for s in suppliers if search in str(s).lower()]
+for s in matches:
+    print(s['supplier_id'], s['name'], 'user_id:', s.get('supplier_user_id'))
+"
+```
+
+You're looking for the profile with `supplier_user_id: null` (not yet linked) or with
+a mismatched ID. If you see two profiles for the same company — one with `supplier_user_id`
+equal to the newly registered user, and one with `null` — the one with `null` is the
+"old" profile that needs to be migrated to the user's ID.
+
+---
+
+## Step 4 — Dry-run preview
+
+Always preview before writing anything:
+
+```bash
+makea-cli backfill-supplier-id \
+  --user-id "<cognito_sub / new user_id>" \
+  --old-supplier-id "<old profile UUID>" \
+  --dry-run
+```
+
+Read the output carefully. Key things to check:
+- **Step 1** found the right company name
+- **Step 3** lists the correct products
+- **Step 4** shows the expected number of links to patch
+- **Step 5** confirms quote request backfill will run for the right products
+- `errors` field is empty
+
+If the dry-run looks wrong (wrong company, unexpected products), stop and confirm IDs
+with the user before proceeding.
+
+---
+
+## Step 5 — Apply
+
+```bash
+makea-cli backfill-supplier-id \
+  --user-id "<cognito_sub>" \
+  --old-supplier-id "<old_supplier_id>" \
+  --apply
+```
+
+Summarise the result for the user:
+- How many product links were patched
+- How many products had QRs backfilled
+- Whether S3/document rows were migrated
+- Any errors
+
+---
+
+## Step 6 — Delete the old partition (optional)
+
+Only do this if the user explicitly asks. The old `SUPPLIER#{old_id}` partition is now
+marked `is_migrated` but still present. To remove it permanently:
+
+```bash
+makea-cli backfill-supplier-id \
+  --user-id "<cognito_sub>" \
+  --old-supplier-id "<old_supplier_id>" \
+  --apply \
+  --delete-old-supplier-at-end \
+  --confirm-delete-old-supplier
+```
+
+This is irreversible — make sure the apply in Step 5 succeeded cleanly first.
+
+---
+
+## Verification — list all quotes for the supplier
+
+After linking, verify by pulling all quote requests and supplier links for the new ID:
+
+```bash
+export PATH="$PATH:/sessions/modest-brave-newton/.local/bin"
+makea-cli get-quote-requests-by-supplier-id "<cognito_sub>"
+makea-cli get-supplier-links-by-supplier-id "<cognito_sub>"
+```
+
+Present the results as a clean table per product: link name, sampling price, production
+price tiers (with currency), lead times.
+
+> **Note on `is_archived`**: Backfill sets `is_archived: true` only when the related links
+> are **not** selected by a sampling order. If selected by a sampling order, the quote
+> request stays unarchived.
+
+---
+
+## Quick-reference: IDs across steps
+
+| Thing | Where to find it |
+|---|---|
+| Supplier `user_id` (Cognito sub) | `/admin/users` search by name/email |
+| Old `supplier_id` | `makea-cli list-suppliers` — look for `supplier_user_id: null` |
+| Credentials path | `/sessions/modest-brave-newton/mnt/Application Support--makea-cli/credentials.json` |

makea_cli-0.1.10/.claude/worktrees/vigilant-bartik-a79dc8/.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.10/.claude/worktrees/vigilant-bartik-a79dc8/.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 (`is_archived=true` only when related links are not selected by a sampling order; step 5b applies same rule for 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.10/.gitignore

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

{makea_cli-0.1.9 → makea_cli-0.1.10}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: makea-cli
-Version: 0.1.9
+Version: 0.1.10
 Summary: Makea admin CLI (browser login + Makea admin HTTP API)
 Requires-Python: >=3.10
 Requires-Dist: httpx>=0.27