[Wania-Kazmi]

This branch holds every learner step from 11 onwards. Each step lands on it in its own commits as it is built, and the branch is merged into staging when the human says so. Step 11 is the first; the sections below grow with each step.

Step 16 from decision 124 on, and steps 17 to 25, were built on 2026-10-11 and 2026-10-12 on the learner's standing instructions, "go with your recommended settings" and "choose your recommended options". Every decision from 123 on was taken with the recommended option, recorded with its alternatives in my_notes/decisions.md, and is open to reversal. Each step's database tier, from 16 to 25, now passes on Neon, each on a database of its own (decision 158, below). Decision 158's two main choices were confirmed by the learner on 2026-10-15.

Decision 158: on a database far away

Problem. The database tiers of steps 16 to 25 ran against Neon for the first time on 2026-10-14, 127 ms from this machine. Until then they had run on a PostgreSQL on the same machine. Steps 20 to 25 each failed one to three tests, every one a test of twenty or fifty requests at once. Fifty requests with one key made one payment, but the forty-nine others stopped waiting after two seconds, and 47 or 48 of their refusals then lost their place in the audit log. From step 22, fifty requests from one company raced for the end of its log, and 36 to 39 of fifty reads were refused after ten tries; in steps 24 and 25 a raw audit_pkey error came out of propose with no envelope. Both settings had been measured where a round trip takes a fraction of a millisecond.

Solution. From step 20, a request waits up to thirty seconds, not two, for the same request still being carried out; the wait ends as soon as the answer is there. A look that fails after the first request was seen running, or after its key was found taken, is OUTCOME_UNKNOWN, never "nothing was done". From step 22, each company's log takes one writer at a time: a PostgreSQL advisory lock, taken with the company in the turn's first statement, at READ COMMITTED, ended by PostgreSQL after ten seconds idle, behind a line in the program that waits without a connection and lets the next request go once a turn is taken. Steps 20 and 21 keep step 09's honest refusal of a lost place. Two hostile reviews of the fix found problems, all fixed and each broken on purpose to show its test catches it, except three written down: open question 130 (a busy agent can delay a person's brake past §44), 131 (a waiting retry whose refusal cannot be recorded), and how refusals arrive during an outage.

Behaviour. Every database tier from step 16 to 25 passes on Neon, none skipped: 39, 51, 51, 51, 52, 53, 60, 60, 62 and 75 tests. "Most of twenty, on this machine" became "all twenty, on any server". New tests pin the turn on a stub pool and on a real server, show another company is not kept waiting, and that a quiet turn ends. Unit tests: 735, 754, 840, 881, 923 and 1021. All twenty-two Break it exercises of steps 20 to 25 were measured again, twice; only step 20's Breaks 1, 3 and 4 moved, each explained.

The second review of steps 15 to 25

Problem. On 2026-10-12 the learner asked for a review of steps 15 to 25. Every step passed its own pnpm check in CI and its database tier on PostgreSQL, but a hostile review, one reviewer for each step, three more across the steps, a skeptic for every serious finding and a critic, found 119 problems that held: 5 high, 40 medium and 74 low. Twelve were the code doing the wrong thing. The worst: in step 20, a retry that decision 132 had added let one idempotency key make two payments when a release's reply was lost (measured, 9 runs of 12); and from step 22, no proposal move was written to the audit log, though DSOR-AUD-01 asks for it and step 08 had handed that job to step 22. Most of the rest were tests that still passed with their guarantee removed, and sentences that said more than the code.

Solution. The learner chose to fix everything, with four recommendations: build audit records for proposal moves; let an approver revoke a slip they signed; write down four start-up gaps that need an administrator's mistake, for step 26; and reword step 25's revocation sentence rather than add a second slip check (decision 145). Each finding was fixed in the step where it began and carried into every later folder, red first or broken on purpose (decisions 146 to 156). Decision 157 writes every proposal move with its own proposal_transition record in one statement; the database refuses a move without one; and a record that loses its place in its company's log tries the next place after a short random pause, up to ten. An independent review of decision 157 found the crowd test likely to fail on Neon, two overclaiming sentences and two untested guarantees, all fixed, and a revocation limit that step 29 must handle, written down. The specification's questions are open questions 124 to 129.

