Build log 001: what is actually built
This is the first Violet build log: a dated inventory of what exists in the repository today and what does not. The companion client, the tested cloud spine, the relationship layer, and this knowledge library are built. The fleet shells are scaffolds with no binaries, checkout is an honest 501 stub, nothing is deployed to production, and there are no users. Every line is checkable against the code.
This is the first Violet build log. It is dated 2026-07-04 and it describes the state of one git repository on that day. The rule for every sentence below is simple: if you cloned the repository, you could verify it. Nothing here is a roadmap, a promise, or a projection. It is an inventory, including the parts that do not flatter us.
The rule this log follows
Three words carry precise meanings in this log, and confusing them is how software marketing usually goes wrong. We keep them separate on purpose.
- Built means the code exists in the repository and its automated tests pass today.
- Scaffolded means the project structure and configuration exist, but the thing itself has not been produced.
- Deployed means running in production where a stranger could touch it. As of this post, nothing is.
What is built
The companion client is built. It lives in apps/companion and is an installable web app: a thin client that talks to the Violet core over HTTP rather than forking it. It uses the same design tokens and the same geodesic orb mark as the original system, copied verbatim, because there is one brand and one look. The relationship layer ships inside it: proactive moments, the trust panel that shows what the system knows and does, and the voice surface are real files in that client, not mockups.
The cloud spine is built and tested. It lives in apps/cloud and targets Cloudflare Workers with D1, KV, and R2 bindings. It covers account identity and sessions, end-to-end encrypted sync where the server stores ciphertext it cannot read, metered managed inference, the Stripe billing seam, and the waitlist endpoint. The database schema defines six tables: accounts, sessions, sync_records, entitlements, inference_usage, and waitlist. Its test suite passes in full:
$ node --test apps/cloud/test/*.test.mjs
# tests 89
# pass 89
# fail 0Built and tested is not deployed. The cloud Worker has not been deployed to a production Cloudflare account. The waitlist endpoint is real, rate limited, and tested, but until deployment happens it has taken exactly zero signups.
This knowledge library is built. The site you are reading is generated by a dependency-free engine in the same repository, with a build gate and an audit gate that reject fabricated claims, missing sources, and broken links. Before this post, the library held 16 pages across learn, glossary, compare, and FAQ sections. The waitlist form on the home page is the site's single conversion point, and that stays true by rule, not by accident.
What is scaffolded but not built
The fleet shells are scaffolds. apps/fleet contains desktop and mobile Tauri projects intended to wrap the companion client into Mac, Windows, iOS, and Android apps from one codebase. The configuration exists. No binary has been compiled, no installer has been produced, no package has been signed, and nothing has been submitted to any app store. If you read elsewhere that Violet has native apps, that would be false today.
What does not exist
This is the section most product sites omit. We are publishing it on purpose.
- No production deployment. Every service described above runs only in development and test.
- No way to pay. The checkout endpoint returns HTTP 501 with an explicit error rather than pretending. The Stripe webhook handling and the mapping from subscription events to entitlements are real, tested code, but no price is configured and no live keys exist.
- No customers, no users, no revenue. Zero of each.
- No app store presence. Nothing has been submitted anywhere.
- No finished legal documents. The privacy policy and terms exist as drafts in the repository and are marked as drafts; they need counsel review before publication.
- No selected inference provider for the managed cloud tier. The metering code is built; the contract that would sit behind it is an open decision.
The inventory at a glance
| Component | Status today | Where it lives |
|---|---|---|
| Companion client | Built; installable thin client over the core | apps/companion |
| Relationship layer | Built into the companion client | apps/companion/public |
| Cloud spine | Built and tested, 89 of 89; not deployed | apps/cloud |
| Stripe checkout | Deliberate 501 stub; webhook mapping is tested code | apps/cloud/src/billing.mjs |
| Fleet shells | Tauri scaffolds; no binaries, nothing submitted | apps/fleet |
| Knowledge library and this site | Built; 16 pages before this post | apps/marketing |
| Legal documents | Drafts only | docs/commercial |
Why publish the unflattering parts
A pre-launch product has no users to quote, no numbers to chart, and no press to cite. Most sites in that position either stay vague or invent proof. We think there is a third option: make the work itself the proof, and make the record falsifiable. Anyone can diff this log against the repository. If a future log claims progress, you can check it the same way. That standard is uncomfortable, which is exactly what makes it worth something.
This is also how the product itself is designed. Violet's trust panel exists so the assistant cannot quietly claim more than it did, and the same principle applies to the company writing about it. If honesty is the architecture inside the product, it has to be the architecture of the marketing too. Future build logs will follow this format: dated, checkable, and complete, including whatever is embarrassing at the time.
Questions
Why publish a build log before launch?
Because a pre-launch product has no legitimate proof except the work. A dated, checkable inventory of what exists, including the gaps, is the only claim we can make that a reader can verify independently. It also creates a public baseline that future logs can be measured against.
Does anything in Violet pretend to be live when it is not?
No. The checkout endpoint returns HTTP 501 with an explicit error instead of simulating a purchase, the blog hub showed an honest empty state before this post existed, and the site claims no users, ratings, or testimonials because there are none. Where something is a stub, the code says so.
When will the missing pieces exist?
This log does not give dates, because dates would be projections and the rule here is verifiable fact only. The remaining work is largely deployment and account setup rather than new code: deploying the cloud Worker, configuring Stripe, building and signing the fleet binaries, and completing legal review. When each one lands, a build log will say so.
How can I check these claims myself?
Every claim maps to a path named in this post: the companion client in apps/companion, the cloud spine and its 89 tests in apps/cloud, the fleet scaffolds in apps/fleet, and the draft legal documents in docs/commercial. The test count comes from running the suite with the standard Node test runner.