ESP32-S3 Bench Guide
ESP32-S3 N16R8 bench guide: live pinout, lessons, simulators and the bench log.
翻譯準備中
尚未偵測到更新。GitHub 發布版本後會顯示在這裡。
個人 GitHub 帳號下公開儲存庫的擁有者可以登入並驗證所有權,自行管理介紹,無需管理員核准。
登入並產生驗證檔案,在 30 分鐘內將其提交至此儲存庫的預設分支。其他分支或分叉儲存庫中的檔案無效。然後在下方檢查檔案,即可無需管理員核准直接管理專案。請保留檔案以維持管理權限。
如需登入,將前往登入頁面。登入後請回到此處,再次點擊所選的驗證按鈕。
在專案資料夾中執行 /nomorevibe verify,即可驗證所有權並自行管理介紹。
一分鐘完成驗證正在載入完整 README。 以下為已儲存的摘錄。
A marketplace connecting parents with children's activities and classes in Singapore. Two Vite single-page apps (a parent app and a vendor portal) share a single Next.js backend (API routes + webhooks) on top of Supabase, with GetStream for chat and Stripe for payments.
• app/ — Next.js API routes, webhooks, and middleware
• frontends/parent/ — parent-facing Vite SPA (served at /app/)
• frontends/vendor/ — vendor portal Vite SPA (served at /vendor/)
• lib/, supabase/ — shared server helpers and database migrations
• docs/ — architecture notes檢視完整 README ↗A marketplace connecting parents with children's activities and classes in Singapore. Two Vite single-page apps (a parent app and a vendor portal) share a single Next.js backend (API routes + webhooks) on top of Supabase, with GetStream for chat and Stripe for payments.
app/ — Next.js API routes, webhooks, and middlewarefrontends/parent/ — parent-facing Vite SPA (served at /app/)frontends/vendor/ — vendor portal Vite SPA (served at /vendor/)lib/, supabase/ — shared server helpers and database migrationsdocs/ — architecture notesSee docs/backend-architecture.md and docs/vendor-architecture.md for detail.
| Doc | Covers |
|---|---|
| docs/backend-architecture.md | Parent/backend data model, RLS, triggers, recommendations |
| docs/vendor-architecture.md | Vendor portal backend, roles, bookings/waitlist, attendance |
| docs/SETUP.md · docs/vendor-setup.md | First-time setup, env, Stripe/Stream/Resend wiring, API contract |
| docs/vendor-scraping.md | Apify-based vendor directory refresh (with WordPress fallback) |
| docs/OPERATIONS.md | Ops runbook, scheduled jobs, maintenance schedule, incident playbooks |
Chat runs on GetStream. There are three flows, all gated by Supabase auth, with every client minting its token from /api/vendor/chat/token:
| Flow | Parent UI | API route | Who's in the channel |
|---|---|---|---|
| 1:1 enquiry (personal query) | EnquiryChat.tsx | /api/vendor/chat/start | parent + provider staff |
| Class group chat | ClassGroupChat.tsx | /api/chat/class-group | every parent booked in the class + provider staff |
| Support | /support | /api/chat/token | parent + BabyBrain support |
The vendor never needs to open a channel explicitly — MessagesPage.tsx lists every channel the vendor is a member of, so both the 1:1 enquiry and the class group appear in its inbox automatically. Creating or joining the class group is gated to parents with a live booking (pending / confirmed / completed); the provider's active staff are added as members so the vendor is present to answer.
The repo is indexed into a queryable knowledge graph with Graphify — 1174 nodes · 2056 edges · 83 communities, built entirely from local AST parsing (no API calls). Outputs live in graphify-out/:
graphify-out/graph.html — interactive, clickable graph (open in a browser)graphify-out/GRAPH_REPORT.md — key concepts, community hubs, and suggested queriesgraphify-out/graph.json — full graph data for programmatic accessRebuild and query it (offline, zero API cost):
export PATH="$HOME/.graphify-venv/bin:$PATH"
graphify update . # rebuild after code changes
graphify query "how does booking work" # navigate the repo by question
graphify explain "getStreamServerClient" # explain a symbol and its neighbours
npm run dev # Next.js backend
npm --prefix frontends/parent run dev # parent SPA
npm --prefix frontends/vendor run dev # vendor SPA