First generated site!!! Pipeline finally works!

devlog 002

date: july 10, 2026
project: car vault

what i did

since devlog 001, i worked on making the project more complete after getting feedback on the submission.

the main feedback was that the project needed a better prototype of the software and firmware, plus a cad assembly showing where all the parts would go.

firmware and software

i added prototype esp32-s3 firmware for:

• reading the wheel encoders
• controlling the motors
• pid motor control
• receiving commands from the raspberry pi
• stopping the motors if communication is lost

i also added prototype raspberry pi software for:

• reading the usb camera
• running the vision model
• communicating with the esp32-s3
• creating an occupancy grid
• a* path planning
• sending motor commands
• a placeholder structure for slam

the code is still a prototype and is not fully tested yet, but it shows how the full system is supposed to work.

cad assembly

i worked on the cad assembly several times because the first versions did not look like the actual planned robot.

i changed it so it uses the real:

• chassis base stl
• front skid stl

then i added simple placeholders for:

• raspberry pi 5 and ups
• esp32-s3
• drv8833 motor driver
• imu
• logic-level shifter
• motor battery
• camera
• motors and wheels

i kept the final version basic because it is mainly supposed to show where the parts go, not pretend that the robot is already fully designed.

fusion conversion

i also converted the basic stl assembly into a fusion-compatible step assembly.

the assembly was split into separate named parts so they can show up separately inside fusion instead of being one giant stl mesh.

i made:

• the main step assembly
• separate component step files
• a component map
• a preview image
• a fusion import package

raspberry pi settings

i tested overclocking the raspberry pi 5 to 3 ghz, but decided not to use that as the normal project setup.

the robot will use the stock clock for better stability, lower heat, and longer battery life. the 3 ghz overclock will only be used later as an optional performance mode for heavy vision or slam testing.

what is done now

• prototype esp32-s3 firmware
• prototype raspberry pi software
• vision model structure
• slam and a* software structure
• basic cad assembly
• fusion-compatible step assembly
• separate cad components
• updated hardware layout
• stable raspberry pi power/performance plan

what is still not done

the robot is still not physically built or tested.

i still need to:

• order the parts
• 3d print the chassis
• assemble everything
• test the power system
• test the motors and encoders
• test the camera and imu
• test the vision model
• tune pid
• get slam working
• test autonomous navigation

reflection

this part of the project was mostly about turning the original idea into something that looks more planned and buildable.

the firmware and software are still prototypes, and the cad assembly is still basic, but now the project shows both how the robot will be programmed and where the hardware will actually go.

turning onara into
Google Business Profile → website → quote form → missed-call recovery → lead inbox → booked job follow-up

devlog 001

date: july 5, 2026
project: car vault

what i did

today i worked on getting my stardance submission ready for car vault. the goal is to build an indoor robot car that can do slam, mapping, a* path planning, and pid motor control.

main setup

• raspberry pi 5 for slam, mapping, camera, and path planning
• esp32-s3 for encoders, pwm, pid motor control, safety stop, and telemetry
• usb camera for vision
• mpu6050 imu for orientation
• n20 encoder motors for movement
• drv8833 motor driver
• 3d printed chassis and front support
• raspberry pi 5 ups/battery power

big change

i switched the low-level controller from arduino uno to esp32-s3 because i want the first version to be closer to the final version. the esp32-s3 is faster, more modern, and better for this kind of robot.

i also added a logic-level shifter so the esp32-s3 does not get damaged if the encoder signals are 5v.

bom cleanup

i cleaned up the parts list and removed stuff i do not need, like the acrylic sheet and ball caster. i am 3d printing the chassis and front support instead.

i also added a cheaper raspberry pi 5 ups/battery setup so the robot can run without being plugged into the wall.

files finished

• readme.md
• bom.csv
• selected_parts.md
• submission_summary.md
• submission_validation.md
• power_subsystem.md
• budget_notes.md
• assets folder
• cad folder
• firmware folder
• software folder

what is done

the stardance folder is basically ready to upload to github and submit for funding.

what is not done yet

the robot is not built yet. i still need to test the motors, encoders, imu, camera, esp32-s3 wiring, pid control, slam, mapping, and a* path planning.

next steps

1. upload the folder to github
2. submit the stardance/outpost funding request
3. order parts after approval
4. 3d print the chassis
5. assemble the robot
6. test power, motors, encoders, imu, and camera
7. start pid driving
8. work toward slam and mapping

reflection

today was mostly cleaning up the design and making the submission look real. the project feels a lot more serious now because it has a real parts list, diagrams, power plan, cad plan, and submission folder.

Trying to make the pipeline generate a proper output. Polishing up the application.

devlog 003 - making Onara launch-ready

Date: 2026-06-19

Since devlog 002, I mostly worked on turning Onara from “it works” into something closer to launch-ready.

what I worked on

billing + accounts

I added more real account controls:

• cancel subscription from billing
• plan limits
• better account page
• better checkout layout
• Google-login warning if someone tries password login on a Google account

Google account -> use Continue with Google
Password account -> normal email/password login

generated sites

I worked on making the sites Onara creates more useful after launch:

• contact form lead emails
• better email HTML
• Pro code download
• cancellation placeholder pages
• Google Reviews refresh job
• support email surfaces

contact form -> Onara lead email -> site owner inbox

pipeline fixes

I fixed more backend/build issues:

• longer pipeline timeout
• better health monitor support
• fixed /health HEAD checks
• fixed broken generated HTML cases
• improved Google Maps region filtering back toward DC / VA

GET /health -> 200 OK
HEAD /health -> 200 OK