Behavior. Every step passes pnpm check, and its database tier on a local PostgreSQL 17 set up like Neon, with every demo running against it. All 65 README breaks were measured again on the final code, twice, and the passes agreed.

Step	Tests	Database tier
15	534	39
16	557	39
17	623	51
18	663	51
19	696	51
20	732	52
21	751	53
22	833	57
23	874	57
24	916	59
25	1014	72

On a PostgreSQL 17 on the same machine, twenty payments sent at once now all go through with every move recorded, where 3 of 20 did before. Each step's own section below gives its counts as it was built.

CI: one job per step folder

Problem. CI checked the baby steps in one job per system, one folder after another. From my_09 on, each my_ folder runs its test files one at a time, and each step takes longer than the one before, so the job grew with every step. With 40 to 45 folders it took from 35 minutes to more than 60, and from 41 folders it was cut off at 60 on Windows, so the newest steps went unchecked: Windows had never reached my_23, my_24 or my_25.

Solution. A first job lists every folder with a package.json. Every folder then gets a job of its own on Ubuntu and on Windows, at most 12 at once, because the organization's Free plan has 20 runners for all of its repositories. A job named "Baby steps" passes only when every one of them did. A new step is checked without editing ci.yml, up to 128 folders. A hostile review of the change, five reviewers with a skeptic for each finding, found what the folders would meet on Windows for the first time. The ten-stage ordering walk in my_22 to my_24 would run past its 30-second limit, so it now has two minutes of its own, with the proof unchanged (decision 144). And a fresh Windows machine once took 33 seconds over its first TypeScript run, so each Windows job now runs node on TypeScript once, timed, before the tests. The review also corrected the comment's numbers and my_01's README, which said CI does not run its tests.

Behavior. The first run passed: 95 jobs, 19.5 minutes from the first job to the last (run 38256321861). A folder took 15 seconds to 7.2 minutes on Ubuntu, and 51 seconds to 8.9 minutes on Windows, where my_25 ran for the first time. The ordering walk took 43.2, 33.8 and 33.6 seconds on Windows in my_22, my_23 and my_24: without its own limit all three would have failed. The warm-up took 0.1 to 2.7 seconds on all 45 Windows machines, so there was no stall this time. The test closest to its limit is my_21's start-up check, at 22.5 of 30 seconds on Windows. Not changed: every job still runs the repository's own install, and every push checks every folder; and every job checks its lockfiles against the npm registry again, about 180 checks a push where the old job made 12.

Step 25: revocation and the emergency brake

Problem. When the agent misbehaved at 3 a.m. there was no switch: user_123 could not tear up del_100, nothing stopped one agent or every agent at once, and asking the agent to stop is asking the thing that misbehaves to behave.

Solution. The brake is a record in DSoR's own store (migration 024; decision 142): control.suspend stops one agent in a company, or every agent in it, and releases it. A new stage, §21.4, refuses a stopped agent's commands AGENT_SUSPENDED and lets its reads through; the move to EXECUTING, and a prepared command's to READY, ask the brake again in the same statement. delegation.revoke marks a slip revoked with who and why, and in one statement cancels what waited under it for approval, releasing its reservations (migration 025). The review found a refusal recorded as ALLOW, the brake optional on the way into EXECUTING, and a prepared command not stopped, all fixed: who may revoke and who may release are decided at a new §21.9 stage and recorded (decision 143). The stage-order test became a proof by its parts, since walking all orderings of eleven stages took 65 seconds. Written down: a question for the specification about DSOR-SRC-02b and a revocation's target; the tenant administrator and the expiry half of DSOR-DEL-04c, not built.

Behavior. pnpm check: 876 passed. Database tier: 69 passed on a local PostgreSQL 17 set up like Neon. Three README breaks measured twice, agreeing (5, 1, 2 failing); decision 143's six broken once each, all as predicted. Stage 3 of the learning path is complete.

Step 24: limits with reservations

