What is new in Antifailure.

Every tag now publishes antifailure_<version>_windows_amd64.zip and antifailure_<version>_windows_arm64.zip, each holding af.exe and the runner, signed through checksums.txt and described by the bill of materials like the other four. They install from PowerShell with irm https://antifailure.dev/install.ps1 | iex, which keeps install.sh's promises: the newest release is found without the rate limited API, a download that does not match its published checksum is never installed, a refusal says what GitHub actually answered, and the install ends with af on the user PATH and in the terminal that ran it. Reinstalling over an af.exe that an editor holds open as its MCP server works, because the running binary is moved aside rather than overwritten.

Before this a Windows user had no build, no installer, and an install.sh that told them, from Git Bash, to compile the product from source. That message now points at install.ps1. af.exe is not code signed yet, and the quickstart says what that means for SmartScreen and Smart App Control.

It used to refuse the platform outright, and it could not have worked there as written: it replaced the binary by renaming the new one over it, and Windows refuses to overwrite the image of a running process, which during an update is always the process doing the update.

On Windows the update now fetches the release's zip, checks it against the published checksum exactly as the tarball is checked elsewhere, and applies the same refusals to every entry: no path outside the release, no links, no duplicates, no entry larger than it declares, and a checksum failure in any entry, including ones the update does not install. It then moves the running af.exe aside, which Windows does allow, puts the new one in its place, and puts both the binary and the runner source back if the second step fails. The next af to start deletes the copy that was moved aside; one still running, such as an MCP server an editor keeps open, is left until it exits.

The installation lock uses LockFileEx on Windows, and recovery after an interrupted update closes its journal before removing it, which Windows requires and which had made every recovery there fail at its last step.

added

never takes strings, matched character for character with case and spacing forgiven, and one appearing fails the workflow even when every expectation was met:

```yaml terminal_workflows:

• name: deploy command: ./bin/deploy expect: ['"Applied 3 changes"'] never: ["rollback started"] screen: {} ```

Without it, a full screen program that showed the expected words and went quiet was accepted on that screen, so a program that went on to print an error was passed on what it said first. That is still the default, because it is what keeps a passing workflow fast. Declaring never keeps the program watched until it exits or its budget is spent, ends the watch the moment a forbidden string appears, and reports a watch the budget cut short with keys still to send as blocked rather than passed. Every byte the program wrote is read as well as every screen it drew, so a warning drawn and erased between two snapshots is still caught. Set budget.duration to the window you mean. An entry that a quoted expectation contains, or that a screen workflow types and so echoes, is refused before anything runs, because either one decides the verdict by itself.

Agent replay reproduces the specified original failure before testing a candidate in an independent environment, with strict cassette matching and an inconclusive verdict for missing evidence or unconfirmed cleanup. Saved scenarios can run as local regression suites. The SDK requires explicit content capture and does not provide historical database recovery or a hosted trace store.

Reports omit database row values and primary keys. Retired incident IDs cannot be imported again. Replay checks the proxy's independent writer status and admitted work against its retained log, including failures writing the final record.

None of these changes behaviour anybody can see. They are recorded because three of the four automatic update requests that carried them could not merge on their own: two changed licensed dependencies without regenerating THIRD_PARTY_NOTICES.md, and two edited the same lines of one workspace manifest.

Visitors can compare a migration with an agent's unverified revised plan, inspect the measured finding, and switch between payment, email, and blocked production-service requests to see what the firewall returns. The examples show the effect on application behavior and where the structured result reaches the coding agent.

The migration example puts its table rewrite and measured lock durations in view; the firewall example distinguishes mocked, captured, and refused calls and explains where the containment result appears. Example numbers are labeled so they cannot be mistaken for live customer telemetry.

Their former standalone product pages have been removed. Existing URLs redirect to the product overview, while navigation and related links lead to the remaining product and documentation pages.

The public site and documentation now use the site text font for labels, diagrams and code instead of the slashed-zero mono face.

The budget is raced against the attempt, and when it ran out while Chromium was still starting, the runner waited for the whole open, the launch, the context, the trace and the first page, and only then closed what it had made. A two second budget came back after twelve seconds on a Windows machine starting its first browser, and the required Windows check failed once on a pull request that changed no runner code, at 8332 ms against a test that allows 8000.

The open now carries the budget. The launch is handed what is left of it as Playwright's own launch limit, so a launch that cannot finish in time is stopped by Playwright with nothing left running, and a budget that runs out after the launch closes the browser at once, so the context and the page that were still being made fail instead of finishing. A 50 ms budget that used to take 1.1 to 1.5 s on macOS now ends in under a quarter of a second.

The Windows check could not see a leaked browser at all. The test helper that looks for Chromium below the test process used pgrep and ps, neither of which exists on Windows, and read the failure as "nothing running", so every assertion that a stopped workflow left no browser behind passed there without having looked. It reads the Windows process table now, and refuses rather than answering when it cannot.

Every Windows user saw it, because the latest release when Windows support landed shipped no Windows archive. It now says what happened: release v1.9.0 publishes no build for windows/amd64, nothing was downloaded, and the installation is unchanged. A checksum that is named but is not a checksum is still refused in the old words, because that one is a damaged release.

Windows opened it anyway, but it was a path in two styles for somebody to copy. It is joined with the platform's own separator now.

The sidecar's log was read, it held no decision and no captured message, and both parsers answered with nothing at all rather than with an empty list. Every reader of those answers takes nothing to mean the log could not be read, so af ci said the ssrf and side_effect security families could not complete and reached no verdict, and the MCP egress inspection told an agent that no environment was running for the branch while one was, with the verdict INCONCLUSIVE.

A log that was read now answers an empty list, and only a sidecar that is not there answers nothing. On an application whose policy blocks everything and which calls nothing, both families now look and pass, and the MCP inspection reads PASS with zero decisions observed. A run whose logs could not be read is still refused by both families, exactly as before.

When a program exited, the end of its output could be thrown away before Antifailure read it, so a program that printed what was expected as its last line was reported as never having printed it. With a slow reader this happened in 122 of 150 runs. Antifailure now keeps the terminal open until it has read everything the program wrote.

When af was installed and not yet on the terminal's PATH, it offered export PATH=..., and when another af came first on PATH it offered which -a af; neither exists in PowerShell, which is where install.ps1 leaves the person. It also looked for the install under the name af, so on Windows, where the file is af.exe, it never found it and called an installed af a development build. It now looks for af.exe and offers $env:Path = "...;" + $env:Path and where.exe af on Windows.

Go's clock on Windows advances in steps of the system timer, measured at 0.3 to 0.5 ms, so a statement quicker than one step, which is most DDL on a small table, was timed at 0 ms and looked exactly like a statement that was never timed. Statement durations on Windows now come from the performance counter and are accurate to the microsecond, as they already were on Linux and macOS.

af finds the runner it shipped with relative to itself, beside its own directory, and the installer placed it under AF_PREFIX whatever AF_BIN_DIR said, so an install into ~/.local/bin reported success and af runner install then answered AF-AGT-004. The runner now goes to share/antifailure/runner beside the bin directory, which for the default layout is the same place as before.

An upgrade that failed part way no longer leaves a new af with no runner. The installer replaced af first and then deleted the old runner before copying the new one, so a copy that failed, or a runner directory that could not be moved because af test was running from it, left the machine with neither. The new runner is now staged beside the old one, and each is put back if anything after it fails. Both installers, install.sh and install.ps1.

Liveness asked only whether the holder's process could be opened, and Windows keeps an exited process openable for as long as anything holds a handle to it, an antivirus scan included. It now asks whether the process has ended, which an exit code cannot answer.

The driver handed the terminal emulator one chunk of output at a time and waited for each to be drawn. Every wait costs a timer tick, which is about a millisecond on Linux and macOS and 15.6 ms on Windows, and ConPTY delivers output a dozen bytes at a time. A ten thousand line program that Linux draws in a second was still 72723 of 108989 bytes behind after twenty seconds, so the workflow was blocked for a screen it could not finish drawing. Output that arrives while a chunk is being drawn is now drawn together with it, and the same program is drawn in under two seconds on Windows.

Arrow keys reached a program in the wrong encoding. ConPTY keeps a program's request for application cursor keys to itself, so the driver always sent the normal encoding and a program that had asked for the other one ignored the key. On Windows an arrow is now sent as a key press and release, which the console turns into the encoding the program asked for.

A never check that saw nothing forbidden now blocks rather than passes on Windows. ConPTY hands over the screen as drawn, and a line a program printed and then overwrote in place was missed in every one of fifteen measured runs, so a pass there would claim something nobody could see. A forbidden string that does arrive still fails the workflow.

A desktop application that exits while starting, and on Windows one whose path does not exist, crashed the runner with no result at all. It is now a blocked workflow that says the application did not start.

On Windows every terminal workflow left its console host and two pipes open until the runner exited. They are now closed when the workflow ends.

Every replay and incident write failed with "Access is denied", because the store synced its directory after each write and Windows refuses that. af init named a service at the root of a Windows checkout after the whole path, so C:\Users\me\shop became cusersmeshop, and asked every question about it under that name. The fork gate read the base branch's policy through a path git could not find, so on Windows, and for any manifest below the top of a repository, the base branch's fork_policy went unread and label was used instead, which meant a base branch that said never could still be overridden by a maintainer adding the label. The doctor told every Windows user their state directory was readable by others, because Windows reports every directory as mode 0777, and told them to run chmod.

Files that promised to be readable only by their owner were exactly as readable as their folder on Windows, where a 0600 mode means nothing and the folder's access list decides. The credential af login writes when there is no keyring, the encrypted secret store, the state database and the lock now carry an access list naming only the current user, set as the file is created.

An archive unpacked for a baseline comparison now refuses the names that mean something else on Windows than on Linux: a drive relative path such as C:x, which names a place on drive C rather than in the checkout, a device name such as NUL or COM1, which opens a device in every directory, and a path starting with a slash, which Linux already refused. A repository with a symbolic link no longer fails the comparison on a machine that cannot create one; the link is written as a file holding its target, which is what Git for Windows itself does.

database.seed and persona seed commands run in the sh that ships with Git for Windows, found through git rather than through PATH, and af doctor says where they will run or what to install. pg_dump installed by the PostgreSQL installer is found under Program Files. The terminal image query is no longer written on Windows, where its answer could not be read back and was left in the keyboard buffer; set AF_IMAGES to choose instead.

A new required check runs the engine's tests on Windows on every pull request.

The engine opened the live view on a unix socket file and handed its path to the runner, whose Node net.connect maps a path on Windows to a named pipe and refuses anything else with EACCES. The runner reads an unreachable watcher as nobody watching, so a Windows user got an empty live view and no reason. On Windows the engine now listens on a named pipe with a random name, created first by the engine so nobody can claim the name ahead of it, refusing remote clients, and carrying a security descriptor that admits only the user running the engine. That last part matters because a pipe has no directory to hide in, and the default pipe security admits Everyone to read. Everywhere else the socket and its private directory are unchanged, and a live view that cannot listen now says so at once and names the endpoint.

Requests that cannot be inspected are refused; streaming gRPC metadata remains checked without buffering its message stream.

af ci reads complete egress decisions after load and before teardown, and reports an incomplete log instead of treating missing evidence as clean. A chaos setup error now follows policy.chaos_unverified and appears in the chaos report. MCP masking errors say when rows were already committed, distinguish plan refusals, and avoid retrying an interrupted rewrite automatically.

Adding an identical row is now visible to the comparison, and repeated rows count toward the capture limit. This also prevents an agent replay from treating a duplicate insert as an unchanged database.

A wait pair's holder has three outcomes and the result carried two. It can be one of this run's own clients, it can be another session on the database, or it can be NOT NAMED: pg_blocking_pids returns an empty array for a backend that is genuinely waiting when the holder disconnected between the two reads. The third arrived looking exactly like the second, so the report printed "waited on another session on this database" about a lock whose holder nothing knew, which is a positive claim about whose lock it was made by something that did not know. It is the same defect as reading a null wait count as a zero, one level in: an absence rendered as a finding.

It is also a prepared transaction. pg_blocking_pids reports a two phase commit holder as pid ZERO rather than omitting it, so the holder is named while nothing in pg_stat_activity answers for it. Reported as another session, that sends a reader looking for a session to cancel when there is none: the lock goes when somebody runs COMMIT PREPARED or ROLLBACK PREPARED. A wrong remedy rather than only a wrong label, so it gets its own sentence.

Why it survived review and a merge, which is a shape worth naming: it is RARE exactly where it is tested and CERTAIN exactly where it is shipped. The same assertion failed on one head of another branch and passed on a later one with nothing between them touching this package, because as a superuser it fires only when an unnamed or stateless holder happens to turn up in a sample, which is load dependent. Off superuser, or with a prepared transaction outstanding, it is every run. A defect with that profile passes review, passes CI, and fails at a customer.

The three are now distinct, the run still reports the wait when the holder is unnamed, because the wait is the part that was measured, and a reader is told "a holder the server would not name" instead of being given a stranger.

Also fixed: a test demanded a holder state the server is entitled to withhold. An empty state has three causes and none of them is that the holder was doing nothing. The first is the ordinary case for a customer pointing this product at their own Postgres: a role without superuser and without pg_read_all_stats sees a foreign backend's row while its state, type and query are withheld, so off superuser a named holder has no state every time rather than occasionally. The second is any backend that is not a client, of which an idle server has several. The third is the holder's row being gone by the time the join runs.

Previously the empty-state title included Antifailure before the root layout added it again.

The critical one is in proxy-addr, in the open source web workspace, installed there because the MCP SDK depends on Express. Nothing in that workspace imports Express: the api serves MCP through the SDK's web standard transport on Hono, so the vulnerable code was installed rather than running. The other three are build tooling: source-map-js in the console, website, docs and Next.js example, and smol-toml and postcss-selector-parser in the docs. Each now resolves to its fixed release.

postcss-selector-parser needed an override, because the docs reach it through postcss-nested 6, which allows only the 6.x line, and no 6.x release is fixed. The override lifts that one dependency to 7.1.6 and leaves postcss-nested where it is. The docs built with and without it are identical, every page and every stylesheet, and the build was shown to fail when that parser is broken, so the comparison was exercising it.

Version 4.3.0 was published hours after the advisory was accepted in .npmaudit.yaml, so the docs take it and the acceptance is removed. Every lockfile in the repository audits clean again, with nothing accepted.

The docs lockfile carried the same release too, though the docs build with Astro and never run it: it is installed there only to satisfy a peer dependency of the geist font package. The daily vulnerability scan reported it from 2026-09-29 onwards, and issue #612 said scanning had stopped protecting the repository, but the scan only reports. Nothing it found reached a lockfile.

Next.js moves to 16.3.6 in all four lockfiles. The same pass takes the fixed releases of undici and devalue in the docs, ip-address and fast-uri in the open source web workspace, and DOMPurify in the website, and folds in the open dependency updates that were waiting on a regenerated third party notices file.

One advisory is accepted rather than fixed, because no fixed release exists: http-cache-semantics through 4.2.0, which the docs reach only through Astro's build time cache for remote images. The docs are built to static files, so no request is ever served through that cache. The reason and an expiry are in .npmaudit.yaml.

Each new path has an editable title, introduction, summary and rich body, can contain image, video and code sections, and can be previewed before publication. Publishing builds its URL, Markdown version and sitemap entry; articles also appear in the Writing index and RSS feed. Existing articles are listed individually for editing.

Ask AI now starts with the full page, can align label icons with their adjacent copy on desktop, and uses the stronger design model for layout requests while short copy edits stay on the smaller model. Every suggestion still requires review before it enters a draft. It can also propose a new page or article as a private, editable draft, with route collision checks and a publish gate for incomplete content. The network gate's denied-probe test now keeps its port allocated on one loopback address and probes another, so a new positive-control listener cannot accidentally claim the supposedly denied endpoint during a busy CI run.

Owners can edit page text, images, SEO copy, shared navigation, numbered labels, diagram details, and page-specific blocks. A new Ask AI panel suggests copy, design, and section changes for review in the preview before publication. The Anthropic key stays on the server, and requests have a daily usage limit.

af load compare has always brought a second environment up from the base revision, pinned both sides to one golden, and sent both the same traffic. The one thing it could not vary was the database: database.image lives in the manifest, the baseline deliberately takes everything but the build context from the candidate's manifest, so both sides ran one database build. A person hardening their own storage engine wanted the opposite experiment, the same workload and the same rows on two builds of THEIR database, and there was no way to ask for it.

--image and --baseline-image name the build each side runs, each defaulting to database.image, so a run that names neither is the run that existed before them. When only the images differ the two sides run the same application revision built from the same tree, and a base revision equal to this one is allowed instead of refused: that refusal used to be unconditional, which would have dragged a second application build in alongside the second database and left no difference attributable to either. The report names the axis that differed, revision, image or both, and says plainly that a difference cannot be attributed to either when both moved.

There is still one golden, because two would be two sets of rows. One build wrote that data directory and the other opens it, so a build that CANNOT open it is now its own finding, AF-DB-044, carrying the server's own account: the verdict line is the same sentence for a catalog version, a block size and a write ahead log format, and only the detail beneath it says which. It is noticed when the container stops rather than after the readiness wait, so the most useful verdict in the feature does not arrive as a timeout. A major version mismatch between the two images is refused before either environment is built, by the provider's own comparison against the server rather than against a tag.

A guide walks the whole flow end to end, because the pieces existed on four separate pages and nothing joined them: declare the build, run one workload against both builds on one golden, read the throughput and the latency distribution, then crash the database and read what the recovery kept. Every output block on it is from a run, and the page says which command produced each one.

An environment already running is refused rather than measured. The comparison keeps the environment identifier on purpose, so a database branch already up was adopted for a run that asked for a different build: the copy never happened, the container kept serving the build it was started with, and the report named the one that was asked for. Every number in it was then attributed to a build that did not run. That is now AF-DB-045, which says which build is running and which was asked for. The branch is not replaced, because a branch is copy on write and replacing one destroys everything written since it was made.

And the copy of a golden onto another build is keyed on that build's image ID rather than on its name, because a name is a thing somebody repoints. Rebuilding an image in place and running the comparison again, which is the whole iteration loop for the person this is for, reused the copy made from the previous build while the preflight validated the new one.

Until this, the durability proof asserted only over a schema of the engine's own, for the reason engine/internal/pgcrash/workload.go gives: asserting that a table somebody else is writing did not change, while they are writing it, is a claim about a moving target. That reason expires the moment the writers stop and the database answers a query again. Meanwhile af ci ran the invariants early and the chaos run last, so the rules a project states about its own data were never once evaluated against a database that had just been crashed.

Each invariant is asked twice, before the fault and after the recovery, because one answer cannot be read on its own. An invariant that held before and does not hold after is chaos.invariant.broken_by_fault and it fails. One that did not hold before either is chaos.invariant.already_violated, reported and attributed to nothing, because the run inherited it broken. One that could not be asked on either side is chaos.invariant.unevaluated, which a database that never came back is the loudest case of. A project that declares no invariants sees no change at all.

The editor previews the real site, saves drafts automatically, and publishes with version history and restoration. Text, media, colors, typography, spacing, placement, and reusable sections have responsive controls. Unedited settings follow the current source defaults.

af load compare brought a second environment up from the base revision, branched one golden for both sides so they answered over identical rows, and sent both the same traffic under the same seed in interleaved rounds. It could send exactly one kind of traffic: the weighted HTTP mix. So the promise, the same workload on two builds over the same data at the same concurrency, was true of API traffic and false of the workload that reaches the database directly, which is the half somebody changing an index, a lock, a storage parameter or a storage engine is asking about. They could measure their own build with af load sql and had nothing to measure it against.

af load compare --sql compares it. An explicit flag rather than an inference from the manifest, because comparing the SQL workload whenever load.sql happens to be declared would silently change what the command measures in every repository that adds one, and change it inside a pipeline. It is refused with AF-LOD-017 when there is no load.sql block, --scale is refused with it because a SQL workload has no arrival rate to take a fraction of, and a SQL knob typed without it is refused rather than read and ignored.

The unit of comparison is the transaction and the statement inside it, each with p50, p95 and p99 on both sides, because a p95 alone is not a latency distribution and a transaction whose p99 doubled while its p50 held is a lock that no statement row reports. Throughput is committed transactions a second, judged against the same load.comparison.thresholds.throughput_drop: reading the achieved REQUEST rate for a workload that sends no requests would have reported a declared limit as unmeasurable forever, which is a threshold in force that evaluates nothing.

Every knob is settled once, on this build, and handed to both sides, including the mix itself. A derived mix is read from pg_stat_statements on the database it is about to run against, so a side left to build its own would weight the statements by whatever that environment's own startup executed, and the comparison would be differencing two workloads and calling the result a regression.

What a SQL comparison cannot see is written for a SQL comparison rather than copied from the HTTP one. A mix that writes changes the rows, the table size and the index depth it is measuring; a branch is copy on write, so a write heavy round measures the branching on whichever side reached the page first; and autovacuum, the checkpointer and the background writer run on the server's schedule rather than the comparison's.

The lock contention a run was seen to suffer is compared too, because each side's rounds are pooled before they are differenced and the pooling now adds the waits and the waiting time rather than losing them. A pool where some round never read the wait queues says its count is a floor, and one where no round did reports nothing rather than a build that blocked nothing.

The HTTP comparison's report is unchanged, to the character, and a test now holds it that way.

The product could already say that a run deadlocked or lost a serialization race. Both of those END a transaction, so the client gets a SQLSTATE and somebody writes it down. The commonest outcome of lock contention ends nothing at all: a transaction queues behind another one, gets its lock, and commits. Nothing is raised, nothing is retried, and a build that takes a lock a little earlier or holds it a little longer moves the percentiles and changes no other number in the result. So a slower run could be reported as slower and could not be reported as slower BECAUSE it blocked, which is the difference between a number and a cause.

The only pg_locks query in the repository sampled the MIGRATION rehearsal, filtered to locktype = 'relation', and answered a different question: what one DDL statement HOLDS and for how long, on a branch nothing else is using. It reports a hold whether or not anybody ever waited behind it, and it is untouched here. pg_blocking_pids had never been called anywhere.

The watching connection that already proves the run's clients overlapped now also asks pg_blocking_pids which of this run's own backends are in a lock queue and which backends stand in front of them. Not a third connection, and never the workload's own clients: an observer that competes with the thing it observes is measuring itself.

af load sql reports how many times one of its clients started waiting, how many backend milliseconds of waiting the samples found, and the pairs. Both sides of a pair are named with the mix's own statement labels rather than with a process id, because each client publishes what it is about to execute and withdraws it when the statement returns. A pid means nothing between two runs; a label is the thing somebody acts on. A holder with no statement against it was idle in transaction, which is to say holding every lock it had taken and running nothing, and that is usually the finding.

The waiter is always one of this run's clients, because a neighbour's wait is never this run's result. The holder may be anything else connected to the same database, and a run blocked from outside itself says so rather than blaming its own mix.

lock_waits and lock_wait_ms reach the workload result, the stored history and af workload compare, so "this build blocked more than the last one" is a sentence the comparison can now make. They are null rather than zero when nothing watched, and that rule matters more here than anywhere else it is already applied: zero lock waits is the most reassuring thing this product can say, so an instrument that did not run must not be able to produce it.

What the sampling cannot see is stated in the output rather than in a document. The wait queues are read every 200 milliseconds, so a wait that began and ended between two samples is missing entirely and the counts are floors rather than totals. Every lock type the server queues on is in scope, including the transaction id waits a row conflict produces, tuple locks and advisory locks, and each pair says which kind it was. Contention that never becomes a wait is out of scope by definition.

added

Without it the data directory sits on the container's writable layer, the fault is refused before it acts because filling that would fill the machine, and the refusal named a dedicated volume no manifest key provided. The fill now writes until the declared headroom is left, Postgres meets a real No space left on device, and the undo gives the space back.

inject_declared_faults puts it on the MCP server. An agent asks for the manifest's declared faults to be injected into the environment running for its branch, one at a time, each undone before the next begins, and reads back what the system did about each one: whether the fault landed, the evidence the injector recorded at the instant it acted, whether the undo ran, and, around a fault aimed at the database, whether every commit the client was told was committed is still there and whether anything is there that no client ever wrote.

The result carries held and verified separately, and the second is not the negation of the first. Held says nothing was found to be wrong. Verified says the run established what it set out to. A run that is held and not verified has not passed, it has not looked, and it is reported INCONCLUSIVE. A fault that was applied and changed nothing is refused rather than reported as survived.

There is no argument that chooses which faults run, aims one somewhere else, makes one gentler, or turns the durability proof off. A caller that could weaken a fault could make the check easier on itself, which is the one thing this whole surface promises it cannot do.

The decision behind held and verified moved to engine/internal/gate, where the migration evaluator already lives and for the same reason: it was in engine/internal/cli, the MCP package cannot import that, and the alternative was a second implementation of the split this feature rests on. Three callers read one answer now.

This is the second capability the surface gate has named. af load sql was the first, and it had been reachable from one surface for as long as it existed; this one was reachable from one surface for six hours, because two pull requests were each green against a main that did not yet have both of them.

The nearest thing was engine/chaos, which breaks Antifailure's own engine, and the backup drill, which restores Antifailure's own control plane database. Neither one touches a customer's environment, and a Postgres storage engine developer who asked whether the product could kill a database and validate its crash recovery was asking about something that did not exist.

A new chaos: block declares faults a rehearsal may inject, and af chaos runs them. Seven kinds, all real: SIGKILL to a process inside a container, SIGKILL to a container's main process, a clean stop, a cgroup freeze, a detach from the environment's network, a data directory made read only, and a bounded fill of the filesystem holding it. Each one carries an undo that runs even when the run fails, and each one is aimed at a container resolved from the labels the runtime stamped at create time. A container with no Antifailure label, a container belonging to another environment, and the egress sidecar are refused, and the ownership is read again from the daemon at the instant of the act rather than trusted from the moment the target was resolved.

Around a fault aimed at the database, the run proves the recovery instead of observing that it finished. Concurrent writers commit while the fault lands, and a ledger kept on the client side of the wire records exactly which commits the database acknowledged. Afterwards: every acknowledged commit must still be there, nothing may be there that no client attempted, the write ahead log must have replayed from the position the control file named before the crash to past the last flush a writer saw, and the heap and its index must still agree. The first two claims are about what the database SAID, which the database itself cannot answer, and they are the ones the question was really about.

A fault that was applied and changed nothing is refused rather than reported as survived, because every assertion after it would describe a system that never broke. A process_kill whose pattern matches nothing, a read_only_data fault on a directory whose owner can still write it, a pause the daemon accepted that left the container running: all three are refusals. In the same spirit, findings split across two policy keys. policy.chaos_failure defaults to fail and covers a lost commit, a phantom row, a short replay and a damaged relation. policy.chaos_unverified defaults to warn and covers everything the run could not establish: nothing crashed, no replay is recorded, the control file would not parse, checksums are off so a torn page would not have been seen. A check that found a problem and a check that could not look are different facts.

Network latency and packet loss are not included, and that is a stated limit rather than an omission. Shaping traffic needs tc in the target's network namespace, which the images do not carry and which the environment cannot fetch through a default deny egress policy. A declared fault that silently did nothing would be worse than an absent one.

run_sql_workload puts it on the MCP server. An agent asks for clients on their own connections running whole transactions against the branch's database, and reads back transactions per second, transaction and per statement latency percentiles, deadlocks, serialization failures, retries and the rows the statements actually touched. run_load_test sends HTTP traffic, so the number it reports is the application's latency with the database somewhere inside it, reachable only through whatever the application does on a route the manifest names safe, which is the right measurement for an application change and the wrong one for a change to an index, a lock, a storage parameter or a query.

The gap survived because no instrument in this repository asks whether a capability reaches more than one surface. surfacecheck is about which packages may be imported and whether an export changed shape, wirecheck about whether a documented variable can be delivered by an installation route, routecheck about whether a route the site calls is served. A capability on exactly one surface passes all three, so the instruments were green and could not have been anything else.

tools/paritycheck is the one that asks. The inventory is the exported method set of *env.Orchestrator read with the type checker, and the surfaces are the packages that import it, so neither is a hand written list that drifts. Every capability is reachable from every surface, or carries a row in tools/docs/surface-exemptions.tsv with a kind and a written reason, and each kind has a structural precondition that has to hold: a capability taking a context can never be filed as an accessor, and a row goes stale and fails the moment the gap it excuses is closed. A fourth package importing the capability API fails the gate rather than being ignored, because a surface it cannot classify is "I could not look" and not "I looked and it was fine".

Pointed at the tree before this change it names three: the SQL workload, its thresholds, and af load compare, which landed the same day and is on the command line alone.

Every section of the manifest described the copy: what to build, what to run, what it may reach. Nothing described production. So the one thing a twin is supposed to be measured against, the declaration of what production actually is, was a file in the repository nothing in this product had an address for.

infrastructure is that address. It names the stacks that declare production, one entry each, with the workspace and variable files that stack is read through:

```yaml infrastructure: stacks:

• source: terraform path: infra/terraform workspace: production var_files:
• infra/terraform/production.tfvars ```

Nothing in it changes what an environment builds or starts. Every key belongs to one stack, because a workspace is selected inside a single root module and a variable file is passed to a single invocation, and because a repository that declares its cloud in one tool and its workloads in another is the ordinary case rather than the exotic one.

af init drafts source and path by reading the tree. It names root modules rather than every directory with a .tf file in it, because a module a stack calls is a building block: naming it would point a comparison at a library rather than at the thing built from it. It never drafts workspace or var_files, and says so, because which workspace holds production and which of production.tfvars, staging.tfvars and dev.tfvars describes it is stated nowhere in a repository. This is the one section nothing downstream can check, so a guess there would compare a copy against staging and report a number that looked right.

Validation refuses a path that is absolute, that climbs out of the repository, that two stacks name, that is not there, that is a file where a stack is a directory, or that is a real directory holding no file the source can read. Those refusals exist because nothing downstream would report any of them: a directory with nothing in it declares no resources, and no resources is the same answer an application with no infrastructure gives. The last one is the one a deep typo actually lands on, because mistyping the final segment of a long path usually names a directory that really is there.

All of that had to be written into a manifest by hand, beside the infrastructure as code that actually built production, and the copy went stale the first time somebody edited one and not the other.

A new reader reads the infrastructure instead. Its primary input is terraform show -json plan output, because a plan has already had every variable, local, function, for_each and module evaluated by Terraform, so every number a reader cares about is a literal and nothing is unresolvable. Failing that it reads Terraform and OpenTofu HCL, raw Kubernetes manifests, and the Kustomize image and replica overrides that would otherwise have made the reported image a tag production does not run. Every component says which of those it came from, because a fully resolved description and a partly resolved one must not carry the same authority.

It never executes anything, never reaches a cloud, and never reads a Terraform state file. Those are not conventions. There is one entry point and it takes a directory, so a state file cannot be handed to it in the first place, and a state file is recognised by its content as well as its name, because a state file copied to plan.json is still a state file full of plain text passwords. A test walks the package's real import graph and fails if it can reach os/exec or net/http.

The part that matters most is what it says when it cannot read something. A variable with no default, a value that only exists after an apply, a module from a registry, a Helm chart it will not render: none of those are reported as zero, and none are guessed. Every field is one of three answers, "not declared", "read", or "declared and I could not resolve it", the third carrying a sentence and a line number, and the value of an unresolved field cannot be read at all without asking. A resource behind a count this reader cannot resolve is reported as neither present nor absent, because it is genuinely neither until Terraform runs.

A value the reader worked out and refuses to carry because it is a credential is a fourth answer again, separate from one it could not work out. Both are things it cannot tell you; only one is a hole somebody should go and look at, and a report that counted them together would send somebody hunting a defect that is not there.

Environment variable names, never values. Secret references, never secrets. Four independent controls drop a value and the engine's own redactor catches what they miss, which was measured rather than assumed: terraform show -json writes a sensitive variable's value in the clear in three separate places and marks it in only two of them.

Every emulator an environment starts is configured to keep nothing: LocalStack with PERSISTENCE off, Azurite fresh, and the storage emulator with its backend in memory. That is deliberate, because a twin that inherited the last twin's buckets would be reproducible only by accident. Nothing filled the gap it leaves, so an application that reads its own bucket, queue, table, stream, parameter or secret on startup met an emulator that had none of them, and the failure it reported was a missing bucket, which is a true sentence about the twin and a false one about production.

af up now creates the cloud resources production's infrastructure as code declares, inside the emulators, before any service starts. The requests go through the environment's own sidecar at the provider's own hostname, so what is proved is the route the application has rather than the existence of a bucket somewhere: a host the egress policy does not route is reported refused, exactly as the application would be refused at it.

What an emulator cannot hold is NAMED rather than passed over. Every attribute a declaration carries is accounted for by subtraction, so an attribute nobody thought about is reported rather than dropped: a lifecycle rule that LocalStack stores and never runs, a bucket location the storage emulator answers US-CENTRAL1 for whatever is asked, a SecureString parameter created as a plain String because the surface answers for no key service. A secret and a parameter hold a placeholder and are reported as substituted, never reproduced, because production's value must not be copied into a container a third party image runs. A resource is called reproduced only after it has been read back out of the emulator, and a run in which everything reproduced prints no caveat at all.

```yaml desktop: kind: electron application: ./node_modules/electron/dist/Electron.app/Contents/MacOS/Electron args: ["./desktop"]

workflows:

• name: sign-in surface: desktop persona: ada description: Sign in to the ledger and confirm you land on the signed in screen. expect: ["Welcome back"] ```

surface: desktop selects the desktop driver, and that driver is handed an application to open or it refuses the run. Nothing in the manifest could name one. So the surface was reachable and every run that could ever have used it was dead one field short of working: the schema accepted the manifest, the validator passed it, the documents were built, an environment was created and paid for, and the runner then refused the job for want of a field no person could have supplied.

kind is electron or macos, and it is stated rather than guessed from the path, because a wrong guess means an application driven the wrong way reports as an application that does not work. application is the Electron binary or the .app bundle, resolved against the directory holding the manifest before the runner is told, because the runner is started from somewhere the manifest never mentions. process is what macOS calls a native application when that is not its bundle's name, derived from the bundle when it is left out, and refused on an Electron application, which is launched directly and never looked up.

The pairing is refused in both directions. A workflow that drives the desktop with no application declared cannot run at all. An application no workflow drives is the quieter mistake and the one that looks like a working setting: the run opens a browser instead, every workflow passes, and nothing anywhere says the application somebody named was never launched.

The workflows themselves are ordinary workflows entries with a surface on them, not a list of their own. A desktop application is driven through its accessibility tree as a persona, which is what a browser workflow already says, so the fields are the same fields and a second list would have been a second spelling of one thing.

