registrystack / registrystack/registry-stack
bregctl dev delivers change-request events only to its own receiver
- Dominant language
- Rust
- Stars
- 2
- Forks
- 0
- Avg merge
- 2h 55m
- Merged PRs (30d)
- 130
Description
Found while writing the public tutorial `Review BReg changes in Casework` (0.30.0 plus the `caseworkctl dev --source-project` work that ships with it).
## Use Case
A reader runs `bregctl dev` and `caseworkctl dev --source-project` side by side. The Casework dev session should learn about a submitted change request the moment the registry emits its event, the same way a deployed Casework runtime does through the registry's webhook destination.
## What we hit
`bregctl dev` writes `eventDestinations` for exactly one receiver: its own retained webhook port, computed by `event_destinations(&compiled, port)` in `crates/registry-bregctl/src/dev/config.rs`. A second local subscriber cannot be registered, so the Casework dev session only learns about new work through reconciliation (the `caseworkctl dev` binding uses a short interval for that reason, see the `reconciliationIntervalMilliseconds` binding setting).
## Proposed Behavior
Let a `bregctl dev` session deliver events to an additional local subscriber: either a documented `--event-subscriber ` style option on `bregctl dev`, or a local registration that `caseworkctl dev --source-project` performs through the public `bregctl` CLI (never a crate dependency, the same rule `caseworkctl source add` follows). The registry's own receiver keeps working.
## Boundaries
Loopback only, HMAC key handled as a file secret the way the existing receiver does, and the dev session must still refuse non-loopback destinations. Related: #936 proposes webhook and PostGIS modes for `bregctl dev`.
Triage: later, not needed for the tutorial (reconciliation covers it).
Contributor guide
Research direction
Start in crates/registry-bregctl/src/dev/config.rs at event_destinations(&compiled, port), then read the reconciliationIntervalMilliseconds binding used by caseworkctl dev. Trace how the existing retained receiver handles its loopback check and HMAC file secret. Done means a bregctl dev session can deliver events to one additional loopback subscriber while retaining its own receiver and rejecting non-loopback destinations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- cli, devtools
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 45/100