Problem. del_100 limited each payment to 50,000.00 and nothing else, so the agent could make any number of them in a day; and a daily limit is a running total with a race, where fifty payments at once each read the total and find room.

Solution. The slip gets a daily limit, 200,000.00 USD for del_100 (migrations 022, 023; decision 140). §21.10 books each payment against the slip's total for the UTC day in one INSERT ... ON CONFLICT DO UPDATE ... WHERE used + amount <= limit, writing a reservation keyed by the proposal from the same statement. The door settles it as the proposal ends: committed, released, or held while unknown or prepared, and only when the history holds the move. A dry run books nothing. The review found the settle running without the move, a race test that could not fail, and reserve() taking any currency, all fixed; and that the application's own code could still make room, written down with why: a payment is not tied to its reservation (decision 141).

Behavior. pnpm check: 806 passed. Database tier: 57 passed on a local PostgreSQL 17 set up like Neon, five runs in a row; fifty reservations at once book exactly forty, and with room for one, fifty payments through the door make at most one, while a read-then-write booking made three. Three README breaks measured twice, agreeing (1, 4, 4 failing).

Step 23: three ways to call

Problem. The agent could only find out whether a payment would be allowed by sending it, and every allowed one was made at once; nothing could be prepared now and released later.

Solution. A command is called execute, propose_only or validate_only, said beside its arguments as the key is, read once, its own field only (decision 138). A dry run skips the claim and the proposal, as §21 says, still asks the limit, is recorded as VALIDATED, and answers VALIDATED, ALLOW, with nothing changed. A prepared command walks the same checklist and stops at READY. The claim keeps the mode (migration 021), so the same key in another mode is IDEMPOTENCY_CONFLICT. The review found one request able to leave two READY proposals, and a mode on the request's prototype executing, both fixed (decision 139). A dry run skips the handlers' preconditions until step 32, written down and pinned by a test.

Behavior. pnpm check: 779 passed. Database tier: 55 passed on a local PostgreSQL 17 set up like Neon. Three README breaks measured twice, agreeing (8, 1, 6 failing); decision 139's three broken once each, all as predicted.

Step 22: proposals and their states

Problem. In the morning nobody could say what became of the agent's 2 a.m. request: the answer was spread across the audit log, an idempotency claim and a payment row, if there was one, and nothing kept a request's state from moving backwards.

Solution. Every command past its key's claim becomes a proposal at §21.8 (migration 020, decision 136): its payload as the hashed text, who asked, its key, and a history of moves, each with an actor and a cause; its state is its last move. The §26.2 map is a table and every move must be on it; the history is one line, a state entered once and left once, so a finished proposal cannot move and one cannot run twice, kept by the database and asked about at start-up. The door moves it: DENIED, READY and EXECUTING together, then COMMITTED, FAILED or OUTCOME_UNKNOWN; the receipt names the real proposal. The review found a proposal that could be left READY for good and a careless handler's failure believed, both fixed (decision 137).

Behavior. pnpm check: 753 passed. Database tier: 55 passed on a local PostgreSQL 17 set up like Neon, including twenty moves out of READY at once over a pool, one written. Three README breaks measured twice, agreeing (4, 1, 9 failing); decision 137's three broken once each, all as predicted.

Step 21: optimistic concurrency

Problem. The agent reads a payment, decides to cancel it, and meanwhile a person changes it. The agent's command ran anyway, on a record that was no longer the one it decided about, and nothing in the request said which version that was.

Solution. Invoices and payments carry a version, raised by one in the same UPDATE as every change (migration 019). Every command's contract declares its strategy: invoice.issue and payment.cancel are optimistic, payment.create is none, and the registry refuses any other (decision 133). An optimistic command must say expected_version, a whole number from 1 to 2147483647, asked at §21.6 so that a missing one is recorded as a DENY. The check is part of the change, ... AND version = $3, and a record that moved on is STALE_STATE, retry after_state_refresh, before any business rule, with no new version in the message. The review found a version too large for the column that made the door throw, a declared strategy nothing read, and tests the status alone could pass, all fixed (decision 134). Breaking the fixes on purpose found two more weak tests, both fixed (decision 135).

