docs: define evaOS Teams Buzz and Hermes architecture - #16
Conversation
Signed-off-by: Eva <eva@100yen.org>
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: Organization UI Review profile: ASSERTIVE Plan: Pro Plus Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: ff11efa8cc
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| BUZZ_ACP_CHANNELS=<derived comma-separated approved channel UUIDs> | ||
| BUZZ_ACP_RESPOND_TO=allowlist |
There was a problem hiding this comment.
If the assigned-agent rooms are implemented as Buzz private channels rather than DM-typed channels, this required env leaves buzz-acp on its default BUZZ_ACP_SUBSCRIBE=mentions; the matcher then drops messages without a p tag, and the desktop client only auto-adds participant p tags for channelType === "dm". That means ordinary messages in the one-human/one-agent private room can be accepted by the relay but never wake Hermes, so the canary's “member can talk to assigned agent” path should either explicitly require DM rooms or set a no-mention/all subscription policy for these private rooms.
Useful? React with 👍 / 👎.
|
|
||
| - Repository: `electricsheephq/buzz` | ||
| - Base: exact integrated release head. | ||
| - Dependency: WP4, WP7, security disposition. |
There was a problem hiding this comment.
This packet signs the internal canary artifact but its explicit dependency list omits WP8, even though the roadmap has branding/managed endpoints feeding the signed artifact and WP8 is what removes upstream endpoints and fixes package identity. If a successor follows the packet text instead of the graph, they can start signing after WP4/WP7 and produce a candidate that still has upstream updater/Builderlab surfaces or incomplete product identity; add WP8 here as a hard dependency.
Useful? React with 👍 / 👎.
| Every owner mutation that affects Buzz access increments | ||
| `customer_buzz_communities.access_revision` and inserts an outbox row in the | ||
| same database transaction. |
There was a problem hiding this comment.
This is the only blanket rule tying Supabase changes to Buzz reconciliation, but it narrows the outbox requirement to “owner mutation” while the revocation contract above also depends on identity rotation, role loss, assignment changes, session revocation, and backend/support actions. If implementers follow this literally, a non-owner key rotation or automated revocation can commit without an access revision/outbox row, leaving relay memberships and bridge allowlists stale until manual repair; make this apply to every authorization, identity, or assignment change that affects Buzz access.
Useful? React with 👍 / 👎.
| |---|---| | ||
| | `id` | UUID primary key | | ||
| | `customer_agent_instance_id` | foreign key; one active identity | | ||
| | `public_key` | canonical hex public key | |
There was a problem hiding this comment.
The human identity table explicitly makes public_key unique while active, but the agent identity table only says “canonical hex public key” even though the contract requires an agent identity not be shared across customer accounts. Without the same active uniqueness constraint here, a duplicated VM/agent key can be projected into two accounts or communities and break the cross-account isolation guarantees; add an active unique constraint for agent public keys as well.
Useful? React with 👍 / 👎.
| Q --> K | ||
| R --> K | ||
| V --> K |
There was a problem hiding this comment.
The normative dependency graph lets the canary proceed from the VM bridge to K without the remote-agent discovery packet, even though the Milestone 1 issue list includes that fix and the canary has separate members who need to see and address VM-hosted agents they do not own locally. Following this graph can produce a signed three-user canary where assigned agents are connected but secondary clients cannot discover or mention them, so add the remote-discovery node as a blocker before K.
Useful? React with 👍 / 👎.
|
This pre-reset staging PR is closed as superseded by merged upstream-first reset PR #37 and the current thin-adapter tracker #1/#36. No code is being deleted. The branch and review history remain available. Retained behavior was replayed narrowly in #37; dropped managed brokers, blanket guards, duplicate UI, and control-signed routine collaboration must not be revived from this PR. |
1 participant
Summary
continuity, revocation, Mac Access reuse, packaging, rollout, and rollback
work packets
Review
Three bounded planning reviews were completed:
Material corrections from review include:
pg_net/Edge Functionpattern and a maximum-10-second recovery sweep.
Validation
git diff --cached --checkv0.4.23Proof boundary
This is an approximately 95%-confidence planning and handoff artifact. It does
not implement or prove a relay, customer login, Hermes continuity, signed
artifact, canary, multi-tenant isolation, or rollout.
Closes no implementation issue.
Parent: #1