Rebrand customer-facing surfaces and domain as Wiggleverse Market (market.wiggleverse.org) #23

New Issue

2026-06-11T14:07:29Z

ben.stull commented

2026-06-11 14:07:29 +00:00

Summary

Present the official brand Wiggleverse Market on every customer-facing
surface — the storefront UI, the public web address, and the emails the platform
sends — retiring the internal codename "ecomm" from anything a shopper or
merchant sees.

Problem / pain

The product is customer-visible today (the pre-production environment is live
and taking real sign-ins), and every surface a customer meets presents the
internal codename: the browser tab says "ecomm", the header wordmark and footer
say "ecomm", and sign-in emails speak as "ecomm". A lowercase engineering
codename reads as a placeholder, and a commerce product that asks people for
their email address — and soon their orders and money — pays a trust cost every
time it introduces itself that way.

The cost is about to compound: production stand-up is the next piece of work.
If the brand isn't settled first, the production address customers visit,
bookmark, and share — and the sender identity their mail clients learn — get
minted under the codename, and fixing it later becomes a customer-visible
migration (changed links, a "new" sender to re-trust) instead of a naming
decision made once, on time.

Who feels it

persona	role	what they need
Shopper	visits storefronts, signs in, buys	a named, trustworthy platform — not something that looks half-launched
Merchant	runs a storefront on the platform	a platform brand they're proud to put in front of their own customers
Operator	stands up and runs the deployment	the production address and email identity minted under the real brand the first time, with no later rename migration

Desired outcome / value

Every surface a customer sees introduces the product as Wiggleverse Market,
so the platform presents a deliberate brand from its first production day — and
the codename "ecomm" becomes purely internal (repositories, infrastructure
identifiers, operator tooling), where renaming it would cost much and buy
nothing.

Acceptance — "done right"

Every customer-visible surface — browser/tab title, header and footer
wordmark, landing copy, and the content and sender display of every email the
platform sends — reads "Wiggleverse Market" (or its agreed short form);
"ecomm" appears nowhere a shopper or merchant looks.
The public web address customers visit is market.wiggleverse.org; the
pre-production environment follows the same naming shape.
Internal names are deliberately untouched: repositories, the app's One Name,
and infrastructure identifiers still say "ecomm", and nothing breaks because
of the split between brand and codename.
Production, when stood up, launches under the brand from day one — no
customer ever has to follow a rename.

Scope / non-goals

In scope:

Every customer-visible string in the app: browser/tab title, header and
footer wordmark, landing copy, and any other place the product names itself.
The platform's outgoing email: message content and the sender display
identity customers see.
The public domain: customers reach the product at market.wiggleverse.org;
the pre-production environment adopts the matching naming shape.

Non-goals:

Renaming anything internal: repositories, the app's One Name (ecomm),
cloud project / machine / resource identifiers, operator tooling, logs.
A visual identity redesign — this is the name on the existing surfaces, not
a new logo, palette, or design-system pass.
Marketing or content surfaces beyond the app itself.

Assumptions · constraints · dependencies

Assumes the wiggleverse.org name space is ours to assign (the existing
pre-production host already lives under it).
Constraint: the brand/codename split must be total at the customer boundary —
no surface a shopper or merchant sees may leak "ecomm" once this ships.
Relates to ecomm#16 (sign-in email branding) — the email-identity part of
this feature likely satisfies it; reconcile at design time rather than
duplicating work.
Informs the prod stand-up of Feature #1 (SLICE-4 prod half): the
production hostname decision should land before prod is minted.

Source / signal

Self-originated — operator ask opening capture session ecomm-0028
(2026-06-11): "Rebrand 'ecomm' as 'marketplace' on the front-end and domain …
the official brand is 'Wiggleverse Market'." Domain confirmed in-session as
market.wiggleverse.org.

Priority (WSJF)

Value 5 · Time-criticality 8 (prod stand-up is the next slice; rebranding after
prod turns a naming decision into a customer-visible migration) · Opportunity 2
÷ Size 3 ≈ 5 → priority/P1.

