The canonical "Arduino pin → resistor → BJT base, BJT collector →
load" pattern for multiplexed 7-segment clocks was breaking in the
simulator: getArduinoPinHelper('COM.1') couldn't resolve through
the transistor, so the multiplex-aware 7-segment driver thought no
digit-select pin was wired and fell back to "all digits enabled".
Result: every display in the multiplex array rendered the same
rapidly-changing pattern → user-visible flicker.
Fix: add the NPN/PNP BJTs to the PASSIVE_PIN_PAIRS map with
[collector, base] — the trace function continues from B when it
arrives at C (and vice versa). That makes the Arduino pin driving
the base reported as the controller of the collector — exactly the
relationship the user's multiplex code expects.
Conventions covered:
- NPN (2n2222, bc547, 2n3055): Arduino HIGH → transistor on →
COM pulled LOW → common-cathode digit enabled. Our 7-segment
driver treats "digit pin HIGH = enabled" which matches.
- PNP (2n3906, bc557): inverse logic. We expose the same pin
mapping; users writing PNP-driver code will see the polarity
behave inverted, which is what real hardware does too.
This is a one-line shortcut, not a true active-device model. We're
not simulating BJT saturation, β, base current, or PNP polarity —
just reporting "this Arduino pin is the boss of this collector".
That's enough for the multiplexing use case and the only place
getArduinoPinHelper is consulted today.
The simulator's 7-segment part used to write segments straight into
element.values[0..7] regardless of how many digits the display has and
without considering the COM/DIG select pins. That meant:
- Multi-digit displays (digits=2/3/4) only ever lit digit 0; the
other digits stayed dark even when their DIGn pin was driven.
- For 1-digit displays multiplexed via shared A-G bus + per-display
COM.1 transistor (the canonical Arduino clock pattern), all four
displays showed the same rapidly-changing segment pattern and
rendered as flickering gibberish because COM.1/COM.2 were ignored.
This rewrites the part:
- Per-element state: live segments[] (Arduino-driven A..DP), per-
digit latched digitValues[][], and digitEnabled[] flags.
- Subscribes to the right digit-select pins for the digit count
(COM.1/COM.2 for digits=1, DIG1..DIGn for digits=2/3/4).
- On segment-pin change: writes to segments[] AND mirrors into
every currently-enabled digit's latched slot.
- On digit-pin LOW->HIGH (= enable, transistor-driver convention):
latches the live segments[] into that digit's slot so the first
refresh after enabling reflects the current pattern.
- When NO digit-select pin is wired to an Arduino pin (pure direct
drive, COM tied to GND): all digits default to enabled so segment
writes propagate immediately — preserves the old behaviour for
the simplest single-digit case.
- Rebuilds element.values as a flat array of length digits*8 (the
shape wokwi-7segment-element expects: indices d*8..d*8+7 = digit
d's A..DP).
Result: multiplexed 4-digit clocks built with 4 separate 1-digit
7segments + transistors actually render the four digits as the user
intended. Direct-drive single-digit displays still work unchanged.
The 'raspberry-pi-pico' boardKind used to render <NanoRP2040> — a
<wokwi-nano-rp2040-connect> Web Component. That's a completely
different board: it has pin labels D2..D13 / A0..A7 / 5V / VIN,
and a horizontal 168×68 layout. The actual Raspberry Pi Pico has
GP0..GP28 / 3V3 / VBUS / VSYS and is vertical-narrow (105×264).
Symptom: every wire in a Pi-Pico example that referenced a real Pico
pin (GP10, GP18, 3V3, GND.5, etc.) silently fell back to (0, 0) in
pinPositionCalculator — the calculator looks up `element.pinInfo`
by name, doesn't find GP* on the Nano RP2040 Connect component, and
returns the board's top-left corner. The Pico Doom example was the
loudest casualty (cables to the corner instead of the TFT), but
seven other GP-style examples (pico-7segment, pico-button-led,
pico-rgb, pico-dht22, pico-doom-raycaster, plus pico-ntc/pico-joystick
which use A0/A1 aliases that map to GP26/GP27) all silently routed
to nowhere.
Fix is a two-liner: 'raspberry-pi-pico' shares the same case as
'pi-pico-w' (both use the same Web Component because the Pico and
Pico W are pin-compatible). BOARD_SIZE updated to 105×264 to match
the real Pico footprint. Dropped the now-unused NanoRP2040 import.
Known regression — eleven older examples (pico-blink, pico-serial-led-
control, pico-i2c-scanner, pico-i2c-rtc-read, pico-i2c-eeprom-rw,
pico-spi-loopback, pico-adc-read, pico-multi-protocol, pico-hcsr04,
pico-pir, pico-servo) were wired against D2..D12 of the wrong board.
Their wires will now land at (0,0). Those examples' sketches were
written for the Pi Pico (use LED_BUILTIN = GP25, A0..A3 = GP26..GP29)
so the wires were ALREADY electrically nonsense — they connected
external components to pins the sketch never touched. Visible bug
trades silent bug; both need a follow-up commit to rewire each one
to the Pico pin its sketch actually expects.
Combined with the earlier MADCTL fix (6edc715) and the SPI adapter
fix (6a7b721), Pico Doom should now finally render end-to-end on
velxio.dev.
Build verified (vite OSS+pro, 285 SEO pages).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Long-standing latent bug: SPI parts (ILI9341, custom chips, etc.)
register a handler on simulator.spi.onByte via the lazy adapter, but
the actual rp2040.spi[0].onTransmit assignment in initMCU was a pure
loopback that never consulted the adapter. The MicroPython init path
(initMicroPython) had the adapter-aware version since day one;
the Arduino path (initMCU) didn't.
Symptom: Pico Doom + every other Arduino sketch driving an ILI9341
on the RP2040 saw an empty SPI bus. The ILI9341 emulator's onByte
handler was wired up correctly — it just never received a single
byte. Pantalla negra.
Fix: copy the adapter-aware handler from initMicroPython (line 219)
into initMCU (line 441). Each byte the firmware writes to SPI0 now
checks `_spiAdapter.onByte` first; if a part is registered, it gets
the byte; otherwise we keep the original loopback as the fallback
so plain "echo MOSI back as MISO" sketches still work.
Combined with the earlier MADCTL fix (commit 6edc715) and the
power+MISO wiring fix (8440836), Pico Doom should now render its
title screen + the raycaster.
Build verified (vite OSS+pro, 285 SEO pages).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mirror of the /project/<uuid> pattern but for built-in examples.
Loading an example used to navigate to a generic /editor and lose
all trace of which example was loaded — same URL whether you
clicked Blink or Doom, nothing shareable, no back-button history.
New page: pages/ExampleEditorPage.tsx
- Route: /example/:exampleId (singular, distinct from the plural
/examples/<id> landing).
- useEffect calls loadExample(...) once when exampleId changes,
guarded by a ref so React strict-mode's double-effect doesn't
re-load (which would clobber any edits the user made).
- Renders <EditorPage /> after the load completes — same as how
ProjectByIdPage stays mounted at /project/<uuid> after load.
- SEO: title + description per example, canonical URL points at
/example/<id>.
- 404 state for unknown ids (typo'd link, deleted example).
- Inline install progress while libraries fetch — the overlay
UI moved here from ExamplesPage/ExampleDetailPage so progress
is visible right at the URL you'll bookmark.
App.tsx — registered the new route alongside the existing landing.
Both coexist on purpose:
/examples/<id> = SEO landing page (preview, badges, "Open in
Simulator" CTA). Indexed by Google (130 URLs
already in sitemap.xml).
/example/<id> = live editor with the example pre-loaded; URL
stays pinned so the link is shareable +
bookmarkable like a saved project URL.
ExamplesPage — gallery now navigates to /example/<id> instead of
calling loadExample directly. Also drops the install-overlay block
(progress UI is on ExampleEditorPage now).
ExampleDetailPage — "Open in Simulator" navigates to /example/<id>
instead of loading directly. Drops its own install overlay too.
Side effect: this also kills the data-loss bug from 95f2aa9 in a
second way. Even if a future change forgets to call
clearCurrentProject() somewhere, navigating into ExampleEditorPage
forces a fresh page transition — the previous project's state +
the auto-save subscription don't survive into the example session.
Build verified (vite OSS+pro, 285 SEO pages prerendered).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Critical data-loss bug. Repro:
1. User opens a saved project at /<username>/<slug>. The page sets
useProjectStore.currentProject = { id, slug, ownerUsername, ... }.
Auto-save kicks in and starts watching simulator/editor stores.
2. User clicks the "Examples" link, picks an example, hits Run.
3. loadExample mutates useSimulatorStore (setComponents, setWires,
addBoard, removeBoard) and useEditorStore (loadFiles).
4. Auto-save sees the change. Its eligibility check finds
currentProject still pointing at the user's saved project (we
never touched useProjectStore). It debounces a
PUT /api/projects/<old-id> with the EXAMPLE's components/wires/
files. The user's saved project is overwritten with the example
contents.
The URL changing to /editor isn't enough — useProjectStore is store
state, not router state. ProjectPage / ProjectByIdPage set it on
mount; nothing clears it when the user navigates away.
Fix: loadExample calls useProjectStore.getState().clearCurrentProject()
BEFORE the simulator/editor mutations. autoSaveImpl is subscribed to
useProjectStore via subscribe((s, prev) => ... reset() if id changed),
and Zustand notifies subscribers synchronously inside set(), so the
reset (projectId=null, baseline hash=null) runs in the same tick.
Every subsequent setComponents/setWires/loadFiles fires onChange in
the hook, which now sees projectId=null and returns early. No PUT
ever goes out.
The reset is order-sensitive: it must run BEFORE the store mutations
or the hook would already have queued a save with the old projectId
before we cleared. Comment in the source spells this out so it
doesn't get reordered in a future refactor.
In-flight saves are not affected: buildSavePayload() snapshots state
before its `await updateProject(...)`, so a save that started right
before the example load still sends the user's pre-example state to
the right project. Worst case: the save completes after clear, and
the hook quietly returns idle.
Build verified (vite OSS+pro, 285 SEO pages).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The Pico Doom example loaded with the ILI9341 dangling on three
critical pins:
- VCC — unconnected (no 3V3 from the Pico)
- GND — unconnected (no return path)
- MISO — unconnected
On real hardware the TFT wouldn't power on at all without VCC/GND.
Inside the velxio simulator the missing power isn't strictly fatal
(the simulator drives pixels off the SPI bus, not the rail), but it
makes the schematic incorrect and misleading for users who copy it
to a breadboard. MISO is electrically idle for write-only drivers,
but Adafruit_ILI9341 with the 3-arg constructor binds to hardware
SPI0, so MISO physically maps to GP16 — leaving it floating leaves
the SPI bus topology incomplete.
Wires added:
Pico 3V3 → tft1.VCC (red)
Pico GND.5 → tft1.GND (black) — closest GND pad to GP17/18/19
Pico GP16 → tft1.MISO (amber) — hardware SPI0 MISO
Updated the data-integrity test (examples-pico-doom.test.ts) to
include the three new pairs in the SPI/control/power expectation
map. 10/10 tests pass.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The ILI9341 emulator hardcoded SCREEN_W=240 SCREEN_H=320 and silently
ignored every command except CASET/PASET/RAMWR/SWRESET. The block
comment even bragged about it ("All others are silently accepted —
init sequences, DISPON, MADCTL…").
That's fine for portrait sketches, but every landscape demo —
including the new Pico Doom raycaster — calls tft.setRotation(1) or
setRotation(3). Adafruit_ILI9341 translates those into MADCTL 0x36
with the MV (row/column exchange) bit set, then issues CASET windows
with X∈[0..319] and PASET windows with Y∈[0..239]. The emulator's
bounds check `curX > colEnd` would let curX reach 319, but the
buffer write `id.data[(curY*240 + curX)*4]` would land in a slot
that belongs to a different row — and worse, the SCREEN_W=240
ceiling silently truncated everything past column 239. Net result:
black screen for any rotated sketch.
Fix: parse MADCTL (0x36) and treat CASET/PASET as LOGICAL coordinates.
At pixel-write time, remap (curX, curY) → physical (px, py) using the
MV/MX/MY bits, then write into the still-physical 240×320 imageData.
SWRESET resets MADCTL back to portrait defaults (matches the
datasheet's reset semantics).
MADCTL bit Mask Meaning
D7 MY 0x80 row mirror
D6 MX 0x40 column mirror
D5 MV 0x20 swap X/Y (landscape)
Verified by rebuilding (vite OSS+pro). The fix is data-flow only —
no API change, no new dependency. Pico Doom should now actually
render its title screen + raycast frames in /examples on the
raspberry-pi-pico board.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
addBoard appended the new board to the boards[] array but never
touched activeBoardId. The default INITIAL_BOARD_ID points at a
board the picker injects on first load — but a fresh anonymous
session (or a project that landed in a state without that initial
board) can have activeBoardId pointing at nothing.
When the agent does add_board('arduino-uno') → compile_sketch, step
2 then fails with "no active board on the canvas" and the model
burns a turn on set_active_board.
The fix: at addBoard time, if activeBoardId doesn't resolve to any
existing board, promote the new board to active. If there IS a
valid active board, leave it alone — manual placements of additional
boards via the picker still keep focus on whatever the user was
working on.
New keys across all 9 locales (en/es/fr/de/it/pt-br/ja/ru/zh-cn):
- admin.users.actions.resetAgentUsage — button label
- admin.users.actions.resetAgentUsageTooltip — hover hint
- admin.users.confirmResetAgentUsage — confirm dialog
- admin.users.resetAgentUsageDone — success toast
- admin.users.resetAgentUsageFailed — error toast
Consumed by the velxio-prod overlay's AdminPage Users tab, which adds
a "Reset agent" button per row that hits
POST /api/admin/users/{user_id}/reset-agent-usage and clears today's
pro_agent_usage_events for the user. Live agent quota recomputes
from the events table, so the user can keep using the agent
immediately after the button click.
Two unrelated minimap issues from user feedback:
1. Click on the red viewport rect was sometimes teleporting the
canvas instead of starting a drag. Cause: insideRect compared
click coords against the UNCLAMPED rectX/rectY/rectW/rectH, but
the rendered rect uses clampedX/clampedY (which differ when the
user pans past a world edge). The user clicked on the visible
red rect, but the logical rect was off-minimap → insideRect
returned false → fell through to the teleport branch.
Fix: compute clamped values once at the top, render and hit-test
against the same values. Drag now only fires when the click
really lands inside the visible rect.
2. The 140x105 default still ate too much canvas at typical zoom.
Drop to 100x75 (12% of world width by 2.5%, same proportions as
the world). Mobile breakpoint dropped to 90x68 to stay
proportionally smaller on phones.
User feedback: the default 200x150 minimap eats too much of the
canvas-content area on a typical 13"/14" laptop, and the white
viewport rectangle against a dark canvas blends with the boards
once enough components are placed.
Drop the desktop default down to the size we already use on phones
(140x105 — the mobile media query still wins on screens ≤720px so
that block continues to apply identically). At this size the rect
becomes the focal indicator of where you are in the world; switch
its outline to brand red (#ef4444 — Tailwind red-500) with a faint
red fill so it pops without overpowering the boards (which stay
brand blue).
Body of the work is two number changes + two color tokens; the
rest of the component logic (pointer routing, world rendering,
clamping) is untouched.
After Phase 4 of the OSS / pro split, the OSS code base imports zero
auth/DB modules (verified with grep across backend/app/). But the
requirements.txt + config.py + .env.example + docs still listed
SQLAlchemy, aiosqlite, JWT/bcrypt, OAuth, SECRET_KEY etc. as if they
were live. Self-hosters running `pip install -r requirements.txt`
were pulling ~30 MB of packages the code never imports.
Changes:
* backend/requirements.txt — drop sqlalchemy, greenlet, aiosqlite,
python-jose, passlib[bcrypt], bcrypt, authlib, email-validator,
python-multipart. Keep fastapi, uvicorn, websockets, pydantic,
pydantic-settings, httpx, mcp, esptool, wasmtime — everything OSS
actually uses.
* backend/app/core/config.py — Settings reduced to FRONTEND_URL only.
Comment explains the overlay path that adds the rest at Docker
build time.
* backend/.env.example — same trim: only FRONTEND_URL, with a comment
explaining why this file is almost empty.
* README.md — "Auth & Project Persistence" section rewritten to
describe .vlx export/import. Env-var table reduced to a single row.
Stack table updated: no SQLAlchemy, no JWT, persistence = .vlx
files.
* CLAUDE.md — intro line updated (Auth: None, persistence: .vlx).
Key-file-locations rewritten to list the OSS-stateless backend +
the new lib/proRoutes / proSession / proSaveAction seams, with an
explicit "removed in the split" note pointing to velxio-prod.
Stores section drops useAuthStore (overlay-only now). Backend
gotchas drop the bcrypt + email-validator + model-import notes.
Implemented-features list replaces "Auth + URL persistence + user
profile" with portable .vlx export/import.
* docs/ESP32_EMULATION.md — two `docker run` examples dropped the
`-e SECRET_KEY=...` arg (no longer needed).
OSS build verified end-to-end (285 SEO pages prerender, 20 stateless
routes, zero sqlalchemy imports).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 4 of the OSS / pro split. The OSS image has no auth and no
server-side persistence — without this commit, the user's workspace
was ephemeral (lost on tab refresh). `.vlx` is a single-file JSON
snapshot of the entire workspace (boards, file groups, components,
wires, active board id) that the user can save to disk and reload
later.
New: utils/vlxFile.ts
- buildVlxPayload() / buildVlxBlob() — pure snapshot of the current
editor + simulator stores.
- triggerDownloadVlx({ name? }) — anchor-click download with a safe
filename. Returns the filename actually used.
- parseVlxFile(File) — async reader + validator. Checks
format === "velxio-project", version <= 1, and the required
arrays/objects are present. Throws VlxParseError with a human-
readable message on any issue.
- importVlxFile(File) — convenience wrapper that parses AND calls
useSimulatorStore.loadProjectState() with the result.
Format intentionally mirrors the server's POST /api/projects body so
a Pro user can export-from-pro and import-into-OSS losslessly (and
vice-versa once Pro adds an Export button — out of scope here).
lib/proSaveAction.ts: the default (no-overlay) implementation now
calls triggerDownloadVlx() instead of console.info'ing about the
missing handler. The Pro overlay still wins via installSaveActionImpl()
— Save in Pro keeps opening SaveProjectModal. The Save button in OSS
now actually saves.
components/editor/FileExplorer.tsx: new "Open .vlx" button next to
New + Save. Opens a hidden file input; confirms with the user before
replacing the workspace (loadProjectState is destructive); surfaces
VlxParseError messages via window.alert.
Verified with both builds:
- OSS-only: triggerSaveAction → download .vlx; FileExplorer shows
3 buttons (New, Open, Save).
- OSS + overlay: Pro's installSaveActionImpl overrides — Save opens
SaveProjectModal as before. Open .vlx still works (independent
button, not part of the save flow).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Without the type annotation, FastAPI treats `request` as a Query
parameter and bubbles it up to every endpoint that uses
`Depends(get_current_user_id)`. Result: POST /api/compile/start
and POST /api/compile/ both returned 422
{"loc":["query","request"],"msg":"Field required"} on every call
the frontend made — compile was fully broken in production.
The frontend then caught the 422 axios error and surfaced
response.data as a CompileResult, which had no success/stdout/
stderr/error fields, so the editor's CompilationConsole rendered
only the fallback "✕ Compilation failed" line with no detail.
Annotating `request: Request` is the standard FastAPI pattern;
the framework injects the raw HTTPRequest and no longer treats
it as a query parameter.
Without the type annotation, FastAPI treats `request` as a Query
parameter and bubbles it up to every endpoint that uses
`Depends(get_current_user_id)`. Result: POST /api/compile/start
and POST /api/compile/ both returned 422
{"loc":["query","request"],"msg":"Field required"} on every call
the frontend made — compile was fully broken in production.
The frontend then caught the 422 axios error and surfaced
response.data as a CompileResult, which had no success/stdout/
stderr/error fields, so the editor's CompilationConsole rendered
only the fallback "✕ Compilation failed" line with no detail.
Annotating `request: Request` is the standard FastAPI pattern;
the framework injects the raw HTTPRequest and no longer treats
it as a query parameter.
Phase 3 of the OSS / pro split — frontend side. Phase 2 already moved
the auth/DB stack out of the OSS backend; this commit does the same
for the React app. After this, the OSS image is editor + simulator
+ landing + docs only.
What moved to the private overlay (pro/frontend/src/pro/):
pages/{Login,Register,ForgotPassword,ResetPassword}Page.tsx
pages/{Admin,UserProfile,Project,ProjectById}Page.tsx
components/admin/{AdminBoardsTab,AdminDashboardTab,UserActivityModal}.tsx
components/layout/{SaveProjectModal,LoginPromptModal}.tsx
services/{authService,adminService}.ts
store/useAuthStore.ts
hooks/autoSaveImpl.ts
New seams added so OSS components stay decoupled:
* lib/proRoutes.ts — registerProRoutes()/useProRoutes() via
useSyncExternalStore. mountPro() injects the moved pages at runtime;
App.tsx subscribes to the registry, so registration after the
initial render re-renders without a Not-Found flash.
* lib/proSession.ts — registerSessionCheck()/triggerSessionCheck().
App.tsx fires this on mount instead of useAuthStore.checkSession();
pure OSS no-ops.
* lib/proSaveAction.ts — installSaveActionImpl()/triggerSaveAction().
EditorPage's Save button dispatches through this; the overlay
decides whether to show SaveProjectModal or LoginPromptModal based
on auth state. In OSS without an overlay it's a no-op today; in
Phase 4 of the split it becomes the .vlx Export entry point.
OSS-side rewrites:
* App.tsx drops the 8 page imports + 8 route entries; uses
triggerSessionCheck() instead of useAuthStore directly.
* AppHeader.tsx drops the user/login/register block entirely. The
header-auth slot (introduced in Phase 1) now stays empty in OSS
and gets filled by the overlay's portal mount.
* EditorPage.tsx drops useAuthStore + SaveProjectModal +
LoginPromptModal imports. The Save handler is now triggerSaveAction().
* LandingPage.tsx drops the dead UserMenu component (defined but
never rendered) + its useAuthStore imports.
* main.tsx drops the side-effect import of hooks/autoSaveImpl — the
impl lives in pro now and self-registers via mountPro().
Build config:
* vite.config.ts adds @velxio alias → src/. Lets the overlay import
upstream modules (lib/proRoutes etc.) by stable name regardless of
whether it's symlinked (local dev) or COPYed (Docker).
* preserveSymlinks now gated on VITE_PRO_BUILD only (not on serve
mode). Needed so Rollup keeps the overlay logically inside src/pro/
during local junction-based builds.
Build verification:
* OSS-only: 20-ish routes, no /login, /admin, /:username — 285 SEO
pages prerendered. Bundle drops ~80-120 KB.
* OSS + overlay: full 38 routes (30 upstream + 8 from registerProRoutes),
HeaderAuth dropdown injected via slot, save action wired to the
overlay's modal flow.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Phase 2 of the OSS / pro split. The hook seams introduced in Phase 1
let stateless routes (compile, libraries, simulation, iot_gateway)
run without the auth/DB stack importable. Now we actually delete the
stack:
app/api/routes/auth.py
app/api/routes/projects.py
app/api/routes/admin.py
app/api/routes/metrics.py
app/models/{user,project,usage_event,password_reset_token}.py
app/schemas/{auth,admin,project}.py
app/core/{dependencies,security}.py
app/database/session.py
app/services/{metrics,odoo_mail,project_files}.py
app/utils/{geo,slug,boards}.py
Private deployments (velxio.dev) get the same modules back via the
velxio-prod overlay: pro/backend/app/api/routes/auth.py etc. are
COPYed onto /app/... at container build time, and register_pro()
includes their routers + registers the lifespan/metrics/auth hooks.
main.py shrank back to the stateless router includes + a single
`run_lifespan_startup()` call. The Phase-1 try-import block that wired
record_compile / get_current_user_id from upstream is gone — those
adapters live in pro now.
Verification:
OSS only: 20 routes (compile, libraries, simulation, gateway).
OSS + pro: 94 routes — identical to pre-refactor velxio.dev.
Net change: -2400 lines from OSS, all of which moved to velxio-prod's
overlay. Self-hosted OSS users lose accounts + project persistence;
the Phase 4 .vlx export/import gives them a portable replacement.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
First phase of the OSS / pro split. Goal: open the seams so the auth/DB/admin
stack can move into the private overlay (Phase 2-3) without the routes that
stay in OSS (compile, libraries, simulation, iot_gateway) having to know.
Backend
-------
* New app/core/hooks.py — registry for record_compile, get_current_user_id,
and lifespan startup tasks. Each hook is a no-op by default; overlays
call register_* in register_pro(app) to plug in a real implementation.
* compile.py now imports only from app.core.hooks. Drops the direct deps on
app.core.dependencies, app.database.session, app.models.user, and
app.services.metrics. Route signatures use `Depends(get_current_user_id)`
instead of `Depends(get_current_user)`; the metric helper passes user_id
through rather than a User instance.
* compile_chip.py drops the unused _current_user Depends entirely.
* main.py wraps the auth/DB stack import in try/except. When it succeeds
(today's behavior on velxio.dev), an adapter bridges record_compile and
get_current_user_id to the existing app.services.metrics + dependencies,
and the create_all + ALTER TABLE migration block runs via a registered
lifespan_startup hook. When it fails (the post-Phase-2 OSS image), main
logs "running stateless" and skips registering anything — the routes
still load and behave as no-ops for metrics + always-anonymous for auth.
Frontend
--------
* useAutoSaveProject becomes a skeleton: one useState + one useEffect that
delegates to an installed AutoSaveImpl. installAutoSaveImpl() replaces
the impl without changing hook count, so React's rules-of-hooks stay
satisfied even after the impl moves out of OSS.
* New hooks/autoSaveImpl.ts holds the original logic (debouncing, dirty
detection, owner eligibility, fetch keepalive on unload), refactored to
emit() instead of useState. It self-registers at module load; main.tsx
imports it for the side effect.
* AppHeader wraps the entire user-vs-login UI in a data-velxio-slot
="header-auth" boundary. Today the OSS UI still renders inside the slot
— the overlay can portal-inject additional items now, and in Phase 3
the slot becomes the sole owner of header auth UX.
Behavior is identical on velxio.dev (pro overlay imports everything
successfully, every adapter wires up). The change is purely structural:
deleting the auth/DB modules tomorrow no longer crashes OSS at import.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
index.html ships a #root-seo div with prerendered SEO content (so crawlers
that don't run JS still index per-route copy). The inline CSS comment said
"React removes it on mount", but nothing actually removed it — so every
page kept a position:absolute, ~4096px-tall, visibility:hidden element
parked at top:0. That element does not paint, but it DOES contribute to
document.documentElement.scrollHeight.
Symptom: /admin, /docs, /:username and other short pages had a phantom
scroll roughly the size of the prerendered SEO body. Scrolling past the
real content showed a black band (just the body background) because there
was nothing visible to render down there. When tab content loaded with
more rows, the real content outgrew the phantom and the scrollbar "settled
in" — matching the user-reported symptom exactly.
Verified with puppeteer against velxio.dev:
/dave: documentElement.scrollHeight 4096 → expected ~800 after fix
/admin: documentElement.scrollHeight 4096 → expected ~800 after fix
/docs: documentElement.scrollHeight 4096 → expected ~1161 after fix
The removal runs inside App's mount-effect, so it only fires after React
has actually committed — if App were to throw during render, the SEO
fallback would stay in the DOM as intended.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
arduino-esp32 v2.0.17's libraries/WiFiClientSecure/src/ssl_client.cpp:23
wraps its entire body in:
#if !defined(MBEDTLS_KEY_EXCHANGE__SOME__PSK_ENABLED) \
&& !defined(MBEDTLS_KEY_EXCHANGE_SOME_PSK_ENABLED)
# warning "Please call idf.py menuconfig ..."
#else
ssl_init / start_ssl_client / stop_ssl_socket /
send_ssl_data / get_ssl_receive / data_to_read
#endif
Our esp-idf-template/sdkconfig.defaults did not enable any PSK key-exchange
mode, so MBEDTLS_KEY_EXCHANGE_SOME_PSK_ENABLED was never auto-set by
mbedtls and ssl_client.cpp compiled to an empty translation unit. The
companion WiFiClientSecure.cpp still compiled and ended up in
libarduino-esp32.a with dangling references, breaking the link of every
sketch that pulls in HTTPClient or WiFiClientSecure (directly or
transitively).
Reproduced against the user's WiFi + HTTPClient example.com sketch on the
prod server and again locally with ESP-IDF v4.4.7 + arduino-esp32 v2.0.17;
the prebuilt sdkconfig that ships with arduino-esp32 itself sets both
flags, so we just align with that.
After the fix the same sketch links cleanly:
velxio-sketch.bin binary size 0xbf470 bytes ... 25% free
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two minimal hooks so the velxio-pro agent overlay can offer a 'Diagnose
this compile failure with AI' affordance without touching upstream
component internals:
- New store/useCompileLogsStore: holds the editor's compile output as
Zustand state instead of local React useState in EditorPage. The
setter accepts both a value and an updater fn so the EditorToolbar
callers that used setCompileLogs(prev => [...prev, log]) keep
working without changes.
- CompilationConsole header now renders a
<div data-velxio-slot='compile-console-actions' /> when errorCount
> 0. The pro overlay mounts a 'Diagnose with AI' button into this
slot via slotMounter. Empty in the OSS image — no behaviour change.
EditorPage replaces its local useState<CompilationLog[]> with the store
selector. The downstream prop-drilled setCompileLogs callers (toolbar,
sub-toolbars) keep their signature.
Companion commit lands the button + diagnostic prompt builder in the
velxio-prod overlay.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Mirrors the velxio-prod backend quota bump (PLANS dict in
pro/backend/app/pro/services/quota.py). With 9router serving the bulk
of agent traffic for free, the cost-of-LLM ceiling is much lower than
when the limits were originally tuned, so we can be significantly more
generous and let casual users actually evaluate the agent.
Free 20 /day, 300 /mo → 100 /day, 1500 /mo
Pro 400 /day, 12k /mo → 500 /day, 15k /mo
Pro Max 1000/day, 30k /mo → 2000 /day, 60k /mo
Updates the landing.pricing.tiers.{free|pro|pro_max}.f1 string in all
9 locales (de, en, es, fr, it, ja, pt-br, ru, zh-cn) with each
locale's native thousands separator (',' / '.' / ' ' depending on
convention).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
After the Dockerfile.standalone refactor (PR #182), the qemu-provider
stage requires VELXIO_LICENSE_KEY to fetch libqemu .so + ESP32 ROM
blobs from velxio.dev's gated download endpoint. The Publish Docker
Image workflow was missing the build-arg, so it failed on every push
to master and the GHCR / Docker Hub :master image went stale.
Plumbs the existing repo secret VELXIO_BUILD_LICENSE_KEY into
docker/build-push-action@v6's build-args list. Same secret the
backend-e2e-tests workflow already consumes — single source of truth.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The qemu-prebuilt GitHub Release was the convenience-binary hosting
path before we shipped the license module. With the license module
live at /api/pro/license/downloads/, the prebuilts now live there
behind a free personal-tier key.
Dockerfile.standalone:
- New build-args VELXIO_LICENSE_KEY + VELXIO_BINARY_BASE_URL
- prebuilt/qemu/ local files still win first (lets users compile
QEMU from source per docs/BUILD-QEMU.md and use that instead)
- Legacy QEMU_RELEASE_URL kept as escape hatch for private mirrors
- Fail-fast with a friendly message if no path is configured
backend-e2e-tests workflow:
- Reads secrets.VELXIO_BUILD_LICENSE_KEY (set in repo settings)
- Uses the gated URL pattern; same fallback message on missing key
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds a transparent self-hosting path for users who would rather not
run Velxio's prebuilt libqemu binaries. The prebuilts have always
been a convenience under the AGPLv3 license; this just documents
how to skip them.
- docs/BUILD-QEMU.md as the canonical step-by-step (dependencies per
Debian/Arch/macOS, ESP32 xtensa + ESP32-C3 riscv32 configure-and-
ninja, drop-in instructions, troubleshooting, license notes on the
QEMU/Velxio GPL-vs-AGPL boundary).
- DocsPage gets a new 'build-qemu' section between Setup and Roadmap
in the sidebar. Content is hardcoded English (technical reference,
not marketing copy) and ends with a link to the .md on GitHub.
- nav + SEO meta keys added to all 9 locales (de en es fr it ja
pt-br ru zh-cn). Body remains English in every locale; technical
content doesn't need translation for the audience that follows it.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The /pricing page exists (PricingPlaceholder upstream, real PricingPage
portal-mounted by the private overlay) but had no entry in the top nav.
Adds 'pricing' to header.nav in all 9 locales (de, en, es, fr, it, ja,
pt-br, ru, zh-cn), wires the Link in AppHeader between About and Blog,
and mirrors the link in the landing-page footer.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
A new entry in the games category for the Raspberry Pi Pico. Renders
a first-person 3D corridor à la Wolfenstein / early Doom using a
column-wise DDA raycaster — 160 rays per frame drawn straight to a
320×240 ILI9341 TFT via drawFastVLine, no framebuffer. 16×16 tile map
with 5 wall palettes (slate, blood, brown, toxic green, bronze door),
darkened on NS faces so corners read in 3D. Forward / back move,
two more buttons turn the player. 40-px HUD bar.
Why a demo, not the canonical id Software Doom: Graham Sanderson's
rp2040-doom port shoehorns DOOM1.WAD into 2 MB of flash with custom
compression and pushes video out over PIO-driven DVI / VGA — none of
that survives the rp2040js emulator (no PIO accuracy, no flash
mapping for huge assets). A raycaster reproduces the *visual* of
early Doom using only ~67 KB of flash and 9 KB of RAM, which the
emulator runs perfectly.
Pre-flight: arduino-cli compile against rp2040:rp2040:rpipico
already verified inside the Velxio backend container — 3 % flash,
3 % RAM. The Adafruit_GFX + Adafruit_ILI9341 libs the example
declares are already in the gallery's auto-install list.
Bundled:
test/pico_doom_demo/arduino_sketch.ino — source of truth sketch
test/pico_doom_demo/README.md — what + why + pin map
test/pico_doom_demo/compile_check.sh — operator script that
runs arduino-cli against the same FQBN the prod backend uses
frontend/src/data/examples.ts — gallery entry (boardType
raspberry-pi-pico, category games, difficulty advanced, 5
components, 14 wires)
frontend/src/__tests__/examples-pico-doom.test.ts — 10 vitest
assertions: example is registered exactly once, target board /
category / difficulty match, libraries declared, all four
pushbuttons present, every wire endpoint references a real
component id, SPI pin mapping matches the sketch's #define
block, every button has a GND wire, the renderFrame loop is
still present in the embedded code.
Renders a 200×150 px overview of the whole 4000×3000 world in the
bottom-right corner of .canvas-content. Boards show as filled blue
rectangles, components as small white dots, and the current viewport
appears as an outlined rectangle the user can drag to pan.
Geometry mirrors the canvas's existing pan+zoom model:
SCALE_X = MINIMAP_W / WORLD_W = 0.05
rect.x = -pan.x / zoom * SCALE_X
rect.w = viewport.width / zoom * SCALE_X
Two interaction modes, decided at pointerdown by hit-testing the
rectangle:
- Inside the rect → drag-pan: keep updating pan as the pointer
moves, with delta in minimap-px converted back to world units
by (delta / SCALE) * zoom.
- Outside the rect → teleport: re-center the viewport on the
clicked world point.
Pan is clamped so the viewport rectangle never escapes the minimap
bounds (matches the canvas's implicit world boundaries at 4000×3000).
ResizeObserver on the canvas-content keeps the rect accurate when
the user toggles side panels or resizes the window.
Mobile: at ≤720 px width the minimap shrinks to 140×105 px so it
doesn't eat too much of the canvas. Touch events go through the same
pointerdown / pointermove path — no separate touch code path needed
thanks to Pointer Events.
Bundles with: matching CSS file, import + JSX hookup inside
.canvas-content's render tree.
Two small fixes that compound:
1. Drop LLM model names from the landing AI section. The agent
auto-routes between several providers (9router combo, direct
DeepSeek, direct Gemini, future-others) and naming any of them on
the homepage misleads visitors. Replace "DeepSeek-V4-Flash and
Gemini 2.5 under the hood" with "frontier LLMs auto-routed for
cost and reliability" so the marketing line stays accurate as the
provider mix changes.
2. Pricing copy switches from absolute message counts (300/day,
700/day — small, intimidating, hard to anchor) to comparative
multipliers (Pro = 20×, Pro Max = 50×). Visitors instinctively
read these as "much more" without needing to count usage. The
multipliers reflect the new backend quotas (400/day, 1000/day,
committed separately in velxio-prod's pro overlay).
3. --color-bg-canvas moves from gray-1000 (#000000) to gray-950
(#0a0a0c). Pure black collided with the slightly-lighter card
surface (gray-900 #141416) and produced a harsh transition wherever
a `min-height: 100vh` page wrapper grew taller than its content —
visible on docs and user-profile pages with sparse content. The
2-luminance-step shift removes the jarring while keeping the dark
palette feel intact. gray-1000 stays in the scale for intentional
black uses.
All 9 locales updated for (1) and (2).
Two new sections on the landing page, between Features and Support:
1. "Powered by AI agents" — three cards explaining the in-editor agent
(place & wire parts, generate code, diagnose circuits). Calls out
DeepSeek-V4-Flash + Gemini 2.5 as the LLM backbone so visitors know
the simulator does more than draw boxes.
2. "Pricing" — three cards summarising Free / Pro / Pro Max with the
actual monthly cost, the daily AI-message quota, and a CTA per
tier. Pro is highlighted as Most Popular. Free CTA opens the editor,
the two paid CTAs link to /pricing where the PayPal subscription
flow lives.
The simulator itself stays free — only the AI-agent quota changes per
tier — that copy is repeated in the section subtitle so visitors don't
worry about the boards/components becoming paywalled.
All 9 locales translated.
Closes the long-standing "components are frozen during simulation"
complaint. Once the user clicked Run, interactive wokwi parts
(pushbuttons, slide-switches, potentiometers …) called
stopPropagation in their bubble-phase mousedown handlers and the
canvas's React onMouseDown never fired — so dragging them to
rearrange the layout was impossible without first stopping the sim.
Two surgical changes:
1. DynamicComponent.tsx switches the wrapper from `onMouseDown` to
`onMouseDownCapture`. Capture phase runs before the inner
wokwi-element, so the canvas sees the mousedown regardless of
stopPropagation downstream. The existing posDiff < 5 check in
mouseup keeps disambiguating click vs drag: a click still falls
through to the wokwi-element's own mousedown/up for button-press
semantics, only sustained movement promotes to a drag.
2. SimulatorCanvas.tsx's touch path used to early-return on touchstart
when interactionRunning + .web-component-container, killing any
chance of a touch-drag. Now we remember the touch's start position
in pendingTouchDragRef and let the browser keep synthesizing mouse
events for the wokwi-element. If the finger drifts past
DRAG_PROMOTE_THRESHOLD_PX (8 px) onTouchMove cancels the
passthrough and starts a real component drag — dispatching a
synthesized mouseup on the original target so the wokwi-element
doesn't stay visually pressed mid-drag.
Adds a two-card section at the foot of the landing page (before the
brand footer) that surfaces Velxio's licensing model: AGPLv3 for the
public release, commercial license for teams that need to ship
Velxio inside closed-source products. Mirrors the existing
.feature-card visual language so it slots into the page without a
new design system.
Commercial CTA opens a mailto:info@velxio.dev. Open-source CTA links
to GitHub via the existing trackVisitGitHub handler so the analytics
event still fires.
All 9 locales translated.
In digital / analog board-less examples the user clicks a slide-switch
or pushbutton expecting it to flip its state. Until this commit the
component property dialog opened instead and the click never reached
the wokwi-element underneath, so:
- The user couldn't change switch state through the canvas at all.
- With no state change the SPICE solver kept the old netlist, and
every downstream LED stayed dark — the symptom that read as
"voltages change but no LED lights".
Root cause was the gating: SimulatorCanvas only suppressed the
property dialog when `useSimulatorStore.running` was true, but that
flag is bound to an MCU's start/stop. Board-less circuits have no MCU
to start so `running` is permanently false, even when the SPICE engine
has been live since the example loaded.
New derived flag `interactionRunning = running || (boards.length === 0
&& !electricalPaused)` — true whenever the user is in an "interactive"
session, MCU or SPICE-only. Used in three click-handling paths:
- SimulatorCanvas mouse-up handler: dialog is suppressed and the
click falls through to the wokwi-element (line 1395).
- SimulatorCanvas touch-start passthrough: same for touch (line 474).
- SimulatorCanvas touch-end short-tap: same for tap (line 774).
Also propagated to DynamicComponent so the cursor becomes pointer (not
move) for interactive parts in board-less mode — visual cue that the
user can click instead of just drag.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
davidmonterocrespo24