--- title: Publishing the websites --- # Publishing the websites ## What it is Omniscio serves seven public websites. They are not part of the desktop app's build — each one is published on its own, and this page explains what publishes them. | Website | What it is | Address | |---|---|---| | Documentation site | the help pages and the full reference library | docs.omniscio.com | | Homepage | the marketing page and the legal pages | omniscio.com | | Admin console | the operator dashboard | amc-admin-console.web.app | | Team-chat app | the phone-installable chat app | agentmc-teamchat.web.app | | Web demo | the browser demo of the app | agentmc-demo.web.app | | Short links | `omnisc.io/` → a shared link | omnisc.io | | Old dashboard redirect | sends the retired address to the admin console | — | Every one of them used to be published by GitHub Actions — a set of jobs that ran on GitHub's computers whenever a change landed. On 27 September 2026 those jobs were switched off for this project deliberately, to stop publishing from consuming the monthly allowance. They did not fail; they simply could not run any more, and nothing said so. Within a day the published reference library was **810 files behind**, and a documentation section written the night before was not on the site. The hosting job that published these seven websites was **deleted** on 28 September 2026. It had been labelled "dormant" in a comment, but a comment cannot disable a trigger — it kept firing on every push and failing, and it published a second, older copy of the sites over the local one. It is gone now; this page describes the only publisher. Now every push publishes them instead, from the developer's own computer. ## Where to find it There is no screen for it. Publishing runs by itself, in the background, after every push of the main line of work. What you see of it is the result — the websites update — and, when something goes wrong, an alert in the inbox naming the website that failed. A developer can also publish any website on demand from a terminal. The commands are listed under For agents below. ## How it behaves ### After every push When the developer pushes, the push asks Omniscio to run its web publisher on the same computer. The publisher works out which websites actually changed since it last published them and publishes only those, from a clean copy of exactly the version that was pushed — never from whatever happens to be checked out. A documentation edit never triggers the heavy rebuild of the web demo. The push itself never waits for publishing, so a slow or failed publish never makes the push look failed. For each website it publishes, it does three things and insists on all three: 1. **Builds** it from the pushed version. 2. **Uploads** it to Firebase. 3. **Checks the real address** — it fetches the live page and compares it against what was built. A website only counts as published if that check passes. Publishing by hand works the same way: it is still built from the pushed version, never from unfinished local edits. ### When something fails If any of the three fails, nothing is recorded for that website, so the next push tries that same one again, and an alert appears in the inbox naming it. A push that changed no website publishes nothing. And if a website's changes have waited 48 hours without being published — for instance because Omniscio was not running when the push happened — a separate alert says so. ### The team-chat app's settings The team-chat app needs public Firebase settings baked in when it is built. It used to get them from the GitHub jobs; they now live in a private settings file on the developer's computer that is never committed. The publisher copies that file into the clean copy it builds from, and removes it again afterwards. Without those settings the app builds a bundle that cannot reach Firebase at all — and because the app degrades quietly rather than crashing, that is invisible from the outside. The publisher therefore **refuses to build that app without those settings**, and refuses again if the built bundle does not contain a real key. Web push needs a separate certificate that is not part of those settings. Without it, push registration is skipped and the chat app still works; the build warns rather than refusing. ### Rolling one back Firebase keeps previous releases. If a website is published with a mistake, open the project in the Firebase console, choose the site's release history, and re-release the previous version. ### What else the publisher covers - The same after-push publisher also publishes the Firestore rules and indexes, the storage rules and the Cloud Functions, each through its own steps. - The hosting job that published these seven websites is **deleted**, not merely switched off. The other deploy jobs still exist but are dormant. Publishing these sites from this computer is the only path, which is why the publisher is watched — a failure raises an alert in the inbox. ## For agents - **The job.** A push asks the running app to start its in-app ops job `AMC-publish-web`, which runs `scripts/deploy/publish-web.mjs`. It publishes from a scratch copy of the pushed commit — the remote master tip — never from the working checkout, and a unit that is already current is skipped. - **Publishing by hand.** Each of these still builds from the pushed version: ``` npm run docs:deploy npm run scripts:run -- publish:web --unit homepage npm run scripts:run -- publish:web --unit homepage --force npm run scripts:run -- publish:web --dry-run ``` `npm run docs:deploy` publishes the documentation site (unit `help-site`). `--force` publishes a website again even if nothing changed. `--dry-run` prints what would be published, and every step, without publishing anything. The seven unit ids are `help-site`, `homepage`, `admin-dashboard`, `team-chat-pwa`, `web-demo`, `short-link-redirect` and `cloud-dashboard-redirect`. - **The hosting runner.** Each of the seven websites is built, deployed and proven live by `scripts/firebase-hosting-local-deploy.mjs --unit `, run inside the clean copy. Its table of websites — each one's build steps and live checks — is `scripts/lib/firebase-hosting-local-units.mjs`. The runner takes the project's deploy lock itself, so a hand-started publish and the push-started one never overlap. - **The team-chat settings file.** `firebase/team-chat-pwa/.env.production.local` in this computer's checkout, holding the `VITE_FIREBASE_*` keys. The web-push certificate is `VITE_FCM_VAPID_KEY`. - **The record.** A website that passes its live check is written to `~/.amc/web-publish-ledger.json`, and every run leaves a log under `~/.amc/logs/web-publish/`. ## Related - The Firebase deployment automation contract and its map, in the repository's agent memory, hold the rules every publish follows and how the publisher's parts fit together. - Deploy Profiles is a different feature with a similar name: it tells an agent which cloud account to use when deploying one of your own projects, and has nothing to do with publishing Omniscio's websites.