No Vendor In Customer Facing

Octopus must appear as a monolithic, standalone platform to clients. Vendor topology — including the word 'vendor' itself, brand names of suppliers (Bamboo, Til
Source memory file: feedback_no_vendor_in_customer_facing.md · Category: Feedback / working-preference This is a verbatim dump of Claude's persistent memory for the Octopus project. Rendered inside a code block so nothing is altered.
---
name: Never expose upstream vendor in customer-facing surfaces
description: Octopus must appear as a monolithic, standalone platform to clients. Vendor topology — including the word "vendor" itself, brand names of suppliers (Bamboo, Tillo, iRewardify, Reloadly, SEAGM, DT One, Reborn, etc.), and supplier-shaped framings like "upstream / downstream / supplier" — is internal-only and never appears in client panel, API responses/fields, docs, emails, webhooks, claim pages, or any other client-facing surface.
type: feedback
originSessionId: 7fe8bffb-e88d-4c1b-b5db-499387047acf
---
**The rule: Octopus appears as a monolithic standalone platform.** Clients see Octopus as the entity that does everything — catalogue, pricing, fulfilment, refunds. The existence of a supplier layer is a private implementation detail.

**Why:** This is both a commercial rule (supplier identity, pricing, and margin signals are confidential) and a product rule (the brand experience is that customers buy from *us*, not from a reseller orchestrating someone else). Leaking vendor topology — by name or by framing — exposes commercial info to competitors and weakens the platform positioning. Reinforced 2026-05-20 after a sweep across the docs found 88 stale leaks (folder paths `frontend/octopus-docs/content/docs/{(get-started),(guides),reference,changelog}/*.mdx`).

**Scope: ALL client-facing surfaces.** That means:
- **Client panel** (`frontend/client/`) — UI copy, error messages, transaction logs, dashboards.
- **API responses & field names** — no `vendor_*` fields on the wire; `vendor_discount` / `vendor_product_id` / `vendor_code` / `vendor_id` are internal-only.
- **API docs** (`frontend/octopus-docs/`) — prose, code samples, error catalogue, page titles, error tab labels.
- **Emails** — templated receipts, failure notifications, marketing.
- **Webhooks delivered to clients** — payload shapes, event types, error metadata.
- **Public marketing site** (`frontend/octopus-website/`) — explicit reseller framing is fine ("we work with leading providers") but never name them.
- **Grasshopper / claim pages** — brand-only.

**Two things to scrub, not just one:**

1. **Brand names of suppliers.** Bamboo, Tillo, iRewardify, Reloadly, SEAGM, DT One, Reborn, Wupex, LootBar, NeoCurrency, Runa, etc. Always rephrase to the brand the customer bought (Amazon, Steam, Razer, etc.) or generic ("the platform", "fulfilment").

2. **The generic vocabulary that implies a supplier layer.** This is where I keep slipping. The following words/phrases should not appear in client-facing copy unless deliberately rephrased to remove the topology implication:
   - `vendor` (the word itself, in any compound: vendor outage, vendor processing, vendor margin, vendor response, vendor handoff, vendor-specific, vendor variant, vendor rejected, "submit to vendor", "refresh against the vendor")
   - `upstream` / `downstream` (as in "upstream failure", "downstream signature error")
   - `supplier` / `supplier response` / `provider` (when used to imply a tier behind Octopus)
   - "Vendor → Octopus webhook" internal-endpoint documentation — don't even document the inbound URL pattern in client-facing docs; that leaks the topology by existing.

**Rephrasing patterns (use these):**

| Leaky | Monolithic |
|---|---|
| "vendor outage" / "downstream vendor outage" | "transient platform error" / "platform incident" |
| "vendor processing" / "submitted to vendor" | "fulfilment in progress" / "submitted for fulfilment" |
| "vendor was synchronous" / "vendor responded in time" | "fulfilled inside the request" / "fulfilled in time" |
| "vendor rejected" | "rejected" (just drop the actor) |
| "refreshes the status against the vendor" | "refreshes the latest status" |
| "Octopus queries all vendor APIs" | "Octopus resolves the request against the catalogue" |
| "the vendor's primary guess" | "the platform's primary guess" |
| "vendor-specific SKU" / "highest vendor_discount" | "a SKU within the product" / "the best one for your client" |
| "vendor handoff" (in tracing/observability) | "fulfilment" / drop the phrase |
| "upstream, gateway, or transient infra" | "gateway or transient infrastructure" |
| "vendor limitation, not a platform one" | drop the disclaimer; the customer doesn't care about the layer |
| `failure_code: SEAGM_INVALID_PLAYER_ID` | `failure_code: INVALID_PLAYER_ID` |
| catalogue `code: SEAGM-PUBGM-GLOBAL` | `code: PUBGM-GLOBAL` |

**Internal surfaces are fine.** Admin UI (`/admin/*`), audit logs, ops tooling, internal Slack alerts, debug logs, and `services/external_vendors/` source code itself can name vendors freely — those are internal.

**Self-check before declaring docs/copy work complete.** Run:
```bash
grep -rin 'vendor\|upstream\|downstream' <surface-path> --include="*.mdx" --include="*.tsx" --include="*.ts" --include="*.jet"
```
If any hits land in client-facing files, rephrase before signing off. Cross-check against `MEMORY.md` to confirm the surface is client-facing (not admin/ops).