Bonna-Moon-Studio/VISION.md

Bonna Moon Studio — the system Bonna actually wants

Captured 2026-08-06, in Bonna's words: "a BEAST of a system that is SUPER easy to use for me day to day... cast a large net and then condense functions down until they're easy to use... I'm looking to build an EXTENSIVE thing."

This is a studio backbone in the FMB sense — a custom back-office app, not the site template plus modules. FMB's backbone (recipes → costed ingredients → stock → orders → schedule → margin/break-even) is the architectural blueprint; this maps bakery concepts to a ceramics + woodworking studio.

The public site (live at bonnamoonstudio.poweredbyotm.com, site template) stays as the storefront/marketing layer regardless.

The feature net (everything named so far)

Studio craft core

• Glaze recipe library — store glaze recipes; the FMB recipe_cost analogue.
• Slipcasting & molds (added 2026-08-06 — Bonna is getting into this soon):
  • Mold library — molds are durable studio assets, like glazes: each gets a page with photos, what it casts, number of parts, plaster notes, and a cast counter (plaster molds wear out — the app should know a mold's age).
  • Casting slip recipes — same recipe system as glazes but a distinct type: slips care about specific gravity AND viscosity/deflocculant (Darvan etc.), and get their own journal (cast times, slip condition).
  • Casting log entries — analogous to firings: which molds, which slip, cast time, results.
  • Pieces gain a "how it was made" (thrown / handbuilt / carved / slipcast / wood) — matters for provenance, pricing, and the learning tables.
  • Mold-making shopping: plaster, cottle boards, sodium silicate/Darvan — the one shopping list absorbs all of it. Phase 1 schema implication: "recipes" are typed (glaze | slip | …) and molds are first-class assets from day one, even if mold screens land a bit later.
• Welding / metal sculpture (added 2026-08-06 — Bonna is "VERY very very new"): no dedicated screens yet — the generic bones carry it. Notes with photos and a "welding" tag become the practice journal (beginner logs are gold later); steel stock, rod, gas, and consumables go in pantry + shopping list; pieces' "how it was made" gains welded. If it grows into a serious line, it earns its own module later (settings that worked, joint notes, material costs per sculpture) — same pattern as everything else: start as notes, graduate to structure when the data asks for it.
• Firing log — notes on firings; over time links glazes ↔ clay bodies ↔ cone/ schedule ↔ results.
• Clay body ↔ glaze compatibility — the system learns what works together, fed by the firing log. (The "learning" is structured data + photos first; smart suggestions later.)
• Glazy integration — hook into glazy.org (the open glaze-recipe database) for recipes, chemistry, and photos of fired results.
• Kiln control — Tony is programming a kiln controller; the backbone should eventually schedule/monitor/fire it. Interface TBD with Tony (hardware project, separate repo presumably).

Studio operations

• Inventory — both raw materials (clay, glaze chemicals, wood stock) and finished pieces; back-end tracking AND shop-facing availability.
• Cost tracking — materials cost per piece, per firing, per line.
• Accounting — "like we have on FMB"; full income/expense books.
• Break-even calculator — FMB has one; generalize it, esp. for market/show applications (fees + travel vs expected sales).

Selling & shows

• Market scanner — scan local markets/art fairs/shows worth applying to; surface deadlines, application costs, distance to travel. Paired with the break-even calc for a "worth it?" verdict.

Daily driver

• Notes — extensive, effortless note-taking with photos (studio notes, piece notes, firing notes all interlink).
• To-do list — "a really good one."
• Calendar — firings, markets, deadlines, commissions.

Design principle

Cast a large net, then condense until easy. Day-to-day ease of use beats feature count. Every screen should answer "what do I need to do/know right now."

Key context: Bonna has been away from her art for ~2 years and is building out a brand-new studio space. There is no existing workflow to preserve — the app and the studio habits get designed together, from scratch. The system's job is to be the "solid organizational net" under her return: she should be able to jump back in and trust that recipes, firings, notes, and tasks are held somewhere that isn't her head. Design for re-entry: low friction, forgiving, encouraging.

Architecture decisions (settled with Tony, 2026-08-06)

1. Code lives here. This repo (Bonna-Moon-Studio on Gitea) IS the backbone's repo — vision, designs, prototype, and eventually production code. Follows the FMB own-repo convention; only shared templates live in the platform monorepo. When Phase 1 is worth hosting, a bms-backbone template entry points at this repo and builds from it. Until then the laptop prototype serves Bonna. (Tony is new to git — Claude drives commits/pushes; Tony reads history on Gitea's web UI.)
2. Two apps, either without the other. Site storefront and backbone stay separate services (own containers/DBs/hostnames), like FMB + its site. Any future site↔backbone integration (shop inventory) is an optional bridge with graceful fallback — decoupled by design, connected by choice.
3. Kiln controller — parked. Tony: "don't worry about this yet." Revisit when the hardware project has a shape; Phase 5 stays last regardless.
4. Market scanner = assisted search + manual seed list. No scraping infrastructure. Claude does periodic hunts for local markets/fairs (deadlines, fees, distance) and logs findings; Bonna seeds/curates the list.

