Overview
Verified on 2 October 2026 for this documentation site · the product has no infrastructure: nothing of it is deployed
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 and API | Sign-in, roles, stores, people and invitations built (6 and 11 October 2026), not deployed; see What is built |
| Mobile app | Not built, not deployed |
| Admin app | Settings for platform administrators, a separate application (18 October 2026), not deployed; its production address is prepared, not applied |
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.
Error tracking (GlitchTip)
Built and checked locally on 8 November 2026, not switched on anywhere deployed (SHIF-42, SHIF-43, brought to the common standard in SHIF-44). The API, the app, the admin app and the website can send their errors to our own error tracker, GlitchTip at errors.dreamvention.com (it speaks the Sentry protocol; organisation dreamvention, one project each: shiffty-api, shiffty-app, shiffty-admin, shiffty-website). Nothing deployed sends anything until the owner sets the variables below. The browser side in detail: Browser errors.
| Variable | Who reads it | When | What |
|---|---|---|---|
SENTRY_DSN | API | start (App Platform: RUN_TIME, secret) | The API project's key. |
APP_SENTRY_DSN, ADMIN_SENTRY_DSN, WEBSITE_SENTRY_DSN | app, admin app, website | build (BUILD_TIME); the app and the website also read theirs at start | Each front end's own key. |
SENTRY_ENVIRONMENT | all four | build and start (RUN_AND_BUILD_TIME) | Exactly prod, dev or local. |
SENTRY_RELEASE | all four | build and start | The git commit of the build. |
SENTRY_AUTH_TOKEN | front-end builds | build, BuildKit secret only | Uploads source maps; never a build argument and never in the image. With it: SENTRY_URL (default https://errors.dreamvention.com), SENTRY_ORG=dreamvention and APP_/ADMIN_/WEBSITE_SENTRY_PROJECT. |
- Off by default. Without a key the library is never started and no request is made: in the tests, in CI, locally. An environment that is empty or anything but
prod,devorlocalalso turns it off (GlitchTip keeps every environment name forever, so none is guessed). A local run (make dev,./orca/run.sh) always useslocaland reports only when the key is set in that shell. - What is sent: 5xx answers, unhandled errors and rejections, failed loads of a part of an application, router and start-up errors, failed background jobs (tagged
job). Never a refusal the person was shown (any 4xx), a request that got no answer, a cancelled request, a browser's own network error or an error from a browser extension. - What is removed first: request bodies, cookies, every header but the browser's user agent, query strings and fragments of addresses, emails, tokens, keys and passwords in any text, console output, what was typed, chat and page text, local variables, the machine's name. A person is their id only. No sessions, no tracing (
tracesSampleRate: 0), no screen recording, no profiling. - Release and source maps: the release is the git commit; front-end source maps are
hidden, made and uploaded only when the build has the token, and no.mapfile is ever served. - How to check it: with the environment
localand a tagtask=<ticket>, throw one unhandled error and one unhandled rejection in each runtime; the tracker answers 200 and the events appear in that application's project. A 4xx, a cancelled request and a network error must not appear, nor a?token=…from the address or a line written to the console. Done for SHIF-44 on 8 November 2026 (events taggedtask=SHIF-44).
The variables are named in api/.env.example and in each front end's .env.example; their values are never in the repository.
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. Error tracking exists in the code since 8 November 2026 but is switched on nowhere; see Error tracking (GlitchTip).
- 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.