Behavior. pnpm check: 718 passed. Database tier: 53 passed on a local PostgreSQL 17 set up like Neon, including twenty cancels of one payment on one version over a pool, one made. Three README breaks measured twice, agreeing (2, 6, 1 failing).

Step 20: idempotency keys

Problem. A payment whose answer is lost is sent again by the agent, and DSoR made a second payment: nothing in a request said DSoR had seen it before.

Solution. Every command carries an idempotency key beside its arguments, never inside them, and DSoR claims it at §21.7 with one INSERT into dsor.idempotency_keys, under a primary key on the company, the caller who logged in, the operation and the key (decision 131). The same key and request get the recorded answer word for word, with nothing run and no second decision recorded; the same key with a different request is IDEMPOTENCY_CONFLICT; the same request still running is waited for. The review found three broken guarantees, all fixed (decision 132): only a refusal from the walk releases a claim, so a handler's "safe to send again" after a payment no longer reopens it; a restrictive policy keeps an answer once written, start-up asks for it, and a replay is checked against its caller; and the claim's messages say only what is known.

Behavior. pnpm check: 702 passed. Database tier: 52 passed on a local PostgreSQL 17 set up like Neon, including fifty requests with one key over a pool of twenty connections, one payment, run eight more times. Five README breaks measured twice, agreeing; decision 132's six broken once each, all as predicted.

Step 19: unattended mode and the role source

Problem. At 2 a.m. the agent's payment under del_100 was recorded as the agent acting for itself, direct, with no slip, and what user_123 holds came from a list that never changes while the program runs: when user_123 changes jobs, the agent keeps paying under their name.

Solution. An agent's command under a slip is unattended: the slip must allow that mode, the record's subject is the slip's signer, taken from the slip and never from the request, the agent is in the actor chain, and the slip is named on the record, inside the hash (decision 129). What the signer holds is asked of the company's directory, a fake one per company, at every decision; a directory that does not answer, or none at all, refuses with DEPENDENCY_TIMEOUT. The review found three broken guarantees, all fixed (decision 130): a future-dated or zone-less directory answer counted as fresh, so now an answer counts only with its zone and at most 24 hours old, and a stale or unusable one is FRESHNESS_UNSATISFIABLE; refusals after DSoR found the slip were recorded as the agent acting for itself, and are recorded under the slip now; and a column-level UPDATE on the log passed start-up. A slip allows unattended only when it says so, and none is signed by its own agent.

Behavior. pnpm check: 673 passed. Database tier: 51 passed on a local PostgreSQL 17 set up like Neon, seventeen migrations. Six README breaks measured twice, agreeing; decision 130's nine broken once each, all as predicted.

Step 18: delegations

Problem. The agent held power of its own: its role granted it the commands outright, nobody had signed for what it did, and when user_123 lost a permission the agent kept it.

Solution. The permission slip, dsor.delegations, in DSoR's own store under the same lock. Every command the agent sends runs under the one active slip DSoR finds for it; its power is computed at each decision as the slip's permissions cut down to what the signer holds right then and to the login's scopes, up to the slip's limit per payment (decision 127). The review found four ways past an expiry or a limit, all fixed (decision 128): an expiry the program cannot read is not in force, a slip or a signer that cannot be read is a refusal that is recorded, DSoR never chooses between two slips, and a helper function's owner is asked what the application is asked. A payment over the limit is now LIMIT_EXCEEDED, the specification's code.

Behavior. pnpm check: 645 passed. Database tier: 51 passed on a local PostgreSQL 17 set up like Neon. Eight README breaks measured twice, agreeing; decision 128's eleven broken once each, all as predicted.

Step 17: vendors and payments

Problem. No command said whether its effect could be undone, and there was nothing to undo: the running example's PAY-901 had nowhere to live.

Solution. Vendors and payments, under the same two locks as the invoices. payment.create makes a draft and is compensatable, undone by payment.cancel, which is atomic; every command's contract declares its semantics, the door writes them on every receipt from the contract, and the registry refuses an undo that is not a command the program has (decision 125). The review's eight findings were all fixed (decision 126): a payment's vendor is its invoice's by the database too, the payment numbers are nobody's to choose, a command that answers like a query is refused, a payment is in its invoice's currency, and the handler reads exactly what the payload hash describes.

