RGR guard cannot recover from dirty-tree reviewer veto with missing active ledger #233

New issue

Closed

opened 2026-05-17 11:34:25 -07:00 by jwilger · 0 comments

jwilger commented

2026-05-17 11:34:25 -07:00

Owner

While working on the rootless OCI just serve fix branch, the RGR guard/tool ledger reached an inconsistent state that blocked the normal recovery path after an implementation-review veto.

Observed sequence:

A focused RED/GREEN cycle produced a dirty, uncommitted diff for staged OCI rootfs materialization.
Focused verification passed:
- rtk cargo test -p ar-gateway staged_oci_bundle_materializes_config_and_runtime_command_points_at_stage --lib
- nix build --no-link .#checks.x86_64-linux.ar-gateway-embedded-oci-config-contract
security-reviewer approved the diff.
rgr-implementation-reviewer vetoed a real follow-up issue: directory permissions were applied before copying children, so restrictive packaged directories could make staging fail.
Correct next RGR step should have been to add a new focused RED test in the same dirty checkpoint, then make the minimal GREEN fix before committing.

Tooling state mismatch:

rgr_status reported: No active RGR cycle recorded for this session.
rgr_start refused to start the next cycle because the worktree was dirty: start a new cycle only from a clean worktree.
Delegating to rgr-test-author refused because no active RGR cycle existed.
apply_patch refused Rust test edits under crates/*/src because RED approval was not recorded.
rgr_record_red refused because no RGR cycle was active.
rgr_approve_red refused because no observed RED was recorded.

Impact:

The guardrails prevented both valid recovery paths:

continue the vetoed same-cycle RED/GREEN work in the dirty tree; and
start a new RED cycle for the reviewer-mandated follow-up.

Committing the vetoed dirty state would violate the project RGR discipline, but the RGR tools also blocked writing the corrective RED test.

Expected behavior:

The RGR state machine should support a reviewer-veto recovery path from a dirty, uncommitted GREEN candidate. Possible fixes:

preserve/restore active RGR ledger state across manual/subagent handoffs;
allow an implementation-review veto to reopen the same cycle for a new focused RED while the worktree is dirty;
provide an explicit recovery command for dirty tree + no active ledger + reviewer veto, requiring the orchestrator to record the veto and next RED scope; or
allow test-only RED edits in this recovery state while still blocking production edits until RED approval.

Security note: this is a process/tooling gap, not a secret leak. No secrets were read or committed.

While working on the rootless OCI `just serve` fix branch, the RGR guard/tool ledger reached an inconsistent state that blocked the normal recovery path after an implementation-review veto. Observed sequence: 1. A focused RED/GREEN cycle produced a dirty, uncommitted diff for staged OCI rootfs materialization. 2. Focused verification passed: - `rtk cargo test -p ar-gateway staged_oci_bundle_materializes_config_and_runtime_command_points_at_stage --lib` - `nix build --no-link .#checks.x86_64-linux.ar-gateway-embedded-oci-config-contract` 3. `security-reviewer` approved the diff. 4. `rgr-implementation-reviewer` vetoed a real follow-up issue: directory permissions were applied before copying children, so restrictive packaged directories could make staging fail. 5. Correct next RGR step should have been to add a new focused RED test in the same dirty checkpoint, then make the minimal GREEN fix before committing. Tooling state mismatch: - `rgr_status` reported: `No active RGR cycle recorded for this session.` - `rgr_start` refused to start the next cycle because the worktree was dirty: `start a new cycle only from a clean worktree`. - Delegating to `rgr-test-author` refused because no active RGR cycle existed. - `apply_patch` refused Rust test edits under `crates/*/src` because RED approval was not recorded. - `rgr_record_red` refused because no RGR cycle was active. - `rgr_approve_red` refused because no observed RED was recorded. Impact: The guardrails prevented both valid recovery paths: - continue the vetoed same-cycle RED/GREEN work in the dirty tree; and - start a new RED cycle for the reviewer-mandated follow-up. Committing the vetoed dirty state would violate the project RGR discipline, but the RGR tools also blocked writing the corrective RED test. Expected behavior: The RGR state machine should support a reviewer-veto recovery path from a dirty, uncommitted GREEN candidate. Possible fixes: - preserve/restore active RGR ledger state across manual/subagent handoffs; - allow an implementation-review veto to reopen the same cycle for a new focused RED while the worktree is dirty; - provide an explicit recovery command for `dirty tree + no active ledger + reviewer veto`, requiring the orchestrator to record the veto and next RED scope; or - allow test-only RED edits in this recovery state while still blocking production edits until RED approval. Security note: this is a process/tooling gap, not a secret leak. No secrets were read or committed.

jwilger referenced this issue

2026-05-17 12:09:54 -07:00

fix(gateway): support rootless packaged serve #234

jwilger referenced this issue from a commit

2026-05-17 12:17:49 -07:00

fix(gateway): support rootless packaged serve (#234)

jwilger added the

bug

label

2026-05-17 12:56:19 -07:00

jwilger added this to the 1.0 milestone

2026-05-17 12:56:22 -07:00