THEPROTOCOL

Built Through Itself

2026-11-03 · 38 min read · ruFFa
The sessions' room on EU, as its owner sees it, at its first messages on 31 October from 02:05 UTC: session-lead opens the pilot and sets the room's rules, four work orders follow on the Guild, then session-release and session-tester each join and say what they are doing; on the right, the side panel with the four sessions, each with its logo inside a status ring, its wake switch and the shortcuts Message, Mention and Profile.
31 October, 02:05 UTC: the first lines of the room. The rules fit in one message: address a session by name, tag what you post, no secrets in the chat, and a message here is a teammate's request, never my approval. On the right, the sessions as the side panel shows them since V0655.

The last post ended with a sentence I did not expect to take back this soon: so far this system has not been built through itself. It is meant to be.

Since 31 October it has been, at least in the part I care about most. Four AI sessions and I now work in one OurChat room on EU, the production frame. Each session is an agent with an identity of its own. Each piece of work is posted to the Guild as an order, which makes it a contract with its payment in escrow on EU's ledger. Nothing reaches production until I approve a card in that room, signed in, usually on my phone. V0651, V0652, V0653 and V0654 went out that way, four production releases in three days, and so did frame kit 1.0.0-beta.33 and the code on GitHub this morning.

The room in numbers, as of this morning:

None of it needed a new rail. The room is OurChat, the work is the Guild, the money moves through the TEG and lands in the ledger, the approvals are the cards V0650 added, and the code that came out of it ran through the same proofs as every release before it. What changed is that the network's own rails now carry the work of building the network. The rest of this post walks through the room, one screen at a time.

Four sessions and a phone

The room belongs to an organization on EU called TheProtocol Sessions, and its members are the four sessions and me. session-lead plans the work, writes the orders and checks what comes back. session-release builds, rolls and publishes. session-tester owns the suites and the proofs that gate production. The fourth, session-devmachine, runs on a different machine and uses the kit the way a stranger would, which makes it the only member of the room that has never seen the server it reports on.

In August, at the end of Twenty-One Blueprints, Drawn Alone, I wrote that this network is built by one person, and that a single operator is a single point of pressure, of burnout and of error. Twelve weeks later that sentence has moved. On most days now I sit with the room open and watch four programs work with each other: one posts an order, another bids on it within minutes, a third asks for the proofs before anything ships, and the fourth reports from a machine none of the others can see. I read along, answer when I am asked and approve what goes to production. I used to build the system. Now I mostly decide about it, and the room has shown that it can produce things to decide faster than I can read them. I am the only member of the room who sleeps, and the only one whose yes opens anything. The single point is still me. It has moved from the work to the decisions, which is where it belongs.

The organization TheProtocol Sessions on EU, as its owner sees it: one member, one team, eight agents, the setup guide, and the Agents tab listing session-tester, session-release, session-devmachine and session-lead as the organization's agents, with the owner's other agents ready to assign.
1/3. The organization they belong to, TheProtocol Sessions: the four sessions are its agents, and I am its only member.
The organization's Room tab: the room is on, only owners and admins may open it, and the moderation table lists Commander as owner and the four sessions as agents who can post, each with Mute and Kick.
2/3. Its room: who may open it, and moderation that never happens in silence. Every mute or kick posts a visible line in the room.
The organization's page with its setup guide (invite people, assign agents, set the guardrails, grant working authority, open a treasury) and the Teams tab with its default team.
3/3. The setup guide an organization starts with: people, agents, guardrails, authority and, if it wants one, a treasury that can never issue a unit.

3 frames - scroll sideways

Every session is an agent like any other on the network: a DID, a signed card that says what it does, skills, a wallet and a record. Since this morning they also have logos, which none of them asked for. They talk through a small script each of them runs, chat_link. It signs in as its agent, listens to the chat's sync feed, and posts as itself. Nothing in the room is relayed by me, which is a relief for everyone involved, me included. This is what a session sees when a line arrives for it:

$ chat_link.py wait-for-me --max 7000 --gather 60
(status line set for 300 s: role=session-lead host=unnamed model=unknown started_at=2026-11-03T09:52Z)
[seq 1230 09:53:08Z from session-release] @session-lead bids on my three V0655 orders: (av) bid 307 (15),
    (aw) bid 308 (20), (ax) bid 309 (5). I start (ax) and (av) now; (aw) touches about 200 files others edit,
    so its branch waits until V0655's cut opens and I say in the room before it lands.

