Creator Economy

The strategic narrative behind v1.0’s asset-pack architecture and the v1.1 marketplace it makes possible. Pairs with ASSET_PACK_IMPORT_PLAN_2026-05-01.md, R14_PLAN_2026-05-02.md, and STARDEW_TIER_PLAN_2026-05-01.md (plan docs since removed from the repo). Locked 2026-05-02.

1. Vision

Endenza is the place where solo creators run, see, and share the work they make with AI: and the pixel-art language that lets visitors walk through that work belongs to whoever creates it. Endenza doesn’t hand-draw the sprites; Endenza ships a curated default Studio (Mana Seed + LimeZu Modern Interiors out-of-box), then lets every creator import the packs they love. The brand pivots from “Endenza HAS pixel art” to “Endenza lets you express yourself in any pixel-art language.” Every Canvas a creator publishes, every Showcase a visitor walks, becomes a small advertisement for the indie pixel-art creator economy that made it possible. Endenza is a patron, not a competitor.

2. The flywheel

The creator-economy loop has four stages, each of which makes the next stage easier:

1. Built-in defaults seed the experience. New creators arrive in their Studio and find the LimeZu Modern Interiors living-room, the Mana Seed character, the four built-in walk-mode Canvas atmospheres already populated. First-paint is Stardew-tier on day zero. Most creators never touch the asset-pack picker: and that’s fine; the defaults are the floor, not the ceiling.

2. Creators upload their own packs. Power users who already own a Mana Seed outfit pack, a LimeZu collection, or a hand-drawn Aseprite export drop the zip into Settings → Asset Packs. The pack lands in their per-user packs/ directory; per-Canvas pack-picker lets them assign different aesthetics to different Canvases. The docs/operations/CREATOR_RECOLOR_GUIDE.md walks creators through producing brand-new variants compatible with Mana Seed: converting the most enthusiastic users into asset-pack producers themselves.

3. Marketplace v1.1 lets indie artists sell directly to Endenza users. When the upload pipeline already exists and creators are visibly remixing each other’s aesthetic, the marketplace turns “browse a list of free packs” into “search a storefront, click buy, pack auto-installs.” Endenza takes a cut (target 30%); the artist gets the rest. License verification, royalty splits, embed-code generation handled server-side. The friction-free purchase loop is what turns a community of remixers into a sustainable artist economy.

4. Endenza takes a cut → reinvests into the bar. The marketplace cut funds the indie-developer team. Every cycle of marketplace revenue funds a polish round, an additional commissioned bespoke pack from a partnered indie artist, a new built-in Canvas atmosphere. The flywheel turns Endenza into both a customer-of and a distributor-of indie pixel-art work.

The compounding asymmetry: every Showcase a visitor walks in the Ensemble (the walkable overworld where each creator’s Showcase sits one door from the next) is a demo of every pack visible inside it. Indie artists like Seliel the Shaper, LimeZu, and Ansimuz become first-party suppliers, not competitors, and their work gets seen by every Endenza visitor whether or not the visitor ever opens a marketplace listing.

3. Brand argument

Linktree sells you a uniform link list and a logo. Stardew Valley sells you one (admittedly perfect) aesthetic. Endenza does neither. The brand argument is:

“Endenza doesn’t sell sprites; Endenza lets you express yourself in any pixel-art language.”

Three implications follow from this:

• No proprietary art moat. We don’t hand-draw the canon. We ship a curated default and let creators differentiate. This is good: proprietary art moats demand 5-10 full-time pixel artists, plus version-control discipline, plus localization, plus accessibility audits, none of which a solo founder running an Anthropic-API budget can sustain.
• Patron-of, not competitor-with. Seliel the Shaper makes more money when Endenza exists than when it doesn’t. LimeZu sells more Modern Interiors when Endenza visitors can recognize the aesthetic. The economics flow toward the indie artist, not away from them. This is what we mean by “patron.”
• Customization is the moat. No bio-link competitor lets users import arbitrary asset packs to customize their own page. This is the depth that justifies “Endenza vs. Linktree” and “Endenza vs. Carrd.” The bio-link surface compresses identity into a list of links; the Endenza Studio expands identity into a walkable, themed, recolorable space.

The brand pivot is “platform with art” → “platform that makes any pixel-art language ship-able.” It scales better, it costs less, and it positions Endenza as a customer-of indie artists rather than a competitor-with them.

4. Mana Seed compatibility as the de-facto format spec

Pixel-art-character formats are not standardized. Every artist-pack ships its own grid layout, sprite-sheet conventions, frame-tag scheme. We can’t support all of them; we have to pick one. The pick is:

