Four things changed this week

Nothing was published in these seven days, so this week is read from its own record rather than from companion articles.

Bridge accounts finally have somewhere to keep a credential

The feature: where a bridged account's secret is kept once you have connected one. Not the act of connecting — that ceremony is rebuilt the following week — but custody of the credential it produces.

Before: Slack and Discord had no credential-sealing path whatsoever. WhatsApp and Signal produced linked-device credentials that lived in a plaintext directory on disk. Signal was not even registered as an adapter, so the code that starts a link ceremony had nothing to reach.

Now: all four produce a credential that is sealed into the vault, and the plaintext session directories are wiped when the daemon stops. Two of the four had nowhere to put one at all before this week.

This is the half of the problem that is invisible from outside. Nothing a person does changes — the visible sign-in is still a form, and stays one until the following week, when it becomes a scan.

A credential in a plaintext directory is not stored. It is left. The distinction matters because the code around it looks finished either way — there is a file, it is read back, the feature works. Nothing fails until somebody copies a laptop backup. This is the failure mode that does not announce itself in any test, because the test asserts the credential round trips, and it does.

Six silent catches got a voice. The WhatsApp and Signal link path had six places that swallowed an error and continued. A link failure therefore looked identical to a link that had not been attempted. Each now says what happened. A silent catch is worse than a crash: a crash tells you where to look.

History never loaded. Connecting a bridged account brought the account across but not its past. The synchronisation that pulls existing history on connect was written and was never armed, so every reconnection produced an account with an empty backlog. Nobody reported it as broken, because an empty conversation looks exactly like a new one.

One ceremony, then five. The onboarding assistant could only connect one of the six services, because only that one had been exposed as an operation it could call. The other five existed and worked — they were simply unreachable from the place people start. Building a capability and wiring it to the surface people actually touch are two pieces of work, and the second is easy to believe you have already done.

One call reported success having done nothing. Connecting WhatsApp by scanning a code returned "authentication flow started" without starting one. The caller had no way to tell that apart from a flow that started and was never completed, so the interface waited for something that was never coming. Four built-in connectors were also pointing at files that were not the real ones. A function that returns a success value is making a claim, and a claim nothing checks is a guess with good manners.

Messaging bridges — 212 changes this week, the largest area.

An assistant that will not answer from what it has not read

The feature: the assistant that answers questions about your own material — your memories, your files, the conversation in front of you.

Before: it could produce a confident summary of something it had never opened. Nothing in the answer distinguished a fact read from your memory from one the model supplied from its training, and nothing stopped it from answering anyway.

Now: three things changed, and they compose.

A refusal is wired into the finish of every answer. If the material was not read, the assistant does not summarise it. This runs at the point the answer is finalised rather than in the prompt, because an instruction is a request and a guard is a rule. Prompt text asks a model to behave; code decides whether the output ships.

Every answer carries its own provenance. A stated fact now records structurally whether it came from your material or from the model itself. That is the difference between an assistant you can audit and one you have to trust — and the reason to make it structural rather than a sentence in the answer is that a sentence is generated by the same process that might be wrong.

A tool permission binds where the tool runs. The scope a person consented to is now enforced at execution, not only where the plan is written. An out-of-scope call is refused at the point of use. Agreeing a scope during planning and enforcing it during execution are two different guarantees, and only the second survives a model that changes its mind mid-task.

The workflow itself is now driven by a model, with a human lock. A fixed sequence of phases was deleted and replaced by an assistant that advances the work and can close a design step on its own. The safeguard is not that a human approves every step; it is a plan-lock ceremony — present, approve, lock — so the shape of the work is agreed before it runs, and cannot be quietly rewritten afterwards.

What made this week's version honest was the test harness. A real-model test was being killed by the production memory guard and read as a failure of the feature. Fixing the harness came first: you cannot tell a wrong answer from a killed process if the killed process reports as a wrong answer.

Assistant and planning surfaces — 216 changes this week.

What this means, in plain terms

Five lessons this week paid for. Where others have written about the same ground, this says which part is theirs.

flowchart TB
  ask["A question about
your own material"] --> read{"Was it
actually read?"}
  read -- no --> refuse["Refused, not summarised"]
  read -- yes --> ans["Answered — each fact records
where it came from"]
  tool["A tool the plan agreed to"] --> ex{"Still in scope
at execution?"}
  ex -- no --> stop["Refused at the point of use"]
  ex -- yes --> run["Runs"]
  classDef ok stroke-width:2px;
  class refuse,ans,stop,run ok;

An instruction is a request; a guard is a rule

The assistant was told, in its prompt, not to answer from material it had not read. It sometimes did anyway. The fix was not a firmer instruction but a check at the point the answer is finalised. Prompt text asks a model to behave. Code decides whether the output ships. Anything you actually require belongs in the second place.

An answer you cannot trace is an answer you cannot check

Facts now record structurally whether they came from your material or from the model. Asking the model to say where a fact came from does not work, because the same process that invented the fact writes the citation. Provenance has to be recorded by the machinery, not narrated by the thing being audited.

A consented scope must bind where the work happens

A tool permission agreed during planning is not the same guarantee as one enforced at execution. This week it became both. A model can revise its plan between agreeing a scope and using it, so the only binding check is the one at the point of use.

Fix the harness before you believe the result

A real-model test was being killed by the production memory guard, and the kill was scored as the feature failing. Days of a wrong conclusion sit behind that. A failure mode that reports as an ordinary failure is worse than a crash, because nothing in the result tells you to doubt the instrument.

A credential left in a directory is not stored

Four bridge integrations produced credentials and left them on disk, two with no sealing path at all. Every test passed, because the credential round tripped. A test that proves data comes back proves nothing about where it rested. Storage has a location, and the location is part of the behaviour.

How much healthier is it than a week ago?

Counted the same way as week 19, so the two are directly comparable: files differing between the last commit before each window boundary, under the source, client, script and Rust trees.

Four honest notes.

• No article was published in these seven days. The previous dispatch is dated 2026-07-25 and the next published piece 2026-08-02. This report is therefore read entirely from the week's own commits.
• A busy week without a launch is still a busy week. 2,328 commits against the previous window's 2,409 — within 4% — across 30 areas.
• No before-figure exists for commits or files, because those count activity inside a window rather than a level. The comparison that means something is the previous window, given above.
• Test-file growth is not test quality. It counts how much test material exists, not how much of it is any good, and files were also split this week, which inflates the count without adding coverage.

What changed, area by area

Every area that moved, with its own count, in descending order. Each number is all of that area's file activity for the week.

The four threads, in numbers

The next tier — 98 down to 51 changes

Smaller areas — 36 down to 11 changes