backend-manager 5.9.5 → 5.9.6

package/PROGRESS.md

@@ -1,93 +0,0 @@
-# Project Progress Tracker
-> Agents and maintainers should update this file regularly to reflect the current state of the project.
-
-## 🎯 Current Focus
-* **Goal:** Fix suspended subscription dead zone — users with `suspended` status couldn't cancel or re-subscribe
-* **Current Phase:** Fix applied + tested (24/24 passing), pending commit + publish
-* **Priority:** High
-* **Last Updated:** 2026-06-21 5:50 PM PDT
-* **Notes:** Cancel endpoint now accepts `suspended` subscriptions. Added fallback: if processor rejects (subscription already dead on their end), directly resets user doc to `cancelled`. Traced from live Somiibo user `t9AeAe7QUhNXAUYRV1vUbOU0QVV2` stuck in limbo. Needs BEM publish + Somiibo deploy.
-
-## 📌 Active Task List
-* [ ] Phase 6: Setup scaffolds essential configs for fresh projects
-  * [x] Task 6.1: Add `templates/firebase.json` standard template
-  * [x] Task 6.2: Add `scaffoldConfigs()` + `resolveProjectId()` to setup.js (runs before config resolution)
-  * [x] Task 6.3: Auto-fix `engines.node` instead of throwing
-  * [x] Task 6.4: Fix `dependencies['backend-manager']` crash when BEM is in devDependencies
-  * [x] Task 6.5: Verify fix on truly bare project (dailyembers-backend — 13/14 pass, only service-account expected)
-  * [x] Task 6.6: Optimize — consolidate scattered scaffolding into one `[DEFAULTS]` pass with `loadFiles()` DRY extraction
-  * [x] Task 6.7: Regression test on existing project (ultimate-jekyll-backend — all pass)
-  * [x] Task 6.8: Update docs (CLAUDE.md, CHANGELOG.md)
-  * [ ] Task 6.9: Publish new BEM version
-* [ ] Phase 5: Ghostii feed-based article system
-  * [x] Task 5.1: Create `feed-parser.js` (RSS 2.0, Atom 1.0, JSON Feed parser + article extractor)
-  * [x] Task 5.2: Add `fast-xml-parser` dependency to BEM
-  * [x] Task 5.3: Add `sourceContent` field to Ghostii backend schema (16KB)
-  * [x] Task 5.4: Update Ghostii outline prompt (Step 2 only) with sourceContent for efficient spinning
-  * [x] Task 5.5: Update `writeArticle()` to accept `sourceContent` and per-entry `overrides`
-  * [x] Task 5.6: Upgrade `ghostii-auto-publisher.js` — `$feed:` source type, feed processing, Firestore tracking, fallback
-  * [x] Task 5.7: Update config template with new source types and overrides
-  * [x] Task 5.8: Write extensive test suite (4 test files: unit, integration, extended E2E)
-  * [x] Task 5.9: Verify all tests pass (84 standard + 8 extended against real RSS feeds)
-  * [x] Task 5.10: Create `docs/ghostii.md` deep reference, update CLAUDE.md + CHANGELOG.md
-  * [x] Task 5.11: Verify all recommended feed URLs work (The Verge removed — CDN blocks programmatic access)
-  * [x] Task 5.12: Write ghostii-backend tests for sourceContent (4 schema + 1 extended generation)
-  * [x] Task 5.13: Ghostii sourceContent accepts URL (auto-fetches + extracts article text)
-  * [x] Task 5.14: Add fact paraphrasing to outline prompt + newsletter writer
-  * [x] Task 5.15: Fix Step 3 prompts — assertive link insertion + blockquote in every body section
-  * [x] Task 5.16: Fix humanizer stripping links — `injectBurstiness` was breaking `[text](url)` syntax; added protect-and-restore pattern + tests
-  * [x] Task 5.17: Fix 403 links treated as "working" in link verification step
-  * [x] Task 5.18: Add detective-level `[LINKS]` diagnostic logging to article pipeline
-  * [x] Task 5.19: Ship BEM v5.8.0 to npm
-  * [x] Task 5.20: Ship Ghostii-backend v1.0.5 + deploy to Firebase
-  * [ ] Task 5.17: Publish BEM with feed support
-  * [ ] Task 5.12: Publish BEM with feed support
-  * [ ] Task 5.13: Configure consumer project(s) with `$feed:` sources
-* [x] Phase 7: Fix suspended subscription cancel dead zone
-  * [x] Task 7.1: Trace user `t9AeAe7QUhNXAUYRV1vUbOU0QVV2` — identified asymmetric status gates
-  * [x] Task 7.2: Update cancel gate to accept `suspended` alongside `active`
-  * [x] Task 7.3: Add fallback — direct Firestore reset when processor rejects suspended cancel
-  * [x] Task 7.4: Add `cancel-suspended` test account + `allows-suspended-subscription` test
-  * [x] Task 7.5: All 24 payment tests passing
-  * [ ] Task 7.6: Publish BEM + deploy Somiibo
-* [ ] Phase 3: Post-audit bug fixes
-  * [x] Newsletter ReferenceError: `beehiivConfig` → `newsletterRoleConfig` (committed v5.7.1)
-  * [x] HTTPS proxy: `serve.js` returns boolean, caller uses `httpsReady` not `httpsEnabled`
-  * [x] AI normalizeOptions: array-content system messages now get rules injected
-  * [x] Setup warn handling: `warnCount` tracked separately, warns don't trigger retry
-  * [x] Copy-paste fix: `sender: 'electron-manager'` → `'backend-manager'`
-  * [x] Test: AI array-content-blocks test added + passing (20/20)
-  * [x] Fix: consent rules test — write `'forged'` instead of `'granted'` to avoid value collision with prior email-preferences tests
-  * [x] Fix: `cancel-too-young` account `timestampUNIX` uses seconds (was ms)
-  * [x] Fix: auth on-delete race condition — `deleteTestUsers` uses emulator bulk-clear REST API instead of individual `deleteUser()` calls (eliminates async on-delete triggers that clobbered freshly-created accounts)
-  * [x] Diagnostic: auth-delete-race test — proved the race condition (80-100% clobber rate without mitigation), removed after fix verified
-  * [x] Commit + publish framework fixes (v5.7.2)
-  * [ ] Deploy somiibo-backend + advance stuck sendAt
-* [ ] Phase 4: Root package.json proxy scripts
-  * [x] Task 4.1: Create `root-package-json.js` setup test (proxies `projectScripts` with `cd functions &&` prefix + `preinstall` guard)
-  * [x] Task 4.2: Register in setup test index (after `npm-project-scripts`)
-  * [ ] Task 4.3: Test in consumer project (`npx mgr setup` from ultimate-jekyll-backend)
-  * [ ] Task 4.4: Verify `npm test` / `npm start` work from project root
-
-## ✅ Completed Task List
-* [x] Phase 1: MCP role-based tool scoping + consumer extensibility
-  * [x] Foundation utilities (`src/mcp/utils.js`)
-  * [x] Add `role` to all 19 tools (`src/mcp/tools.js`)
-  * [x] User token support in HTTP client (`src/mcp/client.js`)
-  * [x] Stdio server role filtering + consumer tools (`src/mcp/index.js`)
-  * [x] CLI `--token` flag + `cwd` passthrough (`src/cli/commands/mcp.js`)
-  * [x] HTTP handler — role filtering, OAuth user flow, consumer tool execution (`src/mcp/handler.js`)
-  * [x] Test suite — 44 tests across 5 files
-  * [x] Documentation — `docs/mcp.md`, `CLAUDE.md`
-  * [x] UJM `/token` page update (separate repo)
-* [x] Phase 2: HTTPS local dev + Claude Desktop MCP testing
-  * [x] HTTPS proxy in `npx mgr serve` (mkcert certs, port 5002 → 5443)
-  * [x] `getApiUrl()` returns `https://` when `BEM_HTTPS_PORT` is set
-  * [x] Fix OAuth discovery (root-level issuer per RFC 8414)
-  * [x] Add dynamic client registration (`POST /mcp/register`)
-  * [x] Fix 401 trigger for OAuth flow
-  * [x] Tool annotations (title, readOnlyHint, destructiveHint, etc.)
-  * [x] Role reassignment (cancel/refund/uuid → admin, user = read-only)
-  * [x] Consumer tool override bug fix (listing/execution sync)
-  * [x] Test MCP connection in Claude Desktop — verified end-to-end
-  * [x] Update tests (44 passing) + docs

