Files
Bonna-Moon-Studio/VISION.md
Bonna cd83fd61cb Studio Notebook: vision, Phase 1 designs, and working prototype
- VISION.md: the full studio-backbone product vision (craft core, operations,
  selling, daily driver), Bonna's approved design decisions, and phasing
- design/: two clickable Phase 1 mockups (moonlit palette, CSS-only tabs)
- prototype/: zero-dependency local app (Node built-ins + SQLite) — Today with
  jot-first capture + subtask outliner, Clay & Glazes library, fill-and-go
  Firing Log with emoji unload ratings feeding evidence tables, Pieces with
  core line/tiles/one-of-a-kind + money card, Files with per-piece attachment,
  Sourcing with price ledger + live supplier search links (9 suppliers seeded)
- CLAUDE.md: access notes updated for the provisioned site + this repo's state

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-06 21:46:54 -05:00

9.9 KiB

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/ — 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.