schemas/manifest.v1.json said of the whole load block that traffic is "compared between the base branch and this one" and that results "are always deltas", and said of its thresholds that they are "applied to the difference against the base branch, never to absolute numbers". Nothing did that. The one threshold with a baseline, p95_increase, divides a measured p95 by PRODUCTION's own p95 for that route, taken from the traffic source. That is a useful number answering a different question: is this route slower than the fleet serves it, never did this change make it slower. The same file contradicted itself, because the description on the p95_increase key itself has always described the production baseline accurately, and so has the prose documentation. Only the two container descriptions claimed a comparison, and they were the ones a reader met first.

Throughput was the sharper half of the gap. A load run has always recorded the rate it actually achieved, and no threshold anywhere read it, so a build serving half as many requests per second as the base branch passed every check this product had: each request it did complete was fast, and half as many completed.

af load compare is the comparison the schema described. It brings a second environment up from the base revision, branches the SAME golden for both so the two sides answer queries over identical rows, sends both the same weighted mix in the same order under the same seed, and differences the two. It reuses the oracle's baseline mechanism rather than reinventing it, as the side effect family's base twin already does. load.comparison.thresholds carries p95_increase against the base branch, throughput_drop, and error_rate_increase, and the two container descriptions now say which of the two baselines each key is measured against instead of claiming one for all of them.

A threshold that could not be evaluated reports unverified and exits non-zero, never pass. A route present on one side only is the case that matters most: a build that stopped serving a route has no p95 to be slower than, and calling that a clean comparison would hide the loudest result a run can produce.

The comparison says what it cannot control, on every report. Two runs against two environments are not a controlled experiment. They are sequential, because two environments sending traffic at once on one host would contend with each other and measure that instead, and the seed makes the request sequence the same while making nothing else the same. A difference is a difference, and the threshold is what turns one into a verdict.

Separately, af workload compare computed a per route table and printed none of it. The routes were in the JSON and absent from the text a person reads, so a route that doubled in p95, and a route that vanished between two runs, were both invisible to anybody not piping the output through a parser.

```yaml workflows:

• name: subscribe surface: web ```

web, terminal, desktop, ios and android. All five may be written, including the ones a build carries no driver for, and that is the point: a build registers the drivers it has, so a manifest naming a surface this build cannot drive is refused BY NAME, against the surfaces that build actually carries. A schema that simply refused the value would say only that something is unknown, which reads like a typo and sends somebody looking for a spelling mistake instead of a release.

Without this a driver could be finished, correct and unreachable, because nothing in the manifest could ask for it. That is the same defect the terminal driver had for its whole life, one surface over, and the answer this time is a key that exists before the driver does.

The refusal happens at both layers on purpose. The engine says it while reading the manifest, so the answer arrives before an environment is built, and it names what this build can drive rather than what the schema allows, because those are different lists and only one of them helps. The runner says it again before it drives anything, so a surface nothing drove can never come back green, and it says it as a blocked RESULT rather than by throwing, so one workflow naming a surface nobody built does not take the nine beside it down with it.

surface: terminal on a workflows entry is answered with where it belongs rather than with a list it is missing from: a terminal workflow needs a program to run where a browser workflow needs a persona to sign in as, so it is written in terminal_workflows.

The docker provider hardcoded postgres:<version>-alpine, which ships the contrib modules and nothing else, and hardcoded shared_preload_libraries=pg_stat_statements. An extension out of that set was not a limitation anybody could work around, it was a refusal: the restore stopped on the first object that needed one, and AF-DB-007 said so and offered only "point the provider at a different service". A Postgres storage engine developer asking whether their tables would survive a rehearsal was being told no.

database.image names the image the provider runs Postgres from, database.extensions is created in the golden before the source is copied into it, and database.preload_libraries is ADDED to shared_preload_libraries rather than replacing it, because dropping the statistics module leaves the insights reading a permanently empty table on every environment. The list is recorded on the golden image and read back when a branch starts, so a branch carries what its golden was built with even after the manifest stops asking: a library like timescaledb is loaded by the postmaster, and a server holding its catalog entries without it does not start degraded, it does not start.

Two things a named image can silently get wrong are now refused instead. An image declaring a volume over the data directory would publish a golden holding no rows at all, because a golden is the container's filesystem committed and a declared volume is not in it. An image on a different major than the manifest declares would give every environment a Postgres the application does not run. Both are checked against the running server before anything is loaded.

A table created USING an access method out of an extension now survives the golden, every branch of it, pg_dump and pg_restore, and a subset's binary COPY, with pg_class.relam intact on the far side. Masking is the one thing that will not touch it, and it now says so at planning time rather than partway through: it addresses a row by the primary key or by ctid, both of which are guarantees of the heap, and against citus columnar on Postgres 17.2 each is refused outright while the table accepts a primary key regardless. The refusal names the table and the access method, and it is narrow enough that a column nothing rewrites goes through untouched, which is what lets a golden hold such a table at all.

It was declared and scaffolded: a job naming it was refused, so an iOS application could not be rehearsed at all. It is now implemented against the iOS Simulator through Appium's XCUITest driver, and proven against one: a workflow that signs in passes, one that presses a deliberately broken control fails with the application's own error quoted back, and one whose expectation the app never shows comes back unverified rather than pretending either way.

The approach is the one every other surface here already uses. An iOS app's accessibility tree is what a screen reader reads, which is what these workflows are written against, so it is normalized into the same snapshot shape the browser produces. The planner, the judgement and the verdict are then the existing ones, unchanged: the same workflow sentence means the same thing on a web page and in an app, and a mobile verdict is decided by the same function that decides a web one.

An android surface is added alongside it, implemented against Appium's UiAutomator2 driver and deliberately NOT marked available. No run has driven an application with it: the emulator on the machine it was written on could not finish booting, and its own system watchdog was restarting the device. Claiming it would be a promise nobody has tested, and the iOS work is the argument against doing that: driving a real device for the first time found three defects that every unit test had passed over.

An Appium server is an external tool, the way the engine binary is. A run that cannot find one BLOCKS every workflow with a reason instead of failing it, because our own tooling being absent is not evidence about the application.

Three things measured against real devices rather than assumed, each of which had already produced a wrong answer:

An empty iOS text field reports its own placeholder as its value, so a field nobody had typed in read as already answered. The planner skipped it, submitted an empty form, and the application's complaint about it would have been reported as the application's fault.

The iOS software keyboard is part of the application's accessibility tree, so opening one text field turned a two control screen into one offering twenty six letter keys, shift, Return, Emoji and Dictate as things to press. The keyboard's window is now left out, because it is system interface and no workflow is about the letter q.

A screen recording stopped before its recorder had started produced no file, and one stopped uncleanly produces a file of plausible size that no player will open. Recordings are now held until they are genuinely capturing, stopped with a signal the recorder handles, and checked for the index that makes them playable; a recording that does not survive is reported as no video rather than as a path to a broken one.

examples/mobile-probe is the application these were found against: the same three controls in SwiftUI and in Java, including a failure path, so a driver can be shown saying no as well as yes. The Java half is built and installable and has not been driven, for the reason above.

Everything this engine could send at a preview environment went over HTTP. A load run sends a weighted mix of requests, a scenario walks a journey, a workflow drives a browser. All three reach the database only through the application, so every number they report is the application's latency with the database somewhere inside it. That is the right measurement for an application change and the wrong one for a change to an index, a lock, a storage parameter or a query: the person making that change wants transactions per second and the cost of one statement, and could only reach either through whatever the application happens to do on a route they can call.

af load sql opens connections to the branch and runs statements on them. N clients, each on its own connection, each running whole transactions inside one BEGIN and COMMIT, with think time between them and a seed that makes two runs execute the same sequence. It reports throughput, transaction latency, the cost of every statement, deadlocks, serialization failures and retries. A deadlock that was retried into a commit is counted as contention rather than as a failure, because that is what a correct application does about a deadlock.

The statements come from a document in the repository, or from pg_stat_statements on the branch, which is the traffic that really ran weighted by how often it ran. The derived path cannot recover the parameter VALUES, because the statistics normalise them away, so it prepares each statement to ask the server for the parameter TYPES and generates values of those types. Two consequences are reported rather than hidden: a write is refused unless the manifest allows one, and every run says how many rows its statements actually touched, so a run that matched nothing cannot be read as a fast one. A statement that will not prepare at all is refused by name with the server's own message, which catches a query against a column the change dropped before a single transaction runs.

The claim that a run was concurrent is measured rather than made. A separate connection samples pg_stat_activity while the run is going and reports how many distinct backends it saw and how many were inside a transaction at one instant. N goroutines are not N database sessions. A run whose observer could not connect reports nothing rather than zero, because "no overlap" is a finding and "nobody looked" is not.

A run that committed no transaction reports no throughput and no latency and exits non-zero. Every threshold it carries passed over an empty measurement, which is not the same as passing.

sql_workload is a fifth workload_kind in the control plane, so a hosted run dispatches it, stores its numbers and reproduces through the same plain af load sql command. Migration 0048 also rebuilds the shape constraint the four kinds already had: it was a CASE with no ELSE, and a CASE with no ELSE returns NULL for an unmatched value, which makes a CHECK pass. A fifth kind would have been entirely unconstrained while the constraint went on claiming otherwise.

It has named four surfaces for as long as it has had a surface abstraction, and it could drive two. A job that asked for the desktop was refused, correctly, because a scaffolded driver returning an empty result would have reported a green run that tested nothing. It was still a no.

Desktop now drives native macOS applications through AXUIElement, the platform's own accessibility API, and Electron applications, which is where VS Code, Slack and Discord live, through Chromium's accessibility tree. Both reduce to the same snapshot a browser produces, so the planner, the expectation check, the verdict and the live stream are the ones a browser run already uses, and a desktop result counts and reads exactly as a web result does. A workflow written as a sentence, press Continue, expect Welcome, carries across unchanged.

Native accessibility is a permission a person grants in System Settings, and a locked screen withholds every application's tree whether or not it was granted. Both are reported as themselves, with the step to take, never as an application with no controls on it.

The terminal driver had been written and unit tested for some time, and no customer run had ever reached it. The runner read a terminal list out of the job document, the engine's job document had no such field, and the manifest had no key that could have filled one, so the surface abstraction described four surfaces and the product could ask for exactly one. terminal_workflows is that key, and a terminal result is counted in the verdict and printed in the report exactly like a browser one.

The driver it reaches is a different driver. It was line oriented, which is enough for a program that reads a line and prints lines and is nothing at all for the one kind of command line application nobody can test by hand: a program that takes over the screen will not start without a terminal, reads raw keystrokes rather than lines, and leaves its meaning in a grid of cells rather than in the bytes it wrote. A workflow that declares a screen is now given a real pseudo terminal of that size, sent the bytes a keyboard sends for <down>, <ctrl-c> and the rest, and judged against every screen the program drew. Those screens are the steps in the report.

Arrow keys are sent in the encoding the program asked for rather than a guess, because a program that has taken the screen ignores the other one in silence, and a key that silently did nothing is the worst shape a test failure can take.

Everything a run gathers past the counts, the findings and their fixes, the migration statements and the locks they take, the invariants and the rows that broke them, the access probe readings, the load percentiles, reaches the control plane through the pull request callback rather than the events stream, so none of it is projected into the runs and verdicts tables the run page read. It lands whole in the generation, as the report the engine already rendered for a person, and until now nothing read it back. A check that said one workflow failed linked to a page that said no run had reported.

The run page reads that report now, at /runs?pr=<n>, and shows it in full under a scannable strip of the counts: the findings and their fixes, the migration rehearsal, the invariants, the load, the reproductions folded one click away. Nothing the run measured is dropped between the engine and the person who has to act on it, and it needs no run row to exist, so a repository reports here the first time its check runs.

The workflow template every customer runs already declares a seed and a concurrency input, and the engine already reads them: a seed makes two runs decide the same way so a before and an after can be compared, and a concurrency ceiling caps requests in flight so a load run stays inside a limit. The console had no field for either, and the dispatch verbs did not forward them even when something set them, so the one place a customer drives runs from could neither reproduce a run nor hold a load down. The card now carries the knobs: a seed on an agents run, and seconds, scale, concurrency and a seed on a load run.

Each knob is optional and a blank one is left out of the dispatch rather than sent as a zero, so it reaches the command's own default. That is not only tidy. A seed or a concurrency the customer never set would reach a workflow file that may predate those inputs, which GitHub answers with a 422 that fails the whole run, so an unset knob must not appear in the request at all.

The newest engine shipped, the session kept running the old one, and nothing on the tool surface said so or offered to close the gap.

The server serves an upgrade tool now. It installs the latest verified community release of the CLI and its bundled runner in place, downloading the build for this platform, verifying its published SHA256 checksum, and swapping the binary and the runner source atomically; it leaves shell profiles and project files alone. The check option reports the latest release beside the installed version and changes nothing. It is the same in-place update af update performs, handed to the server as a function value rather than reimplemented, so a tool call and the command cannot install different things.

Two honesties come with it. Applying replaces the file this running server was started from, and the running process keeps its own open copy, so the new version does not take effect until the server is restarted; the result says so and reports the versions before and after rather than letting a caller believe the tools changed under it. And a binary the installer does not own, an enterprise build, a platform with no release, a checksum mismatch or a failed download is reported as a refusal that changed nothing, with the reason and the next step, never as an upgrade that found nothing to do.

The authz family already knew how to decide an idor, a cross-tenant break and a privilege escalation from structured per-persona observations, and canary_leak already knew how to call a planted value in a response a leak. Both read a golden that carried no canaries and observations no runner emitted, so both were live code that could never fire: NewGoldenView had no caller, and every reach the runner made recorded no authorization reading. A build could not tell a held boundary from an unmeasured one, because nothing was ever measured.

A manifest now declares the ownership-scoped objects the suite cannot infer from a diff: a concrete object at a route, who owns it, and the canary the application's own seed planted into it. The engine builds the golden's canary view from those fixtures and drives a new access-probe pass: the runner signs in as each persona and once as nobody, reaches each declared object, decides inside the run whether the object's canary came back, and emits one observation per reach. A persona that reached another owner's object and got the canary back is a proven idor or cross-tenant break; the owner reading its own object is the self-access liveness arm, which is what lets a refusal prove a boundary held rather than that the id was invented. The value stays inside the engine throughout; an observation and a finding carry a route template, a class label and a flag, never the token or the body.

Off by default in the strongest sense: a manifest with no access block does no probing and pays nothing for it, and an absent access-probe pass is the honest not-measured state the differential fails closed on rather than reading as a clean pass.

The "talk to us" form writes a row into enterprise_leads, and migration 0035 arranged that table so the anonymous public endpoint can only INSERT and can never read a row back: a serving role that could also SELECT there is one query bug away from publishing every prospect's name, company and message. That boundary was right, and the reader it left was wrong. The only way to see a lead was af-control-plane-backup leads, a command that needs the migration role or the cluster superuser, so in practice a lead landed and nobody with the operator portal open could read it. It was the waitlist failure the table was built to end, one step downstream: a form that consumed what somebody typed.

The operator portal now has an Enterprise Leads page under Administration. It reads through the operator pool, whose role already held SELECT on the table by 0023's default privileges, and a one line migration grants that same role UPDATE so a lead can be marked handled. The serving role is untouched and stays INSERT-only, so the leak boundary is exactly as 0035 drew it. The queue is oldest first, the message opens in a panel rather than a cell, and marking a lead handled records who did it and when so nobody is answered twice or never. It mails nobody, and the page says so.

The static, model-backed code reviewer already existed, but the only ways to reach it were to submit a whole rehearsal, wait for an environment that a correctness bug does not need, and then read the finding off a run, or to open a pull request and scrape the comment the reviewer left on it. Both put the fastest, cheapest signal the product has, a model reading the added lines, behind the slowest machinery it owns.

The review_change MCP tool exposes that reviewer on its own. It reads the diff, not the twin, so it opens no session, builds no image and needs no database: mid-edit, an agent asks it and gets the concrete defects the model found on the lines the change added, each with a rule, a category, a level, a bounded description, a fix and a file:line into the agent's own changed code. A location is allowed here, unlike a security finding, because it points at the caller's own diff rather than a copy of production, and the projection still refuses to carry anything shaped like a captured body, response or row, because a diff has none. A change that touches no code is reported as nothing to review rather than a clean pass, and a change with code but no model key configured is reported as skipped with the reason, because a review that did not run is not a review that found nothing. The finding's level is the project's own policy, so it advises by default and never blocks a merge on a model's say-so.

The browser recorded no response body and no DOM, and it logged only the GET pages it navigated to. Two consequences followed, both silent because the engine consumers were already in place and simply handed nothing. canary_leak scans the run's DOM and response bodies for a secret by shape, a Stripe key or a private key that reached a response; those streams were always empty, so even a bundle that shipped a live key to the browser produced no finding. And the injection family fuzzes the routes the run observed reaching; with only GET navigations recorded, a POST, fetch or XHR API route was never sourced, so the write path where most real SQL injection lives was never exercised.

The runner records, per same-origin response, the request that reached the server with its method, so a POST or fetch route is fuzzed as the method it was, and the bounded body of each document, JSON or text response, so a leak family has something to scan. It captures the rendered text of each page it stood on for the same reason. Everything is bounded in count and in bytes, a cross-origin third party's body is never captured, and a binary or oversized response is dropped before it is read. The bodies and the DOM stay inside the engine as evidence: a finding reports a location and a kind, a route carries a method, a path and parameter names, and neither ever carries a captured value.

Every lane the product had rehearsed a change against a twin: it built the environment, ran the workflows, drove the security families, and reported what the change DID when it ran. Nothing read what the change WAS. A correctness bug that no workflow happened to exercise reached no verdict at all: an off-by-one on the last element, a nil dereference on a path the diff just added, an error that is checked and then dropped, a boundary the new code does not hold, a new function nothing calls, a value decoded as the wrong shape, an ordering hazard. These are the bugs a senior reviewer catches by reading a pull request, and the product could not read one.

af ci now runs the reviewer as one more collector beside migration, egress, masking, load, cleanup and the security families. It reads the diff and not the twin, so it runs before the environment is brought up and is worth having even on a run whose environment never started. It sends the change's added lines, with the line numbers they carry in the new file, to the model the user already configured, and maps what comes back into ordinary findings that ride the same verdict, exit code and pull request comment as everything else. A finding points at a line the author just wrote.

It is advisory by default. The reviewer is an LLM reading a diff and its findings are probabilistic, so a review finding defaults to warn rather than fail: it advises without blocking a merge on a model's say-so, and a project that trusts it raises policy.review to fail. The level comes from the manifest, never from the collector.

It is honest about absence. With no model key configured the reviewer is skipped and the run says so, in the words a person can act on, rather than reporting a clean pass it never earned. A docs-only or configuration-only change touches no code surface, so no reviewer runs, no model is called, and nothing is spent. A change the router cannot read, a diff the reviewer cannot fetch, a model that could not be reached, and a model that answered with something unreadable are all recorded as notes and produce no finding, because a gap in our tooling is a fact about us and must never redden somebody's build.

The call carries the user's own source to the user's own provider with the user's own key, the same BYOK trust model af model test uses, and nothing Antifailure hosts is involved. It goes through the air gap guard under its own site, so an air gapped installation refuses it at the dial rather than reaching a provider it was sealed away from, and the ledger attributes the attempt to the code reviewer by name.

It read a base twin's effects to do that, and it handled a missing base twin correctly, leaving the comparison unmade rather than reading an absent base as a base of zero. But af ci never built the base twin, so the missing-base path was the only path there ever was. The increase rule was fully built, correctly consuming a baseline it was never handed, and it sat dormant on every run.

af ci now brings a second environment up from the base revision when the change routes a family that reads a baseline and there is a change to compare. It is the oracle's baseline mechanism reused: the base is resolved as the merge base with the base branch, its images are built from a git archive of that revision, and it is pinned to the candidate's own golden so both sides branch one database and a difference is the code's rather than two databases'. It runs the same exploration and the same workflows the candidate ran, so the two effect counts are of the same drive.

The base twin is stamped ephemeral before it comes up and torn down by a deferred teardown after, so a crashed run's base environment is collected by the reaper within the run's budget rather than living the manifest's day, and a base env left standing is named with the exact af down --branch command to remove it. It fails closed: a base that is the same commit, that will not come up, whose workflows did not run, or whose effect logs could not be read is a note and no comparison, never a base of zero that would read as effects the change did not make. A change that routes no baseline reader builds no second environment.

It belongs beside the workflow that creates environments, on the runner or cluster where they live and with the same credentials, and it matters most on the Kubernetes runtime, where a namespace a killed run left up keeps costing money until something removes it.

A pull request could add a postinstall hook, point it at a script it downloaded with curl and piped into a shell, or move a dependency's source from the registry to a git URL, and the rehearsal classified the file as a dependency change and looked no further. The advisory scan that runs beside it answers a different question, whether a version is known-vulnerable, and none of these is a version.

There is a supply-chain family now, on the dependency surface. It reads the lines the change ADDS to a manifest or a lockfile, never the branch's absolute dependency tree, so an install hook a lockfile already carried is not counted against this change and one this change adds is. It catches three shapes the advisory scan does not: a lifecycle install hook added to a package manifest, an install step that downloads a payload and runs it, and a dependency whose source moved off the registry to a version-control URL. The last excludes a repository or homepage field, whose value is a URL by design, and requires the scheme to begin a dependency value rather than appear in prose, so a metadata line is not the false positive that gets the rule switched off.

The family refuses a change on policy grounds, so its findings carry the policy-denial exit code, and a project gates each through security.supply_chain.install_script_added, security.supply_chain.binary_download_in_install and security.supply_chain.registry_source_changed. Each defaults to warn, because a dependency change is noisy and a check that reddens every bump is one a team mutes, and a project raises it to fail once its dependency changes are clean. A finding names the file and the risk and never prints the line.

The runner is one job in and one document out, which is the right contract for a verdict and the wrong one for watching: by the time the document is written the run has finished, so there was no way to see an agent drive the application as it happened. The browser recorded a video of every session and it reached no screen at all.

There is now a live channel. The runner streams agent state, steps, and frames over a local socket while the run is still going. A new command, af watch, runs the workflows and draws them in the terminal, one pane per agent, switchable with the number keys, the arrows, or tab, with honest states rather than a spinner. The control-plane console gains the same multi-agent watch view, streaming from the runner edge. A run targets a surface: web and terminal are driven for real, and desktop and iOS are declared and refused loudly rather than reported as a green run that tested nothing.

The frames stay on the machine that produced them. They reach the terminal and the console straight from the runner edge and are never written to the control plane, which holds counts, verdicts, and a reference to the durable recording, never a body. A test fails if a frame's bytes ever reach the control-plane shape.

A migration that disabled row level security, rewrote a policy so it admitted every row, granted a table to PUBLIC or anon or authenticated, dropped the column a table is scoped by across tenants, or handed a role BYPASSRLS, SUPERUSER or CREATEROLE, applied cleanly and reported pass. Every one of those is a migration that succeeds in review and lets one tenant read another's rows, and none of them was what the seventeen availability rules were watching for.

There are now database-security rules on the same migration path, reasoning about the statements the change adds rather than the branch's absolute grant and role catalogue, because a snapshot restored twin inherits roles the change never touched and a rule that read them would fire on inherited state. They carry the security namespace in their finding rule and route to a security.db_security policy key of their own, so a project can gate a broadened grant apart from a non concurrent index and the release gate gives each one a security exit code: a broadened grant is refused on policy grounds, and the rest are verification failures. Each defaults to fail and a manifest can lower any of them. The permissive-policy rule fires only on a tautological clause, never merely on a policy that omits a tenant column, so an admin only policy is not the false positive that gets the check switched off. BYPASSRLS is caught apart from a grant, because it is an attribute on a role that makes every policy stop applying to that role's sessions rather than a privilege on a table, and conflating the two is how a review misses it.

A change could start returning a column it used to withhold, compile a secret into a client bundle, or render a social security number into a page, and the rehearsal drove the twin, captured the pages, and looked at none of it. The secret shipped, green.

There is a sensitive-data leak family now. It reads the DOM and the response bodies the run already captured against the sanitized twin and looks for two things: a value planted in the twin that must never appear in output, which is an exact match with no false positive, and a secret or a piece of personal data by shape, which is what catches the leak nobody could have planted a value for. A Stripe secret key or a private key reaching a response fails the merge; a national id or a bank account number reaching one is reported. It reuses the same detector lexicon that reads a masked database back, so a secret means the same thing in both places, and it inherits that package's iron rule: a finding names the stream and the kind and never the value, which stays inside the engine against a copy of production.

A project gates it through security.canary_leak.secret_in_response and security.canary_leak.pii_in_response, and a secret in a response carries a security exit code from the release gate. The planted-value path is wired for the day a seeder plants canaries in the twin; the shape path works today, against the evidence the run already has.

The egress and capture logs counted requests; nothing counted what a request MEANT.

Three security check families now read those same logs and drive the same twin to prove behavior rather than match a string. The injection family fires SQL, command, template, NoSQL, path traversal and dynamic query payloads at the endpoints a change touched and reports only the ones it can prove altered the application: an injected sleep that moved the response time, a database error that surfaced the schema, a template that returned the evaluated product rather than the expression, a traversal that read a file outside the application root, an operator that turned a refusal into an answer. Every payload is measured against a benign control, so a slow endpoint or a reflected value is never mistaken for a proven one, and a finding names the endpoint and the class and never the payload value.

The SSRF family reads the egress decision log for a request the application was coaxed into making against an internal or metadata address, and takes the firewall's refusal of that request as the proof. It is a reader over the existing egress mechanism, not a second firewall: an allowed internal request is the twin talking to its own services and is not a finding, and a refused external host stays the egress layer's surprise to report. A refused reach to a loopback, link local, private, carrier grade or metadata address is the finding, and a refused internal reach a webhook or callback produced is reported as callback drift, because the fix is different.

The side effect family counts dangerous effects by meaning, a charge, a refund, an email, an SMS, a webhook, a cloud create, a cloud delete, a queue publish, and compares the count against the same workflows run on the base branch. An increase over the base is a policy denial the base branch did not incur; a destructive operation fires on its own with no baseline defense, because the base deleting a bucket too is not a reason to allow deleting one. A base twin that could not be built leaves the increase unmeasured rather than reporting every effect as new, because a zero that means "did not measure" is the defect this repository keeps finding in its own instruments.

Each family emits an ordinary security finding in the security namespace, so it rides the verdict, the exit code and the read_security_findings projection the spine already wired, and a finding never carries a response body, a row, or the payload that produced it.

A workflow declares a goal, and until now one agent pursued it one way. A regression that only a different kind of user provokes, the one who reads every label before acting, the one who takes the first prominent control and never scrolls, the one who probes the unusual path, went unseen, because the single agent never behaved like them. A single path through the twin is a single opinion about how the change behaves.

A new top level diversity block turns on a population. It draws agents from a built in catalogue of ten personalities, each a behavioral lens ported from a diversity model: an explorer, a fast actor, a cautious analyst, a skeptic, an edge case prober, and five more. A personality is HOW an agent behaves, kept deliberately separate from the persona it signs in as, which is WHO it is: a personality reaches no provisioning and changes only which of the controls already on the page an agent prefers and how it explains the choice. It can never name a control that is not there, because the action grammar and the exact name refusal below the personality preamble are untouched.

The whole plan is resolved from a seed: the same seed against the same application assigns the same personalities and the same behavioral profiles, step for step, so a personality driven finding replays the way an exploration does. Because each personality's reasoning is part of the model prompt and the cassette keys on the whole prompt, N personalities over one page record N answers and the pipeline stays exactly reproducible and free to replay, with a missing recording blocking loudly rather than reaching the network. Off by default: a manifest with no diversity block, or one that is disabled, runs exactly one neutral agent per workflow as before.

The personalities run through the same key the runner already reads from the environment, the user's own, on the ungated model path. Nothing here gates them behind an edition, and a test refuses the import that would.

The contract had shipped: a Family interface, a registry, the policy keys, the exit codes, and read_security_findings. Nothing called Probe. A family could be written, registered, and documented and still never run against a change, because the one place a run assembles its findings, ci's finish, had a collector for the migration, the egress, the masking, the load, and the cleanup and none for security. The whole suite was capability that looked shipped and did nothing, the shape this repository calls a dead, shippable gap.

af ci now routes the change through the family registry, runs each selected family's Probe against the targets the diff touched while the twin is still up, gates each on its edition feature at the probe call site, and folds the findings into the same run.Findings the verdict, the exit code, the pull request comment, and read_security_findings already carry. A family whose surface the change did not touch is not run, an unlicensed one is skipped with a note that names the feature rather than dropped, and the empty registry the spine ships produces no finding and does no work at all. The reader families read what the run captured, the egress and message logs, the browser evidence, and a base twin's counts, through additive accessors on the family Input that report absent rather than empty, so a reader that was handed nothing fails closed instead of passing.

The suite fans out into families that each rehearse a change against the sanitized twin: broken access control, injection, a leaked canary, an unexpected side effect, row level security left off, a weakened response header, a dependency worth a second look. Written in parallel with no shared seam, each would have had to decide for itself how a finding becomes a verdict, which exit code it carries, how it renders in the pull request comment, and how it stays inside the data boundary the control plane depends on. Those four decisions made seven times are four contracts that agree until somebody edits one, which is the drift this repository keeps finding in itself.

This is the spine they share, and it carries no family logic of its own. A security finding is an ordinary report finding in a new policy namespace, so it inherits the verdict, the exit code, the comment and the control plane boundary for free. The change router gains an auth surface for who-may-do-what and emits the routed units a family and a browser personality run against, so a check runs at exactly the endpoint or boundary a diff touched rather than across the whole application. The manifest gains a policy.security block keyed by the finding rule, so a project decides what each finding does the same way it decides everything else. A read_security_findings tool projects those findings for a coding agent, carrying a rule, a level, a location and a bounded description and never the offending body, response or row. And the gate turns a security finding into a dynamic security exit code, a verification failure when a family proved a hole and a policy denial when it refused a change on policy grounds.

The registry ships empty and wired: with no family registered, the plan gains no security check and the report is exactly what it was, which is what lets each family land afterwards by registering against a contract that already holds.

The comparison table in benchmarks/ had a row for RDS and no code behind the name, while most Postgres on AWS runs on plain RDS rather than Aurora.

A branch is RestoreDBInstanceFromDBSnapshot. RDS provisions an instance and hydrates a new volume from the snapshot, and the volume is every byte of the database, so the provider declares CopyOnWrite: false and its branch time is minutes and grows with the data. It refuses an Aurora cluster and names the aurora provider instead.

A restore inherits production's whole role catalog, not just its master password, so the provider closes every inherited login and ends its sessions before a golden is masked, again before it is published, and again on every branch. It rotates the master password to a key derived per instance, turns IAM database authentication off, and places the instance in the source's own subnet group and security groups with no public address. Connections default to verify-full against AWS's published RDS root bundles. Every resource is bound to the source instance's ARN and carries an HMAC receipt under the branch key, so a second source in the same account is never adopted or deleted, and a branch interrupted before its logins were closed is never handed out.

Requests follow AWS's published RDS service model: tags go out as Tags.Tag.N, which is what botocore's query serializer sends, and an instance's subnet group is read as the structure AWS returns. Every request goes through the air gap guard, and the provider is refused under AF_AIR_GAPPED.

After rotating the master password, the provider waits until RDS no longer lists it as pending and the new password actually opens the database, because RDS reports an instance available before a password change is in force. The attestation, the masking rules hash and the provenance are stored in tags as base64, because a tag value refuses the braces, quotes and commas a document contains. Beside the attestation's chunks go a count of them and a digest of the whole, so a golden that lost a chunk, or had one shortened or rewritten, reads as unverified and cannot be branched instead of passing a shorter attestation off as the whole one.

Part of this has run against real AWS. One run in us-east-1 reached a masked, verified candidate over verify-full against RDS's own certificate, with a snapshot in 1 minute 11 seconds and a restore in 5 minutes 4 seconds at 20 GB, and found the two defects above and a third in instance role credentials, all fixed. It stopped before a golden was published, so publishing, branching, isolation and destroy are proved against a fake RDS control plane over a real Postgres only. The benchmark prints UNMEASURED for every wall clock cell, and the copy on write verdict is recorded as unproven, because one restore at one size cannot decide whether branch time grows with the data.

The enterprise licence sold this, LICENSING.md and ee/README.md listed it, and no organisation could have a custom role. Both halves of the mechanism existed and neither was joined to the other. permits() in the community API has asked an installed permission resolver on every request since it was written, and ee/web/rbac has always carried a role model, a validator, a scope resolver and a reviewable file format that answer in exactly that resolver's shape. Nothing stored a model, so there was nothing to build a resolver from, and nothing installed one outside that package's own tests.

What is new is the join: migration 0046 stores a model per organisation under row level security, the enterprise edition mounts four routes that export, preview and apply it as a reviewed YAML file, and its entry point installs the resolver. The resolver reads the model on every request a built-in role would refuse, per request rather than from a cache, for the reason orgProcedure already re-reads the member's role: a model held in memory is a revocation that does not take effect on the replica holding it.

rbac is now enforced rather than reported. It leaves the unenforced map in ee/engine/license/license.go, which is empty as a result and deleted along with the licensegen warning it fed and the checks that read it, because a warning that cannot fire teaches whoever reads it that this state does not exist.

The four built-in roles are unchanged. A resolver is asked only where the built-in table has already refused, so a custom role can widen a role and can never narrow one. That was the documented rule and not the behaviour: permits returned a resolver's false over the table's true, under a test named "a resolver cannot take away what a built-in role grants" that asserted it had.

members.list now returns each member's user_id. A grant names a person by that id, and no route an organisation can call answered it: the list stripped the field from every row, while nextCursor carried the last row's id to the same caller anyway. So the feature above could be used only by somebody with a database console. The id rather than a GitHub login, because a member who signs in through single sign-on can have no GitHub login at all.

Any member of an organisation can read these ids, viewers included, because members.list needs only environments.view, which all four built-in roles hold. A viewer already sees every member's login, name and role, and an id is not a credential: writing a grant with one needs members.manage. The list is bounded to the caller's own organisation by two row level security policies, one on members and one on users, and either one alone holds. A test proves that with no cursor and with a cursor forged from another organisation's member.

Before this the runtimes, the emulators and the secret stores were symmetric across the three clouds and the database was not: aurora was the only managed provider, so "works on AWS, GCP and Azure" was true of three dimensions out of four and the fourth was the one holding the data.

The two are not copies of the Aurora provider and each says where it stops.

cloudsql branches with a Cloud SQL FAST clone, which Google creates from an Instant Snapshot and documents as metadata only, so branch work does not depend on the size of the database. Cloud SQL also has a STANDARD clone whose duration scales with that size, it selects between the two from the shape of the request, and it returns the same operation either way. Three things force the slow one: naming a zone, asking for a point in time, and disk properties that do not match. The first is the trap, because Google documents that re-specifying even the source's own zone falls back, so the request that looks most careful is the one that stops being copy on write. The clone request type here has no field for a zone or a point in time at all, so asking for the slow path does not compile.

