The operator, 2026-10-31: "I'm more a fan of removing incorrect decisions than creating new records, especially if I didn't create and verify/approve the decisions myself". Until now, knowledge-base.withdraw only took back a reserved or proposed record, so every correction added a record on top.
New verb knowledge-base.retract {number, clauses?, why}: it retracts an accepted record whole, or the clauses listed. It takes effect only on the operator's Approve on Telegram, through the same ask path records marked needs-operator use. Once approved, a retracted record or clause no longer holds: ask, holds, get, links, changed-since and progress leave it out or mark it. history keeps every version, and nothing is deleted. Decline or expiry changes nothing, and a waiting retraction can be withdrawn. The whole-set rules accept a retracted target.
Review round 1 found two ways a retracted clause could come back: a record accepted after the retraction, and a return followed by a redraft. Both are fixed: accept() skips retracted targets, Return refuses a record with a retraction, and Retract refuses while drafting is not done. Table rows cover each, on the in-memory store and postgres.
Quick vs thorough: the quick fix was to let withdraw drop an accepted record at once, which skips the approval and hides the record. The thorough fix was chosen: a separate verb honoured by every read and by the rules, approved by the operator, history kept.
Checks: gofmt clean; go vet (plain and -tags integration) clean; go test ./... and -tags integration pass on both stores. 104 unit and 1 integration tests (budget 500/50).
The operator, 2026-10-31: "I'm more a fan of removing incorrect decisions than creating new records, especially if I didn't create and verify/approve the decisions myself". Until now, knowledge-base.withdraw only took back a reserved or proposed record, so every correction added a record on top.
New verb knowledge-base.retract {number, clauses?, why}: it retracts an accepted record whole, or the clauses listed. It takes effect only on the operator's Approve on Telegram, through the same ask path records marked needs-operator use. Once approved, a retracted record or clause no longer holds: ask, holds, get, links, changed-since and progress leave it out or mark it. history keeps every version, and nothing is deleted. Decline or expiry changes nothing, and a waiting retraction can be withdrawn. The whole-set rules accept a retracted target.
Review round 1 found two ways a retracted clause could come back: a record accepted after the retraction, and a return followed by a redraft. Both are fixed: accept() skips retracted targets, Return refuses a record with a retraction, and Retract refuses while drafting is not done. Table rows cover each, on the in-memory store and postgres.
Quick vs thorough: the quick fix was to let withdraw drop an accepted record at once, which skips the approval and hides the record. The thorough fix was chosen: a separate verb honoured by every read and by the rules, approved by the operator, history kept.
Checks: gofmt clean; go vet (plain and -tags integration) clean; go test ./... and -tags integration pass on both stores. 104 unit and 1 integration tests (budget 500/50).
Reviewed-by: rev-retract@shanks at 5d50b952d4cbec213f6311859d4c3fb60aaa8a03
The operator prefers removing a wrong decision to stacking a correcting
record on it, and withdraw took only reserved or proposed records. retract
asks the operator through the router like a record that needs the operator,
and changes nothing until the Approve; a retracted record or clause no longer
holds in ask, holds, get, links and progress, history keeps every version, and
the whole-set rules still read a retracted record's links so a retraction alone
raises no finding. withdraw with retraction true takes a waiting one back.
A record proposed before a retraction and accepted after it marked the
retracted clause changed or the retracted record superseded, serving it again;
and returning a drafted record numbered its clauses anew, bringing retracted
ones back in force or making a waiting Approve mark another clause. accept now
leaves what is retracted alone, Return refuses a record with a retraction, and
retract waits until a record's drafting is done.
Deliverynovox/mesh-catalog@5d50b952d4cb — merged since 2026-10-31T09:31:34Z
Source — source.main moved to novox/mesh-catalog@65fad0ae1c. Whether it reached the machines is mesh-delivery-view's, derived from source.main, the wants and the haves.
Transitions
2026-10-31 09:18 (new) → proposed (announced): novox/mesh-catalog#578's head announced
2026-10-31 09:18 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false)
2026-10-31 09:31 ready → merged (merged): on the trunk its modules follow: merged there
The commit's note under refs/notes/mesh-plan keeps every transition of this change up to its merge: git log --notes=mesh-plan.
<!-- mesh-delivery:view -->
**Delivery** `novox/mesh-catalog@5d50b952d4cb` — **merged** since 2026-10-31T09:31:34Z
**Source** — source.main moved to novox/mesh-catalog@65fad0ae1c31. Whether it reached the machines is `mesh-delivery-view`'s, derived from `source.main`, the wants and the haves.
**Transitions**
- 2026-10-31 09:18 (new) → proposed (announced): novox/mesh-catalog#578's head announced
- 2026-10-31 09:18 proposed → ready (accepted): a verdict names this commit and the trunk's head as its trunk commit, the gate passed or warned, and the repository's own check did not fail; or the check gates no merge (check-gates-merge false)
- 2026-10-31 09:31 ready → merged (merged): on the trunk its modules follow: merged there
The commit's note under `refs/notes/mesh-plan` keeps every transition of this change up to its merge: `git log --notes=mesh-plan`.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
The operator, 2026-10-31: "I'm more a fan of removing incorrect decisions than creating new records, especially if I didn't create and verify/approve the decisions myself". Until now, knowledge-base.withdraw only took back a reserved or proposed record, so every correction added a record on top.
New verb knowledge-base.retract {number, clauses?, why}: it retracts an accepted record whole, or the clauses listed. It takes effect only on the operator's Approve on Telegram, through the same ask path records marked needs-operator use. Once approved, a retracted record or clause no longer holds: ask, holds, get, links, changed-since and progress leave it out or mark it. history keeps every version, and nothing is deleted. Decline or expiry changes nothing, and a waiting retraction can be withdrawn. The whole-set rules accept a retracted target.
Review round 1 found two ways a retracted clause could come back: a record accepted after the retraction, and a return followed by a redraft. Both are fixed: accept() skips retracted targets, Return refuses a record with a retraction, and Retract refuses while drafting is not done. Table rows cover each, on the in-memory store and postgres.
Quick vs thorough: the quick fix was to let withdraw drop an accepted record at once, which skips the approval and hides the record. The thorough fix was chosen: a separate verb honoured by every read and by the rules, approved by the operator, history kept.
Checks: gofmt clean; go vet (plain and -tags integration) clean; go test ./... and -tags integration pass on both stores. 104 unit and 1 integration tests (budget 500/50).
Reviewed-by: rev-retract@shanks at
5d50b952d4Delivery
novox/mesh-catalog@5d50b952d4cb— merged since 2026-10-31T09:31:34ZSource — source.main moved to novox/mesh-catalog@65fad0ae1c. Whether it reached the machines is
mesh-delivery-view's, derived fromsource.main, the wants and the haves.Transitions
The commit's note under
refs/notes/mesh-plankeeps every transition of this change up to its merge:git log --notes=mesh-plan.