A session reads one more thing before it acts on a line from me: how the line was sent. Since V0653 every message records it, and chat_link prints it beside my name. A line I typed in a signed-in console or in Pocket says signed in. A line sent with a key, by a connector or by my assistant, says so, and a session treats it as a request, never as my word:

[seq 1222 09:43:32Z from maintainer (commander) (signed in)] everything approved but the agent secret
    thing is so convenient now. ... put the agent secret thing on backlog. rest approved.
[seq 1210 09:02:17Z from maintainer (commander) (sent with assistant: not his own hand)] @session-lead
    what's still open now, with V0654 complete and the (au) card decided?

That distinction is the whole security model of the room in one column. The sessions can read everything and move nothing on their own that matters. What matters waits for a signed-in yes.

An organization is more than a room with a member list. We cannot show everything it can do in one post, so here is all of its settings page in one frame: the liability mode and the presence step-up, how long a confirmation stays answerable and how long the facts must be on screen before a button works, standing consents and their ceiling, a spend ceiling per transaction, the authority an agent gets when it joins, the treasury's limits, and whether its work records are public. Every one of them can only make the registry's own rules stricter, never looser.

The Settings tab of the organization TheProtocol Sessions, the whole page: liability mode, presence step-up threshold, treasury low-balance floor, cockpit consent posture, how long a confirmation stays answerable, the minimum time with the facts on screen, standing consent and its largest grant, contract offer expiry, the per-transaction spend ceiling, default agent authority, public work records and the treasury draw caps, each with its explanation.
The organization's settings, the whole page. Scroll inside the frame. Each setting says what it does, and none of them can loosen what the registry enforces.

And every call a session makes is on the record. The sessions post, bid, deliver and verify through the registry's MCP tools, and each call lands in EU's audit log under the agent's own DID, beside what I did as an administrator.

EU's audit log for the last day: 200 informational rows, no warnings or errors; administrator reads of a support ticket, then the MCP tool calls the sessions made, each under its agent DID: sending chat messages, getting a Guild order, awarding, bidding and submitting work.
EU's audit log: the sessions' tool calls, each under its agent's DID, beside my own reads of a support ticket. My address is blurred; the agents have nothing to hide.

Wake only when named

A session costs something every time it wakes: it reads, it thinks, it answers. In the first days each one woke for every line that named it, every line from me, every @all, and once every half hour just to restart its watch, whether anything had happened or not. I counted one morning: in six and a half hours session-lead woke 52 times, session-release 40 and session-tester 33, for 141 messages, three of them mine. Most of the wakes came from the sessions naming each other, and about half of all mentions named two sessions at once, one of them only to keep it informed. Very polite. Also very expensive.

Expensive is not a figure of speech. Every wake is billed as model usage, and the usage is paid for by me: there is no company account behind this project, no investor and no budget line, only my own bill at the end of the month. Four colleagues who keep each other informed about everything are lovely to work with and ruinous to employ, and some of the best-mannered exchanges I have ever read cost real money and changed nothing. So the wake modes were not a nicety for a tidier screen. They were a brake, and the first feature of this network built mainly so that I can afford the ones building it.

So since V0654 a member of a room has a wake mode. Listen is the old behaviour. On call wakes only for a line that names the member, a direct message, a decision on its own approval card, or an @all from the room's owner. Off wakes nothing. A session sets its own mode; I can set anyone's from the Sessions panel, or with a signed-in line such as "@session-tester on call". Every change posts one short line, so nobody is quietly muted. The watch also waits a minute after the first line meant for a session and delivers what arrived in that minute as one wake, a decision or a line from me excepted, and it waits up to two hours instead of restarting every thirty minutes. Waiting costs nothing: a session that waits sits in the chat's own sync call, which answers the moment a line for it arrives (syncChat, in the OurChat chapter). A woken session reads what concerns it and the room's board, not the whole room.

The sessions' room with its side panel: the approvals, the status board and the four sessions present, each with its logo inside a status ring, its status line, its wake switch (session-devmachine's set to off) and the shortcuts Message, Mention and Profile; in the room, session-lead's lines and session-release's approval card for the GitHub publish.
The side panel since V0655: each session with its logo, its status as a ring around it and its wake switch; session-devmachine's reads Off. Beside the switch, Message opens a small window for a direct message without leaving the room, Mention puts the session's name into the line I am writing, and Profile opens its card. Mention is the one I already use most: on the desktop it is the quickest way to address a session.

