Repository navigation
Description
Task
| slice | size | difficulty | model | who | estimated lines |
|---|---|---|---|---|---|
| Round-four residuals closed | M | needs care | standard | an agent | 420 (180 code, 240 tests) |
A box activated right after
min secret setadds an upstream trusts that upstream, with no restart of bep serve.
Covers:
- BEP-013
Layers:
- recertify:
- crates/bep/src/main.rs:
StoreAdmissionre-issues the root and publishes it to the identity file when the control socket reports a store registration change, not only at the next CONNECT, so the next box activation reads a root that admits the new upstream (T99 — Re-certify bep's published root when a store registration changes #2746, arch condition C2 on test(e2e): prove Keychain secrets by reference end to end #2612); the CONNECT path stays the fallback for a rule file edited by hand, and a failed re-issue or publish keeps today's retry - crates/bep/src/control.rs: a control request that re-certifies at once and answers only after the re-issue and the publish, with ok or the reason they failed
cargo nextest run -p bep a_store_registration_change_recertifies_the_published_root_at_once
- crates/bep/src/main.rs:
- client:
- crates/minimal/src/cmd/secret.rs:
min secret setsends the re-certify request after it writes the rule, when a proxy answers on its control socket - crates/minimal/src/mint.rs: the control-socket client that the mint path already uses carries the re-certify request
cargo nextest run -p minimal secret_set_asks_a_running_proxy_to_recertify
- crates/minimal/src/cmd/secret.rs:
- e2e:
- scripts/session-e2e.sh:
proof_bep_store_reference_end_to_enddrops the bep stop and daemon restart that test(e2e): prove Keychain secrets by reference end to end #2612 keeps aftermin secret set, and the comment that names T99 — Re-certify bep's published root when a store registration changes #2746; the box activates against the proxy that was already running ./scripts/session-e2e.sh bep_store_reference_end_to_end
- scripts/session-e2e.sh:
Waits on:
- T29 — Keychain secrets by reference, end to end #2294
- T91 — Admit a widened store rule without restarting bep serve #2618
Found by arch-review on #2612 (T29, epic #1501, arch condition C2 at 11b0a4d8), filed by the epic owner's ruling on 2026-10-29.
Gap. Gatehouse §6.10 line 834 binds re-certification of the published root to a registration change. Today StoreAdmission in crates/bep/src/main.rs admits a widened store rule without a restart (T91, #2663), but bep re-issues the published root only at the next CONNECT. Between min secret set <id> --upstream <host> and that CONNECT, a box that activates reads the old root from the identity file, so it does not trust the new upstream, and it keeps that root.
What closes it. When a store registration changes, StoreAdmission re-certifies the published root at once, so the next box activation reads a root that admits the new upstream. Then scripts/session-e2e.sh bep_store_reference_end_to_end can drop the bep restart that #2612 keeps after min secret set, and the comment that names this issue.
Plan block
### T99 — Re-certify bep's published root when a store registration changes
slice: S13
kind: task
covers: BEP-013
size: M
est: 180 code, 240 tests
executor: agent
difficulty: needs care
model: standard
diagnostics: when a running proxy answers that it did not re-issue or publish the root, `min secret set` says that the rule is saved, name the upstream, and say that a box created before the proxy publishes a root with the change does not reach that upstream, pinned by secret_set_asks_a_running_proxy_to_recertify; with no proxy running it prints nothing new, because `bep serve` issues its root from the current rules when it starts
observability: bep serve logs one info line each time a registration change re-certifies the root, with the number of store rules and whether the publish succeeded; the existing error lines still name a failed re-issue or publish
layers:
- recertify:
- crates/bep/src/main.rs: `StoreAdmission` re-issues the root and publishes it to the identity file when the control socket reports a store registration change, not only at the next CONNECT, so the next box activation reads a root that admits the new upstream (#2746, arch condition C2 on #2612); the CONNECT path stays the fallback for a rule file edited by hand, and a failed re-issue or publish keeps today's retry
- crates/bep/src/control.rs: a control request that re-certifies at once and answers only after the re-issue and the publish, with ok or the reason they failed
test: cargo nextest run -p bep a_store_registration_change_recertifies_the_published_root_at_once
- client:
- crates/minimal/src/cmd/secret.rs: `min secret set` sends the re-certify request after it writes the rule, when a proxy answers on its control socket
- crates/minimal/src/mint.rs: the control-socket client that the mint path already uses carries the re-certify request
test: cargo nextest run -p minimal secret_set_asks_a_running_proxy_to_recertify
- e2e:
- scripts/session-e2e.sh: `proof_bep_store_reference_end_to_end` drops the bep stop and daemon restart that #2612 keeps after `min secret set`, and the comment that names #2746; the box activates against the proxy that was already running
test: ./scripts/session-e2e.sh bep_store_reference_end_to_end
produces: none
consumes: none
proof: A box activated right after `min secret set` adds an upstream trusts that upstream, with no restart of bep serve.
depends on:
- blocked by #2294
- blocked by #2618
Generated by Claude Code
Activity
minimal-foundry commentedon Oct 29, 2026
Done. #2767 merged.
branch
agent/2746-re-certify-bep-s-published-root-when-a-store-reg· epic #1501 · PR #2767d6c7b924Updated 2026-10-31T01:00:22.561Z.
test(e2e): restart bep serve after min secret set in the store case
[-]Re-certify bep's published root when a store registration changes[/-][+]T99 — Re-certify bep's published root when a store registration changes[/+]test(e2e): prove Keychain secrets by reference end to end (gominimal#…
feat(bep): re-certify the published root when a store registration ch…