C5: Elder synthesis on request #26

Closed
opened 2026-10-28 11:07:54 +00:00 by jacisjake · 0 comments
jacisjake commented 2026-10-28 11:07:54 +00:00 (Migrated from github.com)

Epic: #21. Depends on: #24

Goal

Make the Elder addressable inside a nest as a service role: a member @-addresses @Elder on a thread and the Elder merges the conspiracy's delivers (existing reconcile path), honoring its persona policy (merged answer first, then "Where they differed:").

Acceptance criteria — falsifiable tests

  1. TestElderAddressableInNest — Given nest(Hugin, Munin) with two delivers for one conspiracy request, when owner posts say with to:"Elder" referring to the request, then exactly one message from author:"Elder" is appended whose text contains both delivers' distinguishing words and refers_to = request msg_id. Red now (Elder can't be addressed), green after.
  2. TestElderOnlyMergesOnRequest — with no Elder-addressed message after the same conspiracy, no Elder message appears in the log. Red now, green after (the responder currently ignores unknown crows anyway — make this explicit and regression-proof).
  3. parseAddressing gains Elder/assistant as addressable service handles: TestParseAddressing extended — parseAddressing("please @Elder merge this", nestMembers(nest)) == "Elder". Red now, green after.

Test command

go test -race -run 'TestElder|TestParseAddressing' .

Blockers / unknowns

Elder is not in nest.Crows — membership check must special-case service roles for to, not for posting (Elder replies via harness, tagged_by "harness").

Epic: #21. Depends on: #24 ## Goal Make the Elder addressable inside a nest as a service role: a member @-addresses `@Elder` on a thread and the Elder merges the conspiracy's delivers (existing `reconcile` path), honoring its persona policy (merged answer first, then "Where they differed:"). ## Acceptance criteria — falsifiable tests 1. `TestElderAddressableInNest` — Given nest(Hugin, Munin) with two delivers for one conspiracy request, when owner posts `say` with `to:"Elder"` referring to the request, then exactly one message from `author:"Elder"` is appended whose text contains both delivers' distinguishing words and `refers_to` = request msg_id. Red now (Elder can't be addressed), green after. 2. `TestElderOnlyMergesOnRequest` — with no Elder-addressed message after the same conspiracy, no Elder message appears in the log. Red now, green after (the responder currently ignores unknown crows anyway — make this explicit and regression-proof). 3. `parseAddressing` gains Elder/assistant as addressable service handles: `TestParseAddressing` extended — `parseAddressing("please @Elder merge this", nestMembers(nest)) == "Elder"`. Red now, green after. ## Test command `go test -race -run 'TestElder|TestParseAddressing' .` ## Blockers / unknowns Elder is not in `nest.Crows` — membership check must special-case service roles for `to`, not for posting (Elder replies via harness, tagged_by "harness").
Sign in to join this conversation.