azurepg branches with a point in time restore and declares copy on write FALSE. Microsoft's statement that a snapshot restore does not depend on the size of the data reads like the copy on write sentence, and the rest of the same paragraph is why it is not one: log replay follows, and the overall recovery is given as a few minutes up to a few hours. It also does the three things Azure does not do for you, each of which is an outage or an exposure if a provider assumes otherwise: firewall rules are not copied across a restore, so a branch is a server nobody can reach; a restored server keeps the SOURCE's administrator login, so without a reset every preview holds production's credential; and a restore cannot cross between public and private access, which is refused before provisioning rather than after.

Both control plane clients obtain identity tokens before making API calls. Azure restores preserve private subnet and DNS configuration, retain ownership metadata when publishing, and list the full paginated inventory. Invalid rows do not discard valid collection entries. A server with several application databases requires an explicit selection. Cancellation after restore acceptance cleans up with a fresh context instead of leaving an untracked billed server.

cloudsql has not been run against Google Cloud. azurepg has met Azure once, where a golden restore, mask and verification succeeded over verify-full in 392.4 seconds and the branch restore after it failed with an internal error from Azure, so the branch path is not proved there. Both suites drive a fake control plane with a real Postgres behind it, so the behaviours that are claims about bytes are checked against bytes, and neither asserts RealService, so the service owned verdicts report unproven rather than passed. Both carry an entry in the copy on write ledger saying so, recorded from a conformance run that reported UNPROVEN for each, and the database providers page says "expected" and "never timed" of both, as it already did of Aurora.

One question is recorded unanswered rather than guessed: Google's documentation does not say whether a STOPPED Cloud SQL instance can be cloned, in either direction. That decides whether a published golden can drop its compute, so the default keeps goldens running, which costs more and is known to work.

database.provider: xata with database.project: <organization>/<project> makes a golden a branch of the project's root, masked and verified in place and published by a rename, and makes every environment a branch of that golden. The attestation travels inside the golden, so a branch carries what was scanned.

The provider declares copy on write, because Xata's own branching page says so, and the copy on write ledger records that declaration as unproven. The conformance suite runs in full against a fake Xata control plane over a real Postgres, built from Xata's published API document, and a fake over one Postgres can only copy. The command that settles it against a real account is on the provider's page.

Refreshing now refuses a manifest asking for a Postgres major the project does not run, with AF-DB-003, before anything is loaded. A refusal from Xata keeps Xata's own code and message. The page for this provider names every call it makes, the three API key scopes it needs, and the capabilities it declares false, with the reason for each.

It ran the goals antifailure.yaml declared exactly as they were declared, and --only chose among them without changing any of them. Asking whether a path works for a viewer rather than the owner, whether the billing page offers a way onward when you start on it, or whether the upgrade control exists on a phone meant editing the manifest first and remembering to put it back. The MCP tool had the same reach: an agent could select a goal and replay a seed, and nothing else.

af explore now takes --persona, --start, --viewport, --budget and --focus, and explore_for_friction takes persona, start_path, viewport, budget and focus. Each overrides the goal for one run and writes nothing. phone is a touch screen and a phone's user agent at 390 by 844 rather than a narrow desktop window, because a layout that switches on either never reflows for a size alone. A persona the manifest does not declare is refused with AF-AGT-022 naming the ones it does. A start path that is a URL, a size outside 320 to 3840 a side, or a budget that is neither a step count nor a duration is refused with AF-AGT-023 before anything is asked of the environment.

Every exploration now reports the persona it signed in as, the page it started on and the window it ran in, both on the terminal and in the JSON, and its replay line carries the same flags quoted for a shell.

A goal's budget.duration now bounds it. The manifest has always normalised it to ten minutes and refused one that was not a duration, and then sent it nowhere, so a goal declaring two minutes ran for as long as its steps took. An exploration now stops at whichever of its steps and its time runs out first, and a goal that sets no duration stops after ten minutes.

The control plane's audit log reached a sink from pull request 372, and the sink was one per process, read from AF_AUDIT_STREAM_SINK. That is right for a self hosted installation, where the operator and the customer are the same person. The hosted enterprise plan sells audit_stream to an organization that shares its process with every other organization on the installation, so an entitled hosted customer was told their audit log could reach their own security information and event management system while the only destination in existence was the operator's.

An organization now owns a destination: a Splunk, Event Hubs or signed webhook endpoint, and the credential it needs, sealed under the mechanism a customer's provider key already uses, which never puts the value in Postgres. An owner or an admin sets it through /enterprise/audit-stream, the entitlement is asked on every request and on every pass of the forwarder, and the forwarder resolves the destination per organization so one organization's entries reach its collector and no other. Delivery state is recorded per organization, because a credential the customer's own system revokes produces a refusal that was previously visible only in the operator's container log.

A destination supplied by a customer is untrusted input and is held to a stricter rule than an operator's: HTTPS always with no loopback exception, no credentials in the URL, and no literal address that is not a public one.

The path is served by the enterprise edition of the control plane, like single sign on and directory provisioning. A deployment running the community image answers it with 404, which is what app.antifailure.dev answered when this was written, so the guide names the host as <your-control-plane> rather than showing a command that fails. The enterprise pages were already written that way and no gate read a path after that placeholder, so a new suite beside the enterprise entry point now holds every documented path to the routes a server built by registerEnterprise answers, and refuses an enterprise path named on a page outside the enterprise section.

Using an emulator normally means changing the program: an endpoint override, an AWS_ENDPOINT_URL, a client constructed one way under test and another way in production. Whatever that run proves, it proves it about code nobody ships. The part worth building is not the emulator, it is removing that change, and this release lands the half of it that can be measured.

Nine services are declared and published as the surface: S3 including virtual hosted bucket addressing, SQS, SNS, DynamoDB, Kinesis, EventBridge, Secrets Manager, Systems Manager Parameter Store, and STS. STS is there because credential chains call it before the first real request, so a surface without it fails at startup with an error naming the wrong thing.

The proof is a suite that runs on every build. The AWS SDK for Go is built from the default configuration chain, told nothing, and it reaches LocalStack anyway. The AWS SDK for JavaScript reads no proxy variable at all, so it is driven the other way, through DNS on an internal Docker network, which is the mechanism that does not depend on a library choosing to honour a variable. Neither application names an endpoint. An AWS host outside the surface is refused rather than answered, with the same 403 the sidecar already writes for a blocked host, because a wrong answer from an emulator is worse than a refusal: it will be trusted.

Read docs/guides/aws.md for the surface and the measurements behind it. An egress rule selects mode emulate and emulator aws; the Docker runtime starts the registered image and routes matching hosts through the sidecar. This change supplies the built-in registration, generated notices, published surface and SDK suite. Separate runtime tests prove application routing, containment and teardown. A test fails when the guide and code disagree.

One fact worth reading before planning around this: LocalStack archived its community edition in March 2026 and the current image refuses to start without an auth token. The image is pinned by digest to the final community build, which starts offline and needs no account, and an organization with a licence can register the supported image under the same name from its own build.

The enterprise edition sold "SIEM streaming with a tamper evident hash chain". Both halves were real and neither was joined to the other. The chain lives in audit_entries and records organization actions including sign on, directory provisioning and administration. The separate global operator log is exported only where its writer also produces an organization entry. The streaming was the engine's, forwarding five actions from a machine with no database. So the log with the chain in it reached no destination at all, and the sentence could point at a real half whenever it was questioned.

The forwarder that carries it had been written, tested and left imported by nothing: not a declared dependency of any package in the workspace, while its own suite ran green on every pull request because the command that runs it runs every workspace. AF_AUDIT_STREAM_SINK now starts a poll loop over audit_entries.seq that batches per organization, signs a manifest over the chain head, and tracks delivery per organization. A late commit in one organization cannot be skipped because another organization committed first. Transient failures remain pending. Permanent collector refusals are logged and skipped; the primary audit log is retained either way.

Two things the wiring found. web/apps/api/src/entitlements.ts had no audit_stream entry, so the per organization gate answered no for every organization on every plan and could never have been passed. And forwarding is a cross tenant read by nature, which now has a policy and a pool scope of its own rather than a reuse of the sweeper's, so the four existing sweeps do not gain the ability to read anybody's audit log.

The receiver verifies the manifest's organization, count, sequence range and chain head against the signed entries. Remote destinations require HTTPS, redirects are refused, requests carry a deadline, and collector response bodies are cancelled rather than buffered or copied into logs. Polling stops through the control plane's shutdown hook.

Event Hubs batches encode each message body as a JSON string and carry the signed manifest in event properties, so it survives delivery to a consumer. Splunk retains the manifest in an indexed field beside each audit event.

LocalStack, Azurite and the vendors' own emulators carry years of fidelity work nobody here is going to reproduce, and every one of them is reached the same way: an endpoint override, a base URL that only has a value under test, a client constructed one way for tests and another for production. The change is small enough that everybody makes it and large enough that it moves the code under test off the path that ships.

A new egress mode removes the change. A rule set to emulate names a registered emulator, and the sidecar answers for the provider's own hostname with a certificate the environment already trusts, then forwards the request to a container beside the services. Your SDK is configured for production and stays that way.

The mode names a registration rather than an image or an address, so a manifest cannot decide what answers for s3.amazonaws.com. A name this build has not registered refuses the environment before it starts rather than falling through to block, because a rule that silently does nothing is how somebody comes to believe an environment was tested against S3. The emulator container joins the environment's inner network and nothing else, so it has no route to the internet at all.

Two headers are deliberately preserved rather than rewritten, and the reason is in docs/concepts/egress.md. The Host header carries the bucket name in virtual hosted S3 addressing, so rewriting it would rename every bucket. The Authorization header cannot leak to anything from a network with no route out, and replacing it without re-signing would produce a signature that disagrees with its own request. The sidecar records the access key id, never the secret, and the live credential tripwire still refuses a key that works against production.

conformance.RunEmulator checks the nine promises the engine makes about an emulator, none of which is about whether the emulator implements S3 correctly. It ships with a broken emulator and a self test that requires each break to turn exactly one behaviour red, including the one that matters most: an emulator that refuses everything passes every other check and is useless.

The container a registration declares carries three fields that LocalStack did not need and the other two clouds do. Command decides which emulator you get, because Google ships four of them inside one Cloud CLI image whose entrypoint is the CLI. Companions are the containers an emulator does not work without, such as the MSSQL instance Azure's Service Bus emulator refuses to start without, and they join the inner network on exactly the emulator's terms so they have no route out either. Maintainer records who stands behind an image, declared rather than inferred from the registry it sits in, because the de facto GCS emulator is community maintained and Google ships none at all.

air_gapped was one of twelve features an enterprise licence can carry, and grepping the repository for it returned two lines: the constant that declares its own name and the entry in AllFeatures that lists it. Nothing read it. An installation running with air_gapped in its licence checked GitHub for a new release, exported telemetry, pulled the Postgres and ClickHouse images from Docker Hub, built the sidecar image from a base image it fetched, asked a model provider to invent HTTP responses for any rule in synth mode, and forwarded the application's own traffic to the real internet for every rule in allow and sandbox mode. It behaved exactly as an installation without the feature did.

AF_AIR_GAPPED=1 now seals the process. Every outbound client in the engine and the enterprise edition dials through one guard, which refuses any address the operator did not name in AF_AIR_GAPPED_ALLOW, records the attempt, and refuses a hostname before resolving it so the refusal does not leak the name over DNS. Loopback and unix sockets are always permitted, because the sidecar, the local Postgres and the Docker daemon are addressed there. A private range is not permitted implicitly: an internal registry is reachable because it was named, not because 10.0.0.0/8 looked harmless.

The variable set without a licence for the feature stops the binary rather than starting it unsealed, because an installation that believes it is air gapped and makes one call it did not expect is the failure the feature exists to prevent, and the belief is the part that does the damage. Once sealed nothing unseals it, including a licence that lapses overnight.

An environment whose egress rules would reach outside is refused before it is created, naming every rule. allow forwards to the real host, sandbox substitutes a test credential and still forwards to the real host, and synth calls a model provider. block, capture and mock are answered inside the environment and are untouched. Refused rather than quietly downgraded, because an environment switched from allow to block behind the operator's back would report that it tested a code path it never reached.

The deliverable is the measurement, not the flag. A test seals the guard and performs a complete lifecycle on real Docker, bringing an environment up, serving a request through it and tearing it down, then reads the ledger. It asserts zero refusals AND, separately, that the readiness probe is in the ledger, because zero refusals out of zero observations is not a measurement and would read the same on a build where the guard was never on the path.

Both error handlers already caught every unexpected failure and both already wrote a line naming the error class, the driver's code, the method and the route. That line went to standard output. On the hosted control plane something ships standard output somewhere searchable; on a self hosted one it is a line in docker logs, with no count, no first seen and no grouping. The one number an operator could reach, af_http_requests_total{status_class="5xx"}, says how many and never says what. The Logs & Error Explorer said in its own header that this product records no fingerprint and no occurrence counter, which was true of the engine's exceptions and needed nothing from anybody to stop being true of the control plane's own.

So the control plane now groups its own failures into a table it writes to its own Postgres, and the operator portal reads them and updates itself every ten seconds without a refresh. A row is a group rather than an occurrence, so the table's size is a function of the code and not of how badly the day is going: a self hoster's disk filling on the day their control plane starts failing would be an incident caused by the feature meant to help with incidents. The store holds at most five hundred groups and says on the page when it has reached that, because a store that quietly under-reports is worse than none.

It keeps no message, no stack and no payload, for the reason already written on the handler above it: a query failure from this stack renders as the whole statement with its parameters after it, so a message here can carry a tenant's data. It keeps no organization either, so it cannot say how many tenants a failure touched, and the page says that in words rather than showing a zero.

Nothing records a stack trace from a customer's run. That still needs the engine to report one.

A branch is an Aurora clone, requested copy on write and never any other way. The clone shares the source cluster's storage volume and diverges a page at a time, so branching moves no data and the work it does is the same at a hundred rows and at a terabyte. Nothing connects to production at any point: the copy is made by the storage layer from the cluster the manifest names, so no credential for the production database is ever read or held.

The half of that claim which is not the clone is in the provider's documentation rather than left for somebody to discover. A clone has no instances and nobody can connect to storage, so a preview environment waits for a writer instance, which is minutes. That wait is flat in the size of the database too, and the provider declares its expected branch latency in minutes rather than in the seconds the fast half would support.

Two things it does rather than the obvious nothing. A published golden's writer instance is deleted once the masking and the verification have run, because a cluster's volume is clonable with nothing attached to it, so a golden costs storage and no compute. And every clone's master password is rotated before anything connects, because a clone inherits the source's credential and a provider that left it alone would hand production's database password to every preview environment.

Three things it refuses rather than substitutes. A source cluster that is not Aurora PostgreSQL is refused at startup instead of falling back to a snapshot restore that would copy every byte. Reset and pooled connection strings are declared unsupported instead of being destroy-and-recreate and a second copy of the direct string. And the benchmark prints UNMEASURED for the wall clock of a real Aurora clone, because no test here has an AWS account and a number from somewhere else is not a measurement.

af up printed one line saying that this build brings up the golden stance only, and then the environment either started a container because a service happened to carry the same name or started nothing at all, and nothing afterwards could tell those two apart. The fidelity report called every one of them unmeasured, which holds a component out of the score in both directions, so a twin of a product whose events live in Kafka scored exactly the same whether its broker held the declared topics or was an empty container nobody had touched.

The stance is the feature. Not everything should be cloned, and a plan that copies a cache and calls it fidelity has misunderstood what fidelity is. So the other three stances are now outcomes.

empty is the store's own service and nothing else, said out loud. That is already the state the stance asks for. What was missing was never a container, it was somebody being told that this store is empty because a person decided it should be, and being told the declared reason. The run says it and the report says it again. What is refused is a store declared empty that nothing in the manifest starts, which is a manifest asking the environment to hold a store while nothing brings one up.

derived runs its declared rebuild command to completion inside the environment, in the image and with the variables of the service it names, once every service is up. A non-zero exit fails the environment rather than leaving an index nobody built. A search index cloned from production is stale against the branch the moment the branch is masked, because the documents in it name people who do not exist in the twin's Postgres. An index built from the branch cannot be stale against it.

topics_only creates the declared topics and consumer groups, with no messages. Three things a consumer needs, none of which exists in an empty broker. The topic, because subscribing to a name that is not there reads nothing and reports nothing, and the run goes green having tested a poll loop against a name that will only ever exist in production. The partition count, because ordering is per partition and a group with more members than partitions leaves members idle, so a twin whose topic has one partition where production has twelve cannot reproduce a reordering bug at all. The consumer group, because a consumer joining a group nobody created reads from the END by default, so the twin's own producers write, the consumer joins, and every one of those messages is skipped.

The commands are the broker's own, run in the broker's own image, and they wait for it to answer a metadata request first, because a broker declares no health path in anybody's compose file and there is nothing for the readiness wait to have waited on. A broker this build has no recipe for is REFUSED by name rather than started with nothing in it, which would be the empty stance wearing a different word. This build shapes Kafka.

Both runtimes run the jobs, after every service and before the environment is called up, because a rebuild reads one store and writes another and a topic creation needs a broker that has finished starting.

The report shows all four as distinct positions. empty, derived and topics_only are substituted rather than unmeasured: not reproduced, because none of the three is production's data and the argument for them is that it should not be, and not held out of the number, because that is what made an honest position and an accident score the same. The score goes down for declaring a cache empty. It should, and the declared reason is carried through as written beside it. A store whose service is not running is absent whatever the manifest says, and a store that is running for which this environment's own run recorded no such job stays unmeasured and is told to run af up again: an environment brought up by an older build runs the same services from the same file with a broker that has nothing in it, and the run journal is the only thing that records what a particular run actually did.

Two of those three are wrong against Microsoft's own documentation, and the third is not the protection it sounds like.

An internal environment governs INGRESS. Microsoft bills a virtual network integrated environment for "one standard static public IP for egress if you're using an internal or external environment", so an internal environment is provisioned with a public egress address and reaches the internet unless a route sends it somewhere else first.

A network security group that denies cannot exist here either. The Container Apps firewall guidance requires mcr.microsoft.com, *.data.mcr.microsoft.com, packages.aks.azure.com and acs-mirror.azureedge.net under the scenario "All scenarios", and offers the private endpoint escape only for your own registry and key vault, never for those four. That is worse than the AWS answer rather than the same one: on Fargate the registry, layer and log dependencies are all reachable through endpoints inside the VPC, so a task can start in a subnet with no route out, and a Container Apps replica cannot. Microsoft states the rest plainly: "Don't explicitly deny the Azure DNS address 168.63.129.16 in the outgoing NSG rules. If you do, your Container Apps environment doesn't function."

So runtime.provider: aca now reaches a package that enumerates twelve egress paths out of a replica and refuses. Eight are closed by the generated configuration, three are open and named, and one is unproven and is never counted as closed. A manifest naming the runtime exits with the whole report rather than with a list of the two runtimes that do exist.

Every verdict is computed from a configuration that has never been applied to an Azure subscription, and the report says so in a constant that cannot be paraphrased away.

engine/internal/detect decides that a host gets egress mode capture; engine/cmd/af-proxy decides what a captured request is answered with. A provider named in the first with no handler in the second is answered by the generic fallback, which returns 200 and an empty object, so an application reading a provider specific id or status out of the response gets nothing.

The two lists agree today, seven providers for seven handlers. This adds the check that holds them there.

The engine declares five sockets a build outside the repository can implement: database providers, datastore providers, runtimes, golden stores and emulators. All five are reachable, validated, and refused by name when a manifest asks for something that is not there. The Providers section described databases and nothing else, so the other four were the quietest kind of missing feature: they work, and nobody outside can find out that they do.

There are now five pages, one per point, with what ships for each, the mechanism underneath, the capabilities the conformance suite tests against, and the editions rule that says which of them are MIT and why. The check that holds it there reads the socket constants and the schema's provider names out of the code, so a sixth extension point, or a new provider name, reds the build until somebody writes it down.

Two new things ship beside it.

gcs is a golden store, MIT and in the engine beside s3 and azure_blob because those are its peers and anything with an MIT peer in the engine stays MIT. A fleet on Google Cloud previously had two choices: give a runner an AWS or Azure credential it had no other use for, or keep every golden on the one machine that made it and stop being a fleet. It authenticates through the metadata server where there is one and through a service account key where there is not.

cloud_database and cloud_runtime are two licensed features covering the managed cloud providers, gated per call rather than at registration, so a licence that lapses while the process is running stops enforcement without a restart. The gate refuses anything that creates a cloud resource and never refuses a teardown, an inventory or a status: a lapsed licence that stopped somebody removing a database cluster would leave them paying for it.

runtime.provider: cloudrun reached the engine's generic refusal, which says this build has local and kubernetes and stops there. That answer is true and it is useless: somebody writing that line is asking whether their environments can run on Cloud Run, and a list of the runtimes that already exist does not tell them why not.

The plan for this lane described the containment as VPC egress for all traffic through a connector, a firewall that denies, and metadata reachable only to the sidecar. Two of those three lines are wrong, and the third is wrong in the direction that flatters the claim. Google's page on deploying multiple containers states that "All containers within an instance share the same network namespace", the container contract states that Cloud Run writes an /etc/hosts entry mapping container names to 127.0.0.1 so containers reach each other on localhost, and one paragraph of the container contract says the opposite in passing, that containers run under network namespaces "isolating them from each other". The mechanism settles it: communication over localhost is what a shared network namespace is. So there is no arrangement in which the sidecar reaches the metadata server and the application container does not. Cloud Run has no way to run a service with no identity at all, and the metadata server hands an OAuth access token for that identity to anything inside the container, on an address that Google states VPC firewall rules do not apply to. That path is closed on Fargate, where a task definition may carry no task role, and it cannot be closed here.

The runtime is registered and it refuses, carrying the enumeration as the reason: ten egress paths out of a Cloud Run instance, six closed by the generated configuration, three open and one that neither the configuration nor Google's documentation decides. Seven of ten for an environment of exactly one service, which is a shape Fargate cannot reach at all, because there the image pull and the log push hold the equivalent allowance open whatever the environment contains.

Cloud Run is the tighter of the two clouds in the place that decided the ECS lane. Google states that container images "are not pulled from their container repository when a new Cloud Run instance is started" and the platform captures the log streams itself, so an environment here starts under a deny all egress rule, where a Fargate task under the same rule never starts and holds three paths open by necessity.

Every verdict is computed from a configuration that has never been applied to a Google Cloud project, and the report says so in a constant that cannot be paraphrased away.

Six services are answered inside the environment: Cloud Storage, Pub/Sub, Firestore, Datastore, Bigtable and Spanner. A Google host outside that list is not routed to an emulator at all, so it is refused by the egress policy rather than answered, because a wrong answer from an emulator is worse than a refusal.

Six containers, not one. Google ships no single emulator the way LocalStack is one for AWS: its official emulators are five separate programs, four of them inside the Google Cloud CLI image and selected by the container's command, and Cloud Storage has no official Google emulator at all. So EmulatorContainer grew a Command, without which four of the six are identical containers that run a shell and answer nothing.

The one that is not Google's is the reason the declaration grew an Official field. Cloud Storage is answered by fake-gcs-server, which is a community project with no affiliation to Google, and nothing in the emulator declaration could say so: a reader had to already know which of the project names were vendor names. A guide printing six emulators in one table with nothing distinguishing them would have presented somebody else's software as Google's, and a user who found that out from a failing test was misled by us.

The guide publishes what was measured rather than what was hoped. An unmodified @google-cloud/storage and an unmodified google-cloud-storage both create a bucket, upload, download and list with no endpoint override and no emulator environment variable. The other five services speak gRPC, and the sidecar's inspected path reads HTTP/1.1 out of the connection it terminates, so an unmodified gRPC client spends its whole sixty second deadline retrying. The same client against the same proxy forwarding HTTP/2 instead answers in 456 milliseconds, which is what says the blocker is one property of one file rather than anything about the emulators.

Both halves were a silence rather than a wrong answer, which is why nothing caught them. The image classifier recognised ClickHouse, Redis and Elasticsearch, and the merge read postgres, asked about mysql and mongodb and dropped every other classification on the floor; Kafka was not classified at all. So the twin of an analytics product came up holding a masked Postgres and an empty everything else. af init now proposes a stance for every store beside the primary, with the reason written per engine, and a store this build has no provider for is reported with the stance it would have taken instead of being written into a manifest af up would then refuse.

A cloud emulator in that same compose file is the strongest statement a repository makes about which cloud it talks to, because somebody configured it rather than installed it. LocalStack with SERVICES=s3,sqs,sns is read as the roster, and each service on it gets the catalog's rule for the real host.

The catalog itself matched a dependency by its exact name, which works for a package called stripe and stops working the moment a vendor ships one client per service. Twenty two entries are added, covering Lambda, CloudWatch, KMS, Step Functions, Athena, Bedrock, Cognito, API Gateway, Firehose, BigQuery, Cloud Logging, Cloud Monitoring, Bigtable, Spanner, Vertex AI, Cloud Run, the Google and Microsoft token endpoints, Azure OpenAI, Azure AI Search, Azure Monitor and App Configuration. Every host is written out rather than derived from the package name, because AWS spells Step Functions as states and CloudWatch Logs as logs, and a host guessed wrong matches nothing while looking like coverage.

Measured against the probe corpus, which grew from 30 concrete cloud endpoints to 62: before, 30 were named by a rule and 32 were refused with "no rule matches"; after, 62 are named and none is answered by a wildcard. What the catalog still does not cover is named at af init rather than discovered as an unreadable refusal in an environment, and the one endpoint that cannot be covered without reintroducing a wildcard is stated in the entry and held there by a test.

extension.AuditSink, Registry.AddAuditSink and Registry.Audit were written, documented and tested, and on the tree this was measured against Registry.Audit had exactly two callers in the whole repository. Both were in engine/pkg/extension/extension_test.go. There was no implementation of the interface anywhere, and no binary registered one. So a customer who bought audit_stream got a licence that granted a feature, a documentation page listing what is audited, and not one entry forwarded to anything. Every piece was present and the behaviour was absent, which is the same shippable gap as a block button that hides nothing.

The engine now records five privileged actions through the socket: an environment refused by organization policy, an environment created, an environment torn down, a golden published to a shared store, and a published golden pulled onto a machine. The refusal is the one a security team came for, because it is the only kind of entry that shows a control holding rather than merely being configured, and it reaches a sink before anything has been created.

The enterprise edition answers with three sinks, each gated on the licence per call rather than at registration so that a licence lapsing mid-process stops forwarding without a restart: syslog over TLS, framed by octet count so a refusal written for a terminal arrives as one entry rather than four corrupt ones; an HTTPS webhook with a signed body, a bounded retry and a dead letter file, because a webhook that posts once loses an entry every time its receiver restarts and loses it silently; and a drop into an object store in the same two shapes the goldens already use, one object per entry so that a retention policy and an object lock can hold over it.

An entry now carries OccurredAt, because a sink stamps when forwarding succeeded and a retry can put that minutes after the action. A stream carrying only the second timestamp reorders itself whenever one destination is slow.

A sink that cannot be reached is reported and does not stop anything. That is the interface's own contract and it matters most on teardown: a forwarding outage that stopped an environment being destroyed would turn a logging problem into a resource leak.

Here is one environment.created entry as each of the three sinks actually puts it on the wire, captured from the sinks themselves rather than described. The webhook and the object store carry the same bytes:

``json {"occurred_at":"2026-09-08T19:04:11.082Z","forwarded_at":"2026-09-08T19:04:11.328Z","org":"acme","actor":"dana@acme.example","action":"environment.created","target_type":"environment","target_id":"env_7c31a8","origin":"engine","detail":{"branch":"add-checkout-retry","outcome":"created","project":"shop","repository":"acme/shop","seconds":41.7}} ``

The two timestamps are the point of carrying both: the action happened at .082 and forwarding succeeded at .328, and only the first is a fact about the environment.

Syslog wraps exactly those bytes in an RFC 5424 header, with the action as the message id so a collector can route on it without parsing the payload, and the byte order mark that declares the payload UTF-8:

`` <110>1 2026-09-08T19:04:11.082Z host antifailure 5799 environment.created - {"occurred_at":"2026-09-08T19:04:11.082Z", ...} ``

The object store writes one object per entry, under a key partitioned by the day the action OCCURRED rather than the day it was forwarded, so a retention rule expires entries by when they happened:

`` s3://acme-audit/antifailure/2026/09/08/190411.082000000-environment.created-cafebabe.json ``

It is sent with If-None-Match: *, so an entry can never replace one already there, and signed with SigV4 over the request the store actually receives.

engine/internal/scheduler was imported by exactly one file in the repository, its own test. scheduler.Plan had zero production callers. Run.Requires was filled by nothing, because schema.Runtime had no field that could carry a placement requirement. The documentation described requirements matched against runtime tags and an error code was reserved for the refusal. A licence gate in front of any of it would have been an enforcement site that never ran.

runtime.targets declares the places an environment may go and the tags each one offers, and runtime.requires is what a repository needs of one. The engine calls scheduler.Plan to choose, and builds the runtime the chosen target names. A requirement no target satisfies is refused with AF-SCH-001, which names the requirement rather than saying no runtime is available: those are different problems fixed by different people.

Placement is a pure function of the manifest. af up, af status, af logs and af down each decide independently and have to agree, so a cluster's health is deliberately not an input; a placement that varied with it would have af status asking the wrong cluster and reporting that the environment does not exist.

Two consequences beyond the feature itself. A target's region tag fills extension.EnvironmentRequest.Region, which had no writer anywhere, so the enterprise policy hook's allowed_regions residency rule could be configured, described back to the operator at startup, and never fire. And more than one target is gated on an enterprise licence carrying multi_runtime, checked through edition.Permits at the one point every path reaches a target, proved by turning the entitlement off and observing the refusal rather than by reading the check.

It still refuses to start an environment, and the refusal is the feature: it enumerates thirteen distinct ways out of an ECS task on Fargate, names the ten the generated configuration closes, the one that is open and the two that neither the configuration nor AWS's documentation decides, and says which verdicts are computed from a configuration nobody has applied to an AWS account.

An unproven verdict is not a weaker closed one and is never counted as one. The instance metadata service and the local time sync service are the two, both on link local addresses that no route table or security group reaches, and settling either takes one request from one running task in somebody's own account.

Three things the enumeration found are worth knowing even if you never run on ECS. A security group cannot deny egress on Fargate, because the image pull runs over the task's own interface under that same security group, so denying egress produces a task that never starts. On AWS a security group cannot filter a DNS query at all: the Amazon provided resolver answers recursive lookups for public names from anywhere in the VPC and the VPC user guide states plainly that neither security groups nor network ACLs can filter traffic to it, so closing that path takes a Route 53 Resolver DNS Firewall rule group. And reaching ECR is a different question from reaching every repository, log group and bucket in the region: the first cannot be closed without giving up the ability to start an environment, the second can, by a VPC endpoint policy, and only the second is an exfiltration path.

The honest summary is unchanged and is now written down: Antifailure runs on EKS and not on raw ECS.

Creating one writes the row with no password, on purpose, and told the reader to "set a password out of band before it is usable". There was no out of band that a person in the portal could reach: the only thing in this repository that had ever written admin_users.password_hash was the set-operator-password command, which runs on a connection string row level security does not apply to. So every account created from that panel sat in the directory reading Not provisioned and Never, and finishing the invitation needed a shell and the admin database URL.

admin.operators.setPassword is the other half, under an operator session and recorded in the platform audit chain at critical severity. The console asks for the password in the panel that created the account and in the account's own drawer, offers to generate one in the browser, and shows it once with the sentence that says nothing on the platform can read it back. The server never chooses a password and still mints none.

Setting your own password needs your current one as well, which nothing else on this router asks for. The danger there is the opposite of the one setRole and suspend guard: an operator cookie lasts twelve hours, and without the check a stolen one buys the account permanently, because the thief sets a password and the revoke below cuts every session the real owner had.

Every live session belonging to that operator is revoked in the same transaction, except the one making the request. A password changed because it leaked, that leaves the sessions it opened alive, is a reset that resets nothing.

The length floor and the refusal of a stray newline now live in one module that both writers ask, because a rule enforced in one of two writers is a rule with a way around it, and the way around it would have been the one reachable from a browser.

Six of those seven clauses had a command behind them. af mask plan, af mask verify, af golden verify, af fidelity, af invariants and af insights all exist and are documented. The clause about one person masking to one person across both stores did not. masking.CrossStoreCheck had been written, was tested well, and had zero production callers: every caller was a test or a benchmark, the phrase cross store appeared nowhere in the command reference, and no tool mentioned it.

So the guarantee was true in our continuous integration, on our fixtures, and on a customer's stack it was something they had our word for. That is the sentence this product exists to refuse to say. Determinism across stores is a property of the masking construction, so their twin almost certainly had it, and almost certainly is exactly the standard being rejected here.

af mask crossstore is the surface. It reads each declared datastore's catalog, assigns the one rules file to all of them, finds every identifier that appears in more than one store, masks probe values through each side, and reports the share that come out identical.

It reads schemas and no rows. That is not an implementation detail, it is what makes the command safe to point at production: the probe values it masks are its own, so what it needs from a store is the catalog. The report says how many tables and columns it read and that it read no rows, as a field rather than as a promise in the description.

And the promise is enforced by something that can contradict it. A live test runs the check against a real ClickHouse and then reads the server's OWN system.query_log back, failing if any statement the check sent selected from a data table. A sentence saying no rows are read is something anybody can write. A query log the server keeps is not.

Every store it could not read is named with the reason, every store that names no source_url_env is named as never read at all, and a run that reached one store reports that it proved nothing rather than reporting a hundred percent of one. The two ways of not passing get two different exit codes, because a pair that disagreed is a statement about the data and a run that compared nothing is a statement about what could be reached, and telling somebody their stores disagree when the truth is that nobody looked would be its own defect.

Datastores gain source_url_env, the name of the variable holding a read only connection string for that store. The primary takes it from database.source_url_env and does not repeat it. A connection string pasted into that field is refused, and the refusal does not print it back.

The fidelity report gains the line where two stores are present. Nothing having compared them is unmeasured, which keeps it out of the score in both directions, carries the sentence saying how to check, and does not invent a finding about an environment nobody looked at. Verified identical is reproduced. A pair that disagreed is absent with the pair named, which is the line the whole thing is for: one identity masked into two people is a twin that is confidently wrong, and every report built on it is plausible.

