Overview
Verified on 2 October 2026 for this documentation site · the product has no infrastructure, because nothing is built
The only thing deployed today is this documentation site, and every push to the main branch publishes it: there is no staging step and no product infrastructure yet.
A push to the main branch is a publication. Everything before it happens on a branch.
What exists today
| Thing | State on 2 October 2026 |
|---|---|
| Source | One private GitHub repository, holding this site and the tooling around it |
| Documentation site | A static site on DigitalOcean App Platform, built with VitePress |
| Publishing | Automatic on every push to the main branch |
| Languages | English, Russian and Ukrainian, built and published together |
| Application, API, mobile app | Not built, not deployed |
How a change reaches the site
- Work happens on a branch, in a working copy of its own.
- The gate. The site is built, then checked for what a successful build does not catch: a page missing in one of the three languages, a dead link or anchor, a page nothing links to. Then the build is served and every page has to answer.
- The owner reviews. There is no reviewer agent; the person who owns the project reads the change and looks at the running site.
- Merging to the main branch publishes.
- Someone opens the changed page on the public site. A successful deployment is not the same as a visible page.
This is the flow as it was set up on 2 October 2026. No change has gone through all five steps yet: the commits made before that date were pushed straight to the main branch.
Working copies and agents
One task gets one working copy, one branch and one agent, managed with Orca. Each copy gets ports of its own, so several can run side by side without touching each other or the main checkout. An agent takes a task to “ready for review” and stops there; it does not merge.
The scripts behind this — setup, run, the gate, teardown — were run end to end in a real working copy on 2 October 2026. Creating a copy through Orca itself has not been tried yet.
Running it locally
From the repository root, make dev starts the site in watch mode and opens a small local dashboard: links to the local and the published site in each language, the working copies and what is running in them, and the live logs. make check runs the gate. The repository’s own README files describe both.
What does not exist
- No continuous integration. The gate runs on the developer’s machine. Nothing on the server stops a push that skipped it.
- No staging or preview environment. The public site is the only deployed copy.
- No monitoring. The published site is checked only while someone has the local dashboard open.
- No task tracker connected. A task is whatever a working copy is created with.
- No infrastructure for the product. Hosting, database, secrets, backups and the release of the mobile app are all undecided; see Architecture. The one stated intention is that a later solver service would run in Kubernetes next to the API; see Agent and solver.
Where to go next
- Architecture: what would have to be deployed once it is built.
- Open questions: what is decided and what is not.