Guard / foldkit-guard

Limits

  • No rule runs on the client. may is the server's answer for the row as it was read, as stale as the row; a live patch of a field its rules read does not answer it again.
  • A handler's own writes are its own to check. GuardServer.mutation checks the row's rule for its interaction; members it sets and relations it points are not known to it, and no startup check can read them.
  • Under a guard, a create refetches the lists over its Entity. The client cannot tell an answer read back under the writer's rule from one a plain handler made up, so it does not place a created row by the list's body alone.
  • A Sync document is one audience. Per-member or per-row secrecy within one is not something a replicated log offers: GuardSync.document refuses it where it is declared.
  • A write's check and the write are two statements. The row is read and its rules decided, then it is written; a change of owner landing between them is not seen. A write that expects a revision is refused once the row moved; one that does not takes that window.
  • Sync's admit reads the table, which lags the journal. An edit lands in the table when its exchange settles, so an edit admitted before another lands is judged against the row as it was: a concurrent change of owner can let its old owner's edit through. Where that matters, keep the fields a row rule reads out of the document and change them through a guarded Remote write.
  • Sync's authorize is synchronous. Its principal guards' bodies must not suspend; row guards run in admit, which may.
  • A row guard over a field the client sets on create reads as matching nothing while the create leaves it unset; use a preset (presets) for a field that should be the creator's.