A project that lists datastores in fidelity.require and holds two stores will see that requirement go from met to unmeasurable until each store names a source_url_env. That is not a regression, it is the point: require means every component of the dimension was measured and reproduced, and the dimension now carries a component that nothing had measured. Reporting it as met would be the report asserting a guarantee that nothing checked. Unmeasurable is a distinct outcome from broken and is reported as one, so nothing fails as though the stores had been compared and disagreed.

The same question is the fourth question inspect_data_masking answers, so an agent can ask it and get a verdict of PASS, FAIL or INCONCLUSIVE rather than a percentage it has to interpret.

Two stores agreeing while a third declared store could not be read is not a pass either, and it carries the coverage code rather than the disagreement one. Nobody looked at the third store, and telling somebody their stores disagree when that is the truth would be the same conflation one level up. A store that names no source_url_env is deliberately not counted there: nobody asked for it to be compared, a cache holds no identity to compare, and requiring one would make a pass impossible for every realistic manifest. It is named in the report instead of becoming a verdict.

The catalog readers are the ones that already ship. The ClickHouse half is clickhouse.Catalog, exported from the provider that refreshes, masks and branches the store, and it is scoped to the database the connection string names. A second reader written for this check would have been a second opinion about what a type means and whether a column can be written to, kept in step with the first by nobody, and the failure mode of a stale one is a check comparing a plan that will never run.

An application reaching Azure Blob, Queue or Table Storage from an environment had two options and both were bad. Leave the host alone and the request went to the real storage account, where an object written from a preview environment is indistinguishable from production data afterwards. Point it at an emulator and the application had to carry a BlobEndpoint= that only exists outside production, so the code under test stopped being the code that ships.

Azurite now answers for *.blob.core.windows.net, *.queue.core.windows.net and *.table.core.windows.net inside the environment, with nothing in the application naming it. The account travels in the first label of the hostname, so the sidecar preserving the Host header is what lets Azurite serve the account the application already asks for.

Service Bus and Cosmos DB are named as outside that surface rather than left for somebody to discover in a failure. The Service Bus emulator needs a SQL Server container beside it, which an emulator declaration cannot yet express, and it refuses to start until a person accepts a EULA, which is not an acceptance a build makes on somebody's behalf.

Antifailure is new, so no model carries it. An agent handed af mcp could submit a rehearsal and read a verdict while having no way to find out what a stance is, what the topology dimension measures, or why a golden that fails verification cannot be branched. It guessed, and it guessed confidently, because nothing told it otherwise.

Three tools now serve the 92 pages this build ships, and the whole design is about what they refuse to send. search_documentation returns the few lines around a match with the heading path and the anchor that reads that section on its own, never a page. list_documentation names all 92 for 1,416 tokens so an agent can orient before it knows what to search for. read_documentation_page reads one section by anchor, bounded, and a page longer than the budget is cut at a line boundary, marked where it was cut, and reported with the exact characters withheld and the anchors of every section past the cut.

Every response states what it did not return: how many pages matched, how many were shown, which were dropped and why. A tool that silently truncates leaves a caller believing it has seen everything, which is the defect this repository exists to find, and it is worse in a documentation tool than anywhere else, because the caller has no independent way to know the answer was partial.

The pages are compiled into the binary by tools/docsembed, so the answer matches the build the caller is running rather than whatever is on the website, and the server needs no network to give it. just generate writes the generated file and CI fails if it has drifted from docs/src/content/docs.

Measured by engine/internal/docs/benchmark_test.go, which just benchmark runs, and counted with cl100k_base: the question "what does stance mean" is answered in 1,138 tokens end to end, against 262,045 tokens for the documentation set it was drawn from. Reading the one page the best excerpt came from would be 6,657, and reading just that section 649.

Across the 22 most recent merged pull requests here, Antifailure's verdict on itself read "Every check passed" twenty one times and "Nothing was verified" twice. The failed column had never held a number. That is consistent with a product that works and equally consistent with a check that cannot refuse, and this repository has already shipped the second thing twice: a database conformance suite that had never turned down a provider, and a coverage gate that printed a number while skipping the files it could not parse.

So the six things the verdict claims to decide are each broken on purpose now, one at a time, through the real code and against a real Postgres, a real browser and a real inventory. A masking rule that misses the column holding addresses, a row an invariant says cannot exist, a page that shows an error instead of the confirmation, an ALTER TABLE holding ACCESS EXCLUSIVE for three seconds, a column the verifier is not allowed to read, and a manifest declaring a store this build has no golden for. Each case requires the finding by name in the report a person actually reads, then restores the break and requires the same case to pass, because a row that can only ever fail is the same defect wearing the other sign. The suite counts what it proved rather than asserting it, and on a machine with the Postgres it needs a class that did not run is a failure rather than a quiet skip.

Two things it found on the way. A migration that held a lock for three seconds produced four lock findings: one about the customer's table and three about the rehearsal's own bookkeeping table, its primary key and its sequence, each telling the author to split a statement that never touched it. Those are excluded from the sample now. And af golden refresh refused a golden whose only problem was a column nobody could read by printing an empty list of findings above the sentence "add a rule for each column above", with the error naming the column discarded on the way out. It names the column, and it no longer recommends a rule for a problem no rule can fix.

A twin of an analytics product held a masked Postgres and zero events. The events live in ClickHouse, the environment started ClickHouse as an empty container, and every query path that mattered ran against no rows while the run went green. A manifest could say datastores: and declare one golden, and nothing read that at run time.

Now af golden refresh makes a golden of every declared store as well as of the database, and af up branches each of them into the environment. A ClickHouse golden is copied from the address source_url_env names, masked, read back by the same verification scanner the Postgres golden is published on, and branched as a database with the golden's partitions attached to it, which ClickHouse hardlinks: a branch of three rows and a branch of a million take about the same few hundred milliseconds. A golden that fails verification is never published and can never be branched, which is the rule the primary database has always had, enforced in the provider rather than in a checklist.

One masking.yaml covers the whole twin. A rule about distinct_id applies to the column wherever it is, so one customer masks to one fake customer in both stores and a join across them still returns one person.

Three things that came out of building it:

• The masking is a value map joined into a shadow table, not the per row statement the dialect describes. One ALTER TABLE ... UPDATE per row is a ClickHouse mutation, which rewrites every part holding a matching row: measured at 1.81 rows a second on a ten thousand row table, where the shape that shipped did the same ten thousand rows in 0.13 seconds. A test masks the same fixture both ways and requires the results to be identical.
• A store the environment provides is no longer also started as a service. Declaring a datastore called events and a service called events is declaring one thing twice, and starting both put two ClickHouses on one network under one name.
• A name inside the environment is no longer decided against the egress policy when it arrives through the explicit proxy port. The sidecar's resolver has always treated one as internal and forwarded it; the proxy had never heard of the list, so a client that reads http_proxy and ignores no_proxy, which busybox wget does, had its call to another service in its own environment refused as egress.

provider.Datastore gained ListGoldens and DestroyGolden. Without the first the engine had to refresh on every command, because it cannot choose a version it cannot see; without the second a datastore could make goldens and had no way to remove one, which the conformance suite had written down as the one place it could not clean up after itself.

replicas had been in the schema and in the reference since version one, and nothing read it. Both Kubernetes Deployments hardcoded a single replica and the local runtime never mentioned the field at all, so a service declaring three ran one. The release before this one closed the silence by refusing the key, which was the right answer for exactly as long as the field did nothing.

It does something now. Both runtimes start the number asked for, behind the one name every other service resolves, so requests and lookups spread across the instances. The migration runs once for the service rather than once per instance, the forwarder is one for the service rather than one per instance, and readiness waits for every instance instead of the first one to answer.

The point is not scale. Nobody needs three copies of a worker on a laptop. What more than one instance buys is a class of bug that cannot be reproduced at one: a nightly job with no leader election that sends its email once per instance, a consumer that reads a row and then claims it so two instances do the same work, a session or a cache held in one process's memory that the next request does not reach. Every one of those passes at a single instance, which is why a runtime that quietly ran one was worse than useless to somebody who wrote replicas: 3 because they suspected exactly this: the green run read as the bug being absent.

Two of those classes are now demonstrated rather than described, in tests that pass at one instance and fail at three with nothing changed but the number. The runtime conformance suite gained the instance count as a behavior, and a second behavior that asks the three processes to identify themselves, because a count is a number a runtime writes down and a runtime running one instance while reporting three says exactly what a correct one says.

af status names the count when it is more than one, and the fidelity report says how many instances are running against how many were asked for. A cron service may not ask for more than one, because every instance runs the schedule and three of them send the nightly email three times.

Found while wiring it: health_timeout was validated, defaulted, printed by af explain and reported over MCP, and never assigned into the spec a runtime receives. A service given ten minutes to start was killed after three. Both runtimes now see the number, and the boundary the two fields were lost at has a test on it for the first time.

There were four database providers and each one was a provider for one product: a Docker daemon, a Neon project, a Supabase project, a Database Lab Engine. A self hosted cluster, a machine at Hetzner or Scaleway or OVH, an internal server behind a bastion, or any managed Postgres whose vendor had no provider here could not be a source at all. The manifest could name it and the engine would refuse, which was the honest answer to a gap that should not have been there: the copy itself is pg_dump and pg_restore, and neither of those cares who runs the server.

database.provider: pgurl is that provider. It knows nothing about any vendor. It takes the source connection string the manifest already names, and one more variable holding the connection string of the server the goldens and the branches live on, and it keeps a golden as a database on that server and a branch as CREATE DATABASE ... TEMPLATE, which is a server side file copy.

Two things it declares rather than implies. Branching is NOT copy on write, so branch time grows with the database, and the measured seconds per gigabyte are published in benchmarks/ beside the harness that produced them rather than described. And the Postgres major it supports is the one the server actually runs, read from the server, so a manifest asking for a version that server does not have is refused instead of quietly building the golden on something else.

Nothing is dropped or written over on the strength of its name. Every database this provider creates carries a marker in its comment, and a name collision with a database it did not create is refused rather than adopted.

Exactly one of those stores held production's data. database was a single struct and it was Postgres: one golden, one masking pass, one verification scan, one branch. Everything else came up as an empty container, and nothing in the product said so.

For a stack shaped like an analytics product that is the whole product. The twin holds masked Postgres metadata and zero events, because the events live in ClickHouse. Every query path that matters is untested, every migration touching the analytics store is unrehearsed, and a workflow that reads a chart sees nothing. The environment is a production twin of one component and a blank slate for the rest.

The manifest gains datastores, a list, and every entry declares a stance: golden for a masked and verified copy, empty for a store that is correct to start with nothing, derived to rebuild one from another, topics_only for a broker. A datastore that declares no stance is refused. Not every store should be cloned, so the answer differs per store and only the person writing the manifest knows it; a default would choose silently, once per manifest, and choosing silently is how somebody ends up trusting a blank ClickHouse. empty is a legitimate answer and because is required with it, because an empty store somebody decided on and an empty store nobody noticed look identical from inside a running environment.

database does not move and does not change. It normalizes into the entry named primary, so a manifest that declares only database: already has the list, and the component inventory for such a manifest is byte for byte the report it produced before. There is one code path afterwards rather than two.

provider.Datastore is the interface an implementation satisfies, and conformance.RunDatastore is the suite that decides whether one is finished. It ships with a broken fake and a self test in the same commit: every behaviour is shown going red against a store built with one thing wrong, and a test fails if a behaviour is added without a control. Nothing yet refreshes a golden for a second store or branches one. Those are the next lanes, and until they land every declared store is reported unmeasured with the reason rather than counted as either answer.

engine/pkg/provider is documented as the main extension point, meant to be written by people outside this repository, with a conformance suite that decides whether an implementation is conformant. All of that was true and none of it was reachable. The engine chose its database provider from a switch in engine/internal/env, its runtime from another, and its golden store from a third, and each ended at a default that refused. Nothing consulted anything a build had registered, because there was nothing to register into: the only way to add a provider was to edit an internal package, which the Go toolchain refuses to let another module import. "Extensible" meant "send us a patch".

engine/pkg/extension now carries five sockets beside the four hooks it already had: DatabaseProvider, DatastoreProvider, RuntimeProvider, GoldenStore and Emulator. The database, runtime and golden store switches consult the registry after their own cases and never before them, so a registration adds a choice and can never take one over, and each refusal now names every provider the build has rather than only the ones that ship. A registration under a built in name is refused at the first command instead of being silently unused, which is the failure that would otherwise be discovered as a build somebody believed replaced the Docker provider.

Two of the five have no lifecycle behind them yet, and each says so in its own documentation rather than leaving somebody to find out. tools/socketcheck is what keeps that honest: every socket is either consulted by the engine or listed there with the reason, both directions fail, and the entry cannot outlive the gap. It was written after finding that Registry.Audit has no caller anywhere in the engine, so audit_stream would forward nothing even once somebody wrote the sinks.

On launch night the founder was signed in to the console and to the operator portal in the same browser, pressed Subscribe to team, and got a 403 naming a header the Plan page has never heard of: the operator transport check was running on a customer mutation because the operator cookie was present. The fix is in the control plane. The question this answers is the one asked next: would rehearsing the change against a twin have found it. It would not have, because this repository's own manifest signed every persona in as one identity, and a bug that needs two live sessions in one browser cannot appear to a workflow that can only hold one.

The manifest gains an operator-owner persona, an operator of the platform who is also a customer of it, which is what everybody on this team is. It is a separate account in admin_users, signed in with a password at the portal, and it is created by deploy/docker/personas.mjs, now run as the seed adapter's command so the password the runner types and the hash the row stores are handed out by one process and agree. The workflow an-operator-who-is-also-a-customer-can-start-checkout signs in to the portal, then to the console, then presses Subscribe to team, and expects the sentence the Plan page shows once the mutation is past the transport gate, which the 403 can never produce. Reverting the fix makes the workflow fail on that 403, which is the proof it can say no.

Two manifest features made it expressible, and both are documented and validated. A workflow may name a list of personas rather than one, and the runner signs in as each in turn in one browser so the sessions accumulate; the last is the identity it acts as. A persona may name a sign_in_path, so the runner finds the operator portal's form at /admin rather than typing an operator's address into the console's own sign-in screen at the workflow's start path.

The mirror image is rehearsed too. The customer transport check had the same defect in the other direction: an operator whose browser also held the console cookie pressed Mark reviewed in the portal and was refused 403 for want of the product token, by a check for a session the request was not using. The check now applies only to a request that names a customer procedure, and a second workflow acts as the operator with both cookies live, marks an application the persona seeder left waiting as reviewed, and expects the queue's own empty state. The preview now carries the operator portal's database credential, so the portal works inside a twin, and the planner without a model presses a control whose whole label the description names, which is how it finds a review queue's buttons on a page with no shared shape.

Signing in for the first time landed on the environments list, which is three empty cards explaining that something appears when the engine reports one. Somebody who came for a check on their pull requests, somebody who came to run an environment from a terminal, and somebody who came to point a coding agent at this control plane all saw the same three cards, and the next step for each of them was on a different page, or on no page at all: the hosted MCP address was shown to operators and to nobody else.

The root now asks which of the three you are and shows that one's next step, with the command, the address or the install link, and the permissions it needs in one line. The answer is remembered in the browser for the organization, the other two paths stay a click away, Not now is honoured, and Settings shows the answer with a way to change it.

That is transport and it is not a boundary. It changes the destination the browser connects to, not who receives the data: PostHog, Inc. receives every event, every autocaptured interaction and every session recording either way, in their US cloud. What it buys is that a content blocker's vendor list does not match the request, so the measurement is not silently half missing; that the recorder bundle, the largest and most blockable thing posthog-js fetches, arrives rather than failing while ingestion looks healthy; and that the reader's address is dropped in passing. It does not buy the sentence "no third party sees this", and PostHog is on the published subprocessor list with a row of its own saying so.

The site is a static export on Azure Static Web Apps. It has no server at runtime and its route rules cannot rewrite to an external host, so the site itself cannot forward anything and the alternative was a browser talking straight to a vendor. AF_POSTHOG_REGION now mounts a proxy at /ph on the control plane, which is the one process this product already runs on its own hostname. It is same site rather than same origin, which is why every route answers a CORS preflight and echoes one origin from AF_SITE_ORIGIN.

Three separate things stop it being a general forwarder, and none replaces the others. The upstream host comes from a closed set of two regions, so no request, header or setting can name a different one. The paths that reach PostHog are an allowlist, so a path that is not on it is not a route and is answered 404 rather than forwarded. A redirect from the upstream is refused rather than followed, which is what stops the vendor from steering this process at somebody else's server.

Nothing of the browser's crosses except content-type: no cookie, no authorization header, and not the reader's address. PostHog therefore receives no visitor IP at all. The cost is that its geolocation properties describe the deployment rather than the reader, which is the trade taken on purpose, because forwarding an address is the one direction that cannot be undone afterwards.

The allowlist holds both capture endpoints. posthog-js posts to /e/ by default and overrides it from the remote config, which for this project returns /i/v0/e/. A proxy built from the documented default alone would have forwarded the flag call, served the script, passed every check anybody ran, and lost every single event.

One prefix, two upstreams: the script and remote config paths go to the region's asset host and everything else to its ingestion host. Both are needed, and the asset half is the one that fails quietly: posthog-js sends every target at a custom api_host, so a proxy that forwarded only ingestion would leave the recorder bundle being fetched from the vendor directly, where a blocker kills replay while ingestion goes on looking healthy.

The legal gate that held the site to "no analytics and no third-party script" was rewritten rather than deleted. It now keys on whether posthog-js is actually a dependency and asserts both states: absent, the page must still deny PostHog by name; present, the denial must be gone and the subprocessor list must carry a row for it. Two more gates beside it refuse any posthog.com ingestion host in the site's source, require the configured api_host to be the mount this repository actually serves, and fail if PostHog starts without consulting the measurement flag the published page promises a reader can switch off.

Both settings can be delivered by the supported deploy paths: posthog_region and posthog_project_key on the Terraform module and stack, and config.posthogRegion and config.posthogProjectKey on the Helm chart. They were documented and read by the application before either path could set them, and the gate that holds the reference to the deploy paths is what found it.

Two producers, both server side, both off unless AF_POSTHOG_PROJECT_KEY and AF_POSTHOG_REGION are set. A hosted MCP tool call sends the tool name, which is a closed set of the eight tools the surface registers, how it ended, and how long it took. A brokered model call sends PostHog's own $ai_generation shape: model, provider, the token counts the provider itself reported, latency and a trace id, plus the cost when there was usage to price.

What is never sent is the point. Not a tool's arguments and not its results: a tool call carries project identifiers, hostnames, table names, SQL and error text, and inspect_recorded_egress alone would ship a customer's outbound destinations to a vendor. Not a prompt and not a completion, which are the customer's input and the model's answer about it. Not an organization identifier: the pseudonym is the same domain separated HMAC the control plane's own analytics already computes, so PostHog holds the identifier our own store holds and neither is an org id, and with analytics off nothing is reported at all.

$ai_latency is in seconds. Everything in this process measures milliseconds, so sending one into the other is a silent thousand fold error on a dashboard nobody would question. It is converted once, in the sink, and the test holds the reported value against how long the request actually took rather than against a plausible looking bound: the first version asserted the number was under sixty, which a local stub answering in three milliseconds satisfies in either unit.

Nothing of this kind exists in the engine and nothing of this kind may be added to it. af mcp runs on a customer's own machine, inside their network. engine/internal/telemetry already carries the engine's events, requires a redactor before any sink may write, and exports to the customer's own control plane. A path from there to our analytics vendor would be an outbound flow nobody agreed to, out of a product sold on the promise that production data stays in the customer's boundary. That is now written at the top of the telemetry package, where somebody would otherwise be tempted.

A failure cannot reach a caller. Both producers sit on load bearing paths, one being a customer's agent and the other being the proxy that spends their money, so every send is fire and forget, swallows its own errors, and is flushed at shutdown rather than awaited on a request. The generation is reported after the spend is recorded, never before, because the charge is the thing that must not be lost.

af mcp served four tools against eighty one commands. An agent could ask what a migration would do and what the environment reached, and had no way to ask the questions that come before either: is there a container daemon, is there a golden this project can branch, is anything running, did the application send the verification email, is a model key configured. Every one of those had to be answered by a person at a terminal, and the usual way an agent found out was a rehearsal that failed twenty minutes in for a reason that had nothing to do with the code.

Thirteen more tools, named for the question rather than the command. check_prerequisites is the one to call first: it runs af doctor and af runner check and reports ready, blocked or undetermined, where undetermined means a deciding question could not be answered and is never reported as a pass. inspect_environments, inspect_goldens, describe_model_key, describe_control_plane_account, read_captured_messages and list_webhook_events read state and change nothing. extend_environment_lifetime, verify_model_key, send_webhook_event and prepare_golden change something and say what.

The three that DESTROY something say so on the wire. destructiveHint was published as false on every tool, with a comment saying nothing here destroys anything a caller owns, which was true while every tool made a throwaway environment and removed it again. remove_expired_environments and remove_old_goldens break that, so the hint is now declared per tool. Both plan by default and remove nothing; carrying a plan out means naming every environment or version the plan listed, and a set that has changed since is refused rather than swept. Neither accepts a wildcard.

Nothing here reads, returns, stores or removes a credential. There is no tool for af secret, af token, af login, af provider set or af model set, and no argument anywhere that carries a key: what a result carries is a fingerprint, a last four, or a token prefix. A support bundle is not offered as a tool either, because it collects the application's own logs and every outbound request it made. Free form text on its way into a result now passes the engine's redactor as well, so a provider quoting back the key it just rejected does not put that key in a model's context.

Installing the App connected a repository and then nothing happened. The installation was recorded, the repository was listed in the console, and no check ever ran on any pull request, because a check needs a workflow file in the repository and nothing had put one there. The documentation sent people to copy a file of over five hundred lines by hand. Most did not, and a repository that read as connected for a month with zero runs was the ordinary outcome rather than the exception.

The App now opens a pull request titled "Check every pull request with Antifailure" on each repository it is installed on. It commits the same short workflow that af init writes to a branch of its own, antifailure/setup, and never touches the default branch. The body says what happens once it is merged, that nothing runs until then, that pull requests from forks wait for the antifailure:allow label, that no secret is required, which secrets are optional and what each one unlocks, and the one repository variable the hosted control plane needs. A repository that already has the file gets no pull request.

The webhook delivery that records the installation only enqueues the work, because a delivery is answered inside seconds and opening the pull request is four calls to GitHub. A sweeper beside the teardown sweeper does the calls under a lease, retries a failure five times and then says so, and reuses a branch or a pull request a dead process left behind rather than opening a second one. An installation that does not hold Contents write is recorded as needing the permission, with the remedy, and is not retried against a refusal that would answer the same way forever; accepting the permission is what puts it back in the queue.

The console's Environments page shows the repositories that are connected and not yet checked under Getting connected: the pull request as a link, the missing permission with its two steps, or the last error. The card is gone once every repository has the file.

The App's Contents permission is Read and write from here on, and self-hosting/production says why and what to do on an App that already exists.

af ci and af change needed antifailure.yaml, so the first pull request after installing the workflow, or the GitHub App, ended in AF-MAN-001 and a red step. The workflow being something nobody has to write was worth nothing while the next thing they met was a file they had to write.

With no manifest, both commands now draft one in memory the way af init would, take every default, and run on it. The report opens with a bold line saying so and naming af init as the command that makes the file theirs. A service nothing could be guessed for is left out of the draft and named, rather than the whole run refusing. When nothing at all can be drafted, af ci writes a skipped run that says why and exits zero, because nothing was learned about the change.

The draft is never written to disk. A file that appears in a checkout because a CI job ran is a file nobody committed and nobody can explain.

af change also writes two more keys to GITHUB_OUTPUT: source_url_env, the variable naming production, and secrets, every variable the manifest reads a credential from. Names only. The action exports exactly those out of the caller's secrets, which is what lets a reusable workflow pass the whole secret set without the customer naming each one.

Everything past the two rehearsals was reachable only by a person typing a command.

Seven more tools now cover the environment's whole working life. start_environment creates the environment for the checked out branch and teardown_environment destroys it. describe_environment says what is running and read_service_logs says what it wrote. run_load_test sends production's weighted mix, a short smoke of it, or the declared journeys, chosen by one enum rather than by three near identical tools. run_browser_workflows drives the declared workflows and asks the manifest's invariants of the rows they leave. explore_for_friction sends agents at a goal with no script.

The division of authority is unchanged and is a property of the schemas rather than a convention. There is no argument on any of these that names a branch, a base URL, a database, a golden, a safe route, a threshold or a runner executable: the environment comes from the checkout, the limits come from the manifest's policy block, and unknown fields are refused. teardown_environment is the one tool that destroys, so it is not marked read only, it says so in the first word of its description, and it requires the caller to name the branch, which is then checked against the checkout. There is no wildcard and no way to reach another branch's environment.

What a run reports is bounded and stripped of what it does not control. The rows behind a violated invariant are counted and never quoted, because they come out of a branch of a masked copy of production. A verdict word this engine cannot read is blocked rather than repeated. Page text, control names, route names, scenario names and service logs are all output the application or the candidate branch wrote, so every one of them is neutralised and clipped. A container id and an artifact path name this host and are reported as present or absent instead.

The verdicts come from the evaluator af ci uses, so a tool call and a pull request check cannot disagree. A load run that sent nothing, a threshold that was in force and measured nothing, an exploration that did not cover its goals, and a workflow run in which nothing reached a verdict are all INCONCLUSIVE rather than clean, because an experiment that did not happen says nothing about the change.

An agent connected to af mcp could rehearse a migration and inspect the egress firewall, and that was the whole surface. Everything else the engine knows, whether the environment is close enough to production to be worth trusting, what a failure code means, what the project is actually configured to do, which checks a diff needs, whether the data still holds, whether this change behaves like the release it replaces, and what masking does, was reachable only by a person typing flags into a terminal. Eight tools now cover that ground: assess_environment_fidelity, explain_error, explain_effective_configuration, plan_checks_for_change, check_data_invariants, compare_with_previous_release, inspect_data_masking and apply_data_masking.

They are named for the question rather than for the command, so a model picks one without reading a manual, and the two that cost minutes submit a run and are polled with get_rehearsal_run like every other experiment here.

Three of them touch data that is real until masking removes it, and none of them returns a value. The masking sample reports whether a column CHANGED, not what it changed from, which is what finds the failure somebody is actually hunting: a rule that names a column and then does nothing to it. The verification reports which detector still recognises something and withholds even the redacted excerpt the scanner keeps, because an excerpt of real data is real data. The invariants report which invariant broke, how many rows came back and what the columns are called, and leave the rows themselves to af invariants.

apply_data_masking is the only one that writes, it is irreversible, and it is a separate tool from the read only one for that reason alone. It also requires an acknowledgement with exactly one accepted value, so that a caller which meant to preview cannot reach it by accident.

af init writes it when the checkout has a GitHub remote, af github init writes it into a project that already has a manifest, and installing the GitHub App opens a pull request adding it. The file's one job calls a reusable workflow, .github/workflows/check.yml, which calls the action, antifailure/antifailure@v1, and a moving v1 tag follows every final release so the line never needs editing.

The documented path was a 505 line workflow that every user copied into their repository and then edited, and three things were wrong with it that no gate could see. The runner was never installed by it, so the agents could not drive a browser in CI and every workflow that needed one came back unverified on the page that taught the integration. The production database secret was never mapped: the manifest names the variable under database.source_url_env, the file did not know the name, and so the check ran on an empty schema for anyone who followed the instructions and reported nothing about it. And a file that long is a file every copy diverges in, so a fix to the template reached nobody who had already copied it.

The action installs the runner when the command needs a browser. The reusable workflow sees the caller's secrets through secrets: inherit, runs af change to learn which variables the manifest reads, and passes exactly those to the action by name, so a secret the manifest never mentions is never read. So the production secret reaches the check under whatever name the manifest chose, with no line in the customer's file naming it, and the report says at the top when it ran on an empty database instead.

A repository with no manifest is checked too: af ci drafts one from the repository and the comment says so in its first lines, with af init as what makes it yours.

Most projects never wrote one, so every column nothing recognised was emptied by a default nobody had read, and the plan kept listing the same questions on every run.

af mask init writes the file. It reads the schema of the source, or of this environment's branch when one is up, decides every column the way the built in rules would, and writes one explicit rule per column: the default restated with its reason where a default matched, and a rule that empties the column, with a reason saying it was unrecognised, where nothing did. A column that cannot be emptied, because it is unique or cannot hold null or is a type the masker cannot rewrite, gets the nearest thing that can run and a reason saying which. The result leaves af mask plan with zero problems and zero unclassified columns, which is the property a masking file is for.

It refuses to replace a file that is already there without --force, since the rules somebody edited are the most valuable thing in it. af init runs the same code when the manifest names a production database and the shell holds it, and af start gained a rung for the file, after the database source and before the golden, naming af mask init as the next command when the source is set and the file is not there.

The site counts page views with a first party beacon that sends a channel and a page shape from closed lists and nothing else. That was a deliberate design and it stays, running beside this. What it cannot do is say where somebody gave up: it sends no address, no element and no ordering, on purpose, so it can report that forty people reached the pricing page and never why thirty nine left it. Autocapture and session replay answer that, and PostHog Cloud US now does it for antifailure.dev.

The masking is the whole of the change and it is set explicitly rather than inherited. Every input value is replaced in the browser before anything is sent, by type as well as by the coarse flag, so a recording of the careers form or the enterprise contact form shows fields filling up with asterisks and never the name, work email, company or paragraph typed into them. No cookie is set, and posthog-js is configured onto sessionStorage rather than its default of a cookie plus a year of local storage, because two sentences already published say there is no cookie and that nothing here joins two visits.

Requests go to an endpoint this project runs on its own domain rather than to a posthog.com host, and the copy says in as many words that this is TRANSPORT and not a boundary: it changes where the browser connects, not who receives the data, and PostHog, Inc. receives it either way. What it buys is a request no content blocker's vendor list matches, so the numbers are not silently half missing, and a reader's IP address that is never forwarded, at the cost of any real geography on those dashboards.

Global Privacy Control, Do Not Track, the switch on the privacy page and a browser reporting itself as automated each stop it, and each stops it BEFORE the library is fetched. The import is dynamic and it is behind the gate, so a reader who has said no makes no request for PostHog's code and there is no recorder that read the page and was then told to stop. The switch also reaches PostHog mid visit: the beacon announces every change to the decision and the recorder ends with the queue, rather than each new producer being one more line somebody has to remember at the switch.

www/lib/subprocessors.ts, the privacy page and the data boundary page all said in writing that no third party saw anything and that there was no PostHog. All three now name PostHog, Inc. as a subprocessor, list what a recording holds and what is masked, and keep the claim that is unaffected and different: no account, organization, repository, policy, run, audit entry or piece of a customer's production data reaches PostHog, because nothing that handles any of those calls it. The subprocessor page also used to say this site loaded no script from another origin, which was already untrue: the contact page has been loading cal.com's booking widget. It says so now.

Eighty five seconds, under a heading that says what it shows: a copy of production the same size and shape and load with every real name replaced, the change running there first on every pull request whether a person or an agent wrote it, a migration caught holding an exclusive lock on 48,201,338 rows and taking GET /orders from a 240ms p99 to 4,730ms, and the copy deleting itself afterwards. Nothing reached production, which is the line the film ends the check on.

It does not autoplay and it does not loop. tools/motioncheck exists to refuse a piece of the interface that animates forever while the reader does nothing, and its rule has no carve out for a real event, so it has none for a film. This one plays once when the section is scrolled to, settles, and stops, which is what the twin figure on the same page already does, and it does not start at all under prefers-reduced-motion.

motioncheck could not have seen it either way, and now it can. Everything that gate reads is CSS, from a stylesheet or from a style attribute, and <video autoplay loop> is neither. A page could carry two of them and the gate would report "0 animations that never stop" over the file they were in. It reads the built HTML for a video that carries both attributes, names the source file so an exemption can be copied from the failure, and takes each attribute as a whole attribute rather than as a substring, because loop is inside loop-demo.mp4 and a rule that refuses a video which does not loop is a rule somebody deletes.

The film is 9.8 MB rather than the 51 MB it was cut at, and nothing downloads until somebody scrolls to it. preload is none and playback is started by the viewport observer, so a visitor who never reaches the section pays nothing for it. The site is served by a Static Web App whose plan allows 250 MB in one environment and 100 GB of bandwidth a month with no overage available, which is the arithmetic that decides this rather than a preference about page weight.

Three things that were wrong before this landed, all of them found by looking at the render rather than the source. The observer could not START playback, only resume it: its flag began as "playing", so the first time the section came into view it did nothing, and the autoplay attribute was what made the section look like it worked. There was no play control at all once autoplay was removed, only a circular arrow labelled restart, so anybody with reduced motion on was looking at a still image with no way to play it that said so. And the three video controls sat at the bottom right, where the film burns its captions, so on a phone "Last year, developers" ran underneath them. They are 44 pixels now rather than 40, which is the tap target floor this project sets and every video control on the site was under it.

It could set 15 of the 46 the configuration reference documents. The other 31 had no value in the chart and no generic escape hatch either, so a Kubernetes installation could not turn them on at all. That is not a documentation gap. The operator portal, the whole GitHub App and therefore installations and webhooks, all of billing, all of mail, the secret that seals customers' provider keys, the analytics pipeline and the origin a marketing site is allowed to post from were unreachable, and every one of them presents as a broken feature rather than as something nobody configured. The contact form is the clearest case: it tells the visitor to check their connection, when the server refused the request on purpose because it had no origin to allow.

The chart now names all of them, with the argument for each written where an operator sets it, and validates the sets that are all-or-nothing. A GitHub App missing its private key, billing missing its webhook secret, an operator pool with no operator credential and a required plan with billing off are refused at render time with a sentence, rather than installing and failing later or, worse, running half configured. helm install now prints which optional features are off in the release it just created.

extraEnv is there too, for a variable the chart does not name yet and for one that belongs to something else in the pod.

tools/wirecheck was the check that should have caught this and could not: it compared the reference page against the Terraform module only, so a variable could be documented, read by the application, wired for the hosted installation and unreachable for every self-hosted Kubernetes one while the gate stayed green. It now asks the same question of both installation routes, and the exemption file carries the route each reason applies to, because a reason true of one route is routinely false of the other.

Somebody filled in the careers form on antifailure.dev and was told "Could not reach the server". Nothing was broken in either half: the form posts to POST /v1/applications, the route was registered, and every test of both sides passed. The site publishes on every merge to main and the control plane only moves when a v* tag is promoted, so the careers page went live the moment its pull request merged while the API it posts to was still serving v1.1.1, twenty two commits behind. POST /v1/applications answered 404 and the form's catch turned that into the only sentence a visitor ever saw.

tools/routecheck asks the deployment rather than the tree, because a check comparing the site against main's server.ts passes on exactly this failure. It runs before the publish, and it fails when it cannot establish an answer rather than reporting a pass it did not earn.

