Designs 32, 25: a state may be read-only to the tools; nats_requests reads spent so
mesh/delivery merged: source.main moved to novox/hq@d4ae72782336
mesh/check being carried to 304ce84cac18 on d4ae72782336 | from 273d608d9faa
mesh/delivery merged: source.main moved to novox/hq@d4ae72782336
mesh/check being carried to 304ce84cac18 on d4ae72782336 | from 273d608d9faa
Claude-Session: https://claude.ai/code/session_01JG73KJNrH5EgFXMKKYSrig
This commit is contained in:
@@ -945,8 +945,8 @@ acted on is refused, deleting nothing and saying which act that warrant already
|
||||
shorter than the 24 hours `requests` keeps a request: a request whose ask ended unanswered is ended and said, and a
|
||||
warrant is not acted on once its ask ended; the tool raises the ask before it hands the request over. A request
|
||||
that cannot act yet says why in its field Waiting, and a hand act the process could not record is written on the
|
||||
request in its field Unrecorded. The tool `nats_requests` reads the waiting and ended requests and the warrants
|
||||
spent, and drops a waiting request by hand, recorded as a hand act. `create` and `apply` need no warrant, since they only make or grow what an accepted manifest
|
||||
request in its field Unrecorded. The tool `nats_requests` reads the waiting and ended requests, and the warrants
|
||||
spent from `spent`, which is declared `read-only: true` (design 32 § 4) so that the tool reads it and holds no publish on it, and drops a waiting request by hand, recorded as a hand act. `create` and `apply` need no warrant, since they only make or grow what an accepted manifest
|
||||
asks for, and the process refuses either for an entry no accepted manifest asks for. A tool acts only for a caller
|
||||
whose role grants it; the process records each act as a hand act (`mesh-hand-acts`) and answers what it did. What
|
||||
stands between the tool runner's account and the process's delete power is that check of the warrant, so its tests
|
||||
|
||||
@@ -306,6 +306,12 @@ replaced by one form, a **provision** of the bus module, as a database is postgr
|
||||
of a module's kept data it asks through that module's tools or seat verbs (§ 4's tool relationship, `serves`),
|
||||
and what a module lets others hear is its declared events, heard through `consumes` (ADR 0363, unchanged; ADR 0596
|
||||
§1). A bucket's layout is never a contract another module depends on; a tool or a declared event is.
|
||||
- **A state may be read-only to the module's tools.** A state's declaration may carry `read-only: true`: only the
|
||||
processes of the module whose `bus.state` names that state write it, and the module's tools read it, holding no
|
||||
publish on its subjects. The judge refuses a read-only state that no process of the module names. How it is checked:
|
||||
the judge's unit tests for the refusal, and the composition test that a tools bundle's account holds a read on the
|
||||
state and no write. The bus module's state `spent` (design 25 § 12.3) is the first user. (A design limit of the
|
||||
milestone's review; no record decides it yet.)
|
||||
- **The move is a module at a time** (ADR 0595 §11, ADR 0596 §3), each when it is next touched, keeping its local
|
||||
names and its old settings as options so its data stays. A reader moves after its owner: the owner declares the
|
||||
event or gains the tool its readers need first, and the judge refuses a moved module's subscription to an event
|
||||
|
||||
Reference in New Issue
Block a user