the run-through · RDM v1 · steward's systems test

The Run-Through

A guide to testing the built system end to end, by hand, before launch. The machine has already agreed with itself; this is where the steward finds out whether the system tells the truth to a person. Walked in order, the run-through drives the outstanding acceptances and sets up the three gate attestations that are ready. G-A is not among them: its sentence asks for a member who is not the steward, so it is the one gate this walk cannot reach alone. Unfamiliar words are defined in the Lexicon. Budget roughly an hour for the walk itself.

cites · RDM v1 · PRD v0.3 §4 · the Gate Book · the notices runbook RegenHub, LCA · Boulder · July 2026
§1

What the machine already proves

Seven suites run on every change, and an eighth rehearses weekly. Before you touch anything, know what is already held, so your attention goes where only a person can look.

ledger-validateThe roadmap is coherent: schema, dependency acyclicity, gating consistency, manifest freshness. A packet cannot claim a status it has not earned.
schema-lint · db-verifyThe migration chain applies clean from zero and the emitted schema matches the Information Model: thirteen tables, the event log append-only, the fold a view.
rls-auditThe probe matrix: every role against every table per AM v0.1 §5, each probe citing its cell. Who can see what is proven cell by cell, not assumed.
gate-rehearsalEvery Belong, Gather, and Find sentence as a committed sequential journey: apply, admit, read, sign, register, attend, post, respond, resolve, with every refusal asserted. Thirteen beats, four personas.
restore-test · style-lintBackup restores and folds match; the prose keeps house style.
walkaway (weekly)Export, stand fresh infrastructure, import, re-export, byte-identical, fold reconstructed. Already run live on 2026-07-21: events export.taken and walkaway.rehearsed are in your record.

What none of this can prove: that the deployed pages against the live database behave the way the CI substrate does; that a real magic link arrives and signs in; that the Telegram notice lands in your hand; and that the whole thing reads honestly to the person using it. That is the run-through.

§2

The bench

Two identities, four windows. Set these up before beat one.

the stewardYour normal browser, signed in as yourself. Your agent row is bound and holds the steward grant.
the newcomerA private or second browser, signed out of everything, plus an email address you control that has never touched the system. The newcomer should feel like a stranger, because the system will treat them as one.
the deskThe SQL editor for seeding the gathering and reading the record, your Telegram (the @nou_guild_bot chat) for the intake notice, and the portal, the signed-in door whose steward's desk counts what waits for your hand.
the countersignerFor the G-B and G-G attestations only: one member who is not an organizer, on their own device, at whatever moment suits you both. Every other beat is yours alone.
on the marks this leaves

The record is append-only, so the run-through becomes the record's first story: an application, a signature, a small gathering, an opportunity posted and resolved. Run the newcomer as a real identity of yours, plainly named, and the story stays honest. If you want a pristine record at launch instead, say so: the walkaway machinery can stand a fresh database and carry over only what you choose. Nothing here forces that decision today.

§3 · X-02, B-02

First act · the front door

01
newcomer
“A member can complete onboarding without a meeting.” In the stranger's browser, open /commons/join/ and submit the application: the newcomer's name, the fresh email, a line of intent. Nobody helps. observe: the received panel, no error, no dead end
02
steward
“Admission notice delivered on the membership.state transition to applied.” Pick up your phone. The intake notice should already be in your Telegram: the applicant's name, the event id, the address, and the named gap where the email acknowledgment will one day ride. this delivery is the X-02 acceptance; say so and the packet verifies
§4 · the steward's desk

Second act · bind and admit

Two acts belong to the assigned hand and nobody else, and both now happen without the SQL editor. Binding happens by itself: when the newcomer clicks their first magic link, the sign-in with the applied address becomes its agent (0008). Admission is one tap: open the directory as yourself and the Admissions panel stands at the top, pending applications listed with name and address. Admit records the state transition and its membership.admitted event as one act. The portal carries the same panel's pulse: its steward's desk shows a live count of pending applications, visible to the grant alone.

Have the newcomer request a magic link on any member page (for example the agreements shelf) and click it; then tap Admit on their row. Order does not matter: admit first if you like, the binding still completes on their first sign-in.

The manual desk remains available if a case ever falls outside the panel (an address typo, an ambiguous match the auto-bind refused):

do $$
declare
  v_email text := 'the newcomer address';  -- the only thing you type
  v_agent uuid;
