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/<code> → 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 the website and the step that failed. That alert also starts a fixer: Omniscio opens a background agent session that reads the run's log, fixes the cause if it is in the code (on its own branch, which ships with the next push), and stops and says what it needs if the cause is outside the code — a sign-in, a permission, a quota or the network. The same failure raises a new alert at most once a day, so a website that keeps failing the same way never starts a pile of fixers; a different failing step counts as a new problem, and a successful publish clears its alerts.

A push that changed no website publishes nothing. And if a website's changes have waited 48 hours without being published — because the fixer could not fix it, or because Omniscio was not running when the push happened — a separate alert says so. It carries a one-click session rather than a command to type.

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 <id>, 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

• deploy-profiles.md — 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.
• help-and-docs-panel.md — the in-app help surface that the published docs site backs.