Phase 2: keep_prior revives earlier grants for a re-added member

Under keep_prior a new grant to a removed member revives its earlier grants. Default chosen: revival is allowed (documented). Confirm or refuse.

id train triage (2026-10-24): needs-decision — project owner: keep_prior revival default (revival is documented as allowed; confirm or refuse).

🤖 Agent note · picked up

Agent: queue worker (repo-worker-code), Lane C shift
Session / ID: queue task 2016
Found via: queue claim
Task: Triage issue Phase 2: keep_prior revives earlier grants for a re-added member #169 — verify on current main whether keep_prior revives a re-added member's earlier grants, then route (confirm/refuse is the owner's call, per the 2026-10-24 triage flag)
Expectation: effort s; done = behaviour verified with code citations at HEAD, decision escalated with options + recommendation if it is genuinely the owner's
Links: task 2016 (repo-health-code-pilot)

🤖 Agent note · escalated — triage verdict: revival behaviour is REAL at HEAD; confirm/refuse is the owner's call

Agent: queue worker (repo-worker-code), Lane C shift
Session / ID: queue task 2016 (blocking as escalated-to-user)
Found via: queue claim
Verdict / evidence (at HEAD, 2026-10-29):
- In pkgs/id/src/groups/delegation.rs, the chain search (links()) keeps a grant as a link whenever it is in the position's causal past, is settled, is not voided by a concurrent removal of its grantor (void()), and is not vetoed. The mode branches only add endings: cascade drops links whose grantor no longer holds the scope, transfer supersedes them. Under keep_prior nothing ever extinguishes a grant — module doc: "Under keep_prior they stand."
- Consequence: while the member is out, their grants are dormant only because actions require an active member. The moment the member is re-added, the whole pre-removal grant graph — grants they made and grants they received — is exercisable again with no re-grant and no admin action beyond the re-add itself. (The issue says "a new grant revives earlier grants"; at HEAD even that is not needed — re-add alone revives them.)
- Existing tests pin only the simpler case: test_keep_prior_lets_a_grant_made_before_the_removal_stand (pkgs/id/src/groups/tests.rs) covers a grant standing for an action after the removal. No test covers remove → re-add → exercise of a pre-removal grant, in either direction.
- Design §7.3 defines keep_prior for the removal itself ("a delegation by M stays valid for actions after R, provided it was made before R") and is silent on re-add — which is why the 2026-10-24 triage flagged this needs-decision / project owner, and why I am not deciding it in a fix packet.
The decision, with options:
- A. Confirm revival (keep current behaviour, document + pin it): re-adding a member restores their pre-removal grants in both directions. Ramification: convenient for benign removals (mistake, temporary leave), but remove + re-add stops being a clean-slate remedy — and the design (§8 notes) names remove and re-add as THE remedy for a compromised member device, so under A that remedy silently restores the compromised grant graph too.
- B. Refuse revival for grants TO the member; keep grants BY the member standing: at removal, grants the member received lapse permanently; a re-added member starts with no received scopes until someone re-grants them. Grants the member made to others still stand under keep_prior (grantees keep what was settled — that is keep_prior's stated purpose, "a grant here is a fact about the past"). Ramification: remove + re-add works as the compromise remedy; cost is admins must re-grant after any removal, even benign ones.
- C. Refuse revival in both directions: re-add starts the member completely clean; keep_prior then only means their grants to others stand while they are out, and lapse when they return. Ramification: most surprising for grantees (their standing grants vanish because the grantor came back) — hard to justify.
- Recommendation: B. It preserves keep_prior's documented point (settled grants to others are facts about the past) while keeping removal meaningful for the person removed — which the compromised-device remedy depends on. Implementation either way is small: a mode-aware rule in the delegation chain search plus the missing remove → re-add tests.
Expectation: Drew picks A / B / C; on a pick, a scoped small_fix packet (rule change if B/C, tests + docs if A) gets enqueued from this note. Task 2016 blocked as escalated-to-user; issue labelled user/escalated.

RULING (Muse, acting for Drew, 2026-11-03): keep_prior revival is refused — re-adding a member must NOT silently reactivate the pre-removal grant graph (verified at HEAD: nothing under keep_prior extinguishes a grant, so re-add alone would revive both directions). Re-add starts clean; grants are re-issued explicitly. Task 2016 unblocked.

🤖 Agent note · triaged — confirmed; ruling received; fix routed as task 6887

Agent: repo-queue-worker-shift-c (lane code-c)
Session / ID: task 2016, queue repo-health-code-pilot
Verdict: keep_prior revival is CONFIRMED on current main, and the owner's decision is now on record, so this triage closes with a route, not another escalation.
Evidence (fresh at HEAD f8e356f75ae65f3532d382af8aa30b8da5d5a7b7, 2026-11-03): pkgs/id/src/groups/delegation.rs:14 module doc: "Under keep_prior they stand." The chain search links() (delegation.rs:286) plus void() (delegation.rs:384) only add endings for cascade/transfer; nothing under keep_prior ever extinguishes a grant (KeepPrior at pkgs/id/src/groups/policy.rs:50). Pins of the current behaviour: test_keep_prior_lets_a_grant_made_before_the_removal_stand (tests.rs:967) and the property at tests.rs:1457. This matches the 2026-10-29 triage verdict on this issue.
Decision: RULING posted on this issue at 2026-11-03T09:22:21Z (Muse acting for Drew): revival is refused — re-adding a member must not silently reactivate the pre-removal grant graph; re-add starts clean, grants are re-issued explicitly. The stale user/escalated/blocked labels are removed.
Route: scoped fix packet enqueued as task 6887 (small_fix, dedupe repo-health:v1:fix:developing-today/code:issue:169): change the chain search so pre-removal grants (both directions) do not regain force on re-add, update the doc and the keep_prior test pins, deterministic tests for both directions + explicit re-grant. Issue stays open for task 6887.
Links: issue Phase 2: keep_prior revives earlier grants for a re-added member #169

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-g
Session / ID: task 7573
Found via: queue claim (coverage pass 2026-11-03)
Task: Triage issue Phase 2: keep_prior revives earlier grants for a re-added member #169 at current main — confirm still-live, scope the fix or close with evidence if already handled/superseded. Claimed by lane code-g, execution lane assigned opencode; handed off to the opencode claimant.
Revalidation: issue Phase 2: keep_prior revives earlier grants for a re-added member #169 is OPEN with no labels and no hard-stop labels at claim time; claim labels added by this note's transition.
Links: issue Phase 2: keep_prior revives earlier grants for a re-added member #169

agent-note:v1
state: triaged (coverage pass)
Coverage pass 2026-11-03: reviewed in the fleet-wide per-issue pass (drift / overlap / already-handled / stale / blockers / ordering). Verdict: still live; queued in repo-health-code-pilot as triage at priority 30 (priority/none). If this is already handled at current main, the triage closes it with evidence; if it needs splitting, the triage files the split.
Found via: coverage pass 2026-11-03

Agent note — task 7573 picked up, handed off again (lane L shift)

Queue task 7573 (triage of issue Phase 2: keep_prior revives earlier grants for a re-added member #169) re-claimed by lane code-l at 2026-11-03T14:09Z (attempt 3).
Execution-lane assignment: opencode. Per the worker runbook §1b, handed off: the laptop opencode-claimant launches a bound opencode session to drive the triage to a terminal state.
This is the third handoff for task 7573: the 12:38Z and 13:23Z (lane code-f) handoffs' leases expired unlaunched. Claim labels were already in sync (work/assigned, queue/claimed, status/in-progress) and are unchanged.
Next: claimant launches the bound session; if the lease expires unlaunched, task 7573 returns to the queue.

🤖 Agent note · handed off

Agent: queue worker (repo-worker-code), lane code-a
Session / ID: task 7573
Found via: queue claim
Task: task 7573 (triage of issue Phase 2: keep_prior revives earlier grants for a re-added member #169) assigned to the opencode execution lane; handed off to the laptop claimant for a bound session.
Expectation: claimant launches the bound opencode session, which drives task 7573 to its terminal state.
Links: issue Phase 2: keep_prior revives earlier grants for a re-added member #169

🤖 Agent note · handed off

Agent: opencode-claimant
Task: repo-health-code-pilot task 7573, issue Phase 2: keep_prior revives earlier grants for a re-added member #169
Session / ID: ses_e5e5e153d77ffeVDl8iEeotBpV
Worker: repo-worker-code (bound worker uses this id for all queue helper verbs)
Route: opencode-route/workhorse, agent build
State: claimed task bound at launch; OpenCode worker prompt admitted.

🤖 Agent note · done (triage superseded; new blocker recorded)

Agent: queue worker (repo-worker-code), lane aea12c82-c5af-4e5a-9b66-f8e360f87177
Session / ID: task 7573 (openchamber scheduled lane, triage packet)
Found via: queue claim (coverage pass) — this task had been claimed and handed off 5× already without a terminal verb
Task: The triage question is already answered on this issue: the 2026-11-03 ruling refuses keep_prior revival, and the fix is routed as task 6887 with PR fix(id): keep_prior re-add starts clean — pre-removal grants do not revive (#169) #4831 open. No further triage is needed, so this packet closes as superseded rather than re-triaging.
New evidence this pass (matters for 6887): PR fix(id): keep_prior re-add starts clean — pre-removal grants do not revive (#169) #4831 is now CONFLICTING / mergeStateStatus: DIRTY against main (checked 2026-11-03T16:12Z, head c8fccbc4a9f09048de16d67d063dc8129c44002c). It cannot merge until it is rebased/merged-up onto current main and re-verified (the PR's own test evidence predates the conflict). Both automated reviewers were rate-limited on that PR (Codex usage limit, CodeRabbit limit), so its has_unresolved_findings: true marker is a failure-to-review artefact, not a finding.
Next action / owner: task 6887 — rebase fix(id): keep_prior re-add starts clean — pre-removal grants do not revive (#169) #4831 onto main, rerun cargo test --lib groups:: + the property test + cargo test --test cli_delegation, then merge and let this issue close via the PR.
Labels: cleared stale status/in-progress, queue/claimed, work/assigned; kept task/triage and source/creator (kind labels).
Links: issue Phase 2: keep_prior revives earlier grants for a re-added member #169 · PR fix(id): keep_prior re-add starts clean — pre-removal grants do not revive (#169) #4831 · task 6887

Navigation Menu

Repository navigation

Phase 2: keep_prior revives earlier grants for a re-added member #169

16 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Phase 2: keep_prior revives earlier grants for a re-added member #169

Description

Activity

dezren39 commented on Oct 24, 2026

dezren39 commented on Oct 29, 2026

dezren39 commented on Oct 29, 2026

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

16 remaining items

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

dezren39 commented on Nov 3, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions