ESP32-S3 Bench Guide
ESP32-S3 N16R8 bench guide: live pinout, lessons, simulators and the bench log.
A practice-planning tool for musicians learning new pieces
Translation pending
EducationJavaScript · PLpgSQLGitHub @ChopinbbyOnlineOwner unconfirmed
Have you tried it? One tap is enough. No sign-in needed.
No updates detected yet. GitHub releases will appear here.
Owners of public repositories under a personal GitHub account can sign in to verify ownership and manage the introduction themselves. No administrator approval is needed.
Sign in, generate a verification file, and commit it to this repository’s default branch within 30 minutes. Files on other branches or forks do not count. Then check the file below to manage the project without administrator approval. Keep the file to retain your access.
If needed, you will go to sign-in. After signing in, return here and press your chosen verification button again.
Run /nomorevibe verify in your project folder to verify ownership and manage the introduction yourself.
Verify in one minuteAsk about other verification options
Loading the full README. The saved excerpt is shown below.
This directory is the canonical, long-term knowledge base for MeasureOne —
product vision, design philosophy, algorithms, data model, architecture, and
decision history. It's written to serve four audiences: future Claude Code
sessions, human developers, future-you months or years from now, and any
collaborator who joins the project cold.
For code-level operating instructions (how to run the app, conventions to
follow while editing, gotchas) see ../CLAUDE.md at the repo
root — that file is what Claude Code auto-loads every session. This
directory is the deeper reference it points into.Read the full README ↗This directory is the canonical, long-term knowledge base for MeasureOne — product vision, design philosophy, algorithms, data model, architecture, and decision history. It's written to serve four audiences: future Claude Code sessions, human developers, future-you months or years from now, and any collaborator who joins the project cold.
For code-level operating instructions (how to run the app, conventions to
follow while editing, gotchas) see ../CLAUDE.md at the repo
root — that file is what Claude Code auto-loads every session. This
directory is the deeper reference it points into.
If you're new to the project, read in this order: Vision.md → Product-Principles.md → UX-Principles.md → User-Flows.md. That's the "what and why" layer. Go to Data-Model.md and Algorithms.md when you need the "how."
If you're an AI assistant about to make a change, read AI-GUIDELINES.md first — it tells you which of the other documents to consult for which kind of change.
If you just want to know what to work on next, go straight to Roadmap.md.
| Document | Answers |
|---|---|
| Vision.md | What is MeasureOne for, and what is it deliberately not? |
| Product-Principles.md | What rules govern whether a feature belongs? |
| UX-Principles.md | How should things look, feel, and behave? |
| User-Flows.md | What does a user actually click through, end to end? |
| Repertoire-Lifecycle.md | What happens to a piece over its full life in the app — including the parts not built yet? |
| Data-Model.md | What data exists, and what does each field/concept mean? |
| Algorithms.md | How is each computed value actually calculated? |
| Research.md | Which numbers are hand-tuned vs. evidence-backed, and what's still unknown? |
| Architecture.md | How is the code organized, and how should it be split up? |
| Decisions.md | Why were things built this way, and what was rejected? |
Every document above states its own purpose, audience, scope, and related documents at the top, and says when it should be updated. Each concept has exactly one canonical home — if you find the same explanation in two places, that's a bug in the documentation; collapse it to one and link from the other. See AI-GUIDELINES.md.
This docs/ set was created from a documentation audit (see
Decisions.md) that found two prior sources of
truth: CLAUDE.md (implementation-focused, in-repo) and a
measureone-context-summary.md file that held real product-decision history
but lived outside the repository entirely, in a local Downloads folder,
invisible to anyone working from the repo alone. Its content has been folded
into this directory — primarily Decisions.md and
Roadmap.md — and should be treated as superseded going
forward; nothing should be assumed to live only in that external file
anymore.
| Roadmap.md |
| What's done, what's next, in what order? |
| Technique-Practice.md | How does daily scale and arpeggio practice work, and what shipped differently from the brief? |
| Accounts-and-Backend.md | How will optional accounts and the account copy of your data work (Supabase, local first), and in what order is it built? Phase 1 built (Passes 105-114) and live since go-live, 2026-10-10. Phase 2 is well under way: Passes 115-123 are live (the app notices changes made on another device; tabs of one browser stay in step; changes can arrive by themselves behind a switch that is off by default; a held piece asks plain questions; a piece deleted on one device is deleted everywhere, with a 30-day way back; what you said no to is remembered and the most recent reorder wins; the app opens with no connection after one visit with one). Turning the switch on by default (124) is next. |
| SOW-Accounts-and-Sync.md | Why accounts and a backend at all, in plain language, and what could go wrong? Written 2026-09-27, before any code, and kept as written; Accounts-and-Backend.md is the design that followed. |
| AI-GUIDELINES.md | How should an AI assistant work in this project? |