package/TODO-2.md

@@ -1,121 +0,0 @@
-TODO
-* pdate deps LIKE WF, PP, ETC
-
-TODO
-* remove shim in
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/libraries/email/transactional/index.js:59-61 — legacy template name map
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/libraries/email/transactional/index.js:132-135 — data.body → data.content shim
-ONly needed for about 10 days after Jue 6th 2026, then safe to remove (queued emails)
-
-PAYMENT SYSTEM
-* Ensure attribution is working (utm but also the AD ID shit like from adwords, tiktok ads, meta etc)
-* ensure legacy plan RESOLVING is working
-
-payments/reactivate
-  * takes a subscription id and reactivates a cancelled subscription. this can only be done if the subscription is still within its billing period, otherwise the user would have to create a new subscription.
-payments/upgrade
-  * takes a subscription id and a new plan id and upgrades the user's subscription to the new plan. this can only be done if the user has an active subscription.
-
-I'd call that cancellation-reversed — it pairs naturally with the existing cancellation-requested transition and clearly communicates the action (they reversed/undid the pending cancellation).
-
-on the email we send, for payment recovered what is the category
-Let me check the handler.
-
-Read payment-recovered.js
-The category is order/payment-recovered (line 13).
-
-TODO-2.md
-waht about when they request a cancel
-Read cancellation-requested.js
-The category is order/cancellation-requested (line 13).
-
-----
-add a dedicated BEM JSON field for usage to reset
-  * this way we can have clear LIMITS with their definitions like
-  * [
-    {
-      name: 'credits'
-      reset: true,
-    },
-    {
-      name: 'agents',
-      reset: false,
-    }
-  ]
-  * mirrors: [
-    {
-      collection: 'agents',
-      fields: ['usage.credits.daily', 'runs.replies.daily],
-    }
-  ]
-
----
-MIRROR settigns in BEM JSON so that usage reset can properly get MIRRED DOCS liek slapform forms or chatsy agents DOCS
-
----
-GHOSTII REVAMP
-* better logic for generating posts. better model? claude?
-
----- MCP
-* ability for consuming prjec to specify MCP functions
-
--------
-UPSELL
-* products in BEM can have an UPSELL where you link another product ID and it allows you to add it to your cart OR shows you after checkout?
-
--------
-USER OBJECT UPDGRADE --> INSTANCE?
-
-const User = require('backend-manager/src/manager/helpers/user');
-+
-User.resolveSubscription(self.request.user);
--->
-one object that cna do resolveSubscription(), getAccount(), etc
-
-since you changed some things, do all tests in all projects align still?
-
-after that, udpate README, CLAUDE.md and ANY TOPLEVLE CLAUDE SKILLS so that we never make this mistake again
-
-including
-
----------
-
-TEST NEWSLETTER
-POST /admin/cron { id: 'daily/marketing-newsletter-generate' }
-
-
-SIGNUP HANDLER
-Here are the instructions for BEM:
-
-Update updateReferral() in sign-up.js to resolve all legacy affiliate code formats:
-
-The affiliateCode value coming from the client could be in 3 formats:
-
-Format	Example	How to resolve
-Affiliate code (7-14 alphanumeric)	rmUKlC4z1	Query users where affiliate.code == value (current behavior)
-UID (28 chars)	6sNjQFxTsObA73D8lkF01gcWdP92	Direct doc lookup: users/{value}
-Base64 email (e.g. cG9ldH...Lm_2)	cG9ldHJ5aW5hY3Rpb24yMDE4QGdtYWlsLmNvbQ_2	Strip _\d+ suffix, base64-decode, query users where auth.email == decoded
-Any other format → ignore (resolve with no referrer).
-
-The resolution logic should go at the top of updateReferral(), before the current where('affiliate.code', '==', affiliateCode) query. Try each format in order:
-
-If affiliateCode matches /^[0-9a-zA-Z_-]{7,14}$/ → query by affiliate.code (current path)
-Else if affiliateCode.length === 28 → direct doc get users/{affiliateCode}, use that as the referrer
-Else try base64 decode: strip trailing _\d+, decode, if result contains @ → query by auth.email
-Else → log and return (unrecognized format)
-Once the referrer doc is found (by any method), the rest stays the same: push to affiliate.referrals.
-
-* if the usage was used and the user is actuall authenticated (uid, not just an admin or unauthed user),
-  * set the user's context (ip, location, etc)
-
-Payment attribution
-* can you ensure the the user's attribution (utm etc) is assocaited with the purchase
-* mostly i am referring to the payent events sent to GA4, tiktok, meta
-* i think we should make it so if the attribution was set less than 30 days ago (the date is in the attribution) then it counts
-* it shouldbe attached to the payments-orders and then ALL FUTURE EVENTS should send that (thats a good idea right??)
-
-Payment disputes
-* automatic dispute handling
-* during bm_cron daily, we should check for open disputes for pypal stripe etc... we should then FILL THEM WITH INFORMATION USEFUL FOR WINNING
-* we should attach USAGE LOGS, IP logs, etc. you should take inspiration from my previous attmept at this (/Users/ian/Developer/Repositories/ITW-Creative-Works/subscription-profile-sync/main/disputes)
-* HOWEVER, i know for a fact i got a lot of it wrong. so JUST USE AS INSPO, you should recreate it full

package/TODO-CHARGEBLAST.md

@@ -1,32 +0,0 @@
-As for the AMEX enrollment, AMEX alerts are not supported on Stripe/Shopify. To enable them, you’ll need a dedicated AMEX MID and a payment orchestrator to route all AMEX transactions through that dedicated MID. Using a dedicated AMEX MID allows for a dispute rate of up to 5%, so routing all AMEX traffic through it will significantly reduce your dispute rate on Stripe.
-
-06:44 PM
-For Discover,
-
-In order to enroll in Discover coverage, you will need to do the following:
-
-First, provide us with details about your business below:
-- Merchant Legal Name:
-- Merchant DBA Name:
-- Merchant Registered Street Address:
-- City:
-- Country:
-- State/Province:
-- ZIP/Postal Code:
-
-Second, you must request from your payment processor’s support for a few pieces of information. To do so, please follow the steps below and send them the email template below.
-
-""I am enrolling for Discover Ethoca Alerts via my third-party vendor, Chargeblast. I need my 15-Digit Discover SE number. Can you please provide these pieces of information to me ASAP? Let me know if you need any additional info from me. Please feel free to provide me with these pieces of information piecemeal.”
-
-06:44 PM
-For AMEX If you’d like to proceed with obtaining a dedicated AMEX MID, we’d be happy to arrange an introduction for you.
-
-06:45 PM
-Avatar of Zander
-Zander
-Are we still connected?
-
-06:56 PM
-Avatar of Zander
-Zander
-Since this chat has been inactive, I’ll close it for now. If you have more questions, feel free to contact us at any time. Have a great day ahead!

package/TODO-WEBHOOK-KEY-LEGACY-REMOVAL.md

@@ -1,15 +0,0 @@
-# TODO: Remove legacy BACKEND_MANAGER_KEY acceptance from webhook routes
-
-When v5.2.x shipped, the two payment-webhook routes were switched to prefer `BACKEND_MANAGER_WEBHOOK_KEY` but still accept `BACKEND_MANAGER_KEY` as a transitional fallback so existing provider URLs (registered with the old key) keep working until OMEGA re-registers them with the new key.
-
-Once every brand's provider URLs (Stripe / PayPal / Chargebee / Chargeblast / Coinbase / etc.) have been re-registered via OMEGA to use `BACKEND_MANAGER_WEBHOOK_KEY`, drop the legacy fallback:
-
-## Files to update
-
-- `src/manager/routes/payments/webhook/post.js` — line ~28: remove the `|| key === process.env.BACKEND_MANAGER_KEY` half of the validation check.
-- `src/manager/routes/payments/dispute-alert/post.js` — line ~20: same removal. Also update the docstring at line ~11 to drop the "BACKEND_MANAGER_KEY accepted as legacy fallback" note.
-- `docs/stripe-webhook-forwarding.md` — drop the "BACKEND_MANAGER_KEY also accepted as a legacy fallback" parenthetical.
-
-## How to verify it's safe
-
-Grep production logs (`npx mgr logs:read --fn bm_api --grep "payments/webhook" --limit 1000`) and confirm zero `401 Invalid key` hits over a meaningful window. If there are any, those are providers still on the old URL — re-register them via OMEGA before dropping the fallback.

package/TODO-WEBHOOK-KEY-UPGRADE.md

@@ -1,138 +0,0 @@
-# TODO: Payment Webhook Key Upgrade — `BACKEND_MANAGER_KEY` → `BACKEND_MANAGER_WEBHOOK_KEY`
-
-## Context
-
-In BEM v5.2.0 we introduced `BACKEND_MANAGER_WEBHOOK_KEY` as a dedicated env var for third-party webhook authentication, scoped narrowly so it can be rotated independently of the admin key. The marketing routes (`/marketing/webhook`, `/marketing/webhook/forward`) use it correctly.
-
-The **payment webhook** (`/payments/webhook`) and **dispute-alert webhook** (`/payments/dispute-alert`) still validate against `BACKEND_MANAGER_KEY` — the general-purpose admin key. This is a security misalignment: a leaked admin key could forge payment webhooks, and rotating the admin key forces every Stripe/PayPal/Chargebee webhook URL to be re-registered.
-
-Plan: gradual rollout. Phase 1 (this BEM release) makes the payment routes accept **either** key so existing brand deploys (with only `BACKEND_MANAGER_KEY` set) keep working AND new brands can start using `BACKEND_MANAGER_WEBHOOK_KEY` immediately. Phase 2 (a later BEM release) drops the legacy fallback after every brand has been migrated.
-
-## Files needing the dual-key check
-
-| File | Line | Current |
-|---|---|---|
-| [src/manager/routes/payments/webhook/post.js](src/manager/routes/payments/webhook/post.js) | 28 | `if (!key \|\| key !== process.env.BACKEND_MANAGER_KEY)` |
-| [src/manager/routes/payments/dispute-alert/post.js](src/manager/routes/payments/dispute-alert/post.js) | 20 | `if (!key \|\| key !== process.env.BACKEND_MANAGER_KEY)` |
-| [src/manager/routes/payments/intent/processors/test.js](src/manager/routes/payments/intent/processors/test.js) | 158 | `key=${process.env.BACKEND_MANAGER_KEY}` |
-
-## Phase 1 — Dual-key acceptance (this BEM release)
-
-### Validation change (webhook + dispute-alert)
-
-Replace the single-key check with a dual-key check. Accept the request if `key` matches EITHER `BACKEND_MANAGER_WEBHOOK_KEY` OR the legacy `BACKEND_MANAGER_KEY`.
-
-```js
-// Before
-if (!key || key !== process.env.BACKEND_MANAGER_KEY) {
-  return assistant.respond('Invalid key', { code: 401 });
-}
-
-// After (Phase 1 — dual-key fallback)
-const validKeys = [
-  process.env.BACKEND_MANAGER_WEBHOOK_KEY,
-  process.env.BACKEND_MANAGER_KEY, // legacy — remove in Phase 2
-].filter(Boolean);
-
-if (!key || !validKeys.includes(key)) {
-  return assistant.respond('Invalid key', { code: 401 });
-}
-```
-
-Notes:
-- `.filter(Boolean)` matters — if a brand hasn't set `BACKEND_MANAGER_WEBHOOK_KEY` yet, `validKeys` becomes `[BACKEND_MANAGER_KEY]` (single-element). If a brand HAS set it, both are accepted.
-- If BOTH env vars are unset (misconfigured brand), `validKeys` is `[]` and every request 401s. That's the right behavior — explicit failure beats silent acceptance.
-- Update the route header comments (lines 11 and 27 of dispute-alert, 27 of webhook) to mention both keys.
-
-### Test processor self-fire URL
-
-Switch [src/manager/routes/payments/intent/processors/test.js:158](src/manager/routes/payments/intent/processors/test.js#L158) to PREFER `BACKEND_MANAGER_WEBHOOK_KEY` and fall back to `BACKEND_MANAGER_KEY`:
-
-```js
-const webhookKey = process.env.BACKEND_MANAGER_WEBHOOK_KEY || process.env.BACKEND_MANAGER_KEY;
-const webhookUrl = `${assistant.Manager.project.apiUrl}/backend-manager/payments/webhook?processor=test&key=${webhookKey}`;
-```
-
-This way the test processor exercises the new key when it's set, and falls back to the legacy key on brands that haven't migrated yet.
-
-### Test infrastructure updates
-
-**`src/test/utils/http-client.js`** — add `backendManagerWebhookKey` field alongside the existing `backendManagerKey`.
-
-**`src/test/runner.js`** — thread `backendManagerWebhookKey` through the runner context the same way `backendManagerKey` is threaded today (3 sites).
-
-**`src/cli/commands/test.js`** — read `BACKEND_MANAGER_WEBHOOK_KEY` from env (parallel to the existing `BACKEND_MANAGER_KEY` read), pass it through to the runner, fall back to the admin key if unset.
-
-**Route + journey tests** — update test fixtures to prefer `BACKEND_MANAGER_WEBHOOK_KEY` when set:
-- `test/routes/payments/webhook.js` — all `${config.backendManagerKey}` interpolations in `payments/webhook?...&key=` URLs
-- `test/routes/payments/dispute-alert.js` — same (13 sites)
-- `test/events/payments/journey-*.js` — only the `payments/webhook?...&key=` URLs (NOT the admin-auth uses elsewhere in journey tests)
-
-Use `config.backendManagerWebhookKey || config.backendManagerKey` everywhere so both keys are exercised.
-
-### Docs
-
-- **`docs/stripe-webhook-forwarding.md`** — line 7 + 18 — note the dual-key acceptance, recommend `BACKEND_MANAGER_WEBHOOK_KEY` for new setups, note legacy `BACKEND_MANAGER_KEY` is still accepted for backwards compatibility.
-- **`CHANGELOG.md`** — entry under the next version. Categorize under `Changed` (NOT `BREAKING` — that's reserved for Phase 2). Spell out: "Payment webhook + dispute-alert routes now accept either `BACKEND_MANAGER_WEBHOOK_KEY` (preferred) or `BACKEND_MANAGER_KEY` (legacy). Set `BACKEND_MANAGER_WEBHOOK_KEY` in every consumer brand's `.env` and run OMEGA payment ensure before Phase 2 ships."
-- **`templates/_.env`** — already declares both keys, no change.
-
-### Verification (manual)
-
-1. **Local test (no `BACKEND_MANAGER_WEBHOOK_KEY` set)** — confirm legacy fallback still passes:
-   ```bash
-   npx mgr test routes/payments/webhook routes/payments/dispute-alert events/payments
-   ```
-   Expect green.
-
-2. **Local test (`BACKEND_MANAGER_WEBHOOK_KEY` set to a different value)** — confirm the new key is accepted AND the legacy key still works:
-   ```bash
-   BACKEND_MANAGER_WEBHOOK_KEY=test-webhook-key npx mgr test routes/payments/webhook routes/payments/dispute-alert events/payments
-   ```
-   Expect green.
-
-3. **Live spot-check on one brand (Somiibo)** — deploy this BEM release to Somiibo (whose `.env` currently only has `BACKEND_MANAGER_KEY` set OR has both), trigger a Stripe test event, confirm the webhook doc lands in Firestore.
-
-## Phase 2 — Drop legacy fallback (future BEM release)
-
-**Do NOT do this until every consumer brand has been migrated and verified.** Tracking checklist for migration readiness:
-
-- [ ] Every consumer `.env` has `BACKEND_MANAGER_WEBHOOK_KEY` set (spot-check via OMEGA across all brands)
-- [ ] OMEGA `payment/ensure/{stripe,paypal,chargebee}-webhook.js` updated to use `BACKEND_MANAGER_WEBHOOK_KEY` when constructing webhook URLs (see "OMEGA changes" below)
-- [ ] OMEGA `--service payment` run across every brand to re-register webhook URLs at Stripe/PayPal/Chargebee with the new key
-- [ ] Stale webhook URLs (the old ones with `key=BACKEND_MANAGER_KEY`) deleted from each provider — these will start 401-ing the moment Phase 2 ships
-- [ ] At least one live billing cycle (Stripe charge, refund, dispute) observed working end-to-end on the new key for at least 3 brands
-
-When all boxes are checked, Phase 2 ships as a **breaking change**:
-
-```js
-// Phase 2 — single-key (legacy removed)
-if (!key || key !== process.env.BACKEND_MANAGER_WEBHOOK_KEY) {
-  return assistant.respond('Invalid key', { code: 401 });
-}
-```
-
-Phase 2 CHANGELOG entry goes under `BREAKING`.
-
-## OMEGA changes (separate repo, needed for Phase 2 prep)
-
-Touched files (do NOT do these in Phase 1 — they're for Phase 2 prep):
-
-| File | Change |
-|---|---|
-| `/Users/ian/Developer/Repositories/ITW-Creative-Works/omega-manager/src/services/payment/ensure/stripe-webhook.js` | Line 38: swap `BACKEND_MANAGER_KEY` → `BACKEND_MANAGER_WEBHOOK_KEY`. Line 76 check + line 77 message + line 64 doc comment: update env var name. |
-| `/Users/ian/Developer/Repositories/ITW-Creative-Works/omega-manager/src/services/payment/ensure/paypal-webhook.js` | Same change at lines 40, 66, 77, 78, 79. |
-| `/Users/ian/Developer/Repositories/ITW-Creative-Works/omega-manager/src/services/payment/ensure/chargebee-webhook.js` | Same change at lines 34, 45, 57, 58, 59. |
-
-**Idempotent re-registration + stale cleanup:** Each ensure file looks up existing webhooks **by URL**. Since the URL will change (the `key=` query param differs), the existing webhook will NOT match and a new one will be created. The OLD webhook (with the admin key) needs to be cleaned up — otherwise the third party will deliver to both and the old one will start failing 401 once Phase 2 ships.
-
-Cleanup approach in each ensure file: after creating the new webhook, scan for any other webhook whose URL points at `/payments/webhook?processor={name}` (regardless of key) and delete the stale ones. Match on path prefix, not full URL. Stripe + PayPal + Chargebee all support webhook deletion via the same API methods these files already use for listing.
-
-Helper: extract a `pathMatchesOurProcessor(url, processor)` in each ensure file — strip query string, match the path-and-processor segment.
-
-## Known constraints / gotchas
-
-1. **Phase 1 is non-breaking.** Any consumer can deploy this BEM release without touching their `.env` — the legacy key still works.
-2. **`BACKEND_MANAGER_KEY` continues to grant admin via `assistant.authenticate()`.** That hasn't changed; it's still the admin secret for internal API calls (newsletter, send-email, user/delete, ghostii cron, electron-client, oauth2 state encryption). This TODO is *only* about scoping webhook endpoints to a separate key.
-3. **`UNSUBSCRIBE_HMAC_KEY` is unrelated** and stays separate.
-4. **Admin grant is NOT triggered by the webhook routes.** Middleware auto-runs `assistant.authenticate()` via `Usage.init()`, which reads `data.backendManagerKey` from the request body. The three webhook routes get their key via `?key=` query string (NOT body), and their request bodies are third-party payloads (Stripe events, PayPal events, Chargeblast alerts) that can't contain the real admin secret. So switching the routes' validation does NOT remove any admin-grant the handlers depend on — they write to Firestore via `libraries.admin` (Admin SDK, always full access) anyway.
-5. **Test processor self-fire** must use the same key the BEM endpoint accepts, which is why the test processor URL also gets updated in Phase 1.

package/TODO-email-auth.md

@@ -1,14 +0,0 @@
-https://github.com/disposable-email-domains/disposable-email-domains?tab=readme-ov-file
-https://www.npmjs.com/package/disposable-domains
-https://github.com/tompec/disposable-email-domains
-
-Two repos:
-
-Repo	Domains	Approach
-disposable-email-domains/disposable-email-domains	5,359	Curated, conservative, high confidence
-ivolo/disposable-email-domains	121,569	Aggressive, aggregated from many sources, more false positives
-Our current list has 854 — so even the smaller curated list is 6x larger.
-
-For our use case (currently only used to skip marketing sync, not blocking signups), I'd recommend the 5,359 curated list — it's comprehensive enough without being overly aggressive. And if we ever do use it for blocking signups, the false positive risk is much lower.
-
-Want to swap to that one?

package/TODO.md

@@ -1,187 +0,0 @@
-????
-  // Attach assistant to req and res
-  if (ref.req && ref.res) {
-    ref.req.assistant = self;
-    ref.res.assistant = self;
-  }
-
-    console.log('*** err', err);
-    console.log('*** req.assistant', req.assistant);
-    console.log('*** res.assistant', res.assistant);
-
-# OAUTH2 (INBOUND + OUTBOUND)
-UJM + BEM CHANGE
-* UJM /oauth2 = for conencting OTHER accounts to user account
-* UJM /token = for connecting user account to OTHER accounts
-  * we should rename this (requires backend change too)
-  * /authorize (most common says claude) or /connect
-
-# PAYMETNS
-https://github.com/invertase/stripe-firebase-extensions/tree/next/firestore-stripe-payments
-
-# Make new BEM API using middleware system
-
-# BEM Test
-* Create test accounts (admin, free user, user with paid plan)
-* Run tests to ensure each account has correct access to features
-
-BEM
-  * Teach it how to mock requests and use test user's SECRET API KEYS to authenticate requests
-  * BEM should create a few test accounts: basic, then one for each plan level
-
-TODO
-Update deps!!!! theres lots
-* we culd have a test that TRIES EACH IMPORT ?? incase updating it fails due to ESM VULLSHIT?
-
-
-TODO
-PAYMENT
-https://hookdeck.com/webhooks/platforms/guide-to-paypal-webhooks-features-and-best-practices
-
-
-# TEST REWRRK
-btw... the account.json needs to be removed. remove it from BEM and the consumong project. when we make our test system, we DO NOT NEED TO STORE THE ACCOUBT IN A JSON file. we just need a source of truth in BEM for what uid/emails to look for
-
-need a "projectScripts" that creates the npm start, npm test, etc scripts in the consuming project.
-
-during test run, we need to check that the test accounts exist. we also need to ALWAYS reset them at the begining of the run to ensure they are in the proper format, specifically by resetting their usage, roles, amd subscriptipn
-
-needa new account type that we can change the subscription level of to test the sub events? maybe _test-upgrade that starts free and we test how it progresses from free to paid to canceled?
-
-# Use gitignore from backend-manager-tempalte
-
-# CLEAN
-having different ID and UID is messy and annoying, just make it the same
-  admin: {
-    id: 'admin',
-    uid: '_test-admin',
-    email: '_test.admin@{domain}',
-
-should be "admin" for ALL
-
-
-# TODO
-Update deps
-Remove unused deps like
-  * node-fetch
-
-# MOVE LEGACY BEM INDIVIDUAL FUNCTIONS TO AN _OLD FOLDER
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/functions/core/actions/create-post-handler.js
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/functions/core/actions/generate-uuid.js
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/functions/core/actions/sign-up-handler.js
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/functions/test
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/functions/core/admin
-
-# Things to deprecate
-* api manager
-
-# Email
-Move the sendEmail function to HERE instead of calling ITW
-
-# BEM TESTS
-# User Auth rules
-* User can only access their own user doc
-  * fails when trying to access another user's doc
-  * succeeds when accessing their own,
-  * fails when NOT authed
-  * fails when trying to perform an admin action (can create/use the test:admin http event to test this)
-  * fails when a user tries to write to a restricted field/key like roles, subscription, usage, etc (SEE RULES)
-  * Any other rules: /Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/templates/firestore.rules
-* User can delete their own user doc (can use _test-delete via user:delete http event)
-  * fails when trying to delete another user's doc
-  * succeeds when deleting their own,
-  * fails when NOT authed
-
-# Signup Flow
-* Create a referrer user and a referred user then use user:signup http event on the referred user to test that
-  * the referral code works and the bonus is applied to the referrer
-  * something is added to the account to denote it received the signup event??? not sure
-  * context data is added to the referred user's account
-  * a second signup event
-
-# Test
-* test:authenticate http event
-  * success when valid uid
-  * fail when invalid uid
-  * fail when no uid
-* test admin
-  * all admin functions fail when not authed as admin
-  * test each admin function
-
-# Usage
-* Using an account with a specific plan, test that the usage limits are enforced
-  * success if user has access to the plan
-  * success if the user is within the usage limits
-  * fail if the user exceeds the usage limits
-  * fail if the user is on a plan that does not allow usage (free plan)
-  * successful usage should increment the usage count
-
-# Events
-* trigger cron daily
-  * it should reset temp usage for all users
-  * reset userdocs to current usage = 0
-
-# Payment
-* test subscription upgrade flow via http event
-  * start with free plan
-  * upgrade to paid plan
-  * verify plan is updated
-  * verify usage limits are updated
-  * downgrade back to free plan
-  * verify plan is updated
-  * verify usage limits are updated
-
-# BEM API
-# Admin
-* All functions need to fail when not authed as admin
-* then test each one
-
-# Advanced
-* test sub accounts
-
-# payment system
-* dont store a "resolved" status, but make a universal library that frontend and backend use to determine whther a user has access to a plan currently
-
-# New bem api and test to make
-# test:usage
-* the fnction itself just utilizes the usage API to increment an arbitrary usage item
-
-the test should check the usage storage and ensure that it was incremented successfully
-
-# test for bm_cronDaily
-then, we need to test the bm_cronDaily function to ensure that it does its things like clearing the usage storage properly
-
-# test for schema
-* a comprehesive schema with fields that test EVERY possible field type including required, default, min, max, "value" etc (both static and FUNCTIONS)
-* test multiple plan levels including unathenticated, basic, & premium
-
-# quetsion
-* how does usage get reset? does it reset daily? or monthly?
-* how do we set usage limits?
-  * per plan? or when users prmeium is updated do we set it inside their doc?
-  * if we store it per plan, where should we store the plan data? firestore or in code?
-  * if its firestore we will use lots of reads, if we store in code we have to push new code to update plan limits (not a huge issue)
-
-
-change name from routes/content/post to maye routes/blog/post??? whatfdo you think??
-
-
-# MIGRATIONS
-## user
-affiliate: {
-  referrer: affiliateCode,
-},
--->
-attribution.affiliate.code
-
-
-
-
-## OLD TESTS
-    "_test": "npm run prepare && ./node_modules/mocha/bin/mocha test/ --recursive --timeout=10000",
-    "test": "./node_modules/mocha/bin/mocha test/ --recursive --timeout=10000",
-    "test:cli": "./node_modules/mocha/bin/mocha test/cli-commands.test.js --timeout=10000",
-    "test:usage": "./node_modules/mocha/bin/mocha test/usage.js --timeout=10000",
-    "test:payment-resolver": "./node_modules/mocha/bin/mocha test/payment-resolver/index.js --timeout=10000",
-    "test:user": "./node_modules/mocha/bin/mocha test/user.js --timeout=10000",
-    "test:ai": "./node_modules/mocha/bin/mocha test/ai/index.js --timeout=10000",