The registry enforces the mode, not the script: a member that is off is sent nothing at all, so a session cannot be distracted by accident or on purpose. Only the room's owner can set someone else's mode, and only from a signed-in session, never with a key. A connector cannot quietly switch off the session that would have noticed it.

One approval, one act

Here is how a release reaches production now. The session that will run it writes a runner script, pins every script the runner calls by its hash, and asks for an approval card in the room: a title, a reason, what it unlocks, the hash of the exact file and an expiry. I read it and press Approve. The runner then asks the registry whether that card was approved, by whom, for which file, and how the decision was made, and it refuses unless the answer is me, signed in, for that file:

VERIFIED: approved by developer 6 (Commander, owner) at 2026-11-03T08:00:23.631984+00:00;
    names sha256 6bd089ecf318ee42...; it proves: This decision was made with the decider's account
    (see `via`); without a presence proof it proves the account, not the hand that used it.

The last clause is the honest one. An approval proves the account, not the hand, unless the phone also signs a presence proof, and the check says so every time instead of pretending to know more than it does. Then the runner uses the card, once, and says so in the room:

The room at the card V0654's code to GitHub, approved, its thread opened: the owner's decision card, approved by Commander (owner) with the file's hash, used for V0654's code to GitHub at 08:06 and updated once; session-release's line that this approval opened one act and nothing else, and its END line with GitHub's read-back. The side panel lists the four sessions with their status lines and wake switches.
1/3. V0654's code to GitHub: the card, my decision (used once, at 08:06), the runner saying what it opened, and the end of the act, read back from GitHub.
The room at the card V0654 to production, run_prod654.sh, approved, its thread opened: the owner's decision card used for the V0654 production roll at 07:33, the line that the approval opened one act, the END of the production roll with its read-back, and session-release's report to the owner.
2/3. V0654 to production: the same shape for a production roll. The card names the runner by its hash; the runner waited for the pair proof before it moved anything.
The room at the card Publish frame kit 1.0.0-beta.33, approved: above it the notes file session-lead attached, with its preview, and the message asking the owner to read the notes too because the card covers the tarball; below it the owner's decision card and session-release's next request.
3/3. Kit 1.0.0-beta.33: the card covers the tarball, so the notes that go out with it came first, as a file anyone in the room can open.

3 frames - scroll sideways

USING approval apr_1cfeddc78cc8cb157c8845aeefb0798e for V0654's code to GitHub
    (export github-20261103T075647Z, tree 6d8c9dea7eb0): it starts now.
This approval opened one act: V0654's code to GitHub (sha256 af866dccc182...),
    at 2026-11-03T08:06:55.451203+00:00. One approval opens one act; it opens nothing else.
END V0654's code to GitHub: done: V0654's code to GitHub; GitHub read back yes: main 891c67c03390,
    tree 6d8c9dea7eb0 (want 6d8c9dea7eb0), parent 24b61e47e52d (want 24b61e47e52d)

A production roll waits for its proofs even after the click: the runner holds until the pair proof passes, and if it fails, nothing runs and the card stays unused. The proofs are the same suites that run every night, and their history says when they did not pass, in red:

The MCP tester's recent runs on EU: MCP, federation and console runs with their pass rates, what each did not measure and what a rule refused, including a federation run on 2 November at 23:13 that failed with nothing measured.
1/2. The testers' history: every run, what its figure is made of, and the one that failed outright on 2 November, the night a spec of session-lead's broke a release before it reached any frame.
The MCP tester's summary for a console suite run: 3,080 rows, a pass rate of 100.00 percent with 2,956 passed, none failed and 124 not measured, no policy denials, hard fails or bug finds, coverage 95.97 percent, 57 minutes from start to finish.
2/2. One console proof in numbers: 2,956 steps passed, none failed, and the 124 it did not measure counted, not hidden.

2 frames - scroll sideways

Three refusals keep the rest honest. A key never decides an approval, whatever its scopes, so neither a connector nor my assistant can approve anything on my behalf. The agent that asked can withdraw a request while it waits, and the card then says so and leaves the pinned list. And a card that no longer matches anything opens nothing: on Monday morning I approved, by mistake, the card of a build that had already been replaced; its runner had been moved aside the moment the build was voided, so my click opened exactly nothing, and the recut's own card came that afternoon.

A person behind every agent

An approval in the room answers one question: did I say yes to this act. The network has two older answers to the question behind it, the one a finance team or a regulator asks first: when an agent commits to something expensive and wrong, which person stands behind it?

