mara/hyperhive
mara/hyperhive
Watch
0
0
Fork
You've already forked hyperhive
 0
Code Activity

archetype flows behave like the built-ins: switch off per archetype or per agent, board cards, duplicate

Browse source 
The document's disabled list takes archetype:<archetype>/<flow> (off for every member) and the same with @<agent> (off for one member); a key naming nothing is ignored. GET /api/notify/flows lists the archetype flows with their members, the board draws a card for each with a switch, a checkbox per agent and duplicate, and the dry run counts their hits. The flows keep following the archetype.
This commit is contained in:
atlas 2026-11-11 19:08:19 +01:00 • committed by mara
commit 68c24643f6
1 changed files with 908 additions and 102 deletions
Download patch file Download diff file Expand all files Collapse all files

28
docs/4-implementation/swarm/notify-router.md
View file

@ -285,10 +285,34 @@ no archetype. The router reads the `agent-archetypes` record and the
`agent-archetype` key of each agent in its roster at most every 10 seconds, when an event arrives, and runs
each archetype's valid, enabled flows after the built-ins and the document's flows, for the
archetype's agents. The router logs a flow it can't use and leaves it out. A read that fails keeps the archetype flows it had.
Each runs under the id `<archetype>:<id>`, so its todos' source is
`router:<archetype>:<id>`. A recipient not in the roster gets nothing, the same as a named agent that doesn't exist.
Each runs under its key, `archetype:<archetype>/<id>`, which is its flow id in the log, the hit counts and a todo's source (`router:archetype:<archetype>/<id>`). A recipient not in the roster gets nothing, the same as a named agent that doesn't exist.
A todo key is the dedupe key as for any flow: the same key from the operator's document replaces the archetype's todo.
**Switching an archetype flow off.** The document's `disabled_builtins` takes
two more kinds of entry besides built-in ids: an archetype flow's key
(`archetype:<archetype>/<id>`) switches it off for every member, and the key
followed by `@<agent>` for that member only. The check accepts any key of that
shape and doesn't ask whether the flow or agent exists, so an edit to an
archetype can't make the stored document fail it; the router ignores a key that
names nothing. The router applies the list to the archetype flows it has read
(`archetype_flows::enabled`) before it runs them, and a flow with no member left
isn't run. A controller that predates this refuses these keys with a 400, as
it refuses any id that's no built-in.
**On the board.** `GET /api/notify/flows` also returns `archetype_flows`:
`[{archetype, key, flow, members}]`, one per enabled archetype flow that passes
the archetype check and has an agent, with the flow as the archetype declares it
(a `todo` to `"members"`). The controller reads the archetype records and the
`agent-archetype` keys itself; a read that fails leaves the list empty and the
document still comes back. The page draws a card for each, with the `on` switch (the
key), a checkbox per member (the key with `@<agent>`) and `duplicate`, which
opens the editor on `?from=<key>`. The copy replaces `"members"` with the one
member's name, or with an empty agent name when there are two or more, since the
operator's document refuses `members`. Hit counts come from the dry run, which
replays the archetype flows (as the router reads them now, less the document's
switches) next to the document's, under their keys. A router that predates this answers a dry run
with no entry for them, and the page shows zero hits.
**Deploying in any order.** The controller, the router and the UI can be on
different hosts. A router that predates `request_reviewer` reads a document
holding such a node (a custom flow with one) as one it can't read and keeps the