Built during the hackathon

This repository is the entry for the Meta Global AI Developer Hackathon, Indie track, created by Nik Reljin and built between October 27 and November 4, 2026. Everything in it was written in that window, with the Meta Model API for the models and Muse Code as the coding agent. This log grows with each feature and links to the commits.

Date	What landed
Oct 27	Project scaffold: FastAPI service with validated settings, health and version endpoints, JSON logs with request IDs; React shell; ./dev runner with its bash helper library; Docker dev and production stacks; CI; this documentation site; release workflow.
Oct 27	Model API client: retries with backoff, strict structured output, spend cap with a persistent ledger priced from the published rates, fixture and record modes.
Oct 28	Label extraction with Muse Spark: photos in, typed fields with confidence and provenance out, deterministic normalisers, POST /api/extract, a command line, a recorded fixture for offline runs.
Oct 28	Segmentation with SAM 3.1: item, label and connector found one concept per call, masks decoded with Meta's parser, overlay and crops rendered, POST /api/segment, a command line; the label crop feeds extraction and evidence is sourced label_crop.
Oct 28	Web: upload form and evidence table; Playwright end-to-end checks in Docker (./dev e2e) and the e2e CI job.
Oct 29	Private inventory: items saved from a reading with every value's provenance and review state, owner values beside observations, intent and availability, separated parts, versions and history, in SQLite under DATA_DIR; the My inventory page.
Oct 29	Measurement from a photo: two-point scale or a homography from a known rectangle, quality checks that refuse a capture with the reason, an uncertainty derived from the marks and the reference, profile features with tolerances (vacuum_attachment, power_adapter, generic_item), captures stored on the item and proposed as observed values; the marking canvas on the item page.
Oct 29	Evidence-backed assessment: rules as data in each profile (hard or soft, equal, within, at least, at most, identity), pass / fail / unknown per rule with the candidate's provenance and measurement uncertainty, the verdict ladder, seller questions for every unknown, POST /api/assess and GET /api/profiles/{id}/rules; the Does it fit? panel on the item page.
Oct 29	Sell or give away: Muse Spark writes the listing draft from confirmed values only, the rules add the disclosures and drop unbacked lines, a preparation and photo checklist with data-removal steps when the item holds data, drafts versioned and marked stale when the item changes, copy and hand off to the Marketplace create page; voice notes transcribed with Muse Voice Transcribe and kept as the owner's words.
Oct 29	Price guidance: Muse Spark with search grounding proposes comparables, the rules keep only those a search result backs; four figures kept apart (asking, sold, reported, the model's estimate) with count, range, source and date, three labelled strategies, weak evidence called weak, whole against parts from the parts' own guidance, sales the owner records; POST /api/items/{id}/price; the What is it worth? panel on the item page.
Oct 29	Missing items: a search request for what an item needs, with a Marketplace search link the owner runs; candidates brought back as listing text (read by Muse Spark into fields), a screenshot or typed values, each dated, assessed by the profile's rules and placed on the ladder's states; recheck, withdraw, and the seller's questions as a message; POST /api/searches, POST /api/searches/{id}/candidates; the Find a part page.
Oct 29	Demo gate: an access code for every page with signed sessions kept nowhere, so many tries per address, allowances per visitor and per day on every call that spends, a per-address limit on every request, an operator's switch apart from the spend cap, the gate's state on /readyz; the browser checks run through it.
Oct 29	Public wording: README, docs home, roadmap, limitations and site description rewritten to the product as it stands, with what follows named as such.
Oct 29	Build and reuse: preferences kept once; project templates as data; Muse Spark proposes projects through a tool-calling loop over the inventory and the catalog (stateless replay, one ledger entry and fixture per step), the rules keep only allocations the inventory backs; projects proposed, shortlisted, selected (items committed and reserved, never to two builds at once, conflicts answered and moved only on request), building, done or abandoned; the budget across the selected set; a missing requirement becomes a search request; the Build and reuse page.
Oct 29	Build pack and outcome: one Markdown document per selected project written by the rules from what stands, with a version and a digest of its inputs, stale when an item, the project or the budget changes, downloadable as a file; steps as a progress checklist; the outcome in the owner's words (set-up, test, day, working, limits), a working result marking the project done; a redacted share text, off by default.
Oct 29	Android app: the phone as the capture device for the same inventory, a photo read and saved privately, a voice note kept as the owner's words and read back; ./dev android, unit tests on the JVM, an ADB smoke run on a phone or a headless emulator, the app's own checks in CI and the release APK on each release.
Oct 29	Docs complete: every page of the site filled, the pages about what is not in this version saying so, the demo walkthrough, the tools the model is given, the data model and the history, a new category by hand.
Oct 29	The demo set as data: photos scrubbed of metadata, one recorded run that keeps every model answer, and a load that resets the inventory and replays the set at no cost; the public demo is the set.
Oct 29	The phone as the capture tool: photos, a clip, a spoken note and a line sent in one go and kept privately; the Inbox in the web app; a capture read into an item on request, with the label found first and the note kept as the owner's words.
Oct 29	One path from a fresh machine to the app on the phone: the setup installs the JDK and the Android tools, one command builds, installs and launches the app, and the phone pairs by scanning a code that carries the address and a session of its own.
Oct 29	Clearer reads: contrast and edges lifted on what the model is shown, a blur score with a warning to retake, the photo kept as taken.
Oct 30	Hosting: the web app on Cloudflare Pages, the backend on Modal with a volume and one secret, sessions across origins, the pairing code carrying the backend's origin, a key probed at startup so a dead key means recorded answers rather than errors.
Oct 30	The photos beside the facts: the item dialog shows the photos the item was read from above the values to accept or reject, in view while the list scrolls; the web form keeps them at save time, a capture's photos pass to the item it becomes.
Oct 30	Two doors: the access code as the live door (codes issued as records beside the master code), the demo visitor on recorded answers with every write refused in one line, the model client choosing the key or the recordings per request.
Oct 31	The story on the docs site: one clickable diagram of how it fits together, two paths through the demo set, the lessons learned, the next steps with the roadmap folded in, and the pitch.
Oct 31	Decide what it becomes: one panel on the item that gathers what it is, what it is worth, what it is good for (the templates it fills by the rules, the uses Muse Spark proposes) and what would complete it, then keeps the owner's choice as the intent and a line in the history.
Oct 31	The evaluation loop: the demo set scored by the rules after each load (values read against what the set expects, fit verdicts, proposals kept against written, stub answers, spend), a report and charts under eval/, a diff of two reports, a training export of the accepted reads, and the written path from the report to a tuned Muse Spark Open adapter.
Oct 31	A picture of what an item could become: Muse Image draws it from the item's type, accepted values, condition and faults and the use the owner types, only on a click and only when PICTURE_ENABLED is set; kept beside the photos and never as one, captioned as drawn, charged per image; the demo visitor sees those of public items and cannot draw one.
Oct 31	A phone paired by QR claims an access code of its own, good for thirty days and never past the code that paired it; release 0.3.0 with the APK; Sign out in the header and Unpair on the app's Backend tab; the pictured pairing guide and the APK install steps with Play Protect.
Oct 31	The live check: one real Model API call per operation through the product's own services, each with its model, tokens and cost, held under a spending ceiling, also over HTTP against the hosted backend through both doors.
Oct 31	The item dialog in titled sections with a bar of section links, and the forms on the pages in the same layout; clearer, shorter wording across the web app and the phone.
Oct 31	A skills profile (none to pro) and What should I do with it?: three cards written by Muse Spark for the item and the profile, keep and fix, reuse it, sell or give away, with one recommendation; the choice kept as the item's plan, the repair steps added to its notes.
Oct 31	Plan the search: Marketplace search links in three to six phrasings, a match pattern run on RE2 and exclusion words; listings pasted back or read from screenshots ranked fits, maybe or does not fit with no model call; Check fit turns one into a candidate.
Oct 31	Location and notes kept from the demo visitor on public items; the demo set rebuilt from the owner's own photos, every answer recorded, ./dev eval at 14 of 14 expected values.
Oct 31	Draw it for a finished project on each Reuse it card and Build project; the header always shows its sign-in or sign-out; the hosted deploy restarts its containers so a changed secret applies.
Oct 31	Facebook Marketplace (US) listings: listing details with the private fields kept private, a draft in Marketplace's fields with its category and condition from a data file, each field to copy, the photos as a zip in order, the create page by handoff, and listed, sold or given recorded after.
Oct 31	The sample gallery: without the access code a visitor clicks the demo set's own photos instead of uploading, each answered by the recording of that exact photo; uploads only through the code's door.