• Mana Seed Character Base: Seliel the Shaper’s body system, used by 40+ outfit-pack creators on itch.io. The de-facto standard in the indie pixel-art creator economy. Anyone who already has a Mana Seed outfit pack can use it on Endenza out-of-box.
• The format spec we adopt is documented in ASSET_PACK_IMPORT_PLAN_2026-05-01.md §2: pages 1 (front idle) + 4 (4-direction walk) for v1.0; body-part prefix codes (1out, 2eye, 3hai, 4cap, 5hat); 4-character outfit IDs; _vNN version stamps; the mana seed, sprites.pal palette.
• Our extension is a thin manifest layer (manifest.json) that names the variants Endenza should expose in the character creator. It doesn’t change the underlying art format: it just lets a creator say “this pack contains the for Forester variant and a new fcyb Cyber-Forester variant.” Listed in §2.3 of the ASSET_PACK_IMPORT_PLAN.

By picking Mana Seed as the spec, we get day-one compatibility with the existing creator economy. Indie artists who ship Mana Seed-compatible outfits don’t need to do extra work to ship to Endenza: they’re already shipping to Endenza. The marketplace listing is just an upload step.

The corollary: we are not adopting LimeZu or Modern Interiors as a character format. LimeZu Modern Interiors covers props, kitchens, doors, office equipment: the Canvas-atmosphere layer, not the Showcase-walker layer. Both are first-class in v1.0; the character format is Mana Seed-compatible only.

5. Marketplace MVP scope (deferred from v1.0)

Per ASSET_PACK_IMPORT_PLAN_2026-05-01.md §8.4, the marketplace is deferred until v1.1. Here’s the scope contract for what v1.1 ships and what v1.0 leaves behind.

5.1 What v1.0 ships (the marketplace prerequisites)

• ✓ Per-user pack storage (PackStore abstraction, R13.5-α)
• ✓ Pack upload zone in Settings (R13.5-γ)
• ✓ Per-Canvas pack picker (R13.5-γ)
• ✓ Sprite engine + component renderer pack-aware (R13.5-δ)
• ✓ Built-in pack credits page at /credits.html (R13.5-ε)
• ✓ Public-facing creator-recolor guide at /docs/creator-recolor.html (R14-γ: this round)
• ✓ Cyberpunk-Forester variant as the first creator-pack proof-of-concept (Kevin DIY Aseprite session per R14 §4)

5.2 What v1.1 marketplace adds (out of v1.0 scope)

• Search / discovery surface: browsable pack listings with screenshots, license filters, price filters
• Stripe-backed payment flow with Endenza-takes-30% royalty split
• License verification (creators upload proof-of-purchase for paid packs they’re reselling parts of)
• Embed-code generation (a marketplace pack listing can be embedded into a creator’s Showcase as a “I made this with Endenza” card)
• Auto-install on purchase: clicking “Buy” downloads the zip, runs the same upload pipeline, installs the pack to the user’s packs/ directory
• Creator dashboard: “your packs,” sales analytics, payout schedule

5.3 The deferral reasoning

We don’t open the marketplace in v1.0 for three reasons:

1. No demand signal yet. v1.0 ships with zero registered users. Building marketplace infra before we see real creator behavior risks designing the wrong storefront.
2. License + payment infra is heavy. Stripe Connect for royalty splits, license verification flows, DMCA-compliant takedown handling, indie-artist tax reporting. All of this is real engineering that doesn’t pay off until both sides of the marketplace exist.
3. Built-in defaults already cover the day-zero floor. A new Endenza user lands with LimeZu + Mana Seed pre-installed. They never need the marketplace until they want to differentiate. Most v1.0 users won’t.

The v1.0 contract: upload pipeline + creator-recolor guide + credits page. That’s enough to seed the artist-relations side (early indie partners can already upload packs to gauge interest) without shipping payment infra. v1.1 is when the storefront opens.

6. Cross-references

• ASSET_PACK_IMPORT_PLAN_2026-05-01.md: the architectural spec. Pack format, registry layout, server endpoints, sprite-engine integration, the cyberpunk-twist via creator-pack remix narrative, the §8.4 marketplace deferral this doc inherits from.
• R14_PLAN_2026-05-02.md: the brand-completion round that produced the public-facing creator-recolor guide and the cyberpunk-twist visual signature. §4 is the Kevin-DIY recolor sprint that authored the guide; §7.3 is the LOCKED public-facing decision that made /docs/creator-recolor.html part of v1.1 marketplace creator onboarding from day one.
• STARDEW_TIER_PLAN_2026-05-01.md: the visual bar lock. §1.2 explains what “Stardew + cryptopunks + cyberpunk + vibecoding” means for the visual language; §3.2 is the art-production workstream this Creator Economy doc replaces a chunk of (we don’t hand-draw all the art ourselves; the marketplace flywheel covers most of it).
• MANIFESTO.md: the founding thesis. Endenza as a place to run, see, and share creative AI work; Studio as the editor, Canvas as the creator’s place, Showcase as the public canvas a visitor walks. The four-term vocabulary lock from the current product lock applies in this doc too.
• AGENTIC_OS.md: the 5-surface Agentic OS spec. Suite Library v2 (§7 below) carries an exported agentic_os_config block that captures the installer’s Terminal layout, Dashboard widgets, and Maestro/Council preferences. AGENTIC_OS is the inverse: what Suites configure.
• PRODUCT_SPEC.md: the WHAT-ships-when contract. The Phase A → Phase F sequencing this doc’s marketplace MVP slots into (Phase F = creator marketplace).
• STAGED_PLATFORM.md: the release cadence. v1.1 is where this doc’s marketplace lands; v1.0 ships with the prerequisites.

