|
|
|
@@ -27,7 +27,7 @@ decisions:
|
|
|
|
|
One file of milestone G's part of [design 47](../47-delivery-from-commit-to-delivered.md); the part opens at
|
|
|
|
|
[G.md](G.md). Its design lines are numbered across every file of the part and cited as "design 47 G §n".
|
|
|
|
|
|
|
|
|
|
*§522 and §542 are the operator's answers of 2026-11-11 at 12:11 and 12:33 CET at lead-47's terminal. §543 to §550
|
|
|
|
|
*§522, §542 and §551 to §553 are the operator's answers of 2026-11-11 at 12:11, 12:33 and 12:41 CET at lead-47's terminal. §543 to §550
|
|
|
|
|
answer what the four reviewers found in round 3 of [G-13](G-13-review-round-3.md) (§600 to §609), which has no round
|
|
|
|
|
of its own after it. Every other line answers a question
|
|
|
|
|
develop met after [G-11](G-11-develop-answers-review.md), of internal form only (playbook 07, step 0b), each the
|
|
|
|
@@ -36,7 +36,7 @@ line. Questions that an earlier line already answers have no line here: develop
|
|
|
|
|
|
|
|
|
|
## Kept data on the bus: restore points and what is set aside
|
|
|
|
|
|
|
|
|
|
- §516 **A restore point's bytes, and the forms of `snapshot-kept` and `restore-kept`.** The seat `mesh-broker`'s two
|
|
|
|
|
- §516 **A restore point's bytes, and the forms of `snapshot-kept` and `restore-kept`.** (§551) The seat `mesh-broker`'s two
|
|
|
|
|
verbs (§405) take and answer the forms its definition in mesh-contracts gives them, which this line makes the
|
|
|
|
|
design's: `snapshot-kept` takes `module`, `kept` (the kept data's local name), `form`, `fingerprint`, `why` and
|
|
|
|
|
`catch-up` as `{tool, arguments}` (§451), and answers `point` (the module, the kept data, its form, the
|
|
|
|
@@ -58,8 +58,7 @@ line. Questions that an earlier line already answers have no line here: develop
|
|
|
|
|
aside's `id` is that directory's name, its `name` the bus name it was live under, its `size` its bytes on disk;
|
|
|
|
|
nothing of an aside stays on the bus, so it takes none of the bus's storage limit, and the definition's
|
|
|
|
|
description of `name` reads "the bus name it was live under". `discard-aside` removes that directory and nothing
|
|
|
|
|
else. No part removes a restore point in G: how long one is kept waits for the operator (issue 1921's note), and
|
|
|
|
|
until the answer is written here every point stays. This completes §405 and §406. Why: ADR 0235 has the bus
|
|
|
|
|
else. A restore point is removed only as §551 says. This completes §405 and §406. Why: ADR 0235 has the bus
|
|
|
|
|
module's account write the bus's snapshots into its own directory and the backup holder back that directory up;
|
|
|
|
|
the server restores a stream only where no stream of that name exists, so the live data is set aside as a
|
|
|
|
|
snapshot before the point takes its name (develop questions BKP1, BKP3 and NATS4's argument names). How it is
|
|
|
|
@@ -73,7 +72,7 @@ line. Questions that an earlier line already answers have no line here: develop
|
|
|
|
|
0619 §1, ADR 0666 §4): a point under `point.<module>.<kept>.<form>.<fingerprint>` with the answer's `point` whole,
|
|
|
|
|
written when `snapshot-kept` answers done; an aside under `aside.<module>.<kept>.<at>` with the answer's `aside`
|
|
|
|
|
whole, written when `restore-kept` answers one, each token escaped as a key's name is (§73). The holder deletes an
|
|
|
|
|
aside's key when `discard-aside` answers done, and deletes no other key in G (§516). `backed-up` lists both from
|
|
|
|
|
aside's key when `discard-aside` answers done, and a point's key when it hears that point's `point-removed` (§551). `backed-up` lists both from
|
|
|
|
|
that state, each with its size (§302), and the holder's read tool of its state reads it. The seat `mesh-broker`
|
|
|
|
|
gains no read verb. The holder's old `state` entry `good` moves to `requires` in the same change, keeping its local
|
|
|
|
|
name and settings, as ADR 0595 §11 moves a module G touches. Why: the holder took each from its own call's answer,
|
|
|
|
@@ -452,6 +451,32 @@ line. Questions that an earlier line already answers have no line here: develop
|
|
|
|
|
runner's contract had no field for it (develop's note on §334). How it is checked: unit (runner's contract), the
|
|
|
|
|
field read; whole (runner), a publish's pipeline shows its version.
|
|
|
|
|
|
|
|
|
|
## The operator's answers of 12:41 CET
|
|
|
|
|
|
|
|
|
|
- §551 **A restore point is removed after 90 days, never the newest.** The operator, 2026-11-11 12:41 CET at lead-47's
|
|
|
|
|
terminal. The bus module removes a restore point's directory (§516) 90 days after its `at`, as long as delivery
|
|
|
|
|
records are kept, unless it is the newest point of its module and kept data, which it never removes; it checks at
|
|
|
|
|
its start, once a day and at each `snapshot-kept`, on its own clock and its own directory. Each removal is said as
|
|
|
|
|
the seat `mesh-broker`'s event `point-removed` (`module`, `kept`, `form`, `fingerprint`, `snapshot`, `at`), declared
|
|
|
|
|
in its definition; the backup holder consumes it and deletes that point's key in `bus-points` (§517), and its
|
|
|
|
|
repository's copy goes by the repository's own rotation (ADR 0235 §4). Data set aside is removed only by
|
|
|
|
|
`discard-aside` (§516). This completes §516 and answers issue 1921's note on the retention of restore points. Why:
|
|
|
|
|
the operator's answer; the event, the checks and the holder's deletion are the design's. How it is checked: whole
|
|
|
|
|
(bus module, backup holder), a point older than 90 days is removed and said and its key deleted, and the newest
|
|
|
|
|
point of a kept data, older than 90 days, stays.
|
|
|
|
|
- §552 **The checker may drop its own asks until its removal.** The operator, 2026-11-11 12:41 CET at lead-47's
|
|
|
|
|
terminal: the build seats' verb `drop` (§338) gains the checker as a caller until its entry is removed with its
|
|
|
|
|
buckets and bus account (ADR 0667 §12), as `run` has it, so the validator accepts the checker's manifest's
|
|
|
|
|
`invokes` of `seat:node-build-go.drop` and `seat:node-build-node.drop`. This amends §338. How it is checked: unit
|
|
|
|
|
(manifest validator), the checker's manifest accepted; whole (grants part), the checker's drop granted and another
|
|
|
|
|
module's refused.
|
|
|
|
|
- §553 **A step status left empty is `optional`.** The operator, 2026-11-11 12:41 CET at lead-47's terminal: a step
|
|
|
|
|
whose status a registration's policy (module-level `policy.steps`, or an artifact's) leaves empty is read as
|
|
|
|
|
`optional`: it runs, and a failure is shown and holds nothing (§23); `register` and `policy` accept such a policy
|
|
|
|
|
and refuse nothing for it, and the runner, `registrations` and `show` say the step `optional`. This completes §23.
|
|
|
|
|
How it is checked: unit (runner), a step with no status runs and its failure holds no want; unit (mesh-catalog's
|
|
|
|
|
contract), a registration with an empty status accepted.
|
|
|
|
|
|
|
|
|
|
## Questions an earlier line answers
|
|
|
|
|
|
|
|
|
|
These write nothing new; develop reads the line named.
|
|
|
|
|
