Laurence
031074c9a9
Bootstrap of the project (M0). Sets up the monorepo, design docs, hardware BOM, the open API contract, component skeletons, licensing and CI, following the Default Workflow SOP. What changed: - CLAUDE.md + docs/: copied the Default Workflow so sessions load the SOP. - state/: PROJECT, ARCHITECTURE, DECISIONS, TODO, NOTES filled in for OpenScribe. ARCHITECTURE captures the four-part design (firmware, server, app, case) and the three sync paths; DECISIONS records the hardware, AI-stack, storage, app and licensing choices; TODO lays out milestones M1-M9. - hardware/BOM.md: two build options (compact XIAO ESP32-S3 Sense; dev ESP32-S3 + I2S mic + SD), wiring/pinout, indicative cost. - api/openapi.yaml: the completely open API (device + server surfaces), including recording list/download/delete and exports (wav/ogg/txt/srt/vtt/md/json). - firmware/: PlatformIO ESP32-S3 project, two board profiles, pin map, boot scaffold with module seams for M1-M4. - server/: FastAPI skeleton mirroring the OpenAPI, config for self-hosted MinIO, faster-whisper and Ollama; stub routes browsable at /docs. - app/, case/: Flutter app plan; parametric OpenSCAD enclosure. - Licensing: GPL-3.0 (code), CERN-OHL-S-2.0 (hardware), CC-BY-SA-4.0 (case/docs), REUSE-style LICENSES/ with SPDX headers; LICENSING.md explains the split. - CI: Forgejo Actions workflow builds firmware (both profiles) and lints/imports server. Why: - Everything self-hosted and openly licensed per the user's requirements: an open API, three sync paths (BLE control, WiFi transfer, independent WiFi upload on charge to generic cloud storage), and a full self-hosted transcription+summary stack. Notes: - No custom PCB in v1; off-the-shelf modules. Physical verification waits on parts. - Component code is stubs at M0; features land milestone by milestone, each as its own branch/PR per the workflow. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
46 lines
1.8 KiB
Markdown
46 lines
1.8 KiB
Markdown
# User expectations
|
|
|
|
How the user expects a Claude Code session to behave under this workflow. Read this
|
|
once per session; it rarely changes.
|
|
|
|
## Work autonomously
|
|
|
|
Do not stop to ask which task to pick up next, or for confirmation before routine work.
|
|
Default sensibly and keep shipping. Read `state/TODO.md`, choose the next sensible
|
|
item, do it. Only ask when a decision is genuinely the user's to make and cannot be
|
|
resolved from the repo or sensible defaults.
|
|
|
|
## Cost before speed
|
|
|
|
Staying within usage limits is more important than finishing fast or gold plating.
|
|
When in doubt, take the cheaper path. See [Cost and tokens](cost-and-tokens.md).
|
|
|
|
## Leave a clean trail
|
|
|
|
Every feature ends as: a merged branch, full commit notes, a complete PR, current
|
|
`state/` files, and code commented well enough to document later. The user should be
|
|
able to open the repo weeks later, with no memory of the session, and understand what
|
|
happened and why from the repo alone.
|
|
|
|
## Report honestly
|
|
|
|
If tests fail, say so with the output. If a step was skipped, say that. If something is
|
|
done and verified, say so plainly without hedging. Do not claim more than was done.
|
|
|
|
## Writing style
|
|
|
|
- No em dashes in prose. Use commas, full stops, or restructure.
|
|
- British spelling in prose and copy. Preserve code identifiers as written.
|
|
- Plain, direct language. Say what happened.
|
|
|
|
## Confirm before the hard to reverse
|
|
|
|
Routine coding is autonomous. But confirm first for actions that are hard to undo or
|
|
that reach outside the repo: force pushes, history rewrites, deleting things you did
|
|
not create, deploying, or sending data to external services. Approval for one such
|
|
action does not carry to the next.
|
|
|
|
## The building session stops at merge
|
|
|
|
Do not write the user facing documentation in the building session. That is a separate
|
|
session's job. See [Documentation policy](documentation-policy.md).
|