Behavior. pnpm check: 608 passed. Database tier: 51 passed on a local PostgreSQL 17 set up like Neon. Ten README breaks measured twice, agreeing; decision 126's seven fixes broken once each, six as predicted and one that failed three tests instead of one because the break changed two things.

Step 16: the control-plane store

Problem. DSoR's log, its only paperwork in the database, was public.audit, filed beside the business's invoices in the schema the business's own tools treat as theirs. A cleanup of public would have taken DSoR's evidence with it.

Solution. A second schema, dsor, in the same database, and the log moved into it as it is: records, hash chain, grants and row-level security together (decision 122). The application may use dsor and create nothing there. Two hostile reviews followed (decisions 123 and 124), and start-up now also refuses an application that owns the database or either schema, or may create in either, by itself, one SET ROLE away, or through a helper function's owner.

Behavior. pnpm check: 548 passed. Database tier: 39 passed on a local PostgreSQL 17 set up like Neon; on Neon, dsor_step16 waits for the folder's .env. Nine README breaks measured twice, agreeing.

Step 15: freshness labels

my_15_freshness_labels. Every answer says how old its data is: the mode, when it was read, and from where (DSOR-FRS-01a), and the door refuses a current label stamped before the request began (DSOR-FRS-01b). The problem first, on step 14's demo, run on the local database so step 14's Neon database was not touched: the agent's INV-1008 says issued, with no time and no source, so an agent's hour-old memory and a fresh read look the same. Four decisions taken by the learner before any code (decision 120): the modes in lowercase, as the schemas spell them, against §27's capitals (open question 51); the code that reads writes the label, and the door insists on one; an old value labelled current is refused, not relabelled; no resource_version until step 21. Four pieces, each red first and committed alone: the label, in src/freshness.ts, with the two reads handing back their rows with it; the door insisting on a well-formed label; never an old current; and the demo printing the label under every read.

The hostile review, told this time to assume a careless handler as decision 119 says, found no way past the door and no wrong label on a real read, and three fixes the learner chose (decision 121): a query that answers with a receipt is refused, since a receipt carries no label; the label's time is taken just before the query, so data is at least as fresh as it says, and only an exact ISO time not in the future is accepted; and four guards got a test, with leaveTheDoor keeping only a label's three parts. Written down and not fixed: the door checks when a label was stamped, not whether the code that stamped it read the database, so the cache a later step adds must label its own answers; and a clock moved backwards refuses an honest read with retry never.

The step's own database, dsor_step15, was made on Neon with one CREATE DATABASE through the owner login in the copied .env. The settings refuse Claude any command that names .env, so the learner changed the database name in it.

531 tests, 39 in the database tier on Neon, and ten breaks measured twice with the runs agreeing. Learning-path stage 2 is complete.

Step 14: classification and masking

my_14_classification_and_masking. Every field has a label, the agent has a clearance, and a field above it is taken out of the answer before the answer leaves, and listed (DSOR-CLS-01, 02a, 02b, 03, 05). The problem first, on step 13's running demo: the supervisor's and the agent's reads of INV-1008 print the same line, 31400.00 USD, and the agent's line goes to a model provider. Three decisions taken by the learner before any code (decision 105): one file for all labels, with a field missing from it confidential; a field above the clearance left out and listed, not masked with a placeholder; agents only filtered, the agent cleared for internal. Four pieces, each red first and committed alone: the labels and the clearance; the filter at the door, for one invoice, a page and a command's receipt, with the answer labelled by the highest label among what is left; the record of a confidential read — a second audit record after the decision, with every address returned and the row count, written before the answer leaves and refusing the rows if it cannot be written; and the demo's two lines that are no longer the same.

What the build found (decision 106): the record of a read has to be a second record, because the decision is written before the handler runs and the log is never amended; and a column-level GRANT does not grow with the table — migration 006's first version added two columns and every INSERT into the log was refused.