begin
  -- the application event carries the address (X-02 seam)
  select e.agent_id into v_agent
    from events e
   where e.kind = 'membership.applied'
     and e.payload->>'email' = v_email
   order by e.recorded_at desc limit 1;

  -- bind: the sign-in with that address becomes the agent (B-01)
  update agents a set auth_user_id = u.id
    from auth.users u
   where a.id = v_agent and u.email = v_email
     and a.auth_user_id is null;

  -- admit: the recorded act of the Board's assigned hand (1.3)
  update memberships set state = 'active' where agent_id = v_agent;
end $$;

-- see the result
select a.display_name, a.auth_user_id is not null as bound, m.state
  from agents a join memberships m on m.agent_id = a.id;

Either way, have the newcomer reload, then have them open the portal: the identity strip resolves their name, membership state, and roles; the doors of the map stand open, Direction among them; no steward's desk appears. The system now knows who asks, and shows each person only their own standing.

§5 · G-B

Third act · Belong

The newcomer drives every beat; you watch. The full script with attestation text is in the Gate Book. In short:

03
newcomer
Read the shelf at /commons/agreements/: every agreement that binds them, version and standing marked, their own chip unsigned.
04
newcomer
Sign the membership agreement. Read the confirmation aloud. Then sign again and watch the system refuse the duplicate. observe: the signature panel; the second attempt refused, not doubled
05
newcomer
Open the directory, appear in it, and edit their own profile. Confirm no edit path exists into anyone else's.
§6 · G-G

Fourth act · Gather

Seed one small real gathering as its host, then let the newcomer walk the cycle. Creation is a host act at the desk for now; the calendar, registration, and attendance all live on the page.

-- the host stands a gathering under a named agreement (2.1)
insert into gatherings (title, host_agent_id, agreement_id)
values ('Run-through gathering',
        '<your agent_id>',
        (select id from agreements order by effective_date desc limit 1))
returning id;

insert into sessions (gathering_id, starts_at, ends_at)
values ('<gathering_id>',
        now() + interval '1 day',
        now() + interval '1 day' + interval '90 minutes');
06
newcomer
Open the calendar, see the gathering and its host, then register, cancel, and register again. observe: the full cycle preserved, never deleted
07
steward
As host, open the attendance panel and record the newcomer present. If you are curious, try to have the newcomer record their own attendance; the system refuses. observe: recorder captured; presence counted where the record counts it
§7 · G-F

Fifth act · Find one another

The newest surface, at /commons/opportunities/. Three acts verify the train.

