# 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.

## Open architecture questions (for Tony + Bonna)

1. **Where does the code live?** Platform templates live in the platform monorepo
   with a build chain (per CLAUDE.md, authoring a new template = days). Options:
   new `bms-backbone` template in the monorepo (FMB convention), or app code in
   this repo with its own build. FMB convention suggests the former.
2. **One app or two?** Backbone (admin/ops) + existing `site` storefront, like
   FMB + fullmoonbakehouse.poweredbyotm.com. Probably: keep them separate,
   integrate inventory → shop later.
3. **Kiln controller interface** — what protocol/API will Tony's controller
   expose? Drives how "fire my kiln" lands in the app.
4. **Market scanner data source** — scraping? manual seed list + assisted search?
   This one needs a feasibility pass; deadlines/fees aren't in any clean API.

## 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/](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](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](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](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.