The hostile review, six agents and three verifiers. Five reviewers found ten guarantees no test pinned, each now a test that fails under the review's own mutant: a page filtered row by row, a row with no address staying locked, the human's answer whole, the fourth label reaching the door, the ceiling measuring what leaves, the rebuilt receipt validated again, a page's cursor going with its addresses, a row with no address refused as the program's own error, a store down for the look-back too, and an empty page's label. The critic then found two things that changed the design (decision 107): a label describes a value it can see the whole of, so a value with parts inside is confidential whatever its field is called — a reviewer got the amount out inside a vendor that was an object — and an answer the door cannot filter is an envelope with a code and a retry class of never, where it had thrown a raw TypeError after the side effect. A receipt with no data, legal in the schema and what step 17's first PENDING_APPROVAL receipt will be, leaves as it came. The break measurement then caught the first of those fixes weakening the suite: with every object treated as unseeable, the table's own amount: confidential stopped mattering, so money is the one compound value the rule accepts and that break fails thirty-three tests again instead of two.

One finding is recorded rather than fixed (decision 108): five endings leave one ALLOW record and nothing else — an agent's answered read, a bad limit, an answer over step 13's ceiling, a row with no address, and the evidence store failing — so the log cannot tell a read that was answered from one refused after its decision. Measured against the rules nothing is missing, because DSOR-AUD-01 asks for command decisions, proposal transitions and DSOR-CLS-05 reads and all of those are written; "and then what happened" is a proposal's final outcome, two stages away; and the ending where the evidence store fails cannot be recorded by anything.

After the step, decision 109, the learner's choice: the record of a read kept its row count under extensions, because the build believed audit-record.schema.json had no field for it. It has one, row_count. Migration 007 adds the column with its column-level GRANT, and the count moved there, red first. The tests changed and did not grow. Broken on purpose: no count written fails 3, a read-back that drops it fails 7, and 007 without its GRANT fails 185 (187 once decisions 110 and 111 added two tests), because every INSERT names the column. Also corrected after the step: two citations of §4 that should say §6, a comment in boundary.ts that described a rule the filter now enforces, and the counts in docs/status.md and the step note.

After the step, decisions 110 and 111, both the learner's choice after a run showed the leak. Money, { value, currency }, kept its field's label wherever it appeared, so a handler that put the amount in vendor sent it to the agent labelled internal, with nothing in the list. It now keeps its field's label only in a field declared to hold money, today invoice.amount, as the specification's entity schema declares each field's type; anywhere else it is a value with parts inside, and at least confidential (decision 110). And labelOf walked the prototype chain: labelOf("invoice", "toString") returned a function, which is never above a clearance, so fields named toString and valueOf left for the agent with the amount in them. It asks for the table's own names now, the fix decision 36 made for roles, in a file written after it (decision 111). Each red first, in commits of its own, and each guard broken alone. Break 13 had been measuring another guard: the function it breaks was also the door's "is this a row?" check, so all 65 of its failures were the door refusing every row. Those are two functions now, and Break 13 fails 4, all about the label. A hostile review of the two found no new way past the filter through a row. It found two parts of an answer the filter never looks at, askedBy and a page's next — a gap from the step's first build — two guards no test pins, and sentences that said more than was measured. The sentences are corrected; the rest is decisions 112 to 114.

After the step, decisions 112 to 119, the learner's choices on what three more hostile reviews found. The door writes askedBy itself on every way out, and refuses a page whose next is not the address of its last row. Before, a handler that put the row in either sent the amount to the agent, with amount listed as withheld beside it (112). The money rule is a function a test can reach, and the door's row check is tested with money, as the agent too (113). The door copies a handler's answer once, and the check, the filter, the ceiling and the record of the read all work from that copy: a cursor that answered the check and the filter differently got the row out, and a record of a read named INV-1009 while INV-1008 was returned (116). A receipt is built from the parts its schema closes and is always checked; a row under requires or extensions had left beside a filtered data (117). Three guards the reviews found removable got a test (118). Written down and not fixed: two checks that fail open where nothing in this step reaches (114); an error's envelope, whose open parts take anything while its message is free text (115); and four ways past the copy that each need code written on purpose to trick the door, which could write the amount as text into a field anyway (119). The reviews had been told to assume the handler was trying to get the amount out, a stronger threat than this step is about, and decision 119 says so. Each fix red first, in commits of its own, with each guard broken alone.

