Dark mode: the slate scheme set the header to #3f6b3e, a dark green on a dark page, so
the bar disappeared into the background. It is now green-mid with near-black text.
Typography moves to publishing/typography.css, loaded after brand.css, and declares
Figtree on the elements themselves -- Material defines --md-text-font-family on <body>,
so a :root value loses to it by DOM proximity. Heading colours are scoped to the light
scheme, since ink is unreadable on the dark one.
Material emits its own font variables and defines --md-text-font-family on <body>,
so brand.css's :root value lost to it by DOM proximity -- the same failure mode as the
palette, and the reason the site rendered entirely in the system font stack with
Material's default 32px/300 headings.
theme.font: false stops Material supplying typography, and brand.css now declares the
font on body, the navigation, the header and every heading, with heading sizes closer to
the website. Figtree is still self-hosted from publishing/fonts.
The theme was configured with primary: teal and accent: deep orange, so every page
shipped data-md-color-primary="teal" / data-md-color-accent="deep-orange" and Material
set --md-primary-fg-color and friends on <body>. Those variables then beat brand.css,
which sets them on <html>, because a value on the nearer ancestor wins for descendants
regardless of specificity. The result: cream background and ink from brand.css applied,
but the header, links and accents stayed Material's defaults.
primary/accent are now "custom", Material emits no palette of its own, and the co-op
variables in publishing/brand.css take effect.
- docs-deploy-poll.service and the receiver now build from
/home/ubuntu/.docs-publisher, so uncommitted edits in a working clone can
never block a deploy
- the poller compares origin/main against the last DEPLOYED commit (state
file), so a push made from the deploy clone itself also triggers a deploy
A MkDocs hook turns links like [incidents/](incidents/) — which Gitea
renders as a directory listing but a static site would resolve against the
page URL — into links to the generated landing page for that directory.
infrastructure.md links to incidents/ the way Gitea renders directories.
A static site has no directory listing, so the build now generates a small
landing page (with each document's own title) for any documented directory
that lacks an index. Build artifact only — no document is touched.
The agent host's cloud firewall only admits inbound SSH, so the registered
Gitea webhook cannot reach the receiver. docs-deploy-poll.service polls
Gitea every 60s over outbound HTTPS and deploys whenever main moves; the
webhook stays wired for the moment a port is opened in the Infomaniak panel.
Both serialise on the same deploy lock.
Renders the repository's Markdown (which stays where it is) into a
member-readable static site with Material for MkDocs: co-op brand colours
and logo, self-hosted OFL Figtree, offline search, no external hosts.
- publishing/build.sh stage .site-src, render .site-build (mkdocs --strict)
- publishing/deploy.sh write the build into the Surfer app container
- publishing/webhook-receiver.py + .service Gitea push hook on main
triggers pull -> build -> deploy (agent host, no new
Cloudron app)
Metering on /v1/systemone is live: each call is billed at $0.12 per 1M
input tokens, computed from the exact token count GreenPT returns and
attributed to the calling member key. Replace the "not yet metered"
warnings in models.md and api-access.md with the accurate position.
(metering verified 2026-11-03; code/litellm patch_passthrough_token_cost.py)
models.md claimed decisions count toward the member allowance. Verified today that a
/v1/systemone call registers no spend against the calling key, so the claim was wrong.
States the gap plainly instead. api-access.md now names the decisions route, the fact
that it is not an OpenAI chat endpoint, and the metering caveat.
Add a Decisions section: Metis returns probabilities/choices/scores rather than
text, is called at /v1/systemone with a member's normal gateway key, is
GreenPT-hosted (policy-based privacy, EU, renewable), and is metered
approximately (flat per-call estimate, not exact tokens).
Reviewed by dckc (review 6, APPROVED) and cross-checked against the gateway upgrade
runbook. Merged by push: this repo's approval gate is restricted to the Owners team,
which currently holds only machine accounts, and Gitea will not accept their API
reviews as approvals — see the PR discussion.
Reviewed by dckc (review 6, APPROVED) and cross-checked against the gateway upgrade
runbook. Merged by push: this repo's approval gate is restricted to the Owners team,
which currently holds only machine accounts, and Gitea will not accept their API
reviews as approvals — see the PR discussion.
The policy described chat history and enclave models carefully but never addressed
the API path, and §2 read as though all content is retained — which is wrong for
members using their own keys.
Verified before writing, rather than restating policy language: a request with a
distinctive marker was sent through the gateway and searched for afterwards. It
appears nowhere in the gateway's logs, `litellm_settings` enables no content
logging, and the request records carry usage fields only (model, tokens, cost, key).
- privacy-policy.md §2: content retention now depends on the surface, with a pointer.
- privacy-policy.md §4: new subsection on API requests, including the two limits that
stop it being read as more than it says — we can still link a request to a key and
therefore a member, and "not stored by us" says nothing about the provider.
- api-access.md: a "what we store" section, since that is the page an API user reads
before worrying about it.
- models.md: the privacy-limitations section now distinguishes chat from API.
Records the completed state: room power and the portal's invite credential now both
belong to @inference-admin; the old account's admin flag is dropped, it is
deactivated, and its devices and tokens are deleted. Notes the two corrupt rooms it
cannot leave, so the next person does not re-investigate.
Four automated accounts touch the homeserver and two of them differed by one
character, which caused real confusion (a bot appearing to announce itself; the
steward unable to post in a room it had been asked to report to). This records
the distinction rather than leaving it to be rediscovered.
Power belongs to @inference-admin, voice belongs to @inferencebot, and
@inference-admin never speaks in a member room. @inference-bot is being retired:
its room power was transferred to @inference-admin, which is now administrator of
record for #general, #community, #design, #skillshare, #updates and
#infrastructure.
Also records the one live dependency that blocks finishing: the portal's member
invites still authenticate as the old account via MATRIX_BOT_TOKEN, so that has
to be repointed before its credentials are revoked. Without this written down the
next person would revoke the token and silently break member invites.
Verified while writing: the portal's token hashes to the old account's device
VYQDYBXULA, which is also the unexplained python-httpx client seen using that
account today.
The provider's published catalog says this model takes 30K input and has no
vision support. Both of those are wrong. Sent through our own gateway:
- an image returns the right answer ("Red" for a solid red PNG)
- prompts of 32K, 70K, 130K and 262K input tokens are all accepted, with
Regolo's own usage accounting reporting prompt_tokens=262021
Our own description of the v1.5 generation — image understanding and a 262K
context window — matches what the model demonstrably does, which is why the
figure goes to 262K. The old 65K undersold the model by roughly 4x.
Regolo's meta-model for qwen3.5-122b says 120K; it processed 262,023 tokens and
still followed the instruction at the end, so that row's 262K is confirmed as
written and is left alone.
Adds a line under the table recording that context figures here are measured
through the gateway rather than copied from provider catalogs, because that
difference is exactly what caused a member to report this as an error.
inference-bot
inference-bot