This does not by itself restore the careers form. The route reaches production when a v* tag is promoted, as every control plane change does. What changes today is that the site can no longer be published in front of an API that does not serve it.

Every control plane URL the site builds is now declared in www/lib/control-plane-routes.ts, and a call site that builds one anywhere else fails the www gate naming the file and the line.

added

Setting stripe_price_team made this control plane able to charge; the comment above it sends the reader to the production page for the commands, and that page had no billing section at all. It has one now, in the order that works: which endpoint to create at Stripe and why it has to be first, since the signing secret does not exist until the endpoint does; the nine events HANDLED_EVENTS acts on; the two vault entries; and four checks on the running control plane, where the last one asks the product for the thing the plan was withholding rather than asking the database what it wrote.

A test that walks one organization through the whole path rather than each hop of it. Refused a fourth environment on the free plan, checkout through the tRPC route, a delivery signed over raw bytes at POST /webhooks/stripe, the plan, the subscription row, the SAME refused request now allowed, and what the billing screen shows a signed in browser. Every hop of that was already proven and the JOIN was not, which is the shape this repository keeps finding in itself: a route that answers 200 is not evidence that a plan changed, and a plan column reading team is not evidence that anybody got anything for their money.

Four arrival orderings driven through the two real entry points rather than through the handler, which nothing in production calls. The delivery that beats the customer row is forced from inside the Stripe call, so the webhook lands while checkout is still between its network call and its write, which is not an interleaving that ordering two awaits can reach. Then the same delivery twice, two at once that disagree about the plan, and the delivery that never comes.

• Founding engineering and growth roles have a careers page with current compensation stated upfront, a private application form, and an operator review queue. Applications expire after 180 days through maintenance.

added

Upgrading meant going back to the website and running the install script by hand, and the CLI knew that and said nothing. A command that prints another command is not an upgrade path; it is a note asking somebody to go and find one, and the version they land on is whatever the page happens to serve.

af update reads the published release, downloads the archive for this platform, checks it against the SHA256 in checksums.txt, and replaces the binary and the runner source that shipped with it. What it will not do is as deliberate as what it will. It never writes to a shell profile, to PATH, or to anything inside a project. It refuses a package managed installation and an enterprise binary rather than guessing, because the upgrade for those belongs to the package manager and the enterprise distribution. It refuses to downgrade. af update --check reports the latest release and changes no file.

The order it works in is the part that matters when something goes wrong. The archive is verified before anything is unpacked, unpacked into a staging directory beside the binary before anything is moved, and the binary is replaced last, by a rename, so a failure at any earlier step leaves the installation that was already working. A failure after the runner source has moved restores it, and if that restore fails too, the original is kept and its path is printed instead of being deleted. An interrupted update is recorded and finished on the next run, and the lock means two of them cannot race.

stripe_price_team is set in production.tfvars, which is the one switch the whole feature hangs from: it turns on the two Key Vault secret references, the three environment variables the process reads, and the checkout and webhook routes that were answering 503 "This control plane is not configured to take payments" until now.

Team is a flat 500 USD per month for the organization rather than per seat, which is why checkout sends quantity exactly 1. There is deliberately no enterprise price. That plan is arranged with a person, and checkout refuses it by name rather than reaching Stripe with an empty identifier.

Two things are deliberately NOT part of this and both would have been easy to include by accident. hosted_required_plan stays empty, because turning payment on so somebody can buy is a different act from requiring everybody already here to buy, and the second one locks out every organization on the plane the moment it applies. operator_sets_plan stays unset, and Terraform refuses the combination anyway: a plan that can be granted by hand is not a plan anybody has to buy.

The API key and the webhook signing secret are not in this change and are not in any file. They are addressed by their versionless Key Vault IDs and read by the Container App identity when Azure creates the revision, so Terraform never sees either value and no plan reads them. That also fixes the order this has to happen in: both secrets go into the vault BEFORE the apply, because a missing one fails when Azure resolves the reference rather than when Terraform plans.

• Connect an MCP client to the control plane with explicit browser consent. Hosted tools use the same tenant permissions and execution paths as the console.

Signing in returns to that request without approving it. Declining grants no access, and incomplete or mismatched requests cannot be approved.

af mcp was documented in full: the division of authority, every tool, the verdicts, the errors, what project_id asserts and where output goes. The page opened by saying the server is started by an MCP client rather than typed by a person, and then never showed a client configuration. There was no mcpServers block and no claude mcp add line anywhere in the repository, the docs or the README, so a reader who wanted the thing the page described had nowhere to go.

There is now a verified configuration for Claude Code, Codex CLI, Gemini CLI, Cursor, Windsurf, VS Code, Cline, Continue, Claude Desktop, the ChatGPT desktop app, JetBrains AI Assistant and Zed. The page uses each client's current file, schema and working directory support rather than presenting one JSON shape as universal.

It also names the setting people get wrong. The server binds the directory the client starts it in. The page uses cwd or a Working directory field where the client supports one, and an absolute path passed with -C where it does not. Without either, the failure reads as a missing manifest rather than as a missing setting.

It states the current remote boundary without making it permanent: v1.1.1 has no hosted Antifailure MCP endpoint yet. Browser clients cannot start the local process. An authenticated Streamable HTTP bridge is possible, but it operates containers, a checkout and production shaped data, so it needs deliberate identity, network and tenant isolation. The Supergateway example now selects Streamable HTTP explicitly and names its /mcp endpoint instead of silently starting the default SSE transport.

The subprocessor page already told readers a preference would be remembered if they switched measurement off. The only way to switch it off was a query parameter documented in one source comment, so the promise had no reachable mechanism behind it.

The control renders the reason rather than a position. Four different things can stop a reader being counted and only one of them is the switch: a browser sending Global Privacy Control is not counted whatever the switch says. Where the decision is not the reader's, there is no switch at all, only the state.

Opening any page with ?af-analytics=off switches measurement off for that browser, which is how somebody who works here keeps their own reading out of the numbers.

All three were impossible before, and for one reason: the rollup grouped by a subject and then threw it away, so nothing could follow one organization across two days or one session across two events. The rollup now keeps a working set the application has no grant on, and publishes counts computed from it.

added

Signing in with GitHub now lands you in your own organization on the free plan, owned by you, and the free plan's quotas and cost caps are enforced against it from the first environment. There is no card, no invitation and no password anywhere in the flow: GitHub has to report a verified address before a user row is written, which is the whole of the email verification and is stronger than a link this domain could not send.

The organization is named after your GitHub account and carries its login, so installing the GitHub App on that account later adopts the same organization rather than creating a second one beside it. Environments, audit chain and plan survive the step.

AF_SELF_SERVE_SIGNUP=1 turns it on and it is off by default, because what it grants is a tenant with real compute against it and forgetting a variable has to close a door rather than open one. The process says which mode it is in at start-up, beside the line about the sign-in allowlist, because the two settings are one sentence: who may sign in, and whether there is anything on the other side of the door.

admin.audit.export had been a declared permission, held by the owner and security roles, with no route behind it. A permission that guards nothing looks like a capability from every angle except the one that counts. It is a route now: a file, in JSON or CSV, carrying each entry's previous and current hash so somebody who does not trust the vendor can check it, and recording its own departure in the chain it came from.

The verifier it calls had the same shape in the other direction. It was written, tested, and called by nothing outside a test, so the chain's tamper evidence was a property of the code rather than of the product. Verification now runs over the range a file actually covers rather than the whole chain, because a slice shipped with a verification of something larger verifies a different document from the one in the reader's hands.

Data Governance answers what is held about one person, and refuses to answer the parts this product cannot. The locations are read from the database catalog when the question is asked, so a table added next month is in the answer, and each one carries its foreign key's own on-delete behaviour, because that is the erasure answer rather than a description of one. What is not built is named instead of drawn: there is no per person erasure, organization erasure leaves the people in it behind, both audit chains keep the actor's name on purpose because the name is hashed into the entry, and there is no retention policy table so nothing expires on a schedule.

Security Center is every standing credential on the installation as one list rather than three, with how each organization signs in and who holds an operator account beside it.

Three sections behind Customers. Users & Organizations lists every organization and every account, with the sessions one account holds and the two writes that end them. Support & Impersonation keeps operator notes about a customer and is where an operator steps into an account. Billing & Stripe reads a customer's subscription, invoices, charges and credit from the payment provider rather than from a local copy of it, beside this deployment's own record of every administrative money action taken on the account.

Impersonation is bounded rather than trusted. It needs a stated reason of at least eight characters, it lasts minutes rather than the product's thirty days, the operator portal is closed to that session for as long as it lasts, and the customer gets the record in their own audit log at the moment it starts. The audit entry is written before the session exists, structurally: the session row carries the entry's sequence number as a foreign key into the chain, so a session that was never recorded cannot be represented.

Two ways out, and both now work. Ending it revokes the customer session the browser is holding, and so does signing out of the operator portal, which is the only button the portal offers a session that is already inside one.

It leads with one sentence, backed by real queries: whether an installation switch is engaged, whether a customer deletion stopped part way, whether an organization is suspended, and whether an operator account is waiting to be provisioned. Under it is a work list that is empty exactly when there is no work, and which names the questions it asked so an empty answer cannot be mistaken for a panel that failed to load.

Analytics & Usage measures consumption in environment-hours, the unit every plan cap is already enforced in, per organization and against that organization's own daily cap. It also reads model spend against the budgets somebody set. The page states plainly that there is no usage rollup in this schema, so the figures are computed live, there is no history older than the underlying table, and it draws no trend line over a series nobody stores.

Admins & Permissions can now create an operator, change a role, and suspend or restore an account. Those four routes existed, were guarded, were audited and were enforced by database triggers, and no screen in the console reached any of them. The page also shows what every platform permission grants and which roles hold it.

System Configuration reports what the running control plane actually resolved rather than what its environment intended: which capabilities are configured, the name of the variable behind each, the schema version this database is on, and whether any installation switch is engaged. No credential value appears on it.

Every route exists and opens something from the first commit. A section nobody has built yet says so, names what will live there and which permission will read it. It is deliberately not an empty dashboard: a page of zeroes on this portal is indistinguishable from an answer, and an operator reading "0 failing runs" off a placeholder during an incident has been lied to by their own tooling.

The overview is a directory rather than a wall of numbers, filtered to what the signed-in operator's role can actually reach, so somebody who has not used the portal in a month can find the section they want without opening five of them.

The three screens that already existed keep their behaviour and move to where the navigation says they are. The operator log gained the half of itself it was missing: every entry records what changed, the table had no column for it and dropped it, so the log showed that a plan was changed and never what it was changed to. That detail is now in a panel beside the entry.

The whole portal works on a phone. The rail becomes a drawer that traps focus, closes on Escape, returns focus to the button that opened it, and locks the page behind it, and every list becomes a stacked record rather than a table scrolling sideways with the two columns you came for out of sight.

Four sections. Repositories & Pull Requests lists every repository connected to the installation and, for one of them, its pull requests with the newest check generation on each, so a customer reporting that a check never appeared is answered from the row rather than from a log. A fork approval that no longer covers the head is reported as a stale approval rather than as an approval.

API Keys lists every credential that can act as a customer, with its prefix, what created it, what it acts as and when it was last used. An operator holding admin.keys.revoke can revoke one, and revoking a GitHub workflow identity binding also revokes every token that binding has minted. There is no rotate: only a hash is stored, so nothing in this product can produce a replacement, and the page says so rather than offering a button that could not work.

Integrations & Webhooks shows the GitHub App installations and every delivery that arrived from GitHub or Stripe, including the ones that resolved to no organization and the ones nothing handled. It is inbound only, because that is what this product records.

MCP Management reports that this control plane holds no MCP record, because af mcp runs on the developer's machine and never speaks to it, and lists the four tools the engine serves with the file and symbol each claim comes from.

Five sections of the platform portal are now built against real tables rather than reserved. Production Twins lists every environment on the installation, with the one filter that is a finding: past the lifetime it was created with, not torn down, and costing somebody money for a branch nobody is looking at. Branches groups those environments by the branch that made them and surfaces the same cost from the other side, a live twin on a branch whose pull request closed a fortnight ago. Safe State reads the golden data versions and the masking rules a scan proposed, and leads with the unconfirmed ones, which are the columns a scanner believes hold personal data on a copy somebody is running tests against.

Runs and Jobs is the page an operator opens during an incident, so it is built for one sequence: find the run, see why it failed, see what it touched. The three run families are a filter rather than one merged table, because an agent run has verdicts and artifacts, a load run has percentiles and a lease, and a pull request check has a head commit; a table true of all three would have to drop the columns somebody came for. Every list is keyset paged and says how many rows it is showing, and the failures filter is applied by the query rather than after the page, because filtering a cut page eventually returns an empty page with a cursor behind it, which reads as the end of a list that has more in it.

A run that finished is not a run that passed, and the pages say so. Every run carries a standing beside its own state: a load run whose state is succeeded can carry a failing verdict, and an agent run that reached complete having reported no verdict at all did nothing and found nothing. The second is shown as its own answer rather than as a pass, which is the exit-code-zero-over-nothing defect this repository has already shipped once.

Experiments and Feature Flags is a flags page, and it says so at the top. Flags are complete: state, rollout, targets, the internal-only bit, and a kill with a reason attached, plus the column that matters most during an incident, whether anything in the build reads the flag at all. Experiments are not built. There is no experiment table, no variant, no assignment, no exposure log and no results, and a rollout percent is a share of traffic rather than an experiment because nothing records which subject fell on which side. The page names that absence and the four things that would end it, rather than drawing a dashboard whose every number would be invented.

Safe State names its absences the same way. There is no record of a customer's live database, no snapshot ledger and no restore history anywhere in the schema, so the page cannot say which database was cloned, when a twin was restored, or how old the copy is. It says which table each answer would need instead of leaving somebody to search for a panel that was never built.

Infrastructure and Compute and Incidents and Kill Switches are faces for routes that already existed and had none: system health, the fleet of production twins, the teardown ledger, the egress firewall, and the three switches that stop parts of an installation. The switches show what each one refuses AND what keeps working, require a reason to engage, make the operator type the control's own name, and show the way back at all times. A fleet teardown asks the server what it would touch and makes that count the thing you type, so nobody confirms a blast radius they have not read.

Logs and Error Explorer and Email and Notifications are new, and both are built only from what this product records. There is no exception store, so failures are grouped by the failure code a run ended with, and by the workflow a verdict names. There is no delivery record, so the email page reports whether the installation can send at all, which no query over the database can answer, and counts sign-in links by what became of them. A link issued and never used before it expired is the only trace a delivery failure leaves anywhere in this schema, and the page says that rather than calling the column a bounce.

Both pages name what they cannot show and what it would take to change it. Event payloads are never returned: the field names and the byte size say whether ingestion is working without putting a copy of a tenant's data in an operator's browser.

The release notes listed the stream's set of types as explicitly not stable, with the reason "types are added as features land". That says what happens when the catalog grows and nothing at all about what happens when it shrinks, which is the only direction that breaks anybody.

Nothing was stopping it shrinking. schemas/events.v1.json is generated from the Go type and the catalog, so deleting a type or a field from the envelope regenerates cleanly: the diff is green, every test passes, and the consumer filtering on that type finds out on their next upgrade, receiving nothing and unable to tell that from a quiet system.

engine/internal/events/stream.register.json records the fifty five types and the eight envelope fields version 1 promised, and just eventcheck refuses to let any of them go. A type that is gone, a field that is gone, a field whose type changed, a required field that became optional, and a closed set that lost a value are each a failure naming what went and what it costs.

It also closes a direction nothing was watching. A type declared with no entry in typeDocs is absent from AllTypes, and every existing check walks AllTypes, so an event could be emitted while being missing from the schema, from the reference page and from every check at once. That now fails the build.

One published claim was wrong and is fixed. The description in schemas/events.v1.json said the envelope was identical across the engine, the runner and the control plane. It is not: four of the eight names differ on the control plane's side and two have no counterpart there at all. The comment on the Go type had said so for a while; the published artifact, which is the copy somebody would build against, still carried the claim.

The data object is deliberately outside the promise, and the reference now says so. It is the type specific payload, and its keys move with the code that writes them.

An event whose name is not in the catalog, or whose payload carries a field the catalog does not declare, is refused and counted rather than stored and filtered later.

The organization is recorded as a keyed hash rather than as an id, so the stream counts organizations and follows one through a funnel without being able to name one. The application role holds INSERT on the stream and no SELECT, so only the rollup, which runs as the schema owner, ever reads it, and only daily aggregates come back out.

An event nothing emits is a row on a dashboard that reads zero forever, which is indistinguishable from a quiet week.

The marketing site sends page views, waitlist submissions and waitlist dialog opens. It normalizes the referrer into a bounded channel in the browser, so the raw referrer, the URL and the query string never cross the network at all. It sets no cookie, uses no third party, keeps its session identifier in sessionStorage so it dies with the tab, and turns itself off for a reader who has set Global Privacy Control or Do Not Track.

There is no free-text field kind, so a repository name or a query string cannot reach the database even by mistake.

Milestones live in the organization facts table rather than in the stream. "The first time this organization proved something" was an event until the ordering tests showed two concurrent batches could both claim to be the first; as a column set with LEAST it has no race and converges to the same date whatever order events arrive in.

The page answers about the whole installation rather than one organization, and every organization has an owner who holds every permission in their own, so the route requires membership of the organization named by AF_ANALYTICS_OPERATOR_ORG as well as the analytics.read permission. Unset means nobody, and the route says which variable to set.

Every panel carries where its numbers came from: the window, when the rollup last ran, which days are still moving, and whether recording is switched on at all. Three different things render as zeros and the page says which one it is showing.

The release notes said the stable identifier for a finding was its rule name within a release, which is another way of saying there was no stable identifier at all. Anything filtering, suppressing or counting a finding had to match on a name that the next release was free to rewrite, and rewriting names is what improving a rule looks like: the day index_not_concurrent grew a sibling for the drop and another for the rebuild, a filter written against it was matching a different set of statements than its author meant.

The rule names were also not published anywhere. The insights page describes each rule in a sentence of prose, so somebody reading "rule": "unique_constraint_builds_index" out of --output json had no page to look it up on.

Every finding now carries a LINT-NNN identifier beside the rule name:

{"id": "LINT-010", "rule": "unique_constraint_builds_index", ...}

The report a person reads leads with it too, so the thing to write down is the thing on the page:

What these migrations do to a table this size: LINT-016 table dropped on orders, about 40000000 rows

The identifier is assigned once and keeps its meaning. It is never reused, not even after the rule that earned it is deleted: a retired rule keeps its entry and its number, so a filter written against one never quietly starts matching something else. The rule name, the title, the explanation and the fix all stay free to change, because that is what makes a rule better.

engine/internal/insights/lintcatalog.yaml is the source of truth. The Go code, the new lint findings reference page and the published catalogue at antifailure.dev/lint-findings.v1.json are generated from it, and findings.register.json beside it records every identifier ever handed out. GET antifailure.dev/api lists the catalogue beside the error one, so an agent asking what this host offers a machine is told about it. just lintcheck runs in CI and refuses a rule with no identifier, an entry for a rule that no longer exists, a duplicate, and an identifier that has left the catalogue since it was registered.

Nothing about which findings a release reports has changed.

The portal gains system health, the fleet of running environments, the teardown ledger, the egress firewall, and three emergency switches.

Health is a list of checks rather than a colour, and each one says what was counted, which number would be wrong, and what to do when it is. It reports environments that outlived their expiry and are still holding a database branch and containers, teardowns waiting on a runtime, teardowns abandoned after every attempt failed, the delay between an event happening and arriving, GitHub deliveries accepted and never handled, and pull request checks past their own deadline.

The teardown ledger keeps apart three things a single word hides. A request that was RECORDED with no workflow run and no environment id had nothing to send and will sit until it is abandoned. A request that was DISPATCHED has been asked for and not confirmed, because a cancel GitHub accepts is not a runtime saying the environment is gone. A CONFIRMED request is one the runtime acknowledged. An operator asking for a whole fleet to be torn down is told, per environment, which of those it is.

The firewall view reports one condition as always failing rather than scoring it: an egress rule in sandbox mode with no sandbox credential configured forwards whatever credential the application set, to the real provider. Such a request is identical to a working sandbox call in every column of the request log except that nothing was substituted.

The three switches are maintenance mode, new sign-ups, and new runs. Each is enforced by a named function with a real call site, refuses at a path a test drives, and is released from the same screen that engaged it. Maintenance keeps reads, sign-in and event ingestion working, so the operator who paused the installation can still authenticate to unpause it and no engine loses the record of work that ran anyway. Pausing sign-ups refuses only accounts the installation has never seen, so nobody mid-task is locked out. Freezing runs leaves teardown working, because an operator freezing during an incident still has to be able to stop what is running.

Engaging or releasing a switch writes a high severity audit entry in the same transaction as the change, with the entry first, so a switch cannot take effect without its record and a rollback takes both.

Three environments live at once, twenty four environment-hours committed by one run, and seventy two environment-hours in any rolling day. All three were enforced in the control plane and printed nowhere a customer could read, so the only way to learn the shape of the free plan was to reach a limit and read the refusal.

They live in www/lib/plan-facts.ts and the page renders them from there. web/apps/api/test/plan-facts.test.ts fails the build if that file and PLAN_QUOTAS or PLAN_COST_CAPS stop agreeing, which is the same gate legal-facts.test.ts puts over the legal pages and for the same reason: every one of the seven published claims that test was written for was true when it was written.

Two quotas are deliberately not published. PLAN_QUOTAS also declares goldens and artifactGigabytes for every plan, and neither is enforced anywhere: both are counted for display and no path refuses a creation over either. Publishing a limit that nothing applies is the same defect pointing the other way, so the test refuses those two by name until somebody wires them.

The page also answers the questions a visitor arrives with, including whether the MCP server is free. It is. af mcp is a command of the engine, the engine is MIT licensed, it runs on your own machine over standard input and output, and the enterprise directory contains no MCP code at all.

The free tier is the page's primary action now rather than an outlined afterthought beside an invitation wall.

Doctor's promise is that every problem it names is one you would otherwise meet halfway through a run. Copying production shells out to pg_dump and pg_restore, and it never looked at either. A machine with neither, or with a client older than the source, said "This machine can run Antifailure" and then failed at the step that comes after every other one: the repository read, the manifest written, the images built, and only then does the copy stop.

pg_dump refuses a server newer than itself outright, and there is no flag for it, so the ceiling is worth knowing before the twenty minutes rather than after.

`` ok Postgres client pg_dump 18 at /opt/homebrew/bin/pg_dump, so it can copy a source up to Postgres 18 ``

A warning rather than a failure when nothing is found. A project that fills its golden from database.seed runs neither program, and doctor answers about the machine, so it has no manifest to tell the two apart.

The ceiling is the newest client installed, which is not the one a copy runs. A copy picks the oldest client that still clears the server it just asked, so that a machine with 15, 16 and 18 copies a 16 server with the 16 client. Doctor has connected to nothing and has no bar to clear, and asking the copy's question with no bar returns the oldest install: the first version of this reported a ceiling of Postgres 17 on a machine that copied an 18 source three commands later. The two questions are now two functions and a test holds them apart.

It did not say so before, deliberately. No published release carried either file until v1.0.0, and the releases page disproved the claim in under a minute for exactly the reader it was meant to impress. The workflow steps existed and had never executed.

v1.0.0 ran them for the first time and published both. The sentence is checkable now, and it names the two filenames so a reader can settle it from the release page rather than taking it on trust.

PLAN_QUOTAS and PLAN_COST_CAPS are the price list and they are right: three plans, fixed numbers, enforced. What they could not express is the customer on team who was sold forty environments, the design partner using something nobody else has, and the trial extended by a week because somebody asked on a Friday. Every one of those is ordinary commercial reality, and doing any of them by moving the plan charges the wrong amount.

An override is now a row: which limit, at which of four scopes, to what value, WHY, who granted it, and when it stops. The expiry is not decoration. A grant with no end date is how a one-week trial extension becomes permanent revenue leakage nobody can find, so forever is something a person has to choose rather than something they get by leaving a field blank.

The part that makes it real rather than a table: the three places that can refuse a request now ask it. The environment quota and both cost caps on af up read the resolved value, and there is a seat limit on invitations that did not exist before. Every entry in the catalogue names the call site that reads it and a test greps for it, so an entitlement cannot claim to be enforced and not be; four entries name nothing and say why in prose instead.

The Plan screen shows the value that applies, the plan's own value struck through beside it, an Override badge, the reason somebody typed, who set it and when it ends. Before this, moving the quota under the screen would have left it reporting twenty five while af up refused at forty, which is worse than reporting nothing: somebody acts on it.

Feature flags, targeted by user, organization, project, repository, plan or environment, with a percentage rollout and a kill switch. Checkout and every administrative money write are behind one.

Two decisions worth knowing about. A DENY target beats an ON flag, because taking one customer out of a feature that is working for everybody else is the common incident and turning the whole flag off punishes the rest of them. And killing a flag is recorded as a different event from turning it off: the same change, completely different reasons, and the one worth finding six months later is the incident, so a kill demands a reason and stamps who and when.

A kill switch and a rollout default in opposite directions, deliberately. An unknown flag is OFF for a rollout, so a mistyped key leaves an unreleased feature unreleased. An unknown flag is NOT KILLED for a kill switch, because a control plane that has never had that row would otherwise refuse every checkout on every self-hosted installation, none of which has any flag rows at all.

The operator screen says whether anything actually READS each flag. Finding out that a switch has no call site by flipping it during an incident and watching nothing happen is the worst possible moment to learn it.

Refund, credit, plan change, trial extension, cancel, reactivate, discount, retry payment and resend invoice, on the operator portal, each with the reason recorded beside it.

A refund button that does not refund is a support failure. A refund button that refunds twice is somebody's money, gone, and an apology that does not fix it. Between a double click, a client retry, a load balancer replaying a request and an operator pressing the same button in two tabs, twice is not an edge case.

So every write is claimed in a ledger whose primary key IS the idempotency key, before anything is sent, and the same string goes to the provider in its Idempotency-Key header. The ledger closes the window between the two presses; the header closes the one the ledger cannot, where a process claimed the key, called the provider and died before recording the answer. A key reused with different parameters is refused before anything is sent, rather than answered with the first attempt's result, because reporting success for a refund that never happened is worse than either refunding twice or failing.

The distinction that took two attempts to get right: a provider that REFUSED made a decision, so a deliberate retry is a new request and gets a key of its own. Reusing it there leaves a declined payment un-retryable forever, because the provider replays its own refusal at a customer who has since fixed their card. A request that got NO answer may have been executed with the response lost, so its only safe retry carries the same key. There is no default that is right for both.

A refund larger than what is left on a charge is refused before it is sent, with both amounts and their currency named, so an operator who mistyped has not consumed a key or left a refused refund in the provider's dashboard.

Every one of these is recorded twice: once in the platform's own chain, and once in that customer's audit log, in the same transaction. A record only the vendor can read is a vendor's private note rather than accountability.

Running a hosted control plane means somebody eventually has to look at a tenant they do not belong to: to answer a support question, to read an audit trail, to suspend an account that is abusing the service. Until now there was no way to do that which was not either a database console or a tenant login borrowed from a customer, and neither of those leaves a record anybody can read afterwards.

The boundary is a separate Postgres role with BYPASSRLS, reached through its own pool, and that is the point rather than an implementation detail. A current_setting predicate is a claim the application makes about itself and is only as good as the code that sets it; a role the server authenticates is a credential, and code that has not been handed it cannot widen its own reach by being wrong. The two are independent mechanisms and this surface uses the second.

Every operator action writes to an audit chain of its own, separate from the tenant audit log, so a tenant cannot see operator activity and an operator cannot quietly edit the record of what they did.

Operator administration refuses to act on the caller. admin.operators.write is held by super_admin as well as by owner, so the dangerous move on this surface is not an operator abusing a customer, it is an operator widening their own privileges: a super_admin could otherwise have set their own role to owner and picked up every owner only permission with it. setRole and suspend refuse when the target is the caller, and the refusal is on self rather than on a list of forbidden roles, because "somebody else decides" needs no list to maintain.

Creating an operator mints no credential. The row lands with a null password hash, so the account exists and cannot be signed into until somebody provisions one out of band.

Five surfaces are here: tenants, users, sessions, operators, and a reader over the operator audit trail. The portal is the mount point and the boundary as much as it is those five: the other operator lanes hang their sub routers off the same object, so there is one place an operator route can exist and one matrix test that walks all of them. Impersonation, the support console, and search have their schema and their permission names and no routes yet.

They were served and undocumented. docs/guides/github.md hands a customer a curl line for them, and there is no af command in front of them, so the HTTP call is the surface. A surface a customer is told to call and cannot look up is undocumented rather than internal.

Four rather than three, which is the count everybody including me kept getting wrong. Revoking has two paths and not one: a repository is owner/name and a slash is a path separator, so a single {binding} segment cannot match one.

The document also gains a third security scheme. These take a CLI token from af login, which is neither the browser session nor an engine token, and declaring one bearer scheme for both would have told a reader they are interchangeable.

Postgres 18 has been the current release for a year and the docker provider listed 14 through 17. A project whose production is on 18 had two ways to go, and both were bad.

Setting database.version: 18 was refused:

AF-DB-003 The source database is Postgres 18, and this provider supports 14, 15, 16, 17. Next: Use a provider that supports Postgres 18, or upgrade the source.

No provider in the build supported 18, so the first half of that sentence named nothing, and the second half is the wrong direction: a source is not upgraded to reach a version older than the one it is already on.

Leaving it at the default instead copied an 18 source into a 17 golden and said nothing, so the preview ran a Postgres the application does not.

A golden built by the docker provider is the stock postgres image with the data committed into it, so the majors it handles are the ones that image is published for rather than a list this provider keeps. 18 is now in it, verified by refreshing a golden from a Postgres 18 source holding several schemas, an enum, a partitioned table, a materialized view, a generated column and a row level security policy, then branching it and reading the rows back out of the branch.

A major the provider really cannot build now says which key to edit and what it may hold. The other providers are unchanged: they talk to a service and the service decides.

Every route the contact page offered went to a public tracker or to a list. A private vulnerability report, an issue, a discussion, and a waitlist address are the right destinations for almost every technical question, and none of them is a way to speak to somebody about an evaluation or a design partnership. The domain has no mail exchanger, so there was no address to fall back to either.

The page now opens with a calendar. It shows real openings, and the times come from the calendar rather than from a form that promises a reply. The pricing page's two commercial buttons, on Team and on Growth and Enterprise, now lead to it: both previously pointed at the waitlist, so the highest value action on the site collected an email address.

The embed loads only when the section is close to the viewport, so a widget most visitors scroll past does not cost the page its first paint, and it ships in one route's bundle rather than the shared one. When the frame does not load, which is what happens to anyone blocking third party frames, the card carries the address in full and a button that opens it, because an empty rectangle where a calendar should be is worse than no calendar at all.

Two new pages join them, an acceptable use policy at /acceptable-use and a developer policy at /developer-policy covering the control plane API and the engine's Model Context Protocol surface.

The liability section publishes no cap. The contracting entity, the registered address, the governing law and the figure itself are rendered as visible blanks, because a cap written before a lawyer has chosen the jurisdiction it will be read in is a number rather than a protection. The page says which exclusions no contract can make, and says plainly that whether any of it is enforceable depends on the jurisdiction, on whether the customer is a business or a consumer, and on whether the harm was caused by our own negligence.

What the terms claim about the engine is now held to the engine. legal-facts gained seven assertions: that the customer's source database is opened in a transaction Postgres has marked read only, that teardown refuses a container Antifailure did not label, that NewRuleSet still appends the default masking rules so an unconfigured project is not an unmasked one, and that a golden failing verification is still never published. Each one was checked by breaking the guard on purpose and watching the assertion go red.

The eighth pins the list of column types the verification scan reads. The terms describe that scan as a check that a masking rule missed a column rather than a proof that no personal data survives, and that wording is exact on purpose: the scan's type list and the masking default's type list are the same six entries, so a column outside them is read by neither. Changing either list now sends whoever changed it to the sentence describing it.

No lawyer has read any of it, and every page says so on its face.

Four kinds, kept apart because they measure materially different things. An observed mix has no order, a scenario has no browser, a browser workflow has no request rate, and an exploration has no pass. Each says what a result from it is worth: a scenario replays request for request at the same seed, and an observed mix replays only as a shape.

A workload names things rather than containing them. Everything runnable is declared in your own manifest and selected by name, the same way the command line selects one, so a version is a selection plus the knobs its command actually declares. That is a security property and not a simplification: a scenario is checked against your safe route list before anything is sent, and a control plane able to hand an engine an arbitrary journey could send traffic you never allowed.

Every knob lives in the version rather than on the run, so changing the scale writes a new version and comparing scale 1 against scale 4 is comparing two versions. Versions are immutable and every run records which one it used, which is what makes a run from three weeks ago readable. A form offers a knob only when the kind's command has a flag for it, and says why underneath when it does not.

State and verdict are two separate answers and neither implies the other. A run can do all its work cleanly and fail every threshold in it. abandoned is drawn apart from a failure and said in words: the deadline passed with no engine reporting, which is a defect in the plumbing rather than in the change, and what is missing is the report rather than necessarily the work.

There are five verdicts, not four. flaky is one of them, and a run that came back flaky has found something rather than nothing.

Results are the engine's own rather than a summary of them. Latency is the five percentiles it measures and one it did not record is absent rather than drawn at zero. Errors are broken out by reason, because a thousand timeouts and a thousand refused connections are the same number and completely different problems. Routes are compared against production's own p95 and one with no baseline says so rather than reporting no change. The achieved rate is shown against the rate that was asked for, and a run that fell more than a tenth short says outright that the application did not keep up, because every latency figure under it was then measured behind a queue. A browser run shows five outcome counts, and a run that drove workflows and passed, failed and flaked none of them says that nothing was checked.

Evidence says whether it can still be read. A trace written to a path on a CI runner that no longer exists is shown as the record it is, never as a link.

Stopping a run is a durable command a runtime has to confirm, and the console shows where that request got to. A stop nothing acknowledged before its deadline says it was never confirmed rather than showing a cancelled run that may still be going.

Promoting an exploration compiles what an agent found into a workflow for your manifest, and returns two things in full: everything the compilation could not carry, one sentence each, and the block you have to paste into antifailure.yaml before anything can run it. A control plane that cannot put a file in your repository says so.

The area calls workloads.* on the control plane. Those routes land separately; until they do this ships the screen and not the data behind it.

A workload is a named definition of something to run against a preview environment: observed load, an HTTP scenario, a browser workflow, or an exploration. Versions are immutable, runs carry the version they ran, and what a run measured is stored as an aggregate, per route metrics, threshold verdicts and evidence rather than as one blob.

