dot Emporium: The Pattern Takes a Left Turn

The state pattern that runs project-state was built for one domain: multi-stakeholder, funded, time-bounded projects with external reporting requirements. Grant consortia. Client engagements. Board-backed products.

The pattern was never supposed to end up in a vintage synth storefront.

And yet.

What dot Emporium is

dot Emporium is a vintage and rare goods operation — synthesizers, typewriters, electronics, objects with stories. The items are physical. The buyers are real. The prices are grounded in current Facebook Marketplace comparables, not vibes.

What it needed was a system to move items from acquisition to sale: log the thing, assess it, price it, write it up, publish it, sell it, ship it. Seven steps. All of them create artifacts. All of them need state.

The .emporium/ directory is the result.

Browse the live storefront at dot Emporium on scsiwyg.

The lifecycle

intake → graded → researched → listed → live → sold → fulfilled

Compare that to project-state's lifecycle:

intake → planning → execution → close → archive

The structure is the same. The domain is completely different.

intake — raw photos land in .emporium/inbox/. The emporium-intake skill assigns an ID (emp-2026-001), scaffolds a folder, moves photos, and drafts a catalog record. Waits for approval before committing. The item is logged before anyone decides whether it's worth selling.

graded — condition scoring. Cosmetic, functional, completeness. The score informs the research and, ultimately, the asking price. Low condition scores don't disqualify an item; they adjust the narrative.

researched — this is where the work happens. The emporium-researcher skill produces a dossier: historical context, technical notes, cultural significance, and — mandatory for every item — a Facebook Marketplace pricing section. Real comparables. Canadian prices preferred. Outliers excluded and noted. A single recommended asking price comes out the other end, written back to the catalog record.

listed — the emporium-lister skill drafts listing copy from the research dossier and grading data. Photos are processed. The item becomes a SKU: title, description, condition, price, tags, photos. One record. Reviewable. Approvable before anything goes further.

live — emporium-publisher pushes the approved listing to scsiwyg. One item becomes one post on the dot-emporium blog. The publishing platform is the same one that runs this blog, commit-and-push, claude-skills, and every other property in the system.

sold / fulfilled — the catalog tracks the close: sale price, buyer region, shipping confirmation. The audit trail is append-only throughout.

What's different from project-state

project-state's items are information artifacts: deliverables, reports, milestones, decisions. They don't depreciate. They don't need photos. Their "value" is their completion, not their condition.

dot Emporium's items are physical objects. The condition score is load-bearing — it directly affects the price. The research is competitive: Facebook Marketplace is live, prices shift, and comparables can change between Monday and Friday. The output isn't a PDF for a funder; it's a listing visible to buyers.

Three differences matter:

1. Pricing is grounded in live market data. project-state doesn't price anything. emporium-researcher does, and it does it by checking what the same item is actually selling for right now. The catalog holds the recommended asking price as a first-class field. It can be updated as the market moves.

2. The publish target is a storefront, not a stakeholder. project-state's outputs go to funders, Steering Committees, partner organizations. dot Emporium's outputs go to buyers. scsiwyg handles both — but the audience, the copy, and the intent are completely different. A listing is not a quarterly report.

3. The catalog is structured for machine traversal. catalog/items.yaml is a flat, indexed record of every item: phase, tags, pricing, photo paths, condition scores, slugs. An agent reading it can answer "what's available", "what's priced under $200", "what synthesizers are in the researched phase". That's intentional — and it's what makes the next thing interesting.

Browser agents and the storefront

The catalog is structured. Every live item has a phase, a price, tags, a slug, and a scsiwyg URL. A browser agent navigating dot Emporium could, in principle, answer real buyer questions: "What do you have in the $100–$300 range that's fully functional?" Or surface items to a recommendation layer. Or check whether a specific model is in inventory before a buyer emails.

This isn't built yet. But the structure is already there — which is how good state design works. You don't build the query layer first. You build the state correctly, and the queries become possible. The emporium catalog is machine-readable by design. Where that goes is still open.

scsiwyg, again

Every workflow in this system eventually publishes through scsiwyg. .blog-state/, .app-state/, .project-state/, and now .emporium/ — all of them treat scsiwyg as the output layer. Not because it's the only option, but because a headless, API-first platform that takes Markdown and publishes via MCP tool call is exactly what an agent-native publishing workflow needs. No web editor to open. No copy-paste. No format twice.

The emporium-publisher skill pushes each approved listing as a post to the dot-emporium blog. The listing is Markdown. Photos are referenced by URL. The slug is the item slug. When a buyer finds the listing, they're reading a scsiwyg post.

That's the left turn: the state pattern that started as a way to remember what a blog had published has become the substrate for running a storefront. The skills are different. The domain is different. The publishing platform is still the same.

→ Browse dot Emporium