launch cleanup

I added launch stuff that real products need:

• privacy policy
• terms of service
• support page
• favicon/logo polish
• SEO metadata
• .env.example updates
• docs for production fixes

AI + training data

I also added the start of a cleaner AI improvement system:

• user consent copy
• opt-out/delete handling
• training example storage
• QA-approved examples only
• no saving random bad generated sites into RAG

good QA result -> redact -> save as training example
bad result -> do not save

biggest change

Onara is not just generating sites now. It is starting to act like a real app with billing, support, cancellation, reviews, contact leads, account limits, and safer AI improvement rules.

still left

• finish production deploy polish
• make generated site quality more consistent
• keep fixing slow render/build issues
• launch testing
• outreach assets

devlog 002 - the fake flow became the real app

Date: 2026-06-18

Sorry abt not posting a devlog in a while, completely forgot i had to do them! (too locked in lol).

Onara moved from prototype to real product system.

Devlog 001 ended with the app shell, Supabase setup, and mock agent progress. Since then, the missing backend got built: FastAPI, real agents, deployment, revisions, billing, and account gating.

Find -> Confirm -> Style -> Generate

now connects to the actual pipeline.

what I built

• FastAPI backend
• /generate and /health
• job queue + dedupe
• SSE progress stream
• dashboard build resume
• Cloudflare Tunnel + PM2

Next.js -> FastAPI -> agents -> Cloudflare -> Supabase

AI pipeline

I added the real 10-agent flow: Analyst, Content Writer, Style Agent, Planner, Prompt Engineer, Code Generator, Debugger, SEO Agent, QA, and Mobile check.

Agent 6 now has a plan-gated model picker.

Free -> Onara default
Starter -> Copilot options
Trial / Pro -> full access

I also added shared AI clients for NVIDIA NIM, Ollama, and GitHub Copilot SDK.

z-ai/glm-5.1 -> llama-4-maverick -> gemma4:e4b

RAG and deployment

I added RAG with ChromaDB, BM25 search, seeded HTML/CSS/JS patterns, and contractor layout examples.

Deployment now does this:

• parse generated HTML
• split component files
• back up code to GitHub
• deploy to Cloudflare Pages
• save metadata in Supabase

generated site -> GitHub -> Cloudflare -> Supabase

revisions

The revision page became a real workflow with:

• revision threads
• queued work log
• auto-pick or manual components
• changed-file summaries
• rollback UI
• retry without charging failed builds

{
  instruction: "make the hero CTA bigger",
  componentSelection: { mode: "auto" }
}

The UI also got cleaner: denser chat, better work log placement, flatter composer, and Onara styling.

billing

I added real billing:

• Stripe checkout sessions
• Starter monthly
• Starter annual at $99/year
• Pro checkout
• Stripe webhooks
• payment failed / succeeded handling
• reverse trial setup
• trial downgrade
• monthly revision reset

STRIPE_STARTER_PRICE_ID=...
STRIPE_STARTER_ANNUAL_PRICE_ID=...
STRIPE_PRO_PRICE_ID=...

Checkout now uses embedded Stripe Elements with PaymentElement, ExpressCheckoutElement, wallet buttons when available, and an Onara checkout page.

account and limits

I added plan display, trial days left, usage stats, upgrade CTAs, Starter / Pro cards, and annual Starter.

Free -> 1 active site
Starter -> 1 active site
Pro / Trial -> 3 active sites

Limits are checked before generation and enforced in Supabase.

cancellation flow

When Stripe sends customer.subscription.deleted or invoice.payment_failed, Onara now:

• updates the account
• sets show_url=false
• deploys a Cloudflare placeholder
• marks projects as suspended
• keeps Supabase records and GitHub backups

cancel -> hide URL -> placeholder -> suspended project

Cancellation hides the site but does not delete the generated code.

what changed from devlog 001

Now the pipeline runs, agents generate sites, previews stream status, sites deploy, code backs up, projects persist, revisions work, billing is wired, trials downgrade, limits are enforced, and canceled sites get suspended.

still missing

• lead SMS
• Pro code download
• weekly Google Reviews badge refresh
• monitoring
• privacy / terms cleanup
• support / consent copy
• launch outreach assets

devlog 001 - i started making the app

Date: 2026-06-14

This update was big because Onara is not just plans anymore. I added real app
code inside Onara_Code.

Before this, it was mostly wiki pages, task lists, and design references. Now it
has a real frontend and Supabase setup.

what I built

Next.js app
landing page
auth pages
dashboard
business build flow
Google Places search
agent progress screen
Supabase migrations
Supabase edge functions

The app now has login, signup, password reset, protected dashboard routes, a
contractor landing page, and a 4-step build flow:

Find -> Confirm -> Style -> Generate

I also added the mock agent progress screen. It shows the 10 agents running,
streams progress, updates a preview, and has a fake retry moment. It is not the
real backend yet, but it makes the frontend flow feel real.

Supabase now has migrations for users, projects, pipeline jobs, revisions, RLS,
auth triggers, and cron jobs. I also added edge functions for trial downgrade,
revision reset, and Stripe webhook handling.

what is still missing

The big missing thing is:

Onara_Code/pipeline/

That is where the FastAPI server needs to go.

Still needed:

FastAPI app
/generate endpoint
/health endpoint
real agents
AI client
RAG
deployment code
account/billing pages
Stripe checkout route

verification

I tried:

npm run type-check

but it failed because dependencies are not installed:

tsc: not found

next

Next step:

Build the FastAPI server.

That is what turns the fake agent progress flow into the real Onara AI pipeline.