The four kinds stay four kinds. There is no shared intermediate representation behind them, because a weighted traffic mix has no order, a journey has no browser, a workflow has no request rate, and an exploration has no pass. A constraint refuses a result of one kind wearing another kind's columns.

environments.teardown now reaches a runtime. It used to mark a column and carry a comment saying the engine reads the row; nothing reads the row, so the containers stayed up while the console said the environment was gone. It now writes a durable command, dispatches af down through the customer's own workflow, and is acknowledged by the engine's own env.destroyed event. A teardown nothing confirmed says so instead of expiring in silence.

Until now, running Antifailure in CI meant creating an engine token by hand and storing it as a secret. That credential is readable by every workflow in the repository, has to exist before anything works at all, and never expires, which makes it the thing most likely to still be valid a year after the person who created it has left. The job now asks GitHub for a workflow identity, posts it to POST /v1/auth/github-oidc, and gets back a token that expires in fifteen minutes and works on POST /v1/events exactly as a static one does.

The part worth reading is what the control plane does NOT conclude from that identity. A verified token says, truthfully and with a signature nobody can forge, that this job runs in repository R. It says nothing about who R belongs to. Anybody with a GitHub account can create a repository, put id-token: write in a workflow, and mint a genuine token naming it. A verifier that read the repository owner and looked up the organization for that owner would have authenticated a stranger perfectly and then authorized them anyway, one workflow file away from writing events into somebody else's tenant.

So the claim is an identity and never a permission. Access comes from a claim on the repository, and three things make that claim mean something: at most one live claim per repository across the whole installation, so a verified identity resolves to exactly one organization or to none; creating one by hand needs the same role as minting an engine token, because it grants a workflow that ability standing; and the organization has to hold a live GitHub App installation on the repository's owner, checked in the application where it can produce a sentence somebody can act on and again in the database where a bug in the application cannot get past it.

Most customers never make that claim themselves. When a repository has no claim and exactly one organization holds a live installation on its owner, the claim is created on the first exchange and recorded as having come from the installation rather than from a person. That installation is GitHub saying the organization controls the account, checked against a signature on delivery, so it is the same evidence a manual claim is measured against with one step fewer. The manual claim remains for a repository the App is not installed on.

Stated plainly, because it narrows the rule above: a repository is refused when it has no claim AND no installation that could stand in for one. A repository whose owner no organization has installed the App on reaches nobody, and one whose owner two organizations have installed on is refused rather than guessed at, because choosing between them would decide a tenancy question by row order. Every repository still gets its own claim; installing broadly does not hand one organization the whole account.

Revoking a claim revokes its live tokens in the same transaction. A revocation that leaves fifteen minutes of working credentials behind has not revoked anything, and fifteen minutes is exactly the window somebody revoking in a hurry cares about.

The engine's control plane sink took its credential from AF_CONTROL_PLANE_TOKEN and from nowhere else, and nothing in any workflow this project ships has ever set it. So on a CI runner the sink was never built: the events that say an environment is coming up, is ready, or has been torn down went to the local log and the terminal and no further, and the dashboard stayed empty for every run anybody had.

A job that GitHub will vouch for now proves what it is instead. It asks the runner for the identity GitHub signs for it, trades that with the control plane for a short lived credential, and reports with that. This is the same exchange the report step already performs, so a workflow needs permissions: id-token: write and nothing else: no secret in the repository, nothing to rotate, and nothing for a customer to store.

The credential is short lived, so the engine renews it when the control plane refuses a batch and re-sends that batch rather than losing it. A refusal that renewing cannot fix is attempted at most once a minute, and the events wait on disk rather than being dropped.

AF_CONTROL_PLANE_TOKEN still works and still wins when it is set. A developer's machine and a self hosted engine have no runner to vouch for them, and somebody who has configured a token has said what they want.

Three things a fork or a misconfiguration used to say badly now say what to do. GitHub declines to mint an identity for a pull request from a fork, which is what stops a fork reporting as the repository it forked, and that now reads as the deliberate refusal it is. A control plane too old to offer the exchange says to upgrade it rather than answering "refused". A repository the control plane has not been told about reads as a setup step rather than as an authentication failure, and a rate limit says how long to wait.

Two fixes came with it. The example workflow set AF_CONTROL_PLANE while the engine reads AF_CONTROL_PLANE_URL, so a self hosted installation would have reported its events to the hosted instance, which is the address the engine falls back to. And an engine token's expires_at was written and never read, so a credential with an expiry authenticated forever; ingestion now enforces it.

It was the only reference page in the documentation with no machine coverage, and it is the one that drifted. That is not a coincidence: the command reference, the error reference and the transform reference are all generated or gated, and none of them has ever been wrong about what exists.

Forward: every URL in the documentation that hangs off one of this product's own hosts has to match a route the Hono server registers or a page the console serves. That is what caught /auth/callback in four documents.