512 tests, 39 in the database tier on Neon with migrations 006 and 007, and the fifteen breaks measured twice after decision 118, the two runs agreeing. The limits are in the README: no egress policy, no tokens, no budgets, humans unfiltered, error answers unfiltered and unlabelled, an unknown entity blank for an agent.

Step 13: bounded queries

my_13_bounded_queries. invoice.list, the first operation that returns many rows, with the size of the answer the server's (DSOR-QRY-01). Measured first on a copy of step 12 with a list written the obvious way and fifty thousand invoices seeded: { limit: 1,000,000 } returned all 50,002 rows, three megabytes, in a tenth of a second, and nothing said no. Three decisions taken by the learner before any code: the next page comes after the last invoice on this one, as a cursor; the cursor is an address, so the §21.6 scan refuses one from another company and step 12's suite tests the list with no edit; two maxima and a default in one file, with the handler's SQL carrying LIMIT and the door measuring every answer against both maxima and refusing an oversize one as the program's own error. Three pieces, each red first and committed alone. The test that matters is a connection that counts what every statement returned: a list that fetched the whole table and cut the page afterwards passes every other test.

A hostile review (four reviewers, a mutation pass of thirty-two one-line changes, a critic, three verifiers) found eight holes, each closed with a test that failed first: the counting connection was blind to an extra unordered read; error answers were exempt from the ceiling; the byte ceiling was proven with ASCII only, so a copy that counted characters passed; the list's own WHERE could be deleted with every test green because RLS filtered anyway; the walk trusted JavaScript's sort over the database's order; the demo pin carried a rule id it could not prove and a label that did not come from its request; NaN was refused as "null". One design suggestion declined and recorded (decision 104): the page is not cut by bytes; a row wider than the ceiling refuses, and the README says so. 468 tests, 36 in the database tier on Neon, eleven breaks measured twice with the runs agreeing.

Step 12: cross-tenant test suite

my_12_cross_tenant_test_suite. One generated test that calls every operation in the registry with another company's address: each contract carries an example request under extensions["com.panaversity.tutorial"], the suite moves every address in it to org_789 and asks six questions of every operation — refused with TENANT_MISMATCH; the same refusal, whole, for a real and a fake company and nothing about yours; the other company holds every number the example names, in the same state for a command; its rows untouched; exactly one record for the request in the caller's log, the DENY; the example works for its own company and carries nothing of the other. An operation without an example, or with an example that names no address, fails by name. Built explain → ask → build: the problem measured first (a careless third operation leaked org_789's invoice while step 11's hand-written suite stayed green), two decisions taken by the learner, three pieces red first.

A hostile review (four reviewers, a mutation pass, a critic) found the first version could be lied to — a refusal-shaped envelope carrying the row with a cosmetic DENY appended, a success answer carrying the other company's row, assertions deletable without a failure, a seed row that made a question hollow — and every finding is closed with a test: the six questions are plain functions and cross-tenant-suite-itself.test.ts feeds each the lie it exists to catch. 444 tests, 30 in the database tier on Neon, sixteen breaks measured twice with the runs agreeing. The map's "fresh Neon branch" is recorded as a divergence (decision 99).

Problem

Step 10 keeps the two companies apart with a WHERE tenant_id = $1 in every query. That is one lock, held by the program alone. Measured on step 10's own database as dsor_runtime, a query that forgot the company returned both companies' INV-1008 — and all 376 tests were green, because they only check the queries that exist today. The leak is the query somebody writes next year.

Solution

my_11_row_level_security, a learner build of step 11, copied from my_10_tenants and built explain → ask → build: the problem shown from the running program first, three decisions put to the learner one at a time before any code (both tables get the lock; the company is said before each statement, in its own transaction; the demo runs the forgotten query), then five pieces, each red first, committed on its own, and broken on purpose.