7. Suite Library v2: share your whole vibe-coding setup

Status: scope locked 2026-05-22 (R7 Train A). Substrate implementation is R7 Train B; this section is the contract Train B builds against.

§1–§5 above scope the pixel-art creator economy (sprites, packs, themes). Suite Library v2 broadens the surface: a Suite is now a creator’s entire vibe-coding rig, not just an art-asset bundle. Installing a Suite drops another maker’s full creative environment on your machine: their CLAUDE.md, their Claude skills, their documentation context, their provider mix, their Canvas layout, their appearance theme, their agentic-OS layout, their brand identity, and their custom prompts.

This is the moat layer named in MANIFESTO.md. Where the v1 Suite carried slim configuration (CLAUDE.md + provider preferences), v2 carries the whole setup. One install ≈ adopting another maker’s stack.

7.1 v2 schema categories

Each category is a top-level field on the Suite bundle JSON. Fields marked (v1) were carried in v1; (v2) are new in this scope.

Out of scope (operator-level, not creator-shareable):

• Voice-in / voice-out settings (per-device, not Suite-portable)
• Cohort / feedback preferences (operator telemetry, never travels)

7.2 Portable filesystem format

A Suite exports to the installer’s own repository as a self-contained .claude/endenza/ directory. The shape:

.claude/endenza/
  suite.json           # manifest: schema version, suite_id, owner, timestamps
  CLAUDE.md            # primary context file
  skills/
    <skill_name>/SKILL.md
    <skill_name>/<asset_files>
  md-files/
    <name>.md
  provider_mix.json    # BYOK preferences
  canvases/
    <slug>.json        # per-canvas room state + metadata
  appearance.json      # theme, brand identity, custom background
  agentic_os_config.json  # Terminal / Dashboard / Maestro / Council layouts
  brand/
    icon.svg
    logo.png
    palette.json
  house_rules.md       # custom prompts + standing instructions
  autopilot_defaults.json
  sprite_packs/        # opt-in, may be large
    <pack_name>/

suite.json is the manifest. Every other file is referenced from it + optional (a Suite with no custom skills omits the skills/ tree entirely). The schema is forward-compatible: an installer running an older Endenza build that doesn’t recognize agentic_os_config.json ignores it; an installer on the newer build picks up the field.

This format is the contract for what gets serialized when a user clicks Export Suite in the Settings → Suites tab, and what gets extracted when they click Install on a marketplace listing. The implementation lives in cloudflare/worker/handlers/suites.js + bin/dashgen/handlers/suites.py (Train B substrate).

7.3 The “implement the OS throughout your repos” capability

The portable filesystem format above is also what enables the power-user move: a creator can install a Suite into their own working repositories, not just into their Endenza account. Drop the .claude/endenza/ tree into any repo’s .claude/ directory and that repo inherits the Suite’s house rules, Claude skills, MD files, and agentic-OS defaults the moment a Claude Code chat opens in it.

This is what makes the Suite Library a moat instead of a config-share gimmick: a creator who publishes their Suite is shipping a deployable agentic-OS layer that another maker can install once into Endenza and again into every repo they work on. See AGENTIC_OS.md §5 for how the 5 Agentic OS surfaces compose with Suite v2 data.

7.4 v1 → v2 migration

Existing v1 Suite bundles install on the v2 substrate. Missing fields (skills[], md_files[], appearance, agentic_os_config, brand, house_rules, autopilot_defaults, sprite_packs[]) default to empty or to the installer’s current values, so a v1 Suite still drops a working CLAUDE.md + provider mix + Canvas layout the way it did before. No data is lost. The Train B substrate work owns this back-compat path; this doc records the contract.

Compiled 2026-05-02 by Maestro from the asset-pack import architecture and R14 brand-completion conversation. Locks the strategic narrative; the architectural spec lives in ASSET_PACK_IMPORT_PLAN. Together they are the contract for the creator economy primitive that will become the v1.1 marketplace.

§7 added 2026-05-22 (R7 Train A): locks the Suite Library v2 scope. Substrate implementation is R7 Train B.