Backward: every route the server serves has to be covered by a pattern the API reference names. The page enumerates families rather than routes, /trpc/*, /v1/*, /auth/*, which is the right way to write it, so the check reads it that way and a finding is a family nobody mentioned rather than thirty three lines of noise.

Three families are missing today: /webhooks/, /byok/ and /console/api/, eight routes, including the model proxy that two guides describe in full. That page is another agent's to fix, so those three sit in a register with a second assertion behind them: an entry that stops being missing fails as loudly as a new one appearing. It is a known gap that cannot grow and cannot outlive itself, rather than an exemption that quietly becomes permanent. Both halves were watched failing: emptying the register reports the eight routes, and adding a /byok/* row to the page fails the staleness check until the entry is removed.

af license install tells a paying customer to "Set AF_LICENSE_KEY and AF_ORG where the engine runs", then points them at antifailure.dev/docs/enterprise/licensing, and that page named neither. The product asked for two things and sent the reader to the one page that should have said what they are. af doctor had the same shape: it recommends AF_PORT_RANGE_START to somebody whose ports are busy, and nothing documented it. Both are fixed; this is what stops the next one.

The control plane has had this check since config-docs.test.ts was written, and its page has never drifted. The engine, which is the half a customer runs on their own machine, had nothing.

It parses rather than greps, and that is not fastidiousness. The first version was line oriented and returned a clean zero over AF_PORT_RANGE_START while looking straight at it, because r.Remediation = fmt.Sprintf( and the string that names the variable sit on different lines. A pattern that cannot match looks exactly like a pattern that found nothing. Reading an abstract syntax tree removes the question: a string literal is an argument to a call or it is not, however the source is wrapped. Six shapes are covered and each has a test that watches it fail, including that wrapped one, plus one test in the other direction so a scanner that matched everything would not pass.

Named at a user means printed, or in a Short, Long, Remediation, Example or Next field, or in a flag's usage string, or anywhere in the error catalogue. A variable that is only read is not named at anybody: seven of the engine's variables are spoken and all seven are documented.

tools/docs/variable-exemptions.tsv follows the pattern figure-exemptions.tsv established. A variable may be exempted by a row that states a reason, because an exemption with no argument behind it cannot be told apart from somebody silencing a finding they did not understand, and a row that stops being needed is reported so the file cannot rot. The file is empty today, which is a result rather than an oversight: it exists for the next variable, not for a backlog.

The commitment is written down surface by surface in what is stable rather than made as a blanket claim: a manifest declaring version: 1, the commands with their flags and exit codes, the documented --output json fields, the provider interfaces and the error codes. Breaking any of those costs a major version. The page also names what is deliberately not covered, which is the half worth reading before building against something: the Helm chart's values, the Terraform variables, the control plane's internal HTTP API, the event type set, and the lint rule names.

Release notes are written by hand now. CHANGELOG.md holds one section per tag and tools/relnotes emits the section for the tag being published, so the first thing a reader sees is prose about what changed rather than the list of merged pull requests the workflow used to generate.

That command also owns the verification preamble, and that is the part worth knowing about. The release action tries body_path first and falls back to body only when the path cannot be read, so the moment a notes file read successfully the preamble carrying the cosign verify-blob command would have been dropped from every release note, silently, with the step still green. One emitter means there is no second copy to lose.

The gate refuses a section that is empty as well as one that is missing, because a heading with nothing under it reads as finished in a diff. It runs on every pull request, since at tag time the only remedy is deleting a tag people may already have fetched.

tools/tagsync refuses a version pin that names a tag nobody has published. Most version strings are read from a released tree and should name the release being cut, but the Terraform image_tag defaults are not: azurerm_container_app_job.maintenance reads the image with no ignore_changes, unlike the bootstrap job and the application beside it, so an apply from main takes the value and a default naming an unpublished tag fails the apply on the stack that runs the product. Bumping those defaults after the tag is now a gate rather than a sentence somebody has to remember once a release.

The OpenAPI document is a file generated from the router, validated before it can be committed, and pinned to the revision that built it, rather than a request-time proxy of the production control plane. The site deploys on every push to main and the hosted control plane moves on a release promotion, so a proxy would have served the pre-promotion document while the site's own documentation described the new one. A proxy can also only validate what fits in a function: the one written first checked three root keys, and a document whose nested path item was malformed passed and was cached.

The deploy now checks both documents byte for byte against what the run built, because a stale document is a perfectly healthy 200, and fails when the API version the apex publishes differs from the one the control plane serves.

Contact names only routes that were checked against the live repository: private vulnerability reporting, the issue chooser, Discussions, and the waitlist. There is no postal address, no telephone number and no email, because the domain has no mail exchanger and its SPF policy authorizes no sender, so an email route on the page would be a channel that silently swallows whatever is sent to it.

The first run is nine commands long and any of them can be interrupted, and until now coming back meant reconstructing the state from memory: af init refuses a repository that already has a manifest, af up on a running environment is a no-op nobody recognises as one, and neither says where you actually are.

It derives every answer from the machine rather than from a record of what it last did, so tearing an environment down by hand or switching branches moves the answer with you. It runs nothing and writes nothing, which is the only way it can be honest: a command that ran the steps would have to report on work it did.

Each step reports one of four states and never collapses one into another: done, not yet, blocked, and not checked. The fourth is the point. Listing goldens takes this branch's lock, so a status command safe to run while af up is in flight cannot ask, and that step says so and names af golden list rather than reporting a golden it never looked for. Exit 0 means every step is either done or not reached yet, which is the normal state of a first run in progress. Exit 3 means something is broken.

af mcp serves four tools over the Model Context Protocol: rehearse this branch's pending migrations against a throwaway branch of a sanitized copy of production, inspect what the environment is allowed to reach and what it actually reached, and read or cancel a run that is still going. It is a thin frontend over the same orchestrator af ci and af insights drive, so a tool call and a pull request check cannot disagree about the same change.

The division of authority is a property of the schemas rather than a request. There is no argument on any tool that disables sanitization, widens the egress policy, lowers a threshold, names a database or skips the rehearsal, and a field no schema declares is refused rather than ignored. Thresholds come from the manifest's own policy block. An agent chooses what to test; it does not choose how safely the test runs.

Verdicts are PASS, FAIL and INCONCLUSIVE, and INCONCLUSIVE is never a quieter PASS. A missing golden, an unavailable subsystem, a cancelled run and a server that stopped mid run all report it, because an experiment that did not finish says nothing about the change. Every tool requires project_id: agents usually have one of these servers per repository configured at once, and naming the project turns a misrouted call into a refusal instead of a confident answer about code nobody asked about.

The candidate branch is treated as what it is, which is input written by whoever opened the pull request. Statement text never reaches a result; statements are identified by position and duration, and a name that does not look like a name is replaced rather than repeated, because stripping the line breaks out of an instruction leaves the instruction.

stress_test_pr_branch is not here. It needs a full environment and load cycle, and a tool that appears in the list but cannot run is worse than an absent one, because an agent will call it and spend a cycle finding out.

Answering "why did this account's run fail" has needed somebody who can look at another organization's rows. Nothing in the schema allowed that, so in practice it would have happened through a shared password at a psql prompt, where nothing is recorded. antifailure_admin is that access made explicit: a separate role with BYPASSRLS. It reads widely and writes narrowly, to exactly the actions the portal offers, and it gets INSERT and SELECT on the audit log and never UPDATE, so an operator cannot rewrite the record of what operators did.

A role rather than a policy because the cost of a policy scales with the number of tables, so it is a boundary somebody eventually forgets to extend, and the forgotten table is silently invisible rather than loudly broken.

It is a role rather than a privilege on purpose. The application cannot be granted its way into it, because reaching it means opening a connection with a password the application process is not given. A test asserts nothing has been granted membership and that SET ROLE into it is refused; granting it to the application breaks that test and the operator-notes isolation test together.

Impersonation is recorded on the session row, where the code that resolves a session on every request cannot miss it, and a check constraint makes the rules structural: the four columns are all or nothing, a blank reason is not a reason, and the row must carry the sequence number of the audit entry that authorised it. An impersonated session that was never audited cannot be represented at all, which is a stronger guarantee than writing the two rows in the right order and trusting nobody reorders them.

Support notes are not tenant data. The application role holds no grant on that table, so an operator's private note about a customer cannot appear in that customer's export or on any page they can open.

added

Before this the engine emitted none of workload.started, workload.finished or workload.cancelled and claimed nothing, so a run started from the console was dispatched, appeared, and was recorded as abandoned at its deadline whatever it actually did. The control plane's side of that wire was already built and tested; it was fed by nobody.

af workload run claims the run waiting for its environment, says when it started, says once a minute that it is still going, and reports what it measured. The report is the same document --result writes, so the artifact a job uploads and the numbers a console draws are the same bytes, and a report that cannot be delivered is spooled to disk rather than dropped.

The engine asks for the run rather than being told which it is, because a workflow_dispatch carries only the inputs the workflow declares, GitHub reads that declaration from your default branch, and it refuses an undeclared input with a 422 that is indistinguishable from the file being missing. --run-id still names a run by hand, and claims nothing, so reproducing a hosted run on a laptop cannot take the next queued run away from CI.

A cancel pressed in the console now reaches a run that is already going, and stops it. It arrives on the heartbeat the engine is already making rather than on a poll of its own, so there is no command client in the engine at all. So does a lease taken by another engine, which is what happens after a run has gone quiet long enough for somebody else to pick it up. In that one case the engine stops and then says nothing more, because the control plane's terminal statement is gated on the run's state rather than on who holds it: a report from an engine that has lost the run would end it for whoever now has it, and their measurements would arrive against a finished row and be refused. The result document is still written and uploaded, so nothing is lost on the machine that did the work.

A test reads the control plane's report decoder and checks that every field it reaches for inside the run's aggregate is a field the engine's own struct tags emit. Two green suites had never put a real message on the wire between them, and running one against the other found that the decoder was reading the shape of the engine's internal load result rather than the result document: it would have recorded a run that sent twelve hundred requests as having sent none, with every percentile null and every route beside it decoding perfectly.

Four kinds, kept apart because they measure materially different things: an observed_load mix through af load run, an http_scenario through af load scenario, a browser_workflow through af test, and an exploration through af explore. Each executes the same orchestrator call the plain command already makes, so nothing about those commands changes.

Every result carries the plain command that reproduces it, and a knob the plain command has no flag for is refused rather than dropped: a definition setting concurrency on an observed_load fails before anything is sent, because af load run has no such flag and honouring it would be a promise the run cannot keep.

A run that measured nothing gets its own exit code, separate from the one a real failure gets, so a job gating on the exit code can tell "the tests passed" from "nothing was tested".

af workload teardown removes an environment and says what was actually removed and what is still standing. af workload promote compiles an exploration into a workflow definition and lists, one line each, what the compilation could not carry over. af workload compare differences two results of the same kind and states what it cannot control.

It watched one target, staging, which is the one environment no customer touches, and rendered it as a run of bars with no components, no uptime, no incidents and no notion of not knowing. It now watches seven components across production, the public site and staging, each one a separate line because each one has its own way of failing while its neighbours are fine: the console is a static export inside the control plane's own image and answers 503 when that directory is empty, the installer is placed by the site assembly and has been missing from a publish, and the waitlist API is a managed function that can be present and refuse every request, as it did for two days behind a green deploy each time. Every static check now asserts a marker in the body as well as the 200, since each of those failures would have read as healthy to a check that looked only at the status line.

The page itself is plain on purpose: an incident banner when there is one, then a component per row with its status in a word and its last ninety days, then the response times behind those checks, then the incident history day by day. No card inside a card, nothing that animates, and no font, stylesheet, script or image request leaving the document, because the one moment it has to render correctly is the moment something else is down.

Every figure is computed from the record. Percentages are described as the share of checks that passed rather than as uptime, a ninety day figure is only called that once the record reaches back ninety days, nothing rounds up, a day with no readings is drawn in the neutral and never counted as a day that was up, and an isolated reading is drawn as a dot rather than joined by a line to one hours away.

State never reaches a reader as colour alone. Amber and red are 0.7 apart in OKLab under deuteranopia and green and red are 4.0 apart, so every component states its status in a word, a day containing a failure is capped in near black and sized by the share that failed, and the neutral is achromatic.

Subscribe is an Atom feed generated from the same data, carrying one entry per incident update and one per run of failed checks the probe detected. A button that did nothing would have been worse than no button.

added

There were 125 of them, written by whoever made each change, and the only thing in the whole tree that had ever opened one was a gate that checks documentation paths.

91 are public. The 34 marked internal stay in the repository and are never published: they are real changes with nothing a user of Antifailure could observe, and a changelog full of them teaches a reader that the changelog is not about them.

A date is the day an entry landed on the main branch, read from the commit that brought it there rather than typed. Nothing is backfilled. v0.1.0 and v0.1.1 carry no entries, because both were cut before the convention began and neither tag's tree contains the directory at all; the page says that rather than filling them in with work that plausibly shipped in them.

Settings holds the display name, the billing contact that decides where invoices go, every live session with a way to sign any of them out, a complete copy of everything this control plane holds, and the way to delete the organization. Members gains invitations, so a finance person or a contractor who is not in your GitHub organization can join through a link, and a way to remove somebody outright rather than waiting for a GitHub membership to change.

Deleting an organization is a state machine rather than a cascade, and it runs in this order: what is running is torn down and nothing new can be started, the Stripe subscription is cancelled at the end of the period you have paid for, nothing else happens until that period ends, credentials and the GitHub App installation are revoked, a complete export is produced and you are given a link to it, and only then is anything deleted. Every step is recorded as it happens, so a deletion that is interrupted picks up where it stopped rather than starting again, and it can be called off at any point before it finishes.

Closing your own account erases your name, address, identity and avatar, removes your memberships and signs you out everywhere. It is called closing rather than deleting because the audit log keeps what you did under the name you had at the time: the log is a hash chain, so an entry cannot be rewritten, and those entries go when the organization does.

Five new permissions: organization.settings, sessions.manage and data.export for an admin, organization.delete for an owner alone, and account.close for every role, because leaving is about you rather than about the organization.

--report stays Markdown for a person.

-o json is not that flag. It is the whole terminal's format, so a continuous integration step that shows progress to somebody watching the job and also captures a machine readable result would have to give up one or the other, and redirecting stdout to a file gives up the progress.

The worked example for af ci wrote its Markdown report to a file called report.json, which read as though --report produced JSON. It now names both flags and both file types.

One check run per commit, named Antifailure, so a branch protection rule can require it. The name is stable on purpose: changing it would silently un-require the check on every repository that named it.

Seven states, and blocked and unverified are not passes. GitHub's neutral conclusion reads as "nothing to say" and lets a required check pass, so a pull request whose agents never ran would merge behind a green tick. That is the defect this whole change is downstream of: af ci exits zero on a run that verified nothing, so a green job means the job exited rather than that anything was checked. A run that finishes without reporting is unverified, a run that never reports at all is timed_out, and neither merges.

One comment per pull request, edited in place, and its first line carries the commit it is about. Somebody pushes while a check is running, the first run is cancelled, the cancellation finishes after the second run started: without that fence the comment reports a commit that is no longer the head and nothing says so. A stale result the reader cannot detect is worse than no result. A run whose commit is no longer the head updates its own check, which is correct, and leaves the comment alone.

No repository secret to paste. The job proves who it is with a GitHub Actions workflow identity token and exchanges it for a credential scoped to one commit and one run, expiring within the hour. GitHub does not grant that identity to a pull request job running on a fork, so the fork case is closed by GitHub's own rules rather than by this remembering to check, and it is closed a second time here: a fork's commit gets no credential until a maintainer adds the antifailure:allow label, and the approval covers that exact commit. The next push withdraws it, because a maintainer approved code they read.

af ci --report-json writes the same report as JSON, which is what the job posts.

The whole surface is fenced against the orderings GitHub does not promise: the run event arriving before the pull request event, a job reporting before its check exists, a push during a run, a close during a run, a reopen during a teardown, and the same delivery twice.

added

AF_HOSTED_REQUIRED_PLAN=enterprise refuses every operational procedure until Stripe grants that plan, while leaving authentication, sign-out and the exits reachable. It is unset everywhere except Antifailure's own hosted service, so self-hosting is unchanged. Setting it while billing is off stops the process at startup, since that combination refuses every request and offers no way to pay.

The exits are the part worth stating plainly. A plan gate may restrict what the product DOES for a customer. It may never restrict a customer's ability to leave, to retrieve what is theirs, or to secure their account. So a lapsed plan still permits billing, exporting the organization's data, deleting the organization, closing an account, and listing and revoking sessions. That last one is a security action rather than a convenience: a credential can leak while a subscription has lapsed, and a paywall in front of session revocation would leave somebody unable to contain it.

The gate is enforced in shared tRPC middleware rather than per page, and on the three entrances that do not pass through it: engine ingestion, engine environment reads, and the provider and model proxy calls a terminal makes. billing.set, which exists so a self-hoster can change their own quota, is refused wherever Stripe or the gate is configured, because on a paying deployment it is a caller writing their own entitlement.

The Plan page now calls the subscription routes that already existed, and draws the states nobody builds: never subscribed, subscribed, no invoices yet, a failed call, a cancellation already scheduled, a refresh in flight, and a member who may look but not buy. AF_GITHUB_APP_INSTALL_URL gives a signed-in person with no organization the two actions that resolve it themselves rather than a sentence telling them to wait for somebody else.

The command existed and the only thing that named it was af env list, which nobody is pointed at either, so in practice the way to learn that leftovers accumulate was to read the whole command reference. An environment somebody is working in is not reported as a problem; only ones past the cutoff af env prune itself uses.

Three places told people to create one in the control plane and nothing anywhere could: the console has no page for them and the API could only list and revoke, so an engine could authenticate against a row that had no producer outside the test fixtures.

af-control-plane-backup create-org creates the first organization on a control plane nobody has installed the GitHub App on yet. A tenant otherwise begins only when an installation arrives, so a self-hoster's every sign-in landed with no organization and nothing in the console could be reached. It creates no account and grants no role: sign in through GitHub, then use break-glass as before.

There was one way to give the engine a key, which was to export a variable, and no way at all to find out what it would do with one: nothing said which key was configured, where it came from, or whether it worked, and af doctor said nothing about the model.

af model set stores a key in the system keyring, or in the encrypted local store on a machine without one, and never takes it as an argument. af model show reports the provider, the model, the endpoint, the source and a fingerprint, and never the key. af model test makes one cheap call and tells a revoked key, an exhausted balance, an unknown model name, a rate limit, an outage and an unreachable endpoint apart, because each has a different fix. af doctor now reports the model key, and reports having none as a pass rather than a warning, because running with the deterministic planner is a supported mode.

A key resolves through the same chain and in the same precedence order as every other secret, so an export still beats a stored key, and af model show says when the key you stored is not the one runs will use. It now reaches the two processes that spend it: the runner subprocess, which inherited only the engine's own environment and so could never see a stored key, and the egress sidecar's synth path, which read the environment directly and would have told somebody who had stored a key to set the variable.

af model rm reported a removal that had not happened. Every keyring here returns success for deleting an entry that is not there, so somebody rotating a leaked key was told "Removed the anthropic key from the system keyring" by a keyring that had never held it, and stopped there. It now reads before it deletes and reports only what it can show happened.

A local key and a key capped by af provider on a control plane can both be configured. The local one wins, because nothing routes a run through a control plane unless the base URL says so, which means a monthly cap somebody set is silently not in force. af model show and af doctor now say that, from a local credential read rather than a request, and a control plane gateway is named as one rather than as an anonymous custom endpoint.

Custom endpoints are a first class path for a local model or a gateway, with their own failure advice. A manifest's egress policy does not govern the model call and does not have to name the provider, which is now covered by a test so a refactor cannot quietly turn synth mode off under default: block.

added

af secret set --help now shows what a real invocation looks like rather than only what its switches are called, and the same examples appear on the generated command reference page.

af up, af ci, af test and everything else that builds an environment draw a status line under the step in progress carrying the elapsed time for the run and for the current step, and a reminder that the first Ctrl-C rolls back rather than abandons.

The line is drawn only where there is a terminal to erase it on. Piped output, a file, and a CI log receive exactly the bytes they received before, because text output stays byte stable for the same input. Nothing spins and nothing loops: the line is rewritten once a second because the number on it changed.

The failure it exists for cost most of an evening. A week of www work was verified with www/node_modules holding Next 15.5.23 against a lockfile pinning 16.3.3. Every build, every SEO assertion and a whole prose sweep ran against a different Next major from the one CI uses, and every one of them reported success in good faith. It also explains an inconsistency several people chased separately: next build rewriting www/tsconfig.json is Next 16 behaviour and a stale 15 install does not do it, so the same command dirtied one worktree and not another. It was never flakiness. It was who had last run npm ci. The same trap produced a bogus "Invalid config passed to starlight integration" in docs and an ERR_MODULE_NOT_FOUND that read like somebody else's branch being broken.

It compares rather than installs. npm ci in every recipe that builds would be correct and would make every local run pay for a full reinstall of a tree that is almost always already right. This reads package-lock.json against node_modules/.package-lock.json, which is npm's own record of what it materialised, so it answers in milliseconds with no network and can run at the front of just gate and inside recipes that install nothing.

Four situations, four answers. A drifted tree fails, because everything checked against it answered about the wrong versions. A half installed tree fails for the same reason, and so does one installed before the workspace it links into. A workspace with no node_modules is reported and does not fail the gate, because it cannot have answered anything and every recipe now installs what it uses; the recipes themselves do treat it as a reason to install.

Workspaces are found rather than listed. There are eight lockfiles here and the two places that named them by hand each named a different subset: just deps installed two of the eight, so a fresh clone left six uninstalled and said nothing. It now installs all of them, and derives the ORDER from the lockfiles: a workspace that resolves dependencies out of another with file: links goes last. ee/web is the only one today. npm ci there before web exists succeeds and leaves a tree that does not work, and npm run typecheck then reports five implicit-any errors inside web/packages/db/src/schema.ts, in a file nobody touched, on a branch that is fine. That is now a fourth thing the guard reports.

added

Stripe customers, subscriptions, invoices and payment method metadata, a checkout session, the customer portal, and the webhook that moves organizations.plan, which is what the quota enforcement in PLAN_QUOTAS and checkQuota has always been pointed at and never been able to reach. Billing is off unless AF_STRIPE_SECRET_KEY, AF_STRIPE_WEBHOOK_SECRET and both price variables are set; a partly configured one is reported as off with the missing names, because the one an operator misses is usually the webhook secret and it fails only when a real customer pays.

Every billing table has row-level security enabled and forced. A Stripe delivery has no tenant, so it declares the customer its verified payload named and the policies tie the row it writes to the organization that already owns that customer. Signatures are checked over the raw body, timestamp included, before anything is parsed.

The whole integration is built and tested against the engine's own Stripe mock pack, offline, with no Stripe account and no network.

cd.yml updates the container app, starts the bootstrap job and shifts ingress traffic, and every one of those is a write the deploying identity held no permission for, so the production job would have failed at its first call. The grant is an azurerm_role_assignment in the stack rather than a command somebody ran once: Contributor on the production resource group and nothing else, reviewable in the same place as everything else about the environment, and present in state so a rebuild does not silently leave it behind.

added

github_app_id is set in production.tfvars, so the stack reads the App's private key and webhook secret from Key Vault and hands them to the container app: the sign-in redirect now carries the real OAuth client id instead of a placeholder, and POST /webhooks/github verifies a signature instead of answering 503 to everything.

An egress rule now waits for approval instead of enforcing the moment a member proposes it, and the console carries the queue and the approve control. Create environment, Run agents and Run load dispatch your own workflow in your own repository, so the work still happens in your CI and your data stays there; they need the GitHub App to have Actions write. Runtimes can be registered, tagged and removed, and the registry now shows what environments are actually running on beside what somebody registered. The plan can be read and set, which is what the quota enforcement has always needed and never had. Setting the plan takes no payment.

runtime.ttl had been declared, validated, defaulted and printed by af explain since the manifest existed, and read by nothing: every environment lived until somebody remembered it, holding a database branch, a network and a container per service the whole time.

af env reap removes the environments whose lifetime has ended, and nothing else. The expiry is stamped on the resources when they are created and read back off them, never taken from the manifest the sweep was run with, so a repository with a two hour lifetime cannot remove another project's week long environment on the same machine. An environment whose resources state no lifetime is never removed, because reading "states nothing" as "already over" would turn an upgrade into a machine wipe; use af env prune --older-than for those. An environment something is running against is deferred to the next sweep rather than pulled out from under a running command.

af env extend keeps an environment you are still using. It is bounded by the new runtime.max_ttl, measured from when the environment was created rather than from now, so extending repeatedly cannot walk the limit forward.

runtime.ttl now defaults to 24h rather than 168h. The week was chosen when nothing read the field, so it expired nothing and cost nothing; it is now the default runtime.max_ttl, which means an environment that genuinely needs a week can still have one by asking for it.

The control plane refuses a run that would exceed a per-run or a rolling daily cap on environment-hours, naming the cap, the usage, and that an owner of the organization can change the plan. Reaching a cap refuses the next creation and never removes anything that exists.

See docs/reference/environment-lifetime.

added

Every changed path is classified by a rule that names it, every check is reported as selected or not alongside whether the manifest configures it at all, and the report says what reading a diff cannot see. It opens no environment and touches no database, so it is the one thing the product can say before it has spent anything.

The rule that decides how much to trust it: a path no rule recognises selects every check rather than none, and so does a diff too large to classify and a diff with no files in it. The two mistakes are not symmetric. A path wrongly called documentation skips work nobody finds out about; a path wrongly called unknown costs a run that shows up in the report.

It never grades the change. There is no score and no risk word in the output, because both would be a judgement made from a file listing, and a tool that calls a change safe is making a promise the terms of this product refuse to make. What it produces is one shape of sentence: this file is X, and X is exercised by check Y, and here is the rule that decided.

An added line naming an outbound host is checked against the egress policy using the same code that decides real traffic, so a pull request that starts calling something the manifest does not mention says so before the run rather than after it.

change.rules in the manifest teaches the classifier a layout the built in rules do not predict. A rule says what a path is and never which checks to run, it cannot claim a surface the manifest already derives, and a pattern matching every path is refused, because one would classify everything and the fail safe above would never fire again.

added

Every line comes from something the engine already knew and was not telling anybody. The runtime says what is running. The database provider says which golden the branch came from and whether its signed attestation still matches its own signature. The branch says how many tables and rows it holds and whether each declared persona actually has a row in it. The manifest says which hosts the policy names, and internal/mockpack says which pack answers for each one in mock mode and whether that pack keeps state.

Nothing is estimated. A component whose state could not be determined is reported as unmeasured, excluded from the headline, and named with the reason, which is the same discipline the insights report applies when it says what it could not read. A dimension the manifest never asked for is excluded whole, because an environment that sends no traffic has not reproduced traffic perfectly. When nothing could be measured there is no score, and that is never rendered as nought percent.

The headline is defined every time it is printed: how many of the measured components are production's own thing rather than a substitution, a refusal or an absence. The per dimension verdict comes first, because the one dimension a change touches is exactly what an average hides.

fidelity.require in the manifest names dimensions that must be fully reproduced. A required dimension that was measured and found wanting exits 6 with AF-FID-001; one that could not be measured exits 1 with AF-FID-002, because a gap in what we can see is not the same result as a fact about the environment, and reporting the first as the second is how a check stops being believed.

A reason is required and an entry that stops being needed fails the gate, so the list cannot rot into permissions nobody remembers granting.

It reads source rather than built HTML, because the defect it was written for was drawn client side: the site rendered an invented fid 87% fidelity score on two product pages, and curl on either one found no "87" anywhere, so every audit over the rendered output came back clean.

Only server spans become traffic, both the current and the pre-1.21 attribute names are read, and because a span carries a duration the shape arrives with production's own p95 for each route in it. That is the baseline p95_increase compares against, and until now nothing could provide one: a combined format log line has no duration, so the threshold was real and unreachable.

A scenario is an ordered list of requests with waits between them, parallel blocks so the second submit arrives while the first is still in flight, and assertions over what came back. Sessions walk it at once and start_after lets one journey burst while another is already running, which is the load that actually breaks things and which a flat mix cannot express. It is deterministic per seed, it answers in the verdicts a run already uses, and every step is checked against safe_routes before anything is sent.

A failure is confirmed against a second branch of the same golden with the migrations left off, so a workflow that fails on that release either way is reported as unverified rather than blamed on the change, and anything the check itself could not do is blocked rather than failed. The finding names the object when the previous release's own output supports it: "the previous release still reads customers.email, and this migration dropped customers.email", with the Postgres error and the statement beside it. It exits AF-DB-031 on a proven break.

Configured by insights.rolling_compatibility. when defaults to risky, which runs it only when the migrations take something away, and against defaults to the merge base with the base branch.

added

The engine has rehearsed migrations on a throwaway branch of the environment's own golden, sampled pg_locks every 250ms and diffed query plans since phase 3, and none of it reached a pull request: af insights was a separate command somebody ran by hand. A migration that holds an exclusive lock past policy.migration_lock.fail_ms now fails the check and names the table.

The engine had five verdicts and none of them was the middle one the product has always described, so anything the environment noticed either failed the build or was printed and forgotten. A new policy block in the manifest decides which class of finding warns and which fails, with ignore for the ones a project does not want. blocked keeps its meaning exactly: the runner could not evaluate this, it exits zero, and it never counts against the change.

It brings a second environment up from a baseline revision, branches the same golden for both so they start from identical rows, sends both the same requests in the same order, and reports every difference in what came back and in what ended up in the database. Responses and database contents are compared completely; events, outbound effects, traces and query plans are not compared at all, because two comparisons done properly are worth more than six done shallowly.

Values that no two runs can agree on are normalised before they are compared: two timestamps within an hour, two UUIDs, two numbers within a relative tolerance. Sequence identifiers and numeric epochs are compared exactly on purpose, and everything the comparison declined to look at is printed on every run, defaults included.

They read each page through the accessibility tree, choose where to go, and report where the application cost somebody effort without failing: a control that did nothing, a page with nothing left to try, a route that loops back, an interactive element with no accessible name, a step slower than the goal allows, and a goal never reached. Every finding names the page, the control and the step.

Every choice comes from the goal's seed and every duration from the injected clock, so the same seed takes the same path and each result carries the command that replays it. An exploration reports pass and exits zero even when it finds things, because nobody declared what should happen on the pages it wandered onto and a red mark on a pull request that is fine is a check people mute. A run that could not start is blocked, which means nobody looked rather than nothing was found.

af explore --emit-workflow prints the workflows: block that replays what was explored, so a discovery becomes a check that runs on every pull request.

There are eight rather than the six Terraform writes, because the GitHub App's private key and webhook secret live there too and are read rather than managed.

Each says what breaks while the secret is being replaced, and two carry a warning that is not about rehearsal. Rotating the provider key sealing secret destroys every stored provider key and there is no re-sealing tool. Rotating database-url needs an ALTER ROLE that nothing in this repository runs for you: the bootstrap job creates the application role only when it is absent, so changing the vault value alone hands the application a password Postgres has never seen.

Its bundled profile weights each route by its own declared rate limit from web/apps/api/src/limits.ts, labelled declared_limits rather than production because no real production traffic has been captured yet. See docs/self-hosting/operations#load-testing-the-control-plane-itself for how to run it and what a real local run found: the database connection pool, not the rate limiter, was the first thing to saturate.

deploy/status/probe.sh and deploy/status/render.sh do the work; .github/workflows/status.yml runs it every five minutes and publishes to the status-data branch. See docs/self-hosting/status-page for the design and the one manual step (enabling GitHub Pages on that branch) left for a human.

The Azure page gains a full manual rollback procedure (docs/self-hosting/azure#upgrade-and-rollback-the-manual-path) for the case deploy.sh's own automatic rollback does not fire: how to find the last good revision, move traffic back to it, verify with health-gate.sh, and reason about a migration that already applied, including the case where it was not backward compatible and a code rollback alone would make things worse.

Every organization here is created by an installation webhook before anybody signs in, and sign-in mapped a GitHub administrator to admin, so no organization had an owner and nothing held billing.manage. GitHub still has to say admin: a first sign-in during an outage is still a member, because guessing upward would hand out a tenant on a timeout.

af-control-plane-backup break-glass sets a role directly in the database, for when the GitHub App is gone and nobody inside the organization can act. It writes a member.break_glass audit entry carrying the reason, it refuses to leave an organization with no owner, it cannot create an account, and it grants no session. --dry-run reports what would change and writes nothing. The runbook has it under "Nobody can sign in".

Eleven Azure Monitor rules and one action group where there were none: an availability test against /readyz from three locations outside the stack, server errors, restart loops, replicas below minimum, database storage, connections, CPU and reachability, one rule per container app job, and certificate expiry. Each rule names its runbook in the notification it sends, and every runbook is a page under Self-hosting.

production.tfvars sits beside staging.tfvars and explains every value that differs, including the recovery point objective next to the retention that is constantly mistaken for it. app.antifailure.dev is Terraform's now: the DNS records, the managed certificate and the custom domain binding. Standing up production has a page with the eight things Terraform cannot do, in the order that works.

All four are linked from the footer.

Every subprocessor was established by reading the code that talks to the vendor: Microsoft and GitHub for every organization, Anthropic and OpenAI only when an organization stores a model provider key, and no payment, email, or analytics vendor at all. Every retention period is one the software already enforces, including the two that are not exact.

The privacy notice claimed the control plane holds billing data, which no payment processor exists to produce, and did not mention the waitlist address it stores or the address and user agent a session row carries. All three are fixed.

No lawyer has read any of it, and every page says so on its face.

added

af-control-plane-backup had no caller anywhere in this repository until now: the suite exercised the library, and nothing exercised the command an operator is told to type. just drill runs the same thing on a laptop, and the workflow invokes that recipe rather than a second copy of it.

The drill reports the recovery time it measured, writes it to a JSON report and holds it against a budget, exiting 4 when the restore is sound and slow so that a busy runner never reads as a broken backup.

The one that matters most is lock_timeout: a migration that waits for a lock does not merely wait, it queues every subsequent query on that table behind its own lock request, so a four millisecond ALTER TABLE blocked behind one long running transaction stops all writes for as long as that transaction runs. The rule reads current_setting('lock_timeout') from the branch before it fires, so a project that sets the timeout on the role or on the database rather than in the migration file is not told it has none, and where the rehearsal saw the lock the finding carries how long it was really held on a table with production's row counts.

The rest are SET NOT NULL on a column that already exists, a CHECK constraint added without NOT VALID, ADD CONSTRAINT ... UNIQUE building its index in place, a backfill in the same transaction as the schema change it belongs to, and DROP INDEX, REINDEX, VACUUM FULL, CLUSTER, DROP TABLE and TRUNCATE. Each names the lock mode, the real row count of the table on the branch, and the multi deploy sequence that avoids the problem.

All three are served from antifailure.dev.

A recorded dogfood run spent 95 seconds on its first legacy Docker build after the sessionless API request was refused. Buildx keeps the modern builder's layer cache and supports modern Dockerfiles without pulling BuildKit's session dependency graph into the Antifailure binary.

If Buildx is absent, the existing legacy fallback remains. Antifailure checks that the built image is visible to the daemon running the environment before accepting it, and retains the managed labels, content-based image tag, and redacted bounded build log.

Existing installations and explicitly pinned tags do not change.

Two releases skipped the step that moves those defaults, so the gap was two tags rather than one and anybody who installed the chart without pinning a tag got software two releases older than the release they had just read the notes for.

The three defaults now name v1.7.0: the control plane stack's image_tag, the module's image_tag, and the chart's appVersion, which is what image.tag falls back to. The chart's own version is unchanged, because it moves when the chart changes and the two numbers only agree by coincidence.

Nothing already running changes. A deployment made from the tag's own image is already on v1.7.0, and an installation that pins its own tag is unaffected. What changes is what a fresh install reaches for when it is not told.

Product, solutions, pricing, forms, and articles focus on what a team can test and the findings it can review. The main hero headline and its animated green artwork remain, with a reduced-motion fallback. The hero offers the install command and a demo request, with less empty space above the headline. The demo section plays the owner-provided recording with its original audio and video.

Five compact feature diagrams replace the miniature app windows, with three-line descriptions and aligned baselines. The migration section connects a small schema change to a recorded table rewrite and lock finding in one diagram. Firewall routing shows simulated payments, captured emails, and blocked calls, with a separate composition for narrow screens. The closing panel uses an agent-to-twin diagram instead of the aurora image. The Isolated Twin section shows a focused version of the real console with recorded demo environments. It replaces the animated lifecycle mockup and reflows the environment table into readable records on phones. Mobile comparisons and request ledgers reflow without clipped labels. Form fields use a readable phone size, and menu and video controls retain their tap targets. The demo recording has a new URL so cached older clips do not replace it for returning visitors.

The mobile menu removes repeated links and keeps keyboard focus inside the open menu. The sign-in privacy summary uses an accessible dialog, and the privacy notice distinguishes masked session recordings from submitted form details. Owner-provided business contact details are included. The status page has a main heading and a header that fits narrow screens.

Between 23:17 and 23:25 UTC on 2026-09-24 a publisher made its own MinIO images private, and the consequence was out of all proportion to the cause: the object storage step of the engine job began failing on every pull request, the test step after it reported skipped, and a required check went red having examined nothing. Six pull requests and the main branch were blocked behind one third party's decision about its own namespace.

The pin moved that day to a different publisher's build of the same source, and both files said in as many words that it was a stopgap, because the replacement namespace is a frozen archive with no retention promise. This finishes the job. The image is copied into ghcr.io/antifailure/minio and the two places that start it, the CI workflow and the stores recipe, name our copy.

The copy is byte identical to what was reviewed, and that is checked rather than asserted. Manifests are moved as bytes with crane copy rather than pulled and pushed, which would collapse a multi architecture index into whichever single platform did the pulling and change its digest, so one declaration still resolves to the right image on an amd64 runner and on an arm64 laptop. The digest is read back off the registry afterwards and a mismatch fails the job. It was also verified by hand for the copy now in use: an anonymous manifest read returning the same digest, both child manifests present for amd64 and arm64, every layer and config blob of both readable with no credential, and the pulled image running and refusing a deliberately wrong signature exactly as the original does.

Anonymous readability is the property that matters rather than ownership. A runner and a fresh clone have no registry login, so a private mirror would have reintroduced the failure it exists to escape. Nothing gained a credential, a scope or a login step.

The new risk a mirror brings is that the registry and the repository drift apart, so the check that used to hold the sites equal has been replaced with one that can still see them. The old one groups references by name, which stopped being able to compare a pin against the mirror's source the moment the two named different registries. The new one refuses a pin the mirror does not copy, a pin left on the upstream at the correct digest, a mirror whose own verification is aimed at something it did not copy, a mirror of a moving tag, a copy published under a version it is not, a mirror nothing consumes, and a mirror workflow it cannot read at all. That last one matters most: a gate that reads a missing declaration as a clean tree is the failure this project keeps finding in its own instruments.

One defect in the mirror workflow itself is fixed here too, and it was found by running it rather than by reading it. Its install step reported success while the step after it died with crane: command not found, because go install writes to a directory that is not on the runner's path. The tool is now called by its full path and the install step runs it once, so a tool that arrived is proved rather than assumed.

The analyser mapped the infrastructure surface to nothing, in the same line as prose, your own test suite and your continuous integration configuration, under one true sentence: the environment is built from antifailure.yaml rather than from your Terraform. Read the fail safe this package is built on and the grouping is the mistake. A path wrongly treated as inert skips work that should have happened and nobody finds out; a path wrongly treated as unknown costs a run nobody needed and is visible in the report. Prose, a test file and a workflow file do not run in production. Your infrastructure as code does. It was the one of the four that is not inert, and it sat in the bucket for the three that are.

The consequence was not a quieter report. The published action gates the whole run on steps.change.outputs.environment, so a change to production's database, its capacity or its firewall wrote environment=false and ran nothing.

An infrastructure change now brings the environment up and drives the application inside it, and the added lines are read for what they say. A database engine version or a server parameter selects the migration rehearsal, because the rehearsal is what applies your migrations to a Postgres and measures what they lock. A replica count, an instance size or an autoscaling bound selects load. A firewall or security group rule selects the egress decisions. Each fact names the file, the line number and the rule behind it, the same as every other conclusion this command draws.

The sharpest of them is new rather than renamed. When an added line sets a database engine version and database.version in the manifest is a different major, the report says which one the rehearsal will actually use, naming both numbers. That pair lives in two files and nothing used to hold both, so a repository could move production to Postgres 18 and go on proving its migrations against 17 with every check green.

Read the claim precisely, because the report now repeats it on every run that touches one of these files: nothing applies your infrastructure as code. The environment stands in for the runtime the change describes, and standing in for it is not being it.

Three limits, stated rather than discovered. A bare version key is not read as a database version, because it is also how every provider pin and every chart states its own, so an Azure Postgres version is in a key this cannot see. A URL inside an infrastructure file is not read as an outbound host, because it is usually a module source, which is a download the build makes rather than a call the application makes. And nothing parses HCL: the added lines are read as text, so Kubernetes manifests, Helm values, Bicep and CloudFormation get the same reading rather than the one format a parser was written for.

The published action also exports an output per check now, rather than the two it happened to name, so a job calling it directly can skip its own work on the same answer the action already computed.

Two smaller things fell out of writing the tables down once. The surface table on the concepts page is now compared against the table the analyser plans from, rather than kept in step by hand, and the first thing that comparison found was that auth had never been published at all: the surface existed, it selected the environment and the workflows, and the page a customer reads did not list it. And a check reads the example on that page back out of the binary, so the worked output there is what af change actually prints rather than what it printed when somebody pasted it.

The domain now has MX records and receives mail, so the sentence had become false, and a false fact in a security policy is worse than a missing one: it invites a reader to test it and to distrust the rest of the page when it does not hold.

The policy itself is unchanged. Reports still go through a private vulnerability report on GitHub, and there is still no security mailbox. What changed is the reason given for it, which is now a choice that is stated plainly rather than a limitation that no longer exists: no address on the domain is monitored for security reports, and one sent there would miss every commitment the page makes. The sender half of the old sentence was and remains true, so it is kept and made specific: the root authorises no sender at all under v=spf1 -all with DMARC p=reject.

A nil dereference on a new line is only a bug because of the line above that left the value nil. A value used as the wrong shape is only wrong because of where the shape was set. A new call is only broken because of the contract defined in code the diff did not add. The reviewer was handed the added lines alone and told to be sure about nothing it would need the rest of the file to judge, which is exactly the class of defect a whole file reader catches and a hunk reader cannot.

The reviewer now sends the model each changed file whole, with the added lines marked and the unchanged lines around them shown as context, and decides on the whole file while still reporting only on the added lines. A file too large to send whole falls back to its added lines with a window of surrounding context, and a change too large for the total budget reviews its highest signal files and names the rest as unreviewed rather than dropping them in silence. A finding the model anchors to a context line is dropped, so seeing more of the file never lets the reviewer report a pre existing bug the change did not introduce.

It reads the routes to exercise from security.Input.Routes, and the collector that builds that Input wired the field to nil, because no producer existed. A nil route source is UNAVAILABLE by the family's own contract, so on every run the family reported blocked and moved on. The capability looked shipped and did nothing.

The producer exists now. The collector sources the routes from the browser exploration the run actually performed: every page it stood on and every navigation it made is a route the run OBSERVED reaching, which is what the family is meant to fuzz, rather than a route a manifest merely declared. A concrete id in a path is templated to {id} and only query parameter names cross into a route, never their values, so a route stays a location and never a row id or a user's input. The three states the family reads as opposite verdicts are kept exactly: a populated slice is fuzzed, an empty slice is the quiet pass of a run that reached routes but none worth fuzzing, and nil stays UNAVAILABLE for a run with no exploration to read, so a missing source never reads as a clean bill of health.

Two ways in, both closed now.

runtime.ttl: 0h passed validation: 0h is a duration, so the check that a lifetime is a duration accepted it, and the runtimes stamp the reaper's expiry label only when the lifetime is positive. The result was an environment with no label, invisible to af env reap for ever. A non-positive ttl is now refused at load, with a message that says to set a positive duration or leave it unset for the default. A manifest that states no ttl still inherits the 24h default, so "no lifetime stated" means the default and never means immortal.

A af ci run stamped its throwaway environment with the day-long default, and a run that CRASHED, killed for memory or with its runner pulled out from under it, never reached the teardown that would have removed it. The environment sat for a day carrying that default. af ci now bounds its environment to the run's own budget, its --timeout plus a grace and never more than runtime.ttl, so a crashed run's leaked environment is collected within the hour rather than the next day. The normal path still tears it down at once; only the crash path is changed, and only for the better.

Self-serve organization creation is gated by AF_SELF_SERVE_SIGNUP, which defaults off, so a GitHub exchange from /signup created nothing: the header, the hero, the closing panel, the pricing page, the solutions pages and the footer all promised an account anybody could make, and the account never came. The page under them described a free plan you land in by signing up, on a plane that admits no one who signs up.

The hosted plane is reached by talking to a person now, and the site says so. A new /request-demo page carries the split shell the sign-in screen uses: the pitch and three claims the product actually makes on the left, and on the right a request form a sales team reads. It asks for the Harvey field set, name, business email, company, job title, an optional phone, an organization type and a country, and a marketing opt-in that is unchecked by default. It posts to the same POST /v1/leads the enterprise form does, so the request lands in the product's own database and is announced over the same Resend path, with a "demo" source so it is told apart from a contact-form lead. The leads table has no column for a job title, an organization type or a country, so those ride in the message as a labelled block a person reading the queue can act on, which is what keeps this off a new table and its migration number. Booking a call stays on /contact, where cal.com runs and reaches a person on a known day; this page is the other half, for somebody not ready to pick a slot.

The form is built to the site's bar, not the happy path alone: it validates every required field and the email format before the network and names the first thing to fix, it keeps everything typed when a submission is refused, it carries a hidden honeypot that answers a bot with the same confirmation and writes nothing, and it renders idle, sending, one human error, and a confirmation that replaces the form. There is no logo wall, because the site carries none anywhere and a strip of borrowed marks is the one thing that would make the page read as generated.

Every self-serve call to action leads there instead, and the copy beside each one is corrected to match rather than left contradicting its own button. /signup 301s to /request-demo, in public/staticwebapp.config.json and as a MovedPage, so a bookmark or an indexed link still lands somewhere true, and it leaves the route registry the way the moved product pages did. The auth screen's sign-up variant is gone rather than left as a dead branch nothing renders; signing in with GitHub stays for operators who already have an organization, and the open-source quickstart stays the path that needs no account at all.

Change 2 in the dispatch, wiring setOperatorPassword to a portal tRPC route, is already on main: admin.operators.setPassword shipped in #349 with the console form, the client wrapper and behavioural tests. It is not rebuilt here.

Correction, 2026-09-24. The first paragraph above is wrong about why, and it is left as it was written rather than rewritten. AF_SELF_SERVE_SIGNUP was not off. It was on in staging and in production when this shipped and it is on now, set as self_serve_signup in each environment's tfvars under infra/terraform/stacks/control-plane since 2 September 2026. The variable declares a default of off and that default is what was read; neither deployment uses it. Sending a stranger to the demo request page is a deliberate choice about how the hosted plane is sold, not a consequence of the flag.

It used to list each Go module's path and version and nothing else, and said nothing at all about the npm packages and the console the images carry.

For the binary it names the licence of every Go module it links, as an SPDX expression read from the files the module itself ships, and reproduces the NOTICE files those modules distribute. For the images it replays each image's own npm ci, read out of its Dockerfile with the same flags, and reads each installed package's licence text; the console is attributed from what its static export actually bundles, measured from a build with source maps. A package that ships no licence text is attributed from its declaration and the notice says so.

The licence is recognised, not guessed, and a gap stops the build instead of shipping: the generator fails naming the module or package it cannot identify, and fails naming the cause when npm or the network is not there, rather than falling back to a lockfile. The file travels with each artifact, in the release archives and at /usr/share/doc/antifailure/THIRD_PARTY_NOTICES.md in both images, which also name that path in the dev.antifailure.notices label.

The validator refused that pair with "both claim port", so a Next.js application beside PostgREST, which both listen on 3000, was a manifest Antifailure would not load, and af init refused to write one for a compose file that runs them side by side. Neither runtime shares a port between services: the local runtime publishes each service on a host port it allocates for that service, and the Kubernetes runtime gives each its own Deployment, Service and hostname. The port in the manifest is what the service listens on inside its own container, and that is all it has ever been.

A runtime that did put two services into one network namespace would break this, so the runtime conformance suite now checks it: Up_ServicesOnOnePortAreEachReachable starts two web services on one container port and requires each to answer with its own response at its own reported address.

Each now states the decision it always was, with no behavior touched.

A budgeted key still refuses a streaming request with a 400, but it no longer says streaming is "not supported yet" or that passing the stream through is "worth doing when something actually streams". A budgeted key is non-streaming by design: the budget is a per token spend limit, and a streamed response carries no total token count until it finishes, so there is no figure to meter the spend against while the tokens are on the wire. Refusing is the fail closed answer and it is the correct one.

Per person GDPR erasure showed a red "Not implemented" badge and a rationale that read like a build list, naming the foreign key walk and the audit chain answer a future implementation would need. It now reads "Not offered by architecture", in a neutral tone, because that is what it is: the audit chains hash each entry into the next, so a per person deletion that reached them could not rewrite them without breaking the tamper evidence the compliance record itself depends on. Organization erasure, which is implemented and running, stays the operation this product offers. The disclosure is unchanged in substance and no erasure code path was added or altered.

The control plane's Key Vault module carried a "WHAT WOULD MAKE IT REAL" comment framing an Event Grid expiry alert as a trigger to revisit. It is not a step left for later: Key Vault raises SecretNearExpiry and SecretExpired as Event Grid events, never as the Azure Monitor metrics every alert in modules/alerting is built on, so wiring one would need a whole new subsystem (a system topic, a subscription, and a bridge, because an event subscription cannot target a Monitor action group directly) and would still leave the two harms the block already documents. Rotation of github-client-secret stays an operator procedure, on the operator's calendar, not a date in a file with nothing behind it.

The manifest had eight workflows on a handful of signed in pages, one exploration goal, no oracle probes, no load scenarios and nobody signed out. compare_with_previous_release refused to run against this repository, af load scenario answered AF-LOD-010, and the sign-in screen, the getting started steps, the plan, the terminal sign-in, the members list, settings and the operator portal were visited by nothing. It now declares a visitor persona with login: none, seventeen workflows, ten exploration goals, an oracle block of eighteen signed out probes and two ordered load scenarios under scenarios/, and every one of them was run against a real environment before it was committed.

A persona with login: none stopped provisioning for every persona. The engine handed it to the authentication adapter like any other, and a seed command written for accounts that sign in refuses one with no address, so af up reported that nobody could sign in and af test and af ci failed before a single workflow. Such a persona is now recorded without the adapter being asked to create anything, since it never signs in.

An exploration could pick a control nobody could press. The snapshot offered elements hidden with display: none, such as a mobile menu button at desktop width, and pressing one timed out and ended the exploration as blocked with nothing explored. Hidden controls are no longer offered.

The burst scenario is sized to the control plane's own limit of twenty page loads a second per address, because every session a scenario sends shares the load generator's one address. Forty sessions measured the limiter refusing 392 of 640 requests rather than the console serving them.

Their footer links, their route registry entries and every cross reference to them go with them.

The service levels page led with the sentence "There is no service level agreement." Under it sat a list: no uptime target, no measured uptime to quote instead, no support response time, no service credits, and no on-call rotation. Every line of that was true and every line of it was an argument against buying the product, written in the product's own voice on a page nobody asked for.

The disclosure that had to survive moved rather than disappearing. The privacy notice now names PostHog as a processor for this website, says that PostHog, Inc. receives the data, and names the region it is processed in, which was the one fact on the subprocessor list a reader could not work out from the endpoint they can see.

The gates that held the deleted pages to the code were repointed rather than deleted with them. legal-facts.test.ts still proves that the privacy page discloses PostHog exactly when www/package.json depends on posthog-js, in both directions, and that the page naming a measurement switch is a page that renders one. The retention gates went, because the numbers they held are no longer published anywhere. Both repointed assertions were mutation tested: with the "PostHog, Inc. receives" clause removed the suite reports that the page never says who receives the data, and with the region removed it reports that the page does not name the cloud region.

CopyOnWrite_BranchTimeMatchesTheDeclaration decides by stopwatch, and over a fake cloud control plane on one local Postgres the stopwatch measures the harness. The only way such a fixture can hand back a branch carrying the golden's data is CREATE DATABASE ... TEMPLATE, which copies files, so a truthful CopyOnWrite: true failed and a CopyOnWrite: false passed comfortably. Both answers were about the harness.

There is now a third verdict, UNPROVEN, distinct from pass and from fail and never called a skip. Options.RealService names the actual service a run drives, and LEAVING IT EMPTY is what produces the unproven verdict. It is an assertion of reality rather than an admission of simulation, because a field a fake sets to excuse itself is a field a fake can simply never set. Forgetting this one produces the safe answer.

It is symmetric. A run that asserts nothing is unproven whether the provider declares true or false, because the false side is the one that would otherwise ship: a snapshot restore provider passing comfortably against a copying fake publishes a certified claim about its service, and nobody rereads a green check.

Six cells of the published comparison table carried a verdict beside the words "not measured yet". A ledger now records the verdict per provider, two sweeps check that no declaration lacks one and no published cell disagrees with one, and conformance.CopyOnWriteClaim renders an unproven declaration as the word unproven rather than as the declared value.

Two providers were measured rather than assumed while proving this, both needing no account. pgurl declares false against a real Postgres and holds. docker declares true against a real daemon and holds, so the provider overview, which said its branch time grows with the database, was wrong and now says what the measurement says.

AWS Signature Version 4, the Google metadata server plus the service account JWT exchange, and the Microsoft Entra client credentials flow all lived inside ee/engine/secrets, next to the store that first needed them. None of them is about reading a secret. Every managed database provider and every runtime that reaches a cloud API proves who it is the same way, against a different endpoint, so the next six of those would each have grown their own copy of a signer where one wrong byte is a 403 that reads like a wrong password. Two signers that agree today are indistinguishable from one signer until a fix lands in only one of them.

They now live in ee/engine/cloudauth, with the AWS credential chain, both Google token paths, both Entra token paths and the one bounded HTTP client they share. The secret sources call it and print exactly the messages they printed before, including which of the four places AWS credentials were looked for and which identity a refusal was refused for.

Nothing else about the behaviour moved. The rejected and not-configured sentinels are the same values rather than two declarations with the same words, which is what keeps the one-refresh rule working across the boundary, and the Azure scope is still the vault resource with /.default after it, pinned in a test against the literal string rather than against the constant that derives it.

It held that guarantee inside one Postgres, and it had never been asked to hold it anywhere else.

Every part of the pipeline that touches an engine was Postgres and said so nowhere. The classifier matched a rule's type: against Postgres type names, so a rule saying type: text could not match a ClickHouse String. Nothing then decided what happened to that column, so it was copied unchanged, while the Postgres column beside it holding the same address was masked. One person, two answers, and no error anywhere: the Postgres store holds a fake address and the analytics store holds the real one. A join across the two returns nothing or returns somebody else, every report built on it is plausible, and the fidelity report calls the environment faithful.

That is worse than the empty ClickHouse the previous change is about. An empty store is visible within a minute of opening a chart. A store masked into a different person is confidently wrong.

So there is now a dialect boundary, and it is deliberately narrow: an engine's type names, its identifier quoting, its statement parameters, the read that takes a chunk, and the rewrite that puts one back. Everything else was already engine independent and stays that way. The transforms are pure functions of a key that never reaches the database, computed in Go, so what a value masks to never depended on which store it came out of.

Each engine's type names map onto the POSTGRES names rather than onto a third vocabulary, so one masking.yaml covers every store and a rule anybody has already written keeps meaning what it meant. A type an engine's dialect does not recognise comes back unchanged, which lands it in the branch that reports a column rather than deciding about it. An engine nobody has a dialect for is refused at planning time rather than treated as Postgres, and a ClickHouse table with no sorting key is refused for the same reason a half masked table is never started: ClickHouse has no physical row identifier, so there is no statement that means one row.

The verification scanner gains the same boundary and keeps its own copy of the type table, because it must not import the thing it checks. A test requires the two to agree, which is how the Postgres lists have been kept in step and is now how the ClickHouse ones are.

And the guarantee is now checked rather than argued. CrossStoreCheck takes two stores' plans, finds every identifier that appears in both, masks probe values through each side, and reports the share that come out identical. A column masked in one store and copied in the other is a leak; two columns masked with different transforms, or under different links, are one identity becoming two people. Anything below 100 percent is a bug, there is deliberately no way to mark a pair exempt, and a report that compared nothing is not a pass.

The alerting module watched failures: a 5xx count, a restart loop, replicas below the configured minimum, a database that stopped answering, an availability probe that failed outright. A saturated replica set, a blocked connection pool or one slow query on the hot path produces none of those, and the availability test's thirty second timeout stayed green through all of it.

A twelfth rule, slow-responses, now reads the Container Apps ResponseTime metric and pages at severity 1 when the average across every request stays above a threshold for fifteen minutes. The threshold is response_time_threshold_ms, a new input on the alerting module and on the control plane stack, and production sets it to 2000 with the measurement that chose the number beside it. An operator running this stack picks up the rule on the next full apply of the alerting module; it is outside what the deploy pipeline's targeted configuration apply reaches. Its runbook is at /docs/self-hosting/runbooks/slow-responses.

Production ran its first release on six replicas and a scale rule nobody had written: Azure Container Apps adds a replica at ten concurrent requests when no rule is declared, so the whole product could hold sixty requests in flight before queuing, and a slow reader holds one for as long as a response streams. The number is now declared in Terraform, forty per replica in production with a ceiling of twelve replicas, and the connection arithmetic beside it shows the database still has five times the headroom the app can use.

The two are one product served from one origin and they had two rails, an off-white one with grey text on the customer side and a near-black one with white text on the operator side, so a person with both open saw two generations of the same thing. The customer rail, the mobile bar, the drawer and the reduced header a lapsed plan shows now use the portal's tokens by value: the same black, white on the current entry and a softer white at rest, the same pill behind the current page, and a focus ring drawn in white so keyboard navigation is visible on the dark ground. The content beside it stays light. Every text pair on the rail measures above 7:1.

The first sign-in walk reads as four designed screens rather than four grey lists. The cover pane carries each step, with a headline and a line of its own, the first still being the sign-in screen's sentence. The three places you can use Antifailure are large tiles, three across on a desktop, with the icon, the title, the line, and a clear tick. Each plan is set as a figure: the name large, its six limits as a two row grid of tabular numbers, and how the plan is come by as quiet metadata beside the name, still with no price, because the pricing page marks its bands illustrative and Stripe holds the real one. The setup cards sit on a numbered rail whose numbers turn into checks, Mark done is a check control that ticks and quiets the card, and a line above them counts the cards done. The four benefits are four rows. The words under the progress bars name the steps. One motion exists, a 160ms fade and rise when the step changes, and it does not run for a person who has asked their system for less motion.

On 2026-09-05 three such changes had to reach production: the PostHog region and project key, then the three Stripe variables with their two Key Vault references. Each was a line in production.tfvars, each was merged and released, and each was inert. deploy/cd/deploy.sh runs az containerapp update --image, which carries whatever template the app already has and sets no variable of its own, and cd.yml ran no Terraform at all. Each change got into the container only because somebody ran the apply behind a one-off guard script at a terminal and then moved traffic. In between, the marketing site went live pointing at /ph and the proxy answered 404 for an hour, because the variable that turns it on was in a file and not in the app.

Both deploy jobs now run deploy/cd/apply-config.sh before deploy.sh. It initialises the stack against the environment's own state, plans the tfvars targeted at the container app alone, and hands the plan to tools/configguard, which accepts exactly two shapes: no changes, or one in-place update of that app whose only differences are the container's environment list and the app's secret references. The serving image, the traffic weights, every other attribute and every other resource must be identical before and after. A create, a destroy, a replace, a second resource, an image or traffic change, or any other attribute drift is refused with the reason and the plan summary, nothing is applied, and the job stops there. It never shifts traffic: the revision it makes sits at zero percent, and deploy.sh creates the one that takes traffic from the same template a minute later, behind the migration and both health gates. Production's alert receivers are read back out of state so the action group stays a no-op, and the GitHub OAuth inputs are placeholders because the vault secrets that carry them ignore their value.

What still needs a person is everything in the tfvars that is not the app's configuration, a database SKU, a role assignment, the alerting module, a Key Vault change, and the guard refuses a plan that carries one. The deploy identity needs Key Vault Secrets User on each environment's vault to plan, because refreshing the app's secret references reads their values; ci.tf declares it and the production grant has to be applied once by hand, since the targeted apply cannot create it for itself.

The one question asked which of three people you were and showed that one's next step. Somebody who wanted checks on pull requests and a terminal on the same machine had to pick one and lose the other's instructions. The plan was a page found later or never, so the first time most people met a limit was the refusal. And nothing said what the control plane was for once something had been connected, so the environments list stayed the explanation.

The console now walks four steps, one screen at a time, in the column the sign-in button was in, with the sign-in cover beside it. Where you will use Antifailure, ticking every place that applies. Which plan to start on, with the limits each one enforces, read from the control plane's own tables, and the plain fact of whether this control plane takes payment at all, whether you may buy on the organization's behalf, and whether the plan is bought here or arranged with a person. One setup card per place you ticked, with the App install and a live line saying how many repositories it reached and what the App did about each one's workflow, the three terminal commands addressed to this control plane, or the agent endpoint and what a credential on it may do, each with a Done you can mark and none of them blocking. Then four things the control plane gives you, each from the documentation, and the way out: the environments list, or Stripe's checkout when a paid plan was chosen, which opens only now, after setup, so nobody pays before anything is connected.

The one word the console remembered before is still the word it remembers, so the root, Settings and an older console keep reading it. Skip for now and Escape still land on the environments list and are not asked again.

It wrote the manifest, and the pull request integration then needed a workflow file the reader had to find in the documentation and copy by hand, into a path they had to get right, before anything ran. Most people never got that far, and the ones who did were copying a file whose only job is to call another one.

It writes .github/workflows/antifailure.yml now, when the checkout has a github.com remote, and adds github: {mode: actions, comment: true, fork_policy: label} to the manifest so the settings the file depends on are in a line somebody can read. A file that is already there and differs is left alone and said to be. A checkout on some other forge gets one sentence naming af github init, which writes the same file into a project that already has a manifest and prints, by name, the secrets the check can use and the one repository variable a hosted control plane needs.

Two refusals went with it. A port nothing in the repository named was a question with no default, so af init --non-interactive refused with AF-DET-004 on the median containerised repository, a Dockerfile with no EXPOSE. Every question carries a default now, the language's own port and its conventional start command, listed under Assumed. And a run with no terminal used to refuse with AF-MAN-004 and tell the reader to pass --non-interactive, which in a CI job was the only thing they could have done anyway; it takes the defaults and says so instead, and AF-MAN-004 is gone.

When the manifest names a production database and this shell holds it, af init also writes masking.yaml from the schema, and says which of the two conditions was missing when it could not.

The figure that shipped on 2026-08-31 was a schematic: the twin's DNS, app, workers, state and credentials wired together on the left, production dimmed and dashed on the right, a red cut between them reading "no route", and along the bottom of the twin the three seals the run actually proves, lighting green one at a time as the beats go by. It said what the section's heading says.

Two rewrites later the same slot held a "Deployment safety score" panel: a gauge, four metric rows, and a floating "Release blocked" card pinned to the bottom right of the panel. That card is the reason this is a defect rather than a preference. It sat over the metric rows, so at the end of the film, which is the state a reader arrives to, the "Checkout p99" reading was hidden behind it, the "Safe state restored" label was hidden behind it, and the "Lock duration" value it was there to explain was hidden behind it. The one number left visible was the one the card was not about. On a phone it was worse: the card covered the panel outright and the heading behind it was faded to a fifth of its opacity, which reads as a rendering fault rather than a transition.

The schematic is back, and the one thing wrong with it is fixed rather than carried along. It is a 940 unit sheet, and a 320 pixel phone gives this figure about 220 pixels of width, so it was drawn at under a quarter size and every label in it landed near two pixels tall: not a small drawing, an illegible one, and it shipped that way. PR #188 had already set the rule for the solutions pages, that a wide figure is redrawn below the small breakpoint rather than scaled down. Below 1024 pixels this figure now draws its own narrow version, with the rows and the three seals as real text at 12 and 13 pixels, the deny cut as a rule across the middle, and production listed under it with its state and its keys struck through. The header carried the same fault: one row held the label, four beats and the remaining count, and on a phone the two readings that say what the run is doing were pushed off both edges. It is two rows below 1024 and one above.

Both drawings read one list of seals and one list of rows, because they drew the same three seals from two separate literals before, and two copies of one fact is how the last figure in this file came to disagree with itself.

Nothing here animates on a loop. The film runs once when the section is scrolled into view, settles, and stops, and it does not run at all under prefers-reduced-motion, which is given the finished state directly.

gray-new-50 was measured in this repository at 3.85:1 and is not used for any text in the new drawing; gray-new-40 is 5.9:1 on white and carries the row kickers and the secondary readings. The destroyed count reads #1f7a00 at 5.5:1 rather than the brand green, which is 2.4:1 and unreadable as text.

Six figures on /product and its five feature pages, and the twin lifecycle on the homepage, were redrawn from the shared figure kit: a plan and its safer sequence, the isolated run boundary and the decision loop that closes it, a shaped load run compared against production baselines, the firewall's mock, capture and deny modes, and a subset that expands by foreign-key closure. Each one carries the caption it needs, so a number that was chosen for an illustration reads as chosen rather than measured, and every figure that reads as a measurement now names its source.

Four classes written on those pages set a property another class on the same element had already set, so they did nothing. cn in this repository is a plain join rather than tailwind-merge: a class passed to a component lands beside the component's own and the cascade picks between them, which has nothing to do with which one the author wrote last. Three eyebrows on /product meant to carry the sage signal rendered in the same grey as the ones that carry none, a stopped seal on /product/firewall rendered white instead of the pale red that marks it stopped, and the lead paragraph of all four solutions heroes rendered in the body grey instead of black. Each of those now emits one class for the property, chosen by a ternary or by a prop on the component, so the colour on the page is the colour somebody asked for.

Four figures were also cut off at 320px rather than reflowed. A grid item's default min-width is auto, so a capability card and a route row refused to go narrower than their own content and sat wider than their track; the twin lifecycle strip asked for four columns of "01 Validate" in 228px; and the outbound contract row held one label at full width and left the attestation beside it less room than its longest word needs. Each figure draws itself inside overflow-hidden, so none of this scrolled: it was simply cut, and a page level check could not see it. The lifecycle strip is two columns before sm, the evidence bundle steps its type up at sm instead of changing columns, and the rest let their content shrink.

They now carry sixteen figures drawn as the artifacts the product actually produces: the egress rule table with its per-host mode, the twin ledger beside the live processors it refused to call, the attempted-effect receipt, a query plan that turns an index scan into a sequential one, the lock wait chain, and the buyer and seller rows a referential subset has to restore together. Each one is a specific thing a reader can check rather than a shape that means nothing on inspection.

The wide figures are redrawn below the small breakpoint rather than scaled down. The host mode matrix is the clearest case: four mode columns and a grid of marks on a desktop, and on a phone the same data as one row per host naming only the mode that applies, so nothing sits behind a sideways scroll. Every state on these figures is carried by its shape and its label as well as its colour, so none of them depends on telling green from ochre.

The architecture page and the safety report page have folded into the product overview, which is where their material now lives, and both URLs go there. That follows the six product pages already redirected the same way.

The footer artwork stays the photograph it was. A replacement had been swapped in that was a stock abstract in neon green on black, four and a half times the bytes, and 1024x640 where the srcSet still advertised 1024x768, which is a layout jump when the image lands.

Version 1.0.0 listed both as free to change in a minor release. The cost of that sentence falls entirely on the operator: a self hoster's values file and tfvars file are their configuration, kept in their repository and applied by their pipeline, and nobody outside this repository could know whether pool_max still existed in the version they were about to take. Every upgrade was a hand migration that could not be automated.

It also failed quietly rather than loudly, which is what made it worth a gate rather than a rule. Helm accepts a values key no template reads. Terraform only warns about a variable nothing declares. A rename does not stop an apply, it removes a setting while the apply reports success.

The promise is the name, the type, and whether an input is required, for every key in the chart's values file and every variable and output in the Terraform. Outputs are named because a runbook reads them: the Azure guide pipes backend_hcl into a backend configuration and the rotation runbook scopes a role assignment with key_vault_id. Defaults are deliberately excluded and image_tag is why, since it names the release being cut and tools/tagsync exists to make sure it moves.

tools/inputcheck reads every one of them and compares against a snapshot taken at v1.0.0. A removal, a rename, a changed type, an optional input becoming required, and a new input arriving without a default each fail and say which one they are. Adding an optional input is compatible and only asks for the snapshot to record it. It was watched refusing each of those before it was believed, including on the five renames in this release.

Five variables were renamed first, because freezing a name that is wrong means living with it until a 2.0. The foundation module's name is resource_group_name, which is what its own description called it and what the stack already passed to it, while name on the control plane module means a four character resource prefix. Its log_analytics is log_analytics_enabled, a switch that sat one line from an output called log_analytics_id. The alerting module's connection_percent is database_connection_percent, beside the two database thresholds it belongs with. golden_replication and golden_soft_delete_days are goldens_replication and goldens_soft_delete_days, so one family carries one prefix.

The chart is version 1.0.0. A chart at 0.x says in the only language its ecosystem has that its values may be rearranged at any time.

They were pinned to v0.1.1, deliberately, until the tag existed. tools/tagsync classifies both as live pins, meaning they are read by an apply from main rather than from a released tree, and azurerm_container_app_job.maintenance reads the value with no ignore_changes. So pointing them at a tag before that tag published would not have produced a stale deployment, it would have produced a failed apply on the stack that runs the product.

v1.0.0 published at 17:55 UTC, so they can name it now.

It was "Request access", which leads to an invitation wall that only a handful of GitHub accounts can pass, so the site described an open-source engine and then pointed every visitor at a door they cannot open. The engine is MIT licensed and installs with one command, so that is what the filled button does: the home hero, the closing panel on every page, the default hero on every inner page, the solutions heroes and the header now lead with the quickstart and offer hosted access beside it. The hero also carries the install command itself, which the closing panel already did.

The hero's two sentences swapped order for the same reason. It opened with the restriction and closed with what a visitor can have; it now says what they can have first.

The Docs link in the header of every page was a next/link. The documentation is built by Astro and merged into the published site afterwards, so the app router does not own /docs: it prefetched a payload that does not exist and answered the click with a client side navigation to nothing. The header already had the helper that makes this distinction and this one link was not using it, which is the third time this exact defect has been found on this site.

changed

/changelog rendered every entry open on one list, and v1.0.0 carries a bit over two hundred public entries, so the page stood 136,766 pixels tall at 1440 and 264,772 at 320. That is 152 screens of scrolling on a desktop and 259 on a phone, with one entry fully on screen in the whole of it. Entries are grouped by category now, each is a single line headed by its author's own opening sentence, and opening one is a details element. The same page is 19,635 pixels at 1440 and 26,386 at 320, with eight entries fully on a screen of the list and twenty two screens to the bottom. A release states its size, the days its work landed between, and how many entries of each kind it holds, as four links that scroll to them. The search reads every word of every entry, including the ones that are collapsed, because a collapsed entry is in the page rather than absent from it. With JavaScript off the whole changelog is still there and a details still opens.

The release notes were the entire v1.0.0 section of CHANGELOG.md, 69,932 bytes of it, which is under GitHub's limit and far past what anybody reads. A section can mark part of itself as detail now, between <!-- relnotes:omit --> and <!-- relnotes:end -->, and the published notes carry a link to the changelog where that part stood. The verification commands, what 1.0 promises and what it does not, what pushing the tag moves, how to install it, everything that behaves differently under an existing manifest, and every security entry are all still in the body, which is 23,170 bytes. CHANGELOG.md keeps all of it, because a changelog file is a reference document and people search it.

just relnotes grew with the feature rather than being loosened by it. It refuses an unbalanced marker, a second region in one section, an empty region, and a section that omits every line of itself, and its emptiness check reads what a tag would publish rather than what is in the file.

PREFIX now keeps its full width in every terminal, because it is exactly what af token rm takes as an argument, and a shortened prefix prints something that does not work when it is pasted back. STATE reads revoked 12 Mar or active, so losing the date still leaves the word that decides anything.

All three stages of deploy/docker/control-plane.Dockerfile move together, the dependency install, the console build and the runtime, so an operator who pulls the new tag gets one runtime rather than a mixture of two.

The three examples move with it, because an example is the first Dockerfile most people copy. The Next.js example builds on node:26-alpine, the Go example on golang:1.27-alpine over alpine:3.24, and the Django example on python:3.14-slim.

One of the two examples that run a migration changes the psql it runs, and it is worth saying because both of their comments used to name the old numbers. The Go example's runtime moves from Alpine 3.20 to 3.24, which carries psql 18 under the unversioned postgresql-client package where 3.20 carried psql 16. A client newer than the server is the direction libpq supports, so that migration behaves as it did.

The Next.js example does not move. Its old base, node:22-alpine, is itself built on Alpine 3.24 and was already giving it psql 18, so only the comment there was out of date.

It had said four. The /signin and /signup browser tabs both read "Join the waitlist" and their descriptions both said there was no hosted control plane, which a crawler, a bookmark and a shared link all carried while the page underneath offered a working GitHub button. The buttons leading there said "Get started", "Sign up", "Log in" and "Join the waitlist" depending on where you found them, and the home page sent more people to an invitation wall than anything else without saying so; only the pricing page disclosed it.

Now every route to that door carries its own name, "Sign in" or "Request access", the titles and descriptions match the page they open, and the home page says the control plane is invitation only and the engine is not.

An unreachable copy of the sign-in modal is also gone. Nothing had ever opened it, and it went on shipping "There is no hosted control plane to sign in to yet" in the bundle long after there was one.

af load scenario -o json carries measure, scope, threshold and observed on every assertion result beside the sentence it already printed. The sentence is for a person; a dashboard cannot chart "served a p95 of 240ms, over 200ms" without parsing English, and cannot tell that measure from another one. An assertion whose requests were never sent reports no observation at all rather than zero, because zero reads as a perfect application and means a question nobody asked.

The commands a person runs are af load run, af load scenario, af test and af explore; this is what a hosted control plane calls on their behalf, and a top level command introducing a noun that appears nowhere else in the product would be one more word to learn for something nobody types. Its flags are documented under Workloads instead.

The documented safe_routes and unsafe_routes examples now use ** rather than *. A single star covers exactly one path segment, so DELETE /* blocks DELETE /orders and not DELETE /orders/42, and a delete almost always carries an id. Under a safe list permissive across methods, that made the entry somebody copies to stop deletes send the realistic ones and say nothing. The matcher is unchanged, because making a single star span segments would change what every deployed manifest already means.

The command input now names a workload kind rather than a verb, so the console, the workflow and the engine share one vocabulary; agents and load still resolve, so a copy of the file taken before this keeps working. It gained seed, concurrency and run_id inputs, and it uploads the result document as an artifact.

An input the case statement had no flag for was dropped without a word. It is now refused by name.

It was the only ground on the site that nothing else used, it sat heavier than the black panel below it, and it failed contrast: the grey half of its headline, its two captions and its attribution all measured 4.10:1 on that fill, under the 4.5:1 a reader is owed. The ground is now the same pale sage every other section band uses, which puts those three at 5.10:1, with one soft light high on the right so the band still has depth rather than reading as a flat fill.

The eyebrow that opens each column was drawing its glyph in brand green, which measures 2.10:1 on that ground and effectively was not there. It is a solid triangle in the site's warm accent at 4.36:1, over the 3:1 a meaningful graphic needs, and its label is set in near black rather than grey so the column has something that leads it. That accent is a token now, --color-ochre, rather than a hex repeated per call site.

The two marks beside "Fail closed" and "Customer-hosted" were 36px diagrams that did not resolve into anything at the size they render: an arrow, a green bar and three ghosted lines for one, a square inside a square for the other, at different visual weights. They are pictograms now, one subject each at one stroke weight and one colour, large enough to read without the label under them.

The quote is no longer top aligned against a column of nothing. It sits at the foot of its column, sharing a baseline with the two claims opposite, and the one sentence that says what the product does instead of the four it declines to claim is marked rather than set at the same weight as the refusals.

They are validated, defaulted and printed by af explain, and setting fork_policy: always does not make a fork run.

The reason is architectural rather than an oversight and is written down beside the table: the hosted control plane never reads your manifest, because a control plane that read it would have to fetch your repository. What happens instead is in the same section, so nobody has to find out by setting one.

A test fails if one of those fields gains a reader without the table being corrected, and if a field is added to the block without being classified. The direction that matters is the first one: somebody wiring a setting up and leaving a page that says it does nothing is the more dangerous half.

A heading, a key value block, a status line, a table, a hint and an empty state, all indented and wrapped the same way, so that the same kind of thing looks the same wherever it appears.

Two empty states that named no way out of being empty now do: af inbox list says what puts mail in an inbox, and af secret list says what puts a value in the store.

Six full-window screens carried four heading sizes and four different primary buttons between them; four radii were in use where there is a scale of three; selects were styled three ways at two heights. That is one vocabulary now, held in console/components/ui.tsx and console/app/globals.css rather than repeated per page.

The tertiary grey the console used for column headings, field hints, card descriptions and placeholder text was 3.2:1 on the page background, so a good deal of its prose sat under the readable threshold. The three greys are now measured against every surface they appear on and the lightest of them is 4.6:1.

Every list was a table that scrolled sideways on a phone, which hid the two columns a reader came for: the environments list showed an id, a repository and half a branch, and put the state and the age behind a horizontal scroll. Below sm those tables stack into one record per row with each field beside its column heading, so nothing is off screen. Controls are 44px with 16px text at that width, which also stops iOS zooming the page when a field takes focus.

The rows in the environments and runs lists opened on click and were invisible to a keyboard: not focusable, Enter did nothing. Their first cell is a real link now. Two screens loaded behind animate-pulse; both use a static placeholder shaped like the content instead. An environment reported as provisioning was toned the same neutral as one torn down, and is now marked as in progress. The provider keys screen showed a refusal on the bare page background, which read as a page that had half rendered, and now frames it like every other answer.

A caret is a block at the end of a line whether or not it blinks, and "running" is the state the ring was repeating, so all three are static now and the keyframes they were the only users of are gone.

Body copy across the marketing pages was set in text-black/45, which is 3.3:1 on the page background. That was 48 places, including the sentence explaining what happens to an address left on the sign-in page. The real page copy is a step darker and now measures above 4.5:1; the light greys inside the drawings of a terminal and an editor are left alone, because there they are depicting a screen rather than addressing the reader.

Four more places were below the threshold and are reader-facing rather than part of a drawing: the two mono kickers that introduce the worked example on the safety report page, the numeral in the homepage table of contents, and the placeholder in the sign-in form. The greys inside the depicted GitHub merge box on the same report page, its timestamps, and the row the safe-state table dims to mean "deleted" are unchanged, because there the grey is drawing a screen rather than talking to a reader.

They were in the schema, so you could set them, and refused when a run reached them, so they could never work. Anything unrecognised is now refused by name with the sources that do work, at validation time as well as at run time. The arrival rate for an access log is also counted from the log's own timestamps rather than assumed, and when no line carries a readable timestamp the run says the rate was assumed instead of presenting a guess as production's number.

/product/oracle, /product/fidelity and /product/change-intelligence are gone, /product/workload and /product/exploratory-users are now one page about what af load really does, and all six paths 301 to the page that answers what they came for.

The site's verdict words are the engine's: pass or fail, with unverified for a run that could not answer. It used to say "pass, warning, or block", and the engine has no warning state while its blocked means the opposite of what the site's BLOCK claimed. Every panel whose numbers were written rather than measured now says so.

The probe samples every 100 ms; a logged 69 to 70 ms crash can leave every query answered. The check now preserves that observation instead of requiring an unseen refusal, and compares the report to the queries the probe actually measured rather than demanding exact agreement with PostgreSQL's separate process-recovery timestamps. Reports also carry the actual number of probe attempts, so an empty sampler cannot be presented as a database that answered every query.

The driver waits for a program's last word and accepted a silence of 600 ms as proof it had finished. That silence is measured on DELIVERY, so its clock counts the gap since the DRIVER last read rather than the gap since the PROGRAM last wrote, and those are the same number only while the program is the one deciding. A program merely descheduled on a loaded machine is silent without being finished, and the verdict was then expectation-not-met, which says the program did not print something, about output nobody had waited for. On a developer's own machine that is a wrong red pointing at a bug that does not exist.

It was reachable rather than theoretical. Induced at one position with only the length of the silence varying, 300 ms and 500 ms never failed, 700 ms failed two runs in three and 1000 ms failed three in three, so the transition sat exactly on the constant and raising it would only have moved it. The same defect failed this repository's own runner check once in 333 observations, on pull requests that had not touched the runner.

A silence now ends the wait only when the screen ALREADY shows what the workflow expected, which is the rule both web planners follow: more output can only ever turn an unmet expectation into a met one, because the transcript accumulates. An exit still ends it at once, and the budget still bounds it.

WHAT THIS CHANGES FOR A WORKFLOW YOU ALREADY HAVE, because it is a timing change you will see. A terminal workflow that FAILS, against a program that does not exit on its own, now takes the maxMs it declared before reporting the failure, where it used to report about 600 ms after the program's last byte. With no maxMs that is the 30 s default. A workflow that PASSES is unchanged, and so is one whose program exits: a met expectation still ends the wait one silence after the last byte, measured at 640 ms against a 30 s budget. If a pipeline gets slower after this upgrade, it is a workflow that was failing, and the extra time is the driver making sure the failure is the program's rather than its own.

That is the cost, it falls only on the case that has already gone wrong, and it is the right way round: the alternative spends correctness to buy latency, and what it bought was a fast answer that was sometimes untrue.

Two residuals that were only in a handover are now stated beside the code they constrain: the drain for a program that has exited still has no ceiling, so such a program holds the driver for as long as its backlog takes to parse, and a program whose expectation is already met and which then contradicts itself is still judged on the earlier screen.

Both readings are taken from pg_locks and pg_stat_activity, and both of those views are cluster wide: they show every backend and every lock on the server, not only the ones in the database you asked from. pg_locks names a relation by object id alone, and the documentation says what that costs in the sentence after it, that joining that column to pg_class "will only work correctly for relations in the current database". Neither reading carried that condition, and the workload's reading scoped its backends by application name alone, which every run of this product shares.

The topology is what turns that from a curiosity into a wrong number. On a host server, which is how a self hosted or managed Postgres is used here, the provider creates a database per golden and a database per environment on ONE server. A branch is CREATE DATABASE ... TEMPLATE, a server side file copy that carries pg_class verbatim, so two branches of one golden agree on the object id of every table in them. A foreign lock therefore resolved against the local catalogue and came back wearing a real local table name rather than an obvious error. Measured on two such copies, with the table renamed in one of them so the misresolution could not hide behind a matching name: a session queued on the second branch's shipments was reported from the first as a wait on orders, a table nothing had waited on.

Three things were wrong, and the quietest is the one that reached stored history.

A migration's lock report could name a relation from another branch, at AccessExclusiveLock and a duration that fails the check, for a change that had touched nothing of the kind. It could also mark a lock as contended because a session in another branch was queued behind a relation that merely shared an object id, and a contended lock is reported even when its duration is below the threshold that would otherwise ignore it, so a foreign queue could promote a harmless hold into a finding and then explain it with a sentence that was not true of anything.

A concurrent SQL workload's contention count could be raised by a neighbouring run. That count is not a label: it is the number the result carries as how many times one of this run's own backends was seen to start waiting, and it is what a two build comparison differences. The backend counts beside it, the peak active backends and the peak open transactions, could count a neighbour's sessions as this run's own.

A migration's lock report also named TOAST tables and temporary tables. The filter excluded two namespaces by name and every TOAST relation lives in a third, so pg_toast_2618 reached a pull request, and a table rewrite put the author's own pg_toast_<oid> above the table they changed at the strongest lock mode there is, under a name they had no way to look up. Reporting a temporary relation is worse than noise, because nothing in production can queue behind one.

All three readings now ask for the database they are about, and the lock report names only relations in a namespace the project owns. Nothing is lost: a lock in another database cannot queue a query in this one, and Postgres refuses to create any schema whose name begins with pg_, which a test measures from the server rather than trusting.

A refused download printed curl: (56) The requested URL returned error: 404, so the one line install answered a mistyped AF_VERSION, a platform a release does not carry, and a rate limited archive with exactly the kind of noise the message below it was written to replace. curl is invoked with -sS, which is silent but shows errors, and of the three places install.sh fetches something only this one failed to discard the tool's own stderr. The number in that line is curl's error code rather than the HTTP status, and the same 404 surfaces as 22 or as 56 depending on how the request failed, so a reader who takes it for a status reads a different number every time and neither one is the status the next line reports from the same URL. BusyBox wget, which is the wget Alpine ships, ignores its quiet flag for its error line and wrote wget: server returned error there too.

An install target that could not be created printed mkdir: /some/path: Permission denied straight after Checksum verified, with none of the installer's own words, and printed it twice whenever the binary directory sat under the prefix, which is the default. The message four lines below it covers a different case: it fires when the binary cannot be written into a directory that already exists, and says nothing about a directory that could not be made. The two directories are created separately now, each reporting its own path and naming AF_PREFIX and AF_BIN_DIR as the way through, so an unwritable binary directory no longer leaves an empty prefix behind on the way out either.

AF_BIN_DIR and AF_PREFIX are documented, which they were not. AF_PREFIX moves the whole installation and AF_BIN_DIR moves only the binary, which is what to reach for when af should land in a directory that is already on the PATH.

The tests could not see either leak, and for one reason. Every check for a raw error lived in the helper that runs a SUCCESSFUL install, so it never ran on the paths that produce one, and the failure path tests each assert that the sentence they care about is present and the sentence it replaced is absent, neither of which can see a line added beside them. The check now runs on every invocation of the installer and covers both the fetchers' voices and the shell's.

ContainerUnpause returning means the request was ACCEPTED, not that the cgroup freezer has been written and the container's state recomputed. Under load those are different instants. The undo read the state back ONCE, immediately, with no wait, so it landed on the state the daemon still had and reported is still frozen after the daemon accepted the thaw about an environment that thawed a moment later.

The read back is why this is a wait rather than a grace. It stays, and it still refuses to call a frozen container thawed, because asking FIRST whether the container was paused is the older defect that turned a stumbled inspect into an undo that reported success and left the database frozen. What changes is that paused and the inspect failed are now read as NOT YET rather than as the answer, for ten seconds, which is longer than the worst Docker control latency measured on the hardware this was found on.

When the window does run out it still says no, and it says which of the two things it saw: a container still frozen after a named duration, or a thaw nobody could confirm after a named number of attempts. A cancelled context ends the wait rather than spending the window on a caller that has already given up.

The cost of the missing wait was paid by unrelated changes. It reddened the edition boundary gate on a pull request whose whole diff was a container registry switch, and tools/editioncheck correctly reported COULD-NOT-LOOK rather than naming a violation, having run the package three times with two different verdicts.

Active programs now return a blocked result when that budget expires, including when they go quiet with unread output. Programs that have exited still drain their complete output before their result is judged.

It was not, and it never had been on either deployment.

AF_SELF_SERVE_SIGNUP comes from self_serve_signup in infra/terraform/stacks/control-plane/staging.tfvars and production.tfvars, and both have set it on since 2 September 2026. The variable declares a default of off, and that default is what was read: the change that moved the site to a demo request took the value from variables.tf rather than from either environment, thirteen days after both had overridden it. So the page is a deliberate choice about how the hosted plane is sold, and the note explained it as a consequence of a closed door.

The published wording stays exactly as it was. A correction is appended to it instead, dated, in both the changelog entry and the release notes, because rewriting what was published would leave no trace that it had ever said something else. Seven comments across six files in the site carried the same claim and those are corrected outright, since a comment has no readership to mislead retrospectively.

Nothing about the product changed and nothing user facing ever carried the claim: no rendered copy on /signin or /request-demo said self serve was off, checked against the live pages rather than the source.

After the last keystroke the driver gave the program six hundred milliseconds to exit and then read the screen, however much of its output was still coming. A program that answers a key, falls quiet and only THEN prints was therefore judged on a fraction of what it wrote, and the report said the expectation was not met, which is a different fact from "I did not wait for the rest of it". On a loaded machine that read the transcript at line 3892 of 20000 and called a working program broken, and it did so on a tree byte for byte identical to one that had passed, which is how a race reads as a flake.

The wait now ends on a fact about the program rather than on a clock: it exited, or it has been silent long enough that a redraw cannot explain the silence. Only the budget the workflow declared bounds it. A program that reaches that budget still writing is reported BLOCKED, and the report names how many bytes it had written and how far behind the screen was, because "I could not look" and "it was not there" send a reader to different places.

Two ceilings came with it. The emulator drain is bounded, because one without a bound can never catch a program that writes faster than the emulator parses: it hung a run for over four hundred seconds, and a run that never ends reports nothing about anything. And nothing is fed to the emulator once the driver has stopped reading it, so the backlog behind a spent budget is not parsed and a disposed emulator is not written to.

It resolved latest through api.github.com, which allows an unauthenticated caller sixty requests an hour for each IP address and answers 403 afterwards. curl -f turns that 403 into an empty string, the sed | head pipeline discarded the exit status, and the empty version fell into no release was found; set AF_VERSION to install a specific one. Sixty an hour is shared by everybody behind one address, so a corporate NAT, a cloud network or a shared CI runner reaches it without doing anything unusual, and this is the first command a stranger runs. Our own CI reached it: the job that installs the way a customer's workflow does invokes the installer eleven times, and the first invocation was told the product has no releases.

latest now comes from the redirect on github.com/antifailure/antifailure/releases/latest, which lands on the tag GitHub marks as the latest release. That is the website rather than the API, it needs no token and it has no budget for each address, so the case that broke cannot arise. Serving the version from antifailure.dev was considered and refused: the site deploys when a merge lands on main and a release is published when a tag is pushed, so a version file written at site build time would be stale for every release until an unrelated merge rebuilt it, and installing the wrong release quietly is worse than saying the question could not be answered.

Answers that used to arrive as one sentence now arrive as what they are. Nothing answering, an address that has asked GitHub for too much, a repository that does not exist or is private, a repository that has published no release, a redirect naming something that is not a tag, and a redirect to somewhere that is not a release at all, which is what a proxy or a sign-in portal in front of a network answers with, each say what happened and what to do about it. The rate limit names AF_VERSION because that genuinely is the way through, and AF_VERSION is documented now, which it was not. The same collapse is fixed for both downloads. A release with no build for this platform is no longer reported as could not download, a checksums.txt that a network dropped is no longer reported as one that was never published, and a version nobody published, which is what a mistyped AF_VERSION is, is no longer reported as a platform with no build: the release page is asked which of the two a 404 on an asset means, and the reader is pointed either at the builds that release does carry or at the releases that exist. Both implementations are fixed, curl and wget alike.

A machine whose only fetcher is BusyBox wget, which is what Alpine ships and what this script's own header names as a place somebody pipes it into, keeps working. That wget has no option that reports a redirect and refuses every flag GNU wget reads one with, and the lookup this replaced worked there, so the version is read instead out of the newest release's own checksums.txt, which github.com serves under releases/latest/download and which names the version in every archive it lists. That second way of asking is also what answers if the redirect ever stops being a redirect.

None of this was tested and none of it could have been. Every session in tools/installsh set AF_VERSION, so the resolution never ran, and the stub curl could only exit 22, which cannot express a status at all. The stub is gone: the tests now run the real curl and the real wget against a local server that answers real statuses, and each arm asserts both the sentence it should produce and the absence of the sentence it used to produce.

Each round was printed while the line that counts elapsed time was still on the screen, so "round 4 of 48: sending the mix at this build" was written onto the end of "Ctrl-C to stop and roll back". The pair was wider than a 110 column terminal, it wrapped, and every round left one more fused line and a fragment such as "ld" on a row of its own. af oracle and af scenario print their progress the same way and were exposed to the same thing.

Anything printed during a run now erases the status line first, and the line is drawn again under it at the next second. The status line is also measured against the terminal as it is when it is drawn rather than as it was when the command started, so a pane resized during a run, or one narrower than 40 columns, gets a line that fits. It gives up the interrupt reminder first, then the step timer, and keeps the run timer. Each compare round now also restarts "on this step", which had been counting from the start of the whole compare.

It was timed from the fault to the first query answered after the proof had waited out its settle, undone the fault and stopped its writers, and it made no attempt to reach the database before then. A database that was ready 1.66 seconds after its checkpointer was killed was reported unreachable for 3.1 seconds, and the terminal, the pull request comment and the MCP answer all repeated it.

A probe now runs beside the fault from the moment it is injected. It opens a connection and runs SELECT 1 every 100 milliseconds, and the outage runs from the first attempt that went unanswered to the first answer after it. The line prints its resolution, 110ms, probed every 100ms, and says never when every attempt was answered instead of printing a zero. Against a real Postgres it agreed with the database's own log, from the line saying the checkpointer was killed to the line saying it was ready to accept connections, to within 100 milliseconds.

The chaos guide also explains why the first crash after af up can take several seconds longer to recover than later ones: Postgres syncs its whole data directory to disk before replaying, and on the first crash that includes everything written when the branch was created.

Every environment gets two networks and Docker hands each network one range from a fixed set, about thirty one by default, counted across everything on the machine. When they ran out, af up reported AF-RUN-040, "the environment could not be placed", and pointed at af doctor, which reported the runtime healthy, and af down, which removes only the checked out branch's environment. The daemon that failed held thirty networks, and fourteen of them were Antifailure networks nothing was attached to, left by test runs killed before their teardown ran. Nothing in the product could list them, and af env prune's only selector, age, could not reach them without also reaching the environments in use.

That refusal now has its own code, AF-RUN-052, which counts the daemon's networks and how many of them are Antifailure networks with no container attached, and names af env prune --orphaned. That new selector lists the environments holding networks with nothing attached and nothing running, and removes them with --yes. It waits an hour from an environment's newest resource, so one being brought up is never taken, and it never considers a network without the Antifailure label. af doctor's leftover environments check now counts them too.

The undo asked the daemon whether the container was paused before thawing it, and returned success when the answer was no. The helper it asked also answers no when the inspect itself fails, so one stumble from the daemon at that moment skipped the thaw and still called the fault undone. The undo now always asks for the thaw, then reads the container back: a container still frozen, or one whose state could not be read, is reported as a failed undo. A container that was already thawed or has gone away is still not an error.

The check compared the flush position a writer read, which is where the flushed log ENDS, with the position Postgres prints in "redo done at", which is where the last record it replayed STARTS. Every supported major, 14 to 18, prints the start. So whenever the last record flushed was the last record replayed, the replay looked short by exactly that record, and the durability proof raised chaos.recovery.replay_short against a run that had lost nothing. It failed main's own test with 729 commits acknowledged and 729 present.

The end of replay is now read from the checkpoint Postgres takes the moment crash recovery finishes: from its own log line on Postgres 16 and later, and from the control file on 14 and 15, where it is accepted only when it has the shape of that checkpoint. When neither is available the run says it could not tell, rather than passing or failing. A replay that really stops short of the flushed log is still reported, and the report's "replayed from X to Y" now names where replay ended rather than where its last record began.

The durability proof stopped its writers before it thawed the database, and gives each writer two seconds to finish the statement it is on. Against a frozen database no statement finishes, so every freeze lasted its hold plus those two seconds. The time in place that af chaos now reports showed it, 5.003s against a declared 3s, and the daemon agreed: the container was paused for between 4.9 and 5.3 seconds.

The proof now thaws the database at its declared hold and stops the writers after, and the same freeze measures 3.001s. The durability claim is unchanged and covers more: commits the writers make after the thaw are counted, and each one the client was told was committed must still be there afterwards, like every earlier one.

The verdicts table carried the reproduction as a seventh column and needed 860px to hold it, so on any laptop window from 640 to 1279 wide the table scrolled sideways inside its card and the Reproduction column was cut off at the card's edge. On a wider window it fitted and was a narrow box scrolling a long sentence, so the reproduction was cut off inside its own box instead. The steps also printed as a JSON array, in quotes between brackets.

The reproduction now sits on its own full width line under the verdict it belongs to, and wraps, so every step is on screen at every width from 360 to 1600. The steps print as lines, one step per line. A passing workflow, which has nothing to reproduce, no longer carries an empty line saying so.

An Electron ledger client with thousands of transfer.posted rows was failed in 3.7 seconds with "transfer.posted" was not found, quoting "Journal Reading the ledger". That was the client's loading screen. It fetches its journal in Electron's main process and draws a skeleton until the answer lands. The desktop driver read the accessibility tree as soon as the document parsed, the planner found nothing to press, and that first look became the final verdict. The phone loop had the same shape, and an iOS run had passed only because the app finished loading before the first read.

The browser surface waits for the network to go quiet. Nothing like that exists here: a main process fetch is invisible to the page, and a tree read through Appium has no network signal at all. So the tree itself is watched. The first read is read again until it holds still. Before any verdict that is not a pass, the screen gets up to ten seconds to change. A changed screen goes back to the planner and a still one is judged as it is. aria-busy and macOS's AXElementBusy keep a screen from counting as still.

This never turns a failure into a pass. A screen that finishes loading without the expectation still fails, and the verdict quotes the loaded screen. A screen that never stops changing is judged on its last read, and the verdict says it was still changing. A passing workflow costs one extra read of its first screen.

An agent driving inject_declared_faults against a service declared to be cut off from its database for five seconds got back duration_ms: 0, and said the number made it doubt the cut had lasted. The cut had lasted. Measured from the daemon every 200 milliseconds, the service was off its network for between 4.9 and 5.6 seconds. The zero came from the line that records a fault's duration: it was deferred, and it wrote into a local copy after the return statement had already handed the entry back. Every fault outside a durability proof reported zero, in the MCP result and in af chaos -o json, whatever happened.

The duration is now the step's real length, and every fault also reports how long it was measured to be in place, from the moment the injection returned to the moment its undo began, beside the hold the manifest declared. The terminal and the pull request comment say it in words, "It was in place for 5.001s (declared 5s), then undone.", and the MCP result carries in_place_ms, hold_declared_ms and the same sentence as in_place. A measured zero is said as a sentence rather than printed as a number, and a killed process, which has nothing to undo, is described as the wait before the result was read.

The same run showed that after was not honoured either. The manifest describes it as the least time the run waits before a fault, and the code only used it as part of a timeout, which is a ceiling. The partition went in less than half a second into a run that declared after: 5s, and a database freeze did the same. Both now wait the declared time.

The new measurement also shows something the old number hid: a frozen database stays frozen about two seconds past its declared hold, because the durability proof gives its writers that long to finish the statement they were on before the database is thawed. The report now says so, for example "in place for 5.003s (declared 3s)", instead of repeating the manifest.