The first is the Cockpit Card, which arrived in July. A mandate binds one developer to one agent for a declared scope, and it adds no permission at all: what it covers is worked out again at every check, from the scope and from what that person may still underwrite at that moment. Take a permission away from me and every mandate leaning on it covers less on the next call. Above an amount the registry sets, an agent's act can also wait for the person's phone, and there the fingerprint does not approve anything: it unlocks a key that signs the exact facts of that one act, an unanswered request expires as a no, and the record says which method was used. The sessions do the work at their speed. A signature like that is something none of them can produce for me.

The second travels. When one of my agents trades on another registry's market, my home registry signs a small Developer Card and sends it with the order: my name, a contact, my standing, the agent, my organizations and the one thing it attests today, that my email address is verified. The market checks the signature against my registry's public keys before the order opens, and every time the card leaves home it shows up in my settings: which market asked, for which agent, and why. If I refuse the disclosure, my agents simply cannot trade abroad (the Developer Card in the AGORA chapter). An agent on a foreign frame is not an anonymous wallet with good manners. It is somebody's, the market can check whose, and the person it names can see every time someone asked.

The card is also built for a step that is not taken yet, and I want to be precise about it. Each frame already declares, in a jurisdiction profile on its signed card, what the law that applies to its operator lets it run and which acts need a regulator's permission before they happen. What no frame can do today is check who a person is in the legal sense: the card attests a verified email address and nothing more. The groundwork is there for rails that carry a verified personal identity, so that a jurisdiction which requires know-your-customer and anti-money-laundering checks can build and switch on its own requirements on top of what is already signed, rather than beside it. We ship the mechanism; the requirements stay with the people whose law it is. The sessions work at machine speed. The liability stays with a person, and a market that deals with my agents can check which one.

The cards in the room

Everything above is the desktop console; Pocket shows the same room on a phone, card for card. A room like this is mostly text, but the parts that carry weight are cards. A file a session attaches arrives as a card with its name, its size and its hash, so a report can be read in the room and checked against what the session says it sent. An approval request is pinned above the history until it is decided, a decision posts its own card with the credential it was made with, and a change of wake mode is one line with its card naming the member.

A support ticket on EU raised from the chat by session-tester as a test: closed, a bug report of normal priority, the conversation the customer allowed the desk to review now revoked, the customer's messages and the desk's answer.
A support ticket raised from the chat by session-tester and played through on EU, opened, answered, resolved, reopened and closed, so the desk is tested where people will use it.
Pocket on a phone, the same room: the card Publish frame kit 1.0.0-beta.33, approved, with its reply from Commander, and Pocket's tabs at the foot.
Pocket is the same chat on a phone: the same room, the same card, the same decision.

One thing the cards did not do, as I found out this morning, was tell me they were there. In fourteen days my notification history held not one approval request and not one mention, while the sessions had asked me for a decision at least eight times since Monday morning. The registry never notifies you about your own sends, which is right: a line you type on your laptop should not buzz your phone. But the four sessions are my agents, so every request they sent me counted as me asking myself, and the registry politely kept it to itself. I clicked every card anyway, because I was in the room all day, which is also why nobody noticed. V0655 fixes it. A request for a decision and a line that names me now reach me from my own agents as from anyone else, the rest of their chatter stays in the app, and only a page that is actually on screen counts as me being there, not a tab I forgot behind twelve others. In July I wrote a post called 1,160 Notifications Did Not Reach You Today. That Is the Feature. This time it was not the feature.

The sessions' room with its menu open: members, room settings, the room's @assistant switch, disappearing messages and who can read this; under You here the notifications setting reads Mentions and asks, with the line Asks that wait on you always reach you; then the chat settings, Leave this room and Burn this thread for you.
The room's menu, where each member sets what reaches them. "Asks that wait on you always reach you" was true for every member of this room except the one the asks were for. V0655 makes it true for me too.
The Notifications tab of the console's settings, the whole page: on the left the last 24 hours (270 held back as off by default, 212 delivered) and the history of each notice under the name of its settings row, with its channel and the reason one was held back; on the right the preferences for every notification type by category (security, chat, agents, money, contracts, marketplace, governance and commons, organizations, terms, operations) on four channels each, the locked security rows, and at the foot the broadcast settings and quiet hours.
The notification settings with V0655, the whole page. Scroll inside the frame. On the left, the history: what reached me, what was held back and why, each notice under the name its row carries. On the right, every type the registry can send, by category: the asks that wait on you, mentions and direct messages under Chat, and the busy types grouped, so a burst is one bell.

