carbon6 0.3.1

• A video's transcription takes its model call from the day's budget when it is asked for, so photos looked at meanwhile can't spend it twice
• Site: the memex is part of the head, kits need Docker or Podman on a worker, and upgrading from 0.2 starts by removing c6m

Upgrading from 0.2

0.3.0 was tagged but not published (a macOS test found the budget bug fixed here), so 0.3.1 is the first release with these changes. Upgrade steps:

1. Stop and remove c6m first: brew services stop c6m && brew uninstall c6m (Ubuntu: sudo systemctl disable --now c6m && sudo apt remove c6m). The head takes its knowledge in, moving the folder without copying it, the first time it starts with c6m stopped.
2. Upgrade the head and workers (brew upgrade c6h c6w, then brew services restart c6h c6w), and keep Docker Desktop (or Podman) running on at least one worker.
3. Approve "Install the kit c6-extract?" under Decisions. Mail kept before is then read again in the background, once: about an hour per 200,000 messages on a laptop. Until a message has been read again, its thread shows its text without the HTML.
4. Google accounts synced by the memex before move into the gmail, google-calendar and google-contacts apps on their own (Settings → Mail & calendar).

What changed in 0.3.0 (2026-10-16)

• Upgrading from 0.2 to 0.3: stop and remove c6m first, keep Docker or Podman on a worker, and approve the c6-extract kit
• Workers find Docker or Podman where they are installed even under a service's short PATH (launchd, systemd), look again a minute later when none answers, and attach again to say so when one starts after them
• From the trial on a copy of real data: mail kept before is read again in the background once nothing else waits, a message that can't be is not retried forever, and a folder on the head's machine uses a connected worker
• Gmail, Calendar and Contacts as apps (docs/knowledge.md step 6): gmail, google-calendar and google-contacts on the google kit sync with no agent and act through their operations, signed in once through your OAuth client; the knowledge store keeps mail, events and contacts from whichever app owns an account; what the memex synced itself moves into the apps at start, nothing fetched again
• Shared item kinds and their views (docs/knowledge.md step 5): root's vocabulary gives email, event, photo and the other item kinds a schema and a data card, and apps' items are checked against them; messages, calendar and gallery views show items of a kind from whichever app owns them, their buttons calling the owner's operations
• Never parse (docs/knowledge.md step 2): mail, documents, photos, videos and faces are read by the c6-extract kit on a worker (built from carbon6's own source, installed with your approval, no network), from a queue in the knowledge store; watched folders name their worker and are read where they are; mail is read once and kept as text and HTML; the memex links no parsers
• Kit jobs and providers (docs/knowledge.md steps 3–4): the head runs an app's kit tools on workers with a container runtime from operations and triggers, with no session, and keeps their out/ingest.json as the app's; kits may reach only listed hosts through an egress proxy; packages declare OAuth providers, you connect accounts under Packages, and kit jobs get access tokens only
• Moving what's installed (docs/apps.md step 7, docs/knowledge.md step 7): a c6m that ran on this machine moves its knowledge into the head when the head starts with c6m stopped (c6h import-knowledge for other machines and disks), and c6m's binary, packages and make target are gone; apps installed in a realm of their own are offered a move with their records and history; hand-off collections stay the realm's; decks 1.2.0 installs in home and hands finished decks to you
• Knowledge in the head and claims (docs/knowledge.md step 1, docs/apps.md step 6): the memex runs inside c6h with an in-process link and a separate c6m is turned away; every link and fact is a claim with an owner the head stamps, retracted only by its owner; readers believe by the realm's claim_policies (yours first by default), same_as claims give identity, apps' labels map onto a shared vocabulary in root, and removing an app retracts its claims
• Data that explains itself (docs/apps.md step 5): collections carry data cards (stability, sources, invariants, freshness, the app's version and operations) shown to agents on first read and marked when internal; records keep their provenance and what they were derived from; an upgrade can't narrow what an app publishes without a new major version, and names what depends on it
• Operations (docs/apps.md step 4): apps publish typed write and template operations, the only way anything but the app changes what it owns; called through the API, by agents with app_call (another realm through a call grant), by triggers' operation action, by views' actions, and from forms on an app's collections in the UI
• Apps as instances (docs/apps.md steps 1–3): a package installs in a realm you choose under a name, many times; its code is read from its package and layered into the realm's settings lists; what it owns is written only by it, or by you forced after a decision; its sessions act as it with its settings and approved reads; upgrades, downgrades and forks replace its code without merging; apps installed before are adopted
• Proposed design for knowledge in the head (docs/knowledge.md): the head keeps each realm's knowledge graph and removes c6m, parsing and models run in sandboxed kits on workers, blobs live where you choose, and Gmail, Calendar and Contacts become mirror apps on seven general primitives; apps.md gains claims with owners, reader policies, shared vocabulary and kit operations
• Apps design rewritten: realms are trust domains you draw, apps are named instances installed in them, reading is open within a realm with data cards and provenance, writing belongs to the owner through published operations, and code changes only by upgrade, downgrade or fork (docs/apps.md)
• Proposed design for apps: an app's code apart from the data made with it, tools that run in the realm using them, daemons as today, and app code that changes only by install, upgrade, downgrade or remove (docs/apps.md)
• The Site workflow doesn't publish on the push of a release commit, so the install page names a version only once the Release workflow has uploaded its packages
• carbon6.dev home page leads with productivity: attention on what matters, agents on everything else, and the four levers behind the 10x
• carbon6.dev: a static site rendered by Leptos from site/ (home, install, the README's guide, the design docs, the changelog), make site/site-serve/site-check/site-publish, and a Site workflow that publishes it to the GitHub Pages repository carbon6-dev/carbon6.dev