Task: Keep a member to the parties it works in
Table of Contents
This page documents a task in the Stream the changes as they happen story. It captures the goal, current status, acceptance, and any notes or results.
1. Goal
(Describe what user-visible-or-internal change this task produces.)
2. Status
| Field | Value |
|---|---|
| State | DONE |
| Parent story | Stream the changes as they happen |
| Now | Nothing. |
| Waiting on | Nothing. |
| Next | Nothing. |
| Last touched | 2026-11-04 |
3. Acceptance
4. Plan
- A subscription states a
stream_scope: its tenant, the party the caller works in, and whether the caller sees every party. The hub filters on it when it queues a frame and when it replays one, so a resume cannot widen the scope. - A change that names no party concerns the whole tenant and reaches every party. A change that names one reaches that party and the administrator.
- The route reads the party and roles from the caller's claims:
TenantAdminandSuperAdminsee every party. The gateway decides with what the caller already proved rather than asking IAM, which is what a stream needs: a per-frame call to IAM would be a round trip per change.
5. Measurements
Every number this task claims about a tree, with the command that produced it
and the commit it was measured at. A number without both is not a measurement,
because a clean-up record describes a tree and trunk moves under a branch: a
consumer count, a gate's component count and a suite's size all change with no
code changing, and the reader of a bare number cannot tell which tree it came
from. Where the raw output matters, put it in an evidence/ file beside the
task and name that file in the Command column.
| What | Value | Command | Commit |
|---|---|---|---|
6. Notes
7. Test Scenarios
Manual QA scenarios (scaffolded via compass add test_scenario)
that verify this task. Link
new ones here as they're created; the scenario doc itself links back
via its "Verifies task" field.
| Scenario | State | Notes |
|---|---|---|
8. PRs
| PR | Title |
|---|---|
| #4460 | [http] Complete the change stream: identity, party, conflation |
9. Review
| Comment summary | File | Decision | Notes |
|---|---|---|---|
10. Measurements
| What | Value | Command | Commit |
|---|---|---|---|
| Core suite cases | 55 | ores.http.core.tests |
this branch |
| Core suite assertions | 213 | ores.http.core.tests |
this branch |
11. Result
A stream now hears its own party and the tenant-wide changes, and an
administrator hears every party of the tenant. The hub filters on a
stream_scope when it queues a frame and when it replays one, so a reconnecting
client cannot widen what it sees by asking for a resume. A change that names no
party concerns the whole tenant and reaches every party; one that names a party
reaches that party and the administrator.
The route takes the party and the roles from the caller's claims, so the
decision costs nothing per frame: TenantAdmin and SuperAdmin see every party.
Three cases prove it: a member hears their party and the tenant-wide changes and not another party's; an administrator hears every party of the tenant and no other tenant; and a replay applies the same rule.