Decomposition

Leaf feature — no child issues. A non-binding recommended slicing lives under
Solution notes.

Solution notes (non-binding — discussed and validated in capture session ecomm-0028)

One brand-strings source in the frontend. Title, header/footer wordmark,
and landing copy read a single brand constant so the codename can't drift
back in string by string. (Today: frontend/index.html <title>ecomm</title>;
frontend/src/ui/kit.tsx wordmark "ecomm" / footer "ecomm · a Wiggleverse
line".)
Email identity from the deployment record, not framework code. Sender
display name and message branding are deployment-shape decisions →
deployment.toml, per the no-deployment-shape-in-code rule. This is also the
natural resolution of #16 (sign-in email branding).
Domain cutover via DNS + deployment record. Point
market.wiggleverse.org at the stack for prod; rename PPE to
market-ppe.wiggleverse.org (operator-confirmed) — DNS, TLS, and the
deployment.toml hostname move together; ecomm-ppe.wiggleverse.org may
linger or redirect briefly since only the operator uses it.
Recommended slicing (non-binding):
- UI brand strings (single source + surfaces read it)
- Email identity (sender display + content branding via deployment record; reconcile #16)
- Domain cutover — PPE renamed to market-ppe.wiggleverse.org first;
  prod inherits market.wiggleverse.org at stand-up
Short form for tight UI spots ("Market" vs. full "Wiggleverse Market") is
left to the Solution Design.

## Summary Present the official brand **Wiggleverse Market** on every customer-facing surface — the storefront UI, the public web address, and the emails the platform sends — retiring the internal codename "ecomm" from anything a shopper or merchant sees. ## Problem / pain The product is customer-visible today (the pre-production environment is live and taking real sign-ins), and every surface a customer meets presents the internal codename: the browser tab says "ecomm", the header wordmark and footer say "ecomm", and sign-in emails speak as "ecomm". A lowercase engineering codename reads as a placeholder, and a commerce product that asks people for their email address — and soon their orders and money — pays a trust cost every time it introduces itself that way. The cost is about to compound: production stand-up is the next piece of work. If the brand isn't settled first, the production address customers visit, bookmark, and share — and the sender identity their mail clients learn — get minted under the codename, and fixing it later becomes a customer-visible migration (changed links, a "new" sender to re-trust) instead of a naming decision made once, on time. ## Who feels it | persona | role | what they need | | --- | --- | --- | | Shopper | visits storefronts, signs in, buys | a named, trustworthy platform — not something that looks half-launched | | Merchant | runs a storefront on the platform | a platform brand they're proud to put in front of their own customers | | Operator | stands up and runs the deployment | the production address and email identity minted under the real brand the first time, with no later rename migration | ## Desired outcome / value Every surface a customer sees introduces the product as **Wiggleverse Market**, so the platform presents a deliberate brand from its first production day — and the codename "ecomm" becomes purely internal (repositories, infrastructure identifiers, operator tooling), where renaming it would cost much and buy nothing. ## Acceptance — "done right" - Every customer-visible surface — browser/tab title, header and footer wordmark, landing copy, and the content and sender display of every email the platform sends — reads "Wiggleverse Market" (or its agreed short form); "ecomm" appears nowhere a shopper or merchant looks. - The public web address customers visit is **market.wiggleverse.org**; the pre-production environment follows the same naming shape. - Internal names are deliberately untouched: repositories, the app's One Name, and infrastructure identifiers still say "ecomm", and nothing breaks because of the split between brand and codename. - Production, when stood up, launches under the brand from day one — no customer ever has to follow a rename. ## Scope / non-goals **In scope:** - Every customer-visible string in the app: browser/tab title, header and footer wordmark, landing copy, and any other place the product names itself. - The platform's outgoing email: message content and the sender display identity customers see. - The public domain: customers reach the product at **market.wiggleverse.org**; the pre-production environment adopts the matching naming shape. **Non-goals:** - Renaming anything internal: repositories, the app's One Name (`ecomm`), cloud project / machine / resource identifiers, operator tooling, logs. - A visual identity redesign — this is the *name* on the existing surfaces, not a new logo, palette, or design-system pass. - Marketing or content surfaces beyond the app itself. ## Assumptions · constraints · dependencies - Assumes the `wiggleverse.org` name space is ours to assign (the existing pre-production host already lives under it). - Constraint: the brand/codename split must be total at the customer boundary — no surface a shopper or merchant sees may leak "ecomm" once this ships. - Relates to **ecomm#16** (sign-in email branding) — the email-identity part of this feature likely satisfies it; reconcile at design time rather than duplicating work. - Informs the prod stand-up of **Feature #1** (SLICE-4 prod half): the production hostname decision should land *before* prod is minted. ## Source / signal Self-originated — operator ask opening capture session `ecomm-0028` (2026-06-11): "Rebrand 'ecomm' as 'marketplace' on the front-end and domain … the official brand is 'Wiggleverse Market'." Domain confirmed in-session as `market.wiggleverse.org`. ## Priority (WSJF) Value 5 · Time-criticality 8 (prod stand-up is the next slice; rebranding after prod turns a naming decision into a customer-visible migration) · Opportunity 2 ÷ Size 3 ≈ **5** → `priority/P1`. ## Decomposition Leaf feature — no child issues. A non-binding recommended slicing lives under Solution notes. ## Solution notes (non-binding — discussed and validated in capture session ecomm-0028) - **One brand-strings source in the frontend.** Title, header/footer wordmark, and landing copy read a single brand constant so the codename can't drift back in string by string. (Today: `frontend/index.html` `<title>ecomm</title>`; `frontend/src/ui/kit.tsx` wordmark "ecomm" / footer "ecomm · a Wiggleverse line".) - **Email identity from the deployment record, not framework code.** Sender display name and message branding are deployment-shape decisions → `deployment.toml`, per the no-deployment-shape-in-code rule. This is also the natural resolution of **#16** (sign-in email branding). - **Domain cutover via DNS + deployment record.** Point `market.wiggleverse.org` at the stack for prod; **rename PPE to `market-ppe.wiggleverse.org`** (operator-confirmed) — DNS, TLS, and the `deployment.toml` hostname move together; `ecomm-ppe.wiggleverse.org` may linger or redirect briefly since only the operator uses it. - **Recommended slicing** *(non-binding)*: - [ ] UI brand strings (single source + surfaces read it) - [ ] Email identity (sender display + content branding via deployment record; reconcile #16) - [ ] Domain cutover — PPE renamed to `market-ppe.wiggleverse.org` first; prod inherits `market.wiggleverse.org` at stand-up - Short form for tight UI spots ("Market" vs. full "Wiggleverse Market") is left to the Solution Design.

ben.stull added the type/feature priority/P1 labels 2026-06-11 14:07:29 +00:00

ben.stull referenced this issue

2026-06-11 14:18:50 +00:00

Shopper-first default experience at market.wiggleverse.org; seller experience at its own URL #24

ben.stull commented

2026-06-12 16:16:24 +00:00

Closing as part of the pivot from a generic multi-tenant Shopify-alternative storefront to the commitment-commerce + cross-maker verified referral network direction (see ecomm-content/rfcs/network_strategy.md; session 0036).

Customer-facing 'Wiggleverse Market' storefront rebrand — superseded by the network direction; customer-facing branding will be settled in the network Solution Design.

Nothing is lost — code stays in git history and the issue can be reopened if it resurfaces under the network architecture.

Closing as part of the pivot from a generic multi-tenant Shopify-alternative storefront to the commitment-commerce + cross-maker verified referral **network** direction (see `ecomm-content/rfcs/network_strategy.md`; session 0036). Customer-facing 'Wiggleverse Market' storefront rebrand — superseded by the network direction; customer-facing branding will be settled in the network Solution Design. Nothing is lost — code stays in git history and the issue can be reopened if it resurfaces under the network architecture.

ben.stull closed this issue

2026-06-12 16:16:25 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: wiggleverse/wiggleverse-ecomm#23