• Migration 005 enables and forces row-level security on public.invoices and public.audit, with one policy each: a row is visible, and may be written, only when its company is the one the transaction said. A CHECK ties a record's chain to its company.
• The stores say the company through the one handle they all use, theDatabase(tenant), which refuses an empty company. Two adapters run each statement inside its own transaction after set_config('dsor.tenant_id', $1, true), for PGlite and for a pg pool — where a per-connection setting would be met again by a stranger's statement. The stores' SQL is unchanged.
• The start-up check asks what no privilege check answers: BYPASSRLS; membership of a role that holds it (Neon's neon_superuser, refused by name); ownership of a tenant table or membership of its owner; whether the lock is on at all, and is exactly the one policy the migration wrote; a SECURITY DEFINER helper whose owner skips the lock; and any relation beside the two tenant tables the account may read.
• The test support runs the stores as dsor_runtime. PGlite's connection is a superuser, and a superuser skips every policy: with a store that forgets the company, the tests as the superuser fail 28 of 400 and none is a store's own test; as the application, 131. Sixteen tests that ran raw SQL as the application without a company went red when the lock arrived and now say it, or run as the owner.
• The database tier (13 tests, a local PostgreSQL 17 with a database of the step's own) demonstrates the pool trap on a real pooled connection and then the adapter not doing it; the real login with no company gets no rows.

Rules: DSOR-TEN-01b, DSOR-RP-01a, DSOR-RP-01b, DSOR-RP-01c, DSOR-RP-01d, each with its honest scope in the README. 412 tests; runs from a clean copy outside the repository.

Behaviour

pnpm start prints the forgotten query run through the program's own connection: one row for org_456, no rows with no company said. Everything step 10 printed still prints.

Two measurements corrected the build. BYPASSRLS is a role attribute, and PostgreSQL never passes attributes through membership, so a Console-made Neon user is one SET ROLE neon_superuser away from skipping the lock rather than skipping it outright; the map's wording says "altogether", recorded as a divergence with the map untouched. And the audit policy binds a record's tenant, not its chain, which the migration's comment had claimed — a CHECK now says it.

The hostile review measured three windows past the lock that the first start-up check could not see — a second wide-open policy (policies are OR'd), a SECURITY DEFINER helper owned by a BYPASSRLS role, a view the owner made — each as both companies coming back while the check said the lock was on. All closed, each red first, each guard removed again to see its test fail. Thirteen breaks in the README, every count measured twice at 400 with both runs agreeing.

Tested again, on request. An independent evaluation — four reviewers, a mutation pass on a copy, a critic — graded the folder C and found: three more ways round the helper question (an aggregate, an INHERIT FALSE membership, a trigger on the invoices fired by the application's own UPDATE), the demo's two lines pinned by no test, the pool adapter invisible to pnpm test, two step 09 test files running the stores as the superuser, and singleFork — an option Vitest 4 does not have, ignored since step 09, so the test files had run in parallel all along and the configs were never typechecked. All fixed, each guard removed again to see its test fail; the configs are typechecked now. Two faults were injected for real (a COMMIT that dies on a real server; PGlite's one connection) and the cost of a transaction per statement measured. 412 tests, 16 in the database tier, seventeen breaks measured twice with the runs agreeing. Steps 09 and 10 carry the same singleFork lines and are reported here, not edited. Also fixed on this PR: step 08's demo test, which built its path in a way Windows could not open.

And Neon itself. A project, a database and dsor_runtime made with SQL; the five migrations, the sixteen database-tier tests twice, and the demo through the real login all pass on Neon. Measured there: Neon's owner and every Console- or API-made role hold BYPASSRLS directly and Neon forbids SET ROLE neon_superuser, so the map's "ignores row-level security altogether" is right for Neon, and the folder's earlier "one SET ROLE away" was PostgreSQL's rule, not Neon's — corrected. Over the network a statement with a company is four round trips (117 ms plain, 484 ms through the adapter), the measured price of "before each statement" that step 36's one transaction per request removes.

The four files pull request #4 changed in my_10 (comments only, the drift markers) are carried into my_11 so the new guard holds. docs/status.md and my_notes (decisions 94 to 96, lessons 36 to 38, the step note) are updated in the same change.

🤖 Generated with Claude Code