08
newcomer
Post an opportunity: kind, title, a line of detail. Walk the kind filter and find it on the board. F-01 acceptance
09
steward
Respond to it from your own account. Both of you see the response; the machine has already proven a third member would not (the rehearsal's bystander persona). F-02 acceptance
10
newcomer
Resolve the opportunity with an outcome note. The board shows it closed to everyone; the outcome lands as an event for the parties. F-03 acceptance
§8 · F-04 · T-01

Sixth act · Find, organized; the Desk, quiet

The module work of 2026-07-22: Programs as organizing bodies at /intranet/programs/, and the treasury Desk at /intranet/treasury/, read-only until its instrument adopts.

11
steward
In the desk window, seed the two principal Program agents named by TREASURY-POLICY v1.1 §5, the designation performed as your recorded act:
insert into agents (kind, display_name)
values ('program', 'RegenHub.xyz'),
       ('program', 'techne.coop')
returning id, display_name;
RegenHub.xyz is the workspace operations Program; techne.coop is the craft guild Program, the network of self-organizing communities of practice. Then open the Programs view: both stand in formation, Coordinators to be designated, and the page says honestly that no rates exist until the counting rules record. observe: the roster tells the truth about Programs with no policy
12
newcomer
Post one more small opportunity on the board, then open the Programs view. Your open posting stands on the unaffiliated shelf with the affiliate control beside it, because you are its author. Affiliate it with the Program, and find the line now carries its event id, the opportunity.affiliated row that made the relationship. F-04 acceptance: explore, affiliate, trace the Affiliation to its event
13
steward
Open the Desk. Every section is honestly empty and names the emission that fills it; the instrument panel points at the staged TREASURY-POLICY v1.1 draft, the version that names the two Programs you just seeded. Nothing to act on, and that is the observation: the movement layer refuses to exist ahead of its policy. A balance view is now specified beside it (T-06, TREASURY §9): each rail's reported holding, read-only, with the delta to the record; it stays anticipated until the three read-only rail credentials exist, so there is nothing to walk here yet. T-01 stop: read-only stands; the packet completes on the board's adoption; T-06 waits on the rail reads
the eighth act

Direction

The module work of 2026-07-27: a member gives the instrument work as a recorded act at /intranet/direct/. Walk it once yourself, since the harness that would take the rail on its own is A-04 and does not exist yet; at this stage the relay is your hand, which is exactly what AGY §12 calls R0. What this act proves is the rail and the desk, not the run.

14
member
“A member gives the instrument work, and the record carries who asked.” From the desk, give one Direction: a brief, the kind survey, no repository. observe: the standing strip counted it against your bounds before you gave it; the arc shows it given, with the event id on the line
15
member
“A Direction that crosses the floor is refused in the words of the rule.” Give a second one naming a repository that is not on the Estate list, or give a third and a fourth until the live bound trips. observe: the refusal names AGY §7 or §15 rather than failing silently; nothing enters the record but the refusal
16
steward
“The arc closes by a hand, and the hand is named.” Relay the first Direction to the instrument, then record its accepted and completed events yourself, carrying the direction id and the artifacts. observe: the member's arc now reads given, accepted, completed, with the artifacts linked; this is R0 working exactly as the module describes, and the reason A-03 exists
§9

Read the record back

The system's claim is that state is a fold over events. So fold it, by eye, at the desk:

select e.occurred_at, e.kind,
       coalesce(a.display_name, '(system)') as actor,
       e.payload
  from events e
  left join agents a on a.id = e.actor_agent_id
 order by e.occurred_at;

The morning's story should read in order: an application received, a signature signed, an opportunity resolved, a Direction given, and behind them the July record: the exports, the walkaway, G0. If any act you just performed is missing here, that absence is a defect worth more than any passing suite.

§10

What the system must refuse

A record is defined as much by what it will not do. Each of these is CI-asserted; spot-check whichever you like by hand.

signed outEvery member page shows the auth gate and nothing else. The anon role reads no table.
double signatureSigning the same agreement twice is refused, not duplicated.
another's profileNo member edits any profile but their own.
self-reported presenceAttendance is recorded by host or steward only.
another's postingOnly the author closes an opportunity; a response is invisible to a member who is party to neither side.
the log itselfEvents cannot be updated or deleted, by anyone. Corrections compensate.
§11

Attest and flip

When the walk satisfies you, three gates are ready to attest: G-B and G-G with your countersigner, G-F on the same evidence. G-A waits on a second person and on the first grant, and is not part of this walk. The words and the recording procedure are in the Gate Book: speak the sentence, insert the gate.attested event, and hand me the word; the ledger flips by commit and the roadmap follows.

Left standing after the walk, each named and held: the Q3 counting rules before the Share train exists at all; the TREASURY-POLICY adoption before T-01 completes and the movement layer opens; the read-only rail credentials for Stripe, Mercury, and Xero before the balance view (T-06) can stand; the anchor pass for G-R, re-verifying 0002, 0005, and the schema comments against the governing text (the bylaws mark itself resolved 2026-07-22, the index aligned to the ratified instruments); the Q1 public name for the opportunity surface, yours whenever you want it; the email sink, dormant until the zone manager places two DNS records; and, from the agency train, the first grant with its AM v0.2 addendum, the AGY-ESTATE instrument that would put the Estate list and the flooding bounds on the record instead of in the module's opening values, the §15 visibility decision that fills the commons shelf either way, and the harness rehearsal on your own Directions before any member's.

the run sheet
[ ] join form submitted from the stranger's browser
[ ] intake notice in Telegram            -> X-02 verified
[ ] newcomer bound on first sign-in; admitted from the panel
[ ] portal resolves the newcomer; no steward's desk shown
[ ] agreements read, signed, double-sign refused
[ ] directory: self-edit only
[ ] gathering seeded; register / cancel / return
[ ] attendance recorded by host; self-report refused
[ ] opportunity posted                   -> F-01 verified
[ ] response seen by both parties        -> F-02 verified
[ ] resolved with outcome, closed to all -> F-03 verified
[ ] principal Programs seeded (RegenHub.xyz, techne.coop) -> in formation
[ ] opportunity affiliated; event traced -> F-04 verified
[ ] the Desk read-only; policy staged    -> T-01 awaits adoption
[ ] 0017 and 0018 applied to the live record
[ ] a Direction given from /intranet/direct/ -> A-01 verified
[ ] its arc read back; a refusal shown citing its rule -> A-02 verified
[ ] events log reads the story in order
[ ] G-B spoken and recorded (with countersigner)
[ ] G-G spoken and recorded (with countersigner)
[ ] G-F spoken and recorded