The knowledge base retracts a wrong decision or clause on the operator's Approve, instead of adding a correcting record #578

Merged
mesh-tools merged 2 commits from fix/knowledge-retract into main 2026-10-31 09:31:32 +00:00
Member

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 5d50b952d4

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
mesh-tools added 2 commits 2026-10-31 09:18:44 +00:00
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.
knowledge-base: keep a retraction from being undone by a later acceptance or a redraft
mesh/delivery merged: source.main moved to novox/mesh-catalog@65fad0ae1c31
mesh/check being carried to 5d50b952d4cb on 65fad0ae1c31 | from a68b39f7b512
5d50b952d4
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.
Author
Member

Delivery novox/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`.
mesh-tools merged commit 65fad0ae1c into main 2026-10-31 09:31:32 +00:00
mesh-tools deleted branch fix/knowledge-retract 2026-10-31 09:31:33 +00:00
Sign in to join this conversation.
No Reviewers
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: novox/mesh-catalog#578