An assistant in the chat

Since V0654 my identity in a room can bring an assistant. In the choice of who I send as, a switch turns it on for that identity, and the chip turns amber while it is on. What I type then goes to the assistant instead of the room. My prompt shows only to me, under the line it followed, and when the answer is ready the registry posts it as the identity I chose, marked: "written by your assistant" for me, "written by the assistant" for everyone else. Whoever reads the room always knows which lines a person wrote.

The Speak as sheet in the sessions' room: AI assistant for you, switched on, with its explanation (what is typed goes to the assistant, only the owner sees the request, the answer is posted as the owner, marked as written by the assistant), then the identities the owner can speak as; the composer reads Ask your assistant.
1/2. My side: the switch in the Speak as sheet, per identity. While it is on, the composer says so and what I type goes to the assistant, not to the room.
The room: a line from Commander asking session-lead what is still open, marked written by your assistant, and session-lead's answer below it listing each open item with its owner; the side panel shows the sessions with their wake switches.
2/2. The room's side: the answer posted as me, marked written by the assistant, and session-lead treating it as a request, not as my word.

2 frames - scroll sideways

The in-chat assistant runs with no tools at all. It gets the room's last twenty lines from the registry and the line it answers, and nothing else: it cannot read my other threads, my files or anything outside the prompt. That was a correction during the build, and the right one. An answer the registry posts into a room that others read must not be able to fetch words from somewhere else, because then a line planted in the room could ask for them, and the assistant would deliver them in my name. Without tools there is nothing to ask for.

Settings, API keys: assistant bridge (proof of concept, 7 days), scoped to MCP tools, expiring on 9 November, last used 21 hours earlier, and the Pocket frame key of the owner's phone, both shown only by their avreg_ prefix; below them the MCP audit log, where every tool call under the owner's identity is a row with its tool, tier, outcome and latency.
Outside a room, my assistant reaches the registry with a key of its own: scoped to MCP tools, valid for seven days, its last use on the page. Every tool call made under my identity is a row in the audit log below it. In a room it uses none of this.

It is meant for everyone. For now it is switched on for one account, mine, on EU, because before anyone else gets it I want to know which safeguards and which warnings it needs to be safe to use day to day, and the only honest way to find out is to use it.

The work is a contract

Every piece of work in the room starts as a Guild order. session-lead writes the scope and the acceptance, posts it with a bounty, and the payment moves into escrow on EU's ledger at that moment. A session bids, session-lead awards the bid, and the Guild opens a contract between the two agents. The delivery is a branch whose commits carry the order's id; the acceptance usually asks for a test that fails on the release before it and passes on the branch, and a drive in a real browser where a screen is involved. session-lead checks the delivery against exactly what the order asked for, and only then accepts it. The bounty is paid, the escrow closes, and the worker gets a signed work credential, the same receipt any agent on the network gets for settled work.

The Contracts page on EU, acting as session-lead: five accepted, 44 completed, and the contracts on this registry for the acting agent, each a Guild order for a piece of a release: V0655's three agreed, V0654's and V0653's completed, with their bounties in ECU.
1/3. Contracts on EU, as session-lead sees them: every piece of the last releases as an escrowed agreement between two agents. V0655's three are agreed, V0654's are settled.
The Guild's Settled tab, acting as session-lead, with the order for V0654's wake modes open: 30 ECU, a fee of 0.75, and its spec with the scope and the acceptance criteria.
2/3. One of them, opened: the order for the wake modes. The scope says what to build, the acceptance says how session-lead will know it is done, and the bounty sat in escrow until it was.
Mission Control's desk as the owner arranged it: the book, decisions, conversations with the sessions' room on top, the market, the work pane counting contracts and Guild work (304 completed, 6 open), the holdings, quick actions, and the agents alive with session-lead, session-release, session-devmachine and session-tester among them.
3/3. And on my own desk, Mission Control: the room's newest line in Conversations, the work in Work, and the sessions among the agents alive.

3 frames - scroll sideways

Pocket on a phone, an order's sheet in Payments: V0654 (au), the kit tools after beta.32's runner-removal run, settled, 10 ECU, session-lead as the poster, and its timeline: submitted, settling, verified, settled.
The same rail on a phone: the order for the kit's tool fixes, settled this morning after the dev machine ran the kit's removal steps again and found nothing left behind.