Prototype (built 2026-08-06)

Bonna's product structure (2026-08-06): the reintroduced core line (solid kitchen tools, serveware) alongside small batch / one of a kind work (sculptural pieces, home scenting). The app tracks them "together but separate" — one Pieces tab, distinct sections and behaviors (counts vs statuses). Money tracking starts as price + rough cost estimate per piece with one-tap sales; FMB-style true costing comes with Phase 2 accounting.

Phase 1 exists as a working local prototype in prototype/ — zero dependencies (Node built-ins only), runs via Start Studio Notebook.command in the repo root, data in gitignored prototype/data/. See prototype/README.md for scope. It implements the approved decisions above (jot-first, fill-and-go firings, emoji unload ratings, evidence-only compatibility, batch scaling) and serves as the schema/UX reference for the production build.

Rough phasing (to refine)

• Phase 1 — the notebook: glaze recipes, firing log, notes with photos, materials list. (Highest daily value, zero external dependencies, and it starts accumulating the data the "learning" features need.) A clickable design sketch Bonna liked lives at design/phase1-studio-notebook-mockup.html — soft plum/blush/sage "moonlit studio" palette, Today/Glazes/Firing Log/Notes tabs, jot-box-first capture with optional "file it as…" chips. Note: it uses CSS-only tabs deliberately (preview panes strip scripts).

  Deep screens sketched in design/phase1-glaze-firing-screens.html: a glaze's detail page, new-glaze form, start-a-firing, and unload day. Decisions Bonna has approved:

  • Capture model: jot-first, optional one-tap "file it as…" chips (note / glaze / firing / to-do / piece).
  • Glaze page: recipe as % + scaled batch weights (500g/1kg/2kg/5gal); a "plays well with" clay-body table built ONLY from unload-day evidence, never edited directly; running journal; photo wall; Stull chart ("the chemistry map") computed from the recipe with region overlay (crazed/gloss/semi-matte/ matte/under-fired) — Glazy-style, regions adjusted per cone; other glazes appear as faded dots.
  • Firing lifecycle: plan → load → fire → unload, as explicit steps. Load rows are the piece + clay + glaze triple (this feeds the compatibility learning). Kiln-photo-before-closing nudge.
  • Unload day: one-tap rating per item, emoji scale 😍🙂😕💔 — approved "for now, maybe change in production." One save fans out: pieces → ready-to-sell, glaze pages gain evidence rows, firing closes.
  • New glaze: name-only minimum; cone/atmosphere/surface/source as chips; materials autocomplete from pantry (ties to inventory later); "Save & mix a test batch" secondary action; Glazy paste-to-import deferred to Phase 4.
  • Shopping list (added at Bonna's request): ONE running list for everything — glaze materials, tools, packaging, business cards, stickers, paper goods. Lives on Today; items arrive from jots ("order more wax resist"), from pantry-low signals, or typed directly. Phase 1 scope.
  • Firing flow must not be fussy — Bonna: "the fussier it is, the less likely I am to use the tool… more of a fill the kiln and go kind of girl." The plan→load→fire→unload steps are a trail, not a form: a firing can be started with nothing but type+cone, and the load can be described later, even at unload. Efficient load planning is a someday-nice-to-have, never required.
  • Context on glaze chemistry: Bonna took a course with Katz (Ceramic Materials Workshop) — solid theory, thin practice. Don't dumb the chemistry down; do build experience-confidence (the Stull chart and evidence tables serve exactly this).

• Phase 2 — the business: inventory (materials + pieces), cost tracking, break-even calc, accounting.

• Phase 3 — the calendar & todos: calendar, to-do list, market/show deadline tracking (manual entry first).

• Phase 4 — the reach: market scanner, Glazy integration, shop-facing inventory on the public site.

• Phase 5 — the kiln: controller integration when Tony's hardware is ready.

Phasing is by dependency and daily value, not importance — the kiln being last doesn't mean it matters least.