The direction graph reads back, and the reading repairs nothing (#417 part c)

ARCHITECTURE.md

@@ -37,7 +37,7 @@ it. The layers, lowest first:
 | Sync | `synclock.ts`, `transport.ts`, `registrycache.ts`, `pusher.ts`, `puller.ts`, `pushermain.ts` | sending a server-backed store's queue and receiving the workspace's copy. `transport.ts` addresses and authenticates a request and reports a status, some headers and a body — and one further answer, `reached: false`, for a refused connection, an unresolvable name, a socket cut mid-body and a request that ran out of time alike, because all four leave the same question open. `pusher.ts` and `puller.ts` hold the two response tables, written out row by row and first match wins, and they are the review surface for what a status means: nothing else in the tree branches on one. `synclock.ts` is the single-flight lock — synchronous, chmod-free, never waited for — and the one rewrite it guards, which carries onto its replacement whatever the foreground appended while it was deciding. `registrycache.ts` caches the workspace's own project list and each project's server id, which is the one thing that tells a project this machine has never registered from one another machine deleted. This layer sits above Credential and below Pipeline and is the **only** part of the tree that reaches both a token and a store's files: the state writers may hold no import path to a credential, and this holds one, so it asks `pending.ts` and `logfile.ts` to write and they know nothing of it |
 | Domain | `dates.ts`, `skills.ts`, `runbooks.ts`, `instructions.ts` | what is left of the CLI's own domain layer. `dates.ts` holds the two refusals a typed date argument is judged by; the per-domain state shapes and their reducers — `completion.ts`, `objectives.ts`, `entities.ts`, and the calendar arithmetic — are `@superself/fold`. The other three are the derived readings of the record kinds that are composed out of the `entity.*` grammar rather than minted: which records answer as a skill, a runbook or an instruction, what each one is read as, and the lines each prints. They are derivations and nothing else — nothing here is stored, and no event type, reducer or reserved key belongs to them. Each reads the entity fold and its own peers only, never `model.ts`, so the store walk that says *which* records answer in a project is handed to them (`renderedIn`) rather than reached for |
 | Model | `model.ts` | the CLI's end of the fold: the one place a store directory becomes the arguments `@superself/fold` takes — the log, the registry's description, the workspace zone, the session, the verdicts — and the store walks (`workspaceModels`, `projectsHolding`, `readableModels`) that fold a project at a time. The calculation is the package's; this module is what a machine hands it. `foldedOthers` is where a workspace-wide answer folds the projects it is not about: one of them whose state will not read is left out and named on stderr rather than taking the whole answer down, while the project a command *is* about is folded by its caller and refuses loudly — `views.ts` folds the workspace in a second shape and asks the same function, so the rule is written once |
-| Render | `view.ts`, `views.ts`, `pretty.ts`, `output.ts`, `reachability.ts` | HTML and terminal rendering of a folded model; `output.ts` is the render gate — the one function that puts a command's blocks on stdout, and the `notice` a lower layer's message is printed through; the block shapes themselves are declared in `types.ts` |
+| Render | `view.ts`, `views.ts`, `pretty.ts`, `output.ts`, `reachability.ts`, `check.ts` | HTML and terminal rendering of a folded model, and the projections *of* one that are not the fold itself — `reachability.ts` judges evidence against this machine's git, and `check.ts` is the read-only direction check (#417 §6): folds in, findings out, and nothing else. `check.ts` reads no machine at all — no clock, no filesystem, no `process` — because its answer has to be the same on two machines holding the same events; `objective-check.test.mjs` holds its source to the same five rules `apps/fold/test/purity.test.mjs` holds the fold package to. It is here rather than in `@superself/fold` because it reads which records answer as a runbook run, and that derivation is this tree's `runbooks.ts`; `output.ts` is the render gate — the one function that puts a command's blocks on stdout, and the `notice` a lower layer's message is printed through; the block shapes themselves are declared in `types.ts` |
 | Fold | `fold.ts`, `connect.ts` | writing canonical markdown, views, and the managed agent block |
 | Pipeline | `pipeline.ts`, `sanitize.ts` | appending events, then refolding and committing. Which file an append lands in is what the store's mode decides: the store's own `log.jsonl` where it is git-backed, the queue where it is server-backed and `log.jsonl` beside it is the server's copy to write |
 | Command support | `artifact.ts`, `retirement.ts` | what more than one command surface shares: artifact staging (`artifact.ts` also holds the `artifact` verb), and the disclosure-and-approval path every destructive verb takes (`retirement.ts`, read by `main.ts`, `goals.ts` and `state.ts`) |