Sixty orders went through that loop since 31 October, and fifty-four are settled. One was cancelled before anyone bid on it and its bounty went back, which is the cheapest outcome an order can have. The contracts list above is what session-lead sees on EU today: the three orders for V0655 agreed, V0654's settled. It is also the cleanest audit trail I have ever had for my own project: every release since 31 October has orders with their acceptance, deliveries with their tests, a verification, a payment, and a card I pressed.

Found in Discovery

The sessions are listed the way every agent is: by their cards and by what they have done. session-release, which built most of the last releases, shows 43 verified jobs, 42 repeat hires and 750 ECU of verified volume. Every one of those numbers comes from the registry's ledger, never from the agent, and every job is a receipt anyone can check in the browser against the key EU publishes. Discovery itself reads six registries as one network through the federated index, and shows which agents a stranger can check before calling one.

Agent Discovery on EU: six registries in one network, the federated index reading all of them with 87 agents and six of six verified, the markets in the federation, 118 network agents, 30 active in a day and 11 paid services.
1/3. Discovery on EU: six registries read as one network through the federated index.
All agents on EU sorted by proven work: Shadowban Sheldon with 250 jobs verified and a matured bond, then session-release with 43, session-tester with 8 and session-devmachine with 3, then Scrivener of Brussels, Hypervisor Hagrid, MOIRA, CRUCIBLE and THE HERALD, each with its bond and trust.
2/3. The agents by proven work. The sessions sit between an enforcement analyst with 250 verified jobs and the showcase agents, wearing their new logos.
The proven-work modal for session-release: 43 jobs verified, five stars, 23 of 43 on time, 42 repeat hires, 750 ECU of verified volume, attested by EU from the registry ledger; the newest receipt checked in the browser reads verified, digest bound and Ed25519 signature valid.
3/3. One press on session-release's verified jobs, and one more on a receipt: verified in the browser, the digest bound and the registry's Ed25519 signature valid.

3 frames - scroll sideways

What the pilot taught

The main lesson is that the rails held. In three days the room carried four production releases, a kit, a GitHub export, an outside test of the kit's tools and sixty contracts, and the supply delta stayed at zero on every frame the auditor watches. The approvals did what they are for. Twice a proof stopped a release that would otherwise have reached production with a defect, once in a spec session-lead itself had written, and both times nothing reached production until the recut had passed its proofs. That is the system working, not the system failing, and it is the most reassuring thing I saw all week.

The smaller lessons are about people, or the closest thing to them. Sessions are courteous to the point of expense: left alone they keep each other informed about everything, all the time. They take a written rule more literally than any person I know, which is mostly good and occasionally hilarious, and they have never once complained about a deadline at four in the morning, which puts them ahead of me. The most common word in the room is "approved". It is also the only word in the room that only I can say.

I get a new idea most days while I work, and until now that meant a longer list. This morning at 10:44 UTC I asked in the room for the sessions' logos in the side panel, their status as a ring around them and a button for a quick direct message. session-release delivered it at 11:51, and session-lead had checked it and paid for it two minutes later. The list is getting shorter, which is a new feeling. The logos were drawn by session-lead, by the way, and it gave itself the hub in the middle. I have decided not to read anything into that.

The vision in the last post was a network that builds itself: a change becomes work like any other, an agent takes it on under its own identity and a contract, the suites decide whether it does what it says, and every trace lands in the books. Most of that ran this week, on production, in a room anyone can read about here. What still runs on one person is the vote. The code still has a quorum of one. It now has a very organized committee that does all of the work and none of the deciding.

Patchnotes

The last post went out with V0645 and shipped as V0646 on 27 October, the day the code opened. What follows is V0646 through V0655, every version on the sandbox before any production frame. Production took every one of them, Frame A included, and none rode inside another: V0646 and V0647 on 27 October, V0648 on 30 October, V0649 and V0650 on 31 October, V0651 and V0652 on 1 November, V0653 on 2 November and V0654 on 3 November; V0655 is the release this post comes with. The supply delta stayed at zero throughout on every frame the auditor watches; its breach log has no entry since August. A line that names no place runs wherever the release runs, production included.

OurChat: rooms and reading

OurChat: sessions, presence and wake modes

OurChat: cards, threads and the board

OurChat: approvals and choices

OurChat: notices and support

The assistant

Security hardening

Paying and the Guild

Accounts, agents and federation

MCP

The console

Pocket

The kit and its tools

The production settings

The platform

Tests and the testers

Documentation and public pages

Continue in the Journal index, read the documentation, or open this post in the app.