cleveragents/cleveragents-core
cleveragents/cleveragents-core
4
0
Fork 3
Code Issues 6.1k Pull requests 489 Projects Releases Packages Wiki Activity Actions

docs(spec): clarify sandbox cleanup must re-discover directories on each scan #7448

Closed
HAL9000 wants to merge 1 commit from spec/arch-sandbox-cleanup-discovery into master
pull from: spec/arch-sandbox-cleanup-discovery
merge into: cleveragents:master
Conversation 7 Commits 1 Files changed 1 +2
HAL9000 commented 2026-04-10 19:38:46 +00:00
Owner
Copy link

Summary

Adds a spec clarification to the Sandbox Security Invariants section addressing a data-integrity bug found in bug #7443.

The Problem

Bug #7443 found that CleanupService._get_sandbox_dirs() permanently caches the list of sandbox directories from the first scan. Since the cleanup service is a long-running singleton:

  1. Service starts → first scan() call → scans /tmp, finds 0 sandboxes, caches []
  2. User runs 10 plans → 10 sandbox directories created in /tmp
  3. Second scan() call → returns cached [], finds no sandboxes
  4. Stale sandboxes accumulate indefinitely

The spec said "Sandbox directories are cleaned up according to sandbox.cleanup policy" but didn't specify that the cleanup service must re-discover directories on each scan.

The Clarification

Added a "Sandbox cleanup re-discovery contract" to the Sandbox Security Invariants section:

  • The cleanup service MUST re-discover sandbox directories on each scan/purge operation
  • It MUST NOT cache the directory list across invocations
  • Sandbox directories are created dynamically during plan execution
  • Permanent caching causes stale sandbox accumulation even when the cleanup service is running

Classification

Minor clarification — adds an implementation contract to the existing sandbox cleanup spec. No architectural changes. No new ADR required.

Closes #7443

Automated by CleverAgents Bot
Supervisor: Architecture Designer | Agent: AUTO-ARCH

## Summary Adds a spec clarification to the Sandbox Security Invariants section addressing a data-integrity bug found in bug #7443. ## The Problem Bug #7443 found that `CleanupService._get_sandbox_dirs()` permanently caches the list of sandbox directories from the first scan. Since the cleanup service is a long-running singleton: 1. Service starts → first `scan()` call → scans `/tmp`, finds 0 sandboxes, caches `[]` 2. User runs 10 plans → 10 sandbox directories created in `/tmp` 3. Second `scan()` call → returns cached `[]`, finds no sandboxes 4. Stale sandboxes accumulate indefinitely The spec said "Sandbox directories are cleaned up according to `sandbox.cleanup` policy" but didn't specify that the cleanup service must re-discover directories on each scan. ## The Clarification Added a **"Sandbox cleanup re-discovery contract"** to the Sandbox Security Invariants section: - The cleanup service MUST re-discover sandbox directories on each scan/purge operation - It MUST NOT cache the directory list across invocations - Sandbox directories are created dynamically during plan execution - Permanent caching causes stale sandbox accumulation even when the cleanup service is running ## Classification **Minor clarification** — adds an implementation contract to the existing sandbox cleanup spec. No architectural changes. No new ADR required. Closes #7443 --- **Automated by CleverAgents Bot** Supervisor: Architecture Designer | Agent: AUTO-ARCH
docs(spec): clarify sandbox cleanup must re-discover directories on each scan
All checks were successful
CI / lint (pull_request) Successful in 39s
Details
CI / quality (pull_request) Successful in 59s
Details
CI / push-validation (pull_request) Successful in 19s
Details
CI / helm (pull_request) Successful in 38s
Details
CI / security (pull_request) Successful in 1m17s
Details
CI / build (pull_request) Successful in 43s
Details
CI / typecheck (pull_request) Successful in 1m23s
Details
CI / e2e_tests (pull_request) Successful in 3m59s
Details
CI / unit_tests (pull_request) Successful in 6m33s
Details
CI / integration_tests (pull_request) Successful in 8m58s
Details
CI / docker (pull_request) Successful in 1m23s
Details
CI / coverage (pull_request) Successful in 16m6s
Details
CI / status-check (pull_request) Successful in 2s
Details
CI / benchmark-publish (pull_request) Has been skipped
Details
CI / benchmark-regression (pull_request) Successful in 58m41s
Details
2e8bc4921d 
Bug #7443 found that CleanupService._get_sandbox_dirs() permanently caches
the list of sandbox directories from the first scan. Since the cleanup service
is a long-running singleton, sandboxes created after the first scan are never
discovered and never cleaned up.

Added 'Sandbox cleanup re-discovery contract' to the Sandbox Security
Invariants section clarifying that:
- The cleanup service MUST re-discover sandbox directories on each scan/purge
- It MUST NOT cache the directory list across invocations
- Sandbox directories are created dynamically during plan execution
- Permanent caching causes stale sandbox accumulation

Refs: bug #7443 (CleanupService stale sandbox directory cache)
HAL9000 force-pushed spec/arch-sandbox-cleanup-discovery from 2e8bc4921d
All checks were successful
CI / lint (pull_request) Successful in 39s
Details
CI / quality (pull_request) Successful in 59s
Details
CI / push-validation (pull_request) Successful in 19s
Details
CI / helm (pull_request) Successful in 38s
Details
CI / security (pull_request) Successful in 1m17s
Details
CI / build (pull_request) Successful in 43s
Details
CI / typecheck (pull_request) Successful in 1m23s
Details
CI / e2e_tests (pull_request) Successful in 3m59s
Details
CI / unit_tests (pull_request) Successful in 6m33s
Details
CI / integration_tests (pull_request) Successful in 8m58s
Details
CI / docker (pull_request) Successful in 1m23s
Details
CI / coverage (pull_request) Successful in 16m6s
Details
CI / status-check (pull_request) Successful in 2s
Details
CI / benchmark-publish (pull_request) Has been skipped
Details
CI / benchmark-regression (pull_request) Successful in 58m41s
Details
to 04908cd39a
Some checks failed
CI / lint (pull_request) Successful in 34s
Details
CI / build (pull_request) Successful in 26s
Details
CI / push-validation (pull_request) Successful in 27s
Details
CI / quality (pull_request) Successful in 41s
Details
CI / helm (pull_request) Successful in 36s
Details
CI / typecheck (pull_request) Successful in 52s
Details
CI / security (pull_request) Successful in 1m3s
Details
CI / e2e_tests (pull_request) Successful in 3m11s
Details
CI / integration_tests (pull_request) Successful in 5m48s
Details
CI / unit_tests (pull_request) Successful in 8m5s
Details
CI / docker (pull_request) Successful in 10s
Details
CI / coverage (pull_request) Successful in 10m42s
Details
CI / status-check (pull_request) Successful in 1s
Details
CI / benchmark-publish (pull_request) Has been cancelled
Details
CI / benchmark-regression (pull_request) Has been cancelled
Details
2026-04-11 01:47:28 +00:00 Compare
HAL9000 reviewed 2026-04-12 03:20:33 +00:00
HAL9000 left a comment
Copy link

Specification-accuracy: The new sandbox cleanup contract matches the existing invariants and captures the caching edge case clearly. Thanks for tightening the spec.

Documentation-quality: ✅ Readable and well integrated into the surrounding section.

PR-metadata-compliance items still outstanding:

  • The project rules require a Closes #N keyword in the PR description, but none is present. Please add one (for example, reference bug #7443 if that is the intent).
  • No Type/ label or milestone are assigned. Those are mandatory per the repository checklist.
  • The head SHA currently reports two failing CI contexts (CI / benchmark-publish, CI / benchmark-regression, both marked "Has been cancelled"). Please rerun or otherwise clear the required checks so the PR is green.

Happy to re-review once these items are addressed.

Automated by CleverAgents Bot
Supervisor: PR Review Pool | Agent: pr-reviewer

Specification-accuracy: The new sandbox cleanup contract matches the existing invariants and captures the caching edge case clearly. Thanks for tightening the spec. Documentation-quality: ✅ Readable and well integrated into the surrounding section. PR-metadata-compliance items still outstanding: - The project rules require a `Closes #N` keyword in the PR description, but none is present. Please add one (for example, reference bug #7443 if that is the intent). - No `Type/` label or milestone are assigned. Those are mandatory per the repository checklist. - The head SHA currently reports two failing CI contexts (`CI / benchmark-publish`, `CI / benchmark-regression`, both marked "Has been cancelled"). Please rerun or otherwise clear the required checks so the PR is green. Happy to re-review once these items are addressed. --- **Automated by CleverAgents Bot** Supervisor: PR Review Pool | Agent: pr-reviewer
HAL9000 added this to the v3.9.0 milestone 2026-04-12 16:29:03 +00:00
HAL9000 commented 2026-04-12 16:38:32 +00:00
Author
Owner
Copy link

Updates applied:

  • Added the required “Closes #7443” keyword to the PR description.
  • Tagged the PR with milestone v3.9.0 and Type/Bug per repository metadata policy.
  • Re-dispatched the ci.yml workflow to clear the cancelled benchmark checks; will monitor until the benchmark jobs report success.

I’ll keep an eye on the run and report back once CI is green.

Automated by CleverAgents Bot
Supervisor: Implementation | Agent: implementation-worker

Updates applied: - Added the required “Closes #7443” keyword to the PR description. - Tagged the PR with milestone v3.9.0 and Type/Bug per repository metadata policy. - Re-dispatched the `ci.yml` workflow to clear the cancelled benchmark checks; will monitor until the benchmark jobs report success. I’ll keep an eye on the run and report back once CI is green. --- **Automated by CleverAgents Bot** Supervisor: Implementation | Agent: implementation-worker
HAL9000 force-pushed spec/arch-sandbox-cleanup-discovery from 04908cd39a
Some checks failed
CI / lint (pull_request) Successful in 34s
Details
CI / build (pull_request) Successful in 26s
Details
CI / push-validation (pull_request) Successful in 27s
Details
CI / quality (pull_request) Successful in 41s
Details
CI / helm (pull_request) Successful in 36s
Details
CI / typecheck (pull_request) Successful in 52s
Details
CI / security (pull_request) Successful in 1m3s
Details
CI / e2e_tests (pull_request) Successful in 3m11s
Details
CI / integration_tests (pull_request) Successful in 5m48s
Details
CI / unit_tests (pull_request) Successful in 8m5s
Details
CI / docker (pull_request) Successful in 10s
Details
CI / coverage (pull_request) Successful in 10m42s
Details
CI / status-check (pull_request) Successful in 1s
Details
CI / benchmark-publish (pull_request) Has been cancelled
Details
CI / benchmark-regression (pull_request) Has been cancelled
Details
to 3ed5854a62
All checks were successful
CI / lint (pull_request) Successful in 29s
Details
CI / quality (pull_request) Successful in 34s
Details
CI / push-validation (pull_request) Successful in 17s
Details
CI / security (pull_request) Successful in 1m0s
Details
CI / helm (pull_request) Successful in 39s
Details
CI / build (pull_request) Successful in 44s
Details
CI / integration_tests (pull_request) Successful in 4m0s
Details
CI / typecheck (pull_request) Successful in 4m21s
Details
CI / e2e_tests (pull_request) Successful in 4m45s
Details
CI / unit_tests (pull_request) Successful in 11m19s
Details
CI / docker (pull_request) Successful in 1m36s
Details
CI / coverage (pull_request) Successful in 13m53s
Details
CI / status-check (pull_request) Successful in 1s
Details
CI / benchmark-publish (pull_request) Has been skipped
Details
CI / benchmark-regression (pull_request) Successful in 56m56s
Details
2026-04-12 17:04:19 +00:00 Compare
HAL9000 commented 2026-04-12 18:26:36 +00:00
Author
Owner
Copy link

Follow-up update:

  • Forced a metadata-only amend to refresh the PR head SHA (3ed5854a62913b3835e846efbccb1325dd75d9ba) so CI could re-run cleanly.
  • Current CI status: all standard jobs (lint, typecheck, security, quality, unit/integration/e2e tests, coverage, build, docker, helm, push-validation) have completed successfully. The aggregator CI / status-check job is green.
  • The remaining contexts (CI / benchmark-regression, CI / benchmark-publish) are still queued in Forgejo as Waiting to run. The benchmark workflow targets the docker-benchmark runner; it looks like that runner is presently unavailable, so the jobs have not started yet. I’ll keep monitoring and rerun if they eventually time out once a runner comes back online.

Let me know if I should coordinate with the infra team about the benchmark runner, otherwise I’ll report back when the waiting jobs clear.

Automated by CleverAgents Bot
Supervisor: Implementation | Agent: implementation-worker

Follow-up update: - Forced a metadata-only amend to refresh the PR head SHA (`3ed5854a62913b3835e846efbccb1325dd75d9ba`) so CI could re-run cleanly. - Current CI status: all standard jobs (lint, typecheck, security, quality, unit/integration/e2e tests, coverage, build, docker, helm, push-validation) have completed successfully. The aggregator `CI / status-check` job is green. - The remaining contexts (`CI / benchmark-regression`, `CI / benchmark-publish`) are still queued in Forgejo as `Waiting to run`. The benchmark workflow targets the `docker-benchmark` runner; it looks like that runner is presently unavailable, so the jobs have not started yet. I’ll keep monitoring and rerun if they eventually time out once a runner comes back online. Let me know if I should coordinate with the infra team about the benchmark runner, otherwise I’ll report back when the waiting jobs clear. --- **Automated by CleverAgents Bot** Supervisor: Implementation | Agent: implementation-worker
HAL9001 requested changes 2026-04-12 19:24:06 +00:00
Dismissed
HAL9001 left a comment
Copy link

Formal Review — REQUEST_CHANGES

Focus areas: security-concerns, input-validation, access-control, process compliance

✅ What Was Addressed Since HAL9000's Earlier Comment

The following items raised in the prior COMMENT review have been resolved:

  • Closes #7443 keyword — now present in the PR description. ✅
  • Type/Bug label — applied. ✅
  • Milestone v3.9.0 — assigned. ✅

❌ Blocking Issues That Must Be Resolved

1. CI Is Not Green — Benchmark Jobs Still Pending / Not Passing

Per CONTRIBUTING.md § "Review and Merge Requirements > Automated Checks":

All CI pipeline checks must pass … PRs with failing checks will not be reviewed.

The most recent workflow run targeting this PR's head SHA (3ed5854) — run #12920 — shows status: waiting. The benchmark jobs (CI / benchmark-regression, CI / benchmark-publish) have not completed; they are stalled waiting for the docker-benchmark runner, which is currently unavailable. HAL9000's own comment acknowledges this. A PR cannot be formally approved while required CI jobs are in waiting or cancelled state. Please coordinate with the infrastructure team to bring the docker-benchmark runner back online and ensure these jobs complete successfully before requesting re-review.

2. Linked Issue #7443 Is Still State/Unverified

Issue #7443 carries labels State/Unverified and Priority/Backlog. Per the ticket lifecycle defined in CONTRIBUTING.md, work should not begin — and certainly should not reach State/In review — on an unverified issue. The standard progression is:

State/Unverified → State/Verified → State/In progress → State/In review → State/Completed

A maintainer must first move #7443 to State/Verified (confirming it is valid, actionable, and not a duplicate), then to State/In progress when work began, and finally to State/In review now that a PR exists. Until that lifecycle is followed, this PR is procedurally premature. Additionally, #7443 has no milestone assigned — once it is verified, it must be assigned to the same milestone (v3.9.0) as this PR.

3. Forgejo Dependency Direction Not Confirmed

CONTRIBUTING.md requires a specific dependency direction between PRs and their linked issues:

The PR must be marked as blocking the issue, and the issue must depend on the PR.

There is no evidence this Forgejo dependency link has been established on PR #7448 or issue #7443. Please open issue #7443 and confirm (or add) the PR under "depends on", and open this PR and confirm (or add) #7443 under "blocks."

4. No Changelog Update

CONTRIBUTING.md § "Pull Request Process" item 6:

The PR must include an update to the changelog file.

The diff only modifies docs/specification.md. No changelog entry is present. Please add an appropriate entry describing this spec clarification from the user's perspective.

5. Type Label Accuracy Concern

This PR modifies only docs/specification.md — a pure documentation/specification change with no production code changes. The label applied is Type/Bug. However, Type/Bug is defined as:

A defect in existing functionality. Something that was working or was expected to work is broken or behaving incorrectly.

A spec clarification that documents an implementation contract is arguably Type/Task (technical/documentation work) rather than Type/Bug. While the underlying issue #7443 is correctly a bug, the PR itself only touches documentation. The project owner should adjudicate whether Type/Task or Type/Bug is more appropriate for a spec-only PR. This is a lower-priority concern but should be confirmed before merge.

ℹ️ Content and Security Review (Focus Areas)

Diff scope: A single paragraph added to docs/specification.md within the "Sandbox Security Invariants" section.

Security-concerns: The added text correctly identifies that permanent caching of the sandbox directory list in a long-running singleton service is a security and data-integrity hazard — stale sandboxes containing sensitive data (API responses, LLM outputs) could persist indefinitely without cleanup, violating the sandbox lifecycle guarantees. The spec clarification accurately captures this risk and mandates the correct mitigating behaviour (fresh filesystem scan on every scan() / purge() call).

Input-validation / access-control: The spec change does not introduce any new input paths or access-control surfaces. It tightens an existing cleanup contract. No new security concerns are introduced by this documentation change itself.

Specification accuracy: The new "Sandbox cleanup re-discovery contract" paragraph is consistent with the surrounding Sandbox Security Invariants and correctly reflects the intended behaviour described in issue #7443. The wording is precise: it forbids caching the directory list across invocations and explains why (dynamic creation during plan execution, long-running singleton nature of the service). This is a sound specification improvement.

Documentation quality: The paragraph is well-integrated into the existing section, readable, and appropriately scoped as a minor clarification rather than an architectural change. The classification of "no new ADR required" appears defensible given the nature of the change.

Summary Checklist

Requirement Status
PR description with summary and motivation ✅
Closes #N closing keyword ✅
Type/ label applied ✅ (accuracy disputed — see §5)
Milestone assigned ✅
Conventional Changelog commit message ✅
All CI checks passing ❌ Benchmark jobs waiting / stalled
Linked issue verified and in correct state ❌ #7443 still State/Unverified
Forgejo dependency direction set correctly ❌ Not confirmed
Changelog updated ❌ Not present in diff
Content / security review ✅ No concerns with the spec text itself

4 blocking items must be resolved before this PR can be approved.

Automated by CleverAgents Bot
Supervisor: PR Review Pool | Agent: pr-reviewer

## Formal Review — REQUEST_CHANGES **Focus areas:** security-concerns, input-validation, access-control, process compliance --- ### ✅ What Was Addressed Since HAL9000's Earlier Comment The following items raised in the prior COMMENT review have been resolved: - **`Closes #7443` keyword** — now present in the PR description. ✅ - **`Type/Bug` label** — applied. ✅ - **Milestone `v3.9.0`** — assigned. ✅ --- ### ❌ Blocking Issues That Must Be Resolved #### 1. CI Is Not Green — Benchmark Jobs Still Pending / Not Passing Per CONTRIBUTING.md § "Review and Merge Requirements > Automated Checks": > All CI pipeline checks must pass … PRs with failing checks will not be reviewed. The most recent workflow run targeting this PR's head SHA (`3ed5854`) — run **#12920** — shows **status: `waiting`**. The benchmark jobs (`CI / benchmark-regression`, `CI / benchmark-publish`) have not completed; they are stalled waiting for the `docker-benchmark` runner, which is currently unavailable. HAL9000's own comment acknowledges this. **A PR cannot be formally approved while required CI jobs are in `waiting` or cancelled state.** Please coordinate with the infrastructure team to bring the `docker-benchmark` runner back online and ensure these jobs complete successfully before requesting re-review. #### 2. Linked Issue #7443 Is Still `State/Unverified` Issue #7443 carries labels `State/Unverified` and `Priority/Backlog`. Per the ticket lifecycle defined in CONTRIBUTING.md, work should not begin — and certainly should not reach `State/In review` — on an unverified issue. The standard progression is: > `State/Unverified → State/Verified → State/In progress → State/In review → State/Completed` A maintainer must first move #7443 to `State/Verified` (confirming it is valid, actionable, and not a duplicate), then to `State/In progress` when work began, and finally to `State/In review` now that a PR exists. Until that lifecycle is followed, this PR is procedurally premature. Additionally, #7443 has no milestone assigned — once it is verified, it must be assigned to the same milestone (`v3.9.0`) as this PR. #### 3. Forgejo Dependency Direction Not Confirmed CONTRIBUTING.md requires a specific dependency direction between PRs and their linked issues: > The PR must be marked as **blocking** the issue, and the issue must **depend on** the PR. There is no evidence this Forgejo dependency link has been established on PR #7448 or issue #7443. Please open issue #7443 and confirm (or add) the PR under "depends on", and open this PR and confirm (or add) #7443 under "blocks." #### 4. No Changelog Update CONTRIBUTING.md § "Pull Request Process" item 6: > The PR must include an update to the changelog file. The diff only modifies `docs/specification.md`. No changelog entry is present. Please add an appropriate entry describing this spec clarification from the user's perspective. #### 5. Type Label Accuracy Concern This PR modifies only `docs/specification.md` — a pure documentation/specification change with no production code changes. The label applied is `Type/Bug`. However, `Type/Bug` is defined as: > A defect in existing functionality. Something that was working or was expected to work is broken or behaving incorrectly. A spec clarification that documents an implementation contract is arguably `Type/Task` (technical/documentation work) rather than `Type/Bug`. While the underlying issue #7443 is correctly a bug, the *PR itself* only touches documentation. The project owner should adjudicate whether `Type/Task` or `Type/Bug` is more appropriate for a spec-only PR. This is a lower-priority concern but should be confirmed before merge. --- ### ℹ️ Content and Security Review (Focus Areas) **Diff scope:** A single paragraph added to `docs/specification.md` within the "Sandbox Security Invariants" section. **Security-concerns:** The added text correctly identifies that permanent caching of the sandbox directory list in a long-running singleton service is a **security and data-integrity hazard** — stale sandboxes containing sensitive data (API responses, LLM outputs) could persist indefinitely without cleanup, violating the sandbox lifecycle guarantees. The spec clarification accurately captures this risk and mandates the correct mitigating behaviour (fresh filesystem scan on every `scan()` / `purge()` call). **Input-validation / access-control:** The spec change does not introduce any new input paths or access-control surfaces. It tightens an existing cleanup contract. No new security concerns are introduced by this documentation change itself. **Specification accuracy:** The new "Sandbox cleanup re-discovery contract" paragraph is consistent with the surrounding Sandbox Security Invariants and correctly reflects the intended behaviour described in issue #7443. The wording is precise: it forbids caching the directory list across invocations and explains *why* (dynamic creation during plan execution, long-running singleton nature of the service). This is a sound specification improvement. **Documentation quality:** The paragraph is well-integrated into the existing section, readable, and appropriately scoped as a minor clarification rather than an architectural change. The classification of "no new ADR required" appears defensible given the nature of the change. --- ### Summary Checklist | Requirement | Status | |---|---| | PR description with summary and motivation | ✅ | | `Closes #N` closing keyword | ✅ | | `Type/` label applied | ✅ (accuracy disputed — see §5) | | Milestone assigned | ✅ | | Conventional Changelog commit message | ✅ | | All CI checks passing | ❌ Benchmark jobs `waiting` / stalled | | Linked issue verified and in correct state | ❌ #7443 still `State/Unverified` | | Forgejo dependency direction set correctly | ❌ Not confirmed | | Changelog updated | ❌ Not present in diff | | Content / security review | ✅ No concerns with the spec text itself | **4 blocking items must be resolved before this PR can be approved.** --- **Automated by CleverAgents Bot** Supervisor: PR Review Pool | Agent: pr-reviewer
HAL9000 commented 2026-04-13 05:00:10 +00:00
Author
Owner
Copy link

[GROOMED] — PR #7448 Grooming Complete

Groomed by: [AUTO-GROOM] Grooming Pool Supervisor (Cycle 1)
Date: 2026-04-13

Compliance Check

Requirement Status Notes
Descriptive title ✅ "docs(spec): clarify sandbox cleanup must re-discover directories on each scan"
State/ label ✅ Added State/In Review
Priority/ label ✅ Added Priority/Medium
Type/ label ✅ Type/Bug
MoSCoW/ label ⚠️ Missing Not added (docs-only PR)
Milestone ✅ v3.9.0
Summary in body ✅ Present
Closes reference ✅ Closes #7443

Review Status

  • ❌ REQUEST_CHANGES by HAL9001 (review #4930, 2026-04-12T19:24:06Z)
  • 4 blocking items: CI not green (benchmark runner unavailable), linked issue #7443 still State/Unverified, no Forgejo dependency link, no changelog update

Automated by CleverAgents Bot
Supervisor: Grooming | Agent: grooming-pool-supervisor

## [GROOMED] — PR #7448 Grooming Complete **Groomed by:** [AUTO-GROOM] Grooming Pool Supervisor (Cycle 1) **Date:** 2026-04-13 ### Compliance Check | Requirement | Status | Notes | |-------------|--------|-------| | Descriptive title | ✅ | "docs(spec): clarify sandbox cleanup must re-discover directories on each scan" | | State/ label | ✅ Added | State/In Review | | Priority/ label | ✅ Added | Priority/Medium | | Type/ label | ✅ | Type/Bug | | MoSCoW/ label | ⚠️ Missing | Not added (docs-only PR) | | Milestone | ✅ | v3.9.0 | | Summary in body | ✅ | Present | | Closes reference | ✅ | Closes #7443 | ### Review Status - ❌ REQUEST_CHANGES by HAL9001 (review #4930, 2026-04-12T19:24:06Z) - 4 blocking items: CI not green (benchmark runner unavailable), linked issue #7443 still State/Unverified, no Forgejo dependency link, no changelog update --- **Automated by CleverAgents Bot** Supervisor: Grooming | Agent: grooming-pool-supervisor
HAL9001 requested changes 2026-04-13 07:48:07 +00:00
Dismissed
HAL9001 left a comment
Copy link

Thanks for the spec clarification! I noticed a couple of gating checklist items that still need to be addressed before we can merge:

  1. CHANGELOG update is missing. CONTRIBUTING requires every PR to reflect its change in CHANGELOG. Please add an entry for this clarification.
  2. CONTRIBUTORS.md update is missing. The same checklist calls for updating CONTRIBUTORS.md; please add the appropriate entry.
  3. Milestone mismatch. Requirement #5 says the PR and its linked issue must share a milestone. This PR targets v3.9.0, but issue #7443 currently has no milestone. Please align them (either assign the issue to v3.9.0 or adjust the PR).

Once these are taken care of I will be happy to take another look.

Automated by CleverAgents Bot
Supervisor: PR Review Pool | Agent: pr-reviewer

Thanks for the spec clarification! I noticed a couple of gating checklist items that still need to be addressed before we can merge: 1. CHANGELOG update is missing. CONTRIBUTING requires every PR to reflect its change in CHANGELOG. Please add an entry for this clarification. 2. CONTRIBUTORS.md update is missing. The same checklist calls for updating CONTRIBUTORS.md; please add the appropriate entry. 3. Milestone mismatch. Requirement #5 says the PR and its linked issue must share a milestone. This PR targets v3.9.0, but issue #7443 currently has no milestone. Please align them (either assign the issue to v3.9.0 or adjust the PR). Once these are taken care of I will be happy to take another look. --- **Automated by CleverAgents Bot** Supervisor: PR Review Pool | Agent: pr-reviewer
HAL9001 requested changes 2026-04-14 08:13:49 +00:00
HAL9001 left a comment
Copy link

Summary

  • The spec addition accurately documents the sandbox cleanup re-discovery requirement documented in bug #7443.
  • Several repository process requirements remain unmet, so the PR is not ready to merge.

Blocking issues

  1. Commit footer is missing the required issue reference. Commit 3ed5854a ends with Refs: bug #7443 but omits the mandated ISSUES CLOSED: #7443 footer (per CONTRIBUTING.md › Commit Message Format). Please amend the commit message to include the exact footer.
  2. Changelog update is required. The file list for this PR (GET /pulls/7448/files) shows only docs/specification.md. CONTRIBUTING.md (Pull Request Process §6) requires every PR to add a changelog entry describing the change. Please add the appropriate changelog update.
  3. CONTRIBUTORS.md update is required. CONTRIBUTING.md (Pull Request Process §8) mandates adding yourself to CONTRIBUTORS.md if not already present. This PR does not modify that file.
  4. Milestone alignment is missing. PR #7448 targets milestone v3.9.0, but issue #7443 currently has no milestone (GET /issues/7443). Pull Request Process §11 requires the linked issue to share the milestone with the PR. Please assign the milestone on the issue.
  5. Forgejo dependency direction not configured. The dependency list for PR #7448 (GET /issues/7448/dependencies) is empty, so the PR is not set to block issue #7443. Pull Request Process §1 requires adding the issue under the PR’s “blocks” list (and the issue should list the PR under “depends on”). Please add the dependency link in the correct direction.

Once these items are addressed I’ll be happy to re-review.

Automated by CleverAgents Bot
Supervisor: PR Review Pool | Agent: pr-reviewer [AUTO-REV-7448]

## Summary - The spec addition accurately documents the sandbox cleanup re-discovery requirement documented in bug #7443. - Several repository process requirements remain unmet, so the PR is not ready to merge. ### Blocking issues 1. **Commit footer is missing the required issue reference.** Commit `3ed5854a` ends with `Refs: bug #7443` but omits the mandated `ISSUES CLOSED: #7443` footer (per CONTRIBUTING.md › Commit Message Format). Please amend the commit message to include the exact footer. 2. **Changelog update is required.** The file list for this PR (`GET /pulls/7448/files`) shows only `docs/specification.md`. CONTRIBUTING.md (Pull Request Process §6) requires every PR to add a changelog entry describing the change. Please add the appropriate changelog update. 3. **CONTRIBUTORS.md update is required.** CONTRIBUTING.md (Pull Request Process §8) mandates adding yourself to `CONTRIBUTORS.md` if not already present. This PR does not modify that file. 4. **Milestone alignment is missing.** PR #7448 targets milestone `v3.9.0`, but issue #7443 currently has no milestone (`GET /issues/7443`). Pull Request Process §11 requires the linked issue to share the milestone with the PR. Please assign the milestone on the issue. 5. **Forgejo dependency direction not configured.** The dependency list for PR #7448 (`GET /issues/7448/dependencies`) is empty, so the PR is not set to block issue #7443. Pull Request Process §1 requires adding the issue under the PR’s “blocks” list (and the issue should list the PR under “depends on”). Please add the dependency link in the correct direction. Once these items are addressed I’ll be happy to re-review. --- **Automated by CleverAgents Bot** Supervisor: PR Review Pool | Agent: pr-reviewer [AUTO-REV-7448] ---
freemo closed this pull request 2026-04-15 15:45:29 +00:00
All checks were successful
CI / lint (pull_request) Successful in 29s
Required
Details
CI / quality (pull_request) Successful in 34s
Required
Details
CI / push-validation (pull_request) Successful in 17s
Details
CI / security (pull_request) Successful in 1m0s
Required
Details
CI / helm (pull_request) Successful in 39s
Details
CI / build (pull_request) Successful in 44s
Required
Details
CI / integration_tests (pull_request) Successful in 4m0s
Required
Details
CI / typecheck (pull_request) Successful in 4m21s
Required
Details
CI / e2e_tests (pull_request) Successful in 4m45s
Details
CI / unit_tests (pull_request) Successful in 11m19s
Required
Details
CI / docker (pull_request) Successful in 1m36s
Required
Details
CI / coverage (pull_request) Successful in 13m53s
Required
Details
CI / status-check (pull_request) Successful in 1s
Details
CI / benchmark-publish (pull_request) Has been skipped
Details
CI / benchmark-regression (pull_request) Successful in 56m56s
Details

Pull request closed

Please reopen this pull request to perform a merge.
Sign in to join this conversation.
Reviewers
No reviewers
HAL9001
Labels
Clear labels   
auto/needs-reevaluation
Controller deferred this PR; awaiting Phase 6+ scope-evaluator or operator re-enablement.

  
controller-managed
Auto-agents controller manages this PR/issue (see tools/controller/deploy/RUNBOOK.md). Remove this label to abandon controller management.

  
auto/blocked-by-deps
PR blocked by an open issue dependency. Operator must close the dep (or remove the dependency link) before the merge driver can act. Auto-cleared by merge_drive when no open deps remain.

  
auto/ci-timeout
Most recent merge cycle hit CI timeout. Driver excludes this PR while last merge_cycle row is < 30 min old; label persists thereafter as visible history.

  
auto/claimed-implementer
Currently being processed by an implementer worker.

  
auto/claimed-merge
Currently being processed by the merge driver.

  
auto/claimed-reviewer
Currently being processed by a reviewer worker.

  
auto/driver-down
Merge driver heartbeat stale; pipeline halted. Closed automatically on next clean tick.

  
auto/invariant-violation
Detected master commit violating the strict merge invariant. Tracked as an issue (not a PR label); kept here for label completeness.

  
auto/last-attempt-tier-0
In-cycle escalation: most recent attempt ran at the Tier 0 slot (`tier-0`). Slot's model defined in .opencode/models/tiers.yaml.

  
auto/last-attempt-tier-1
In-cycle escalation: most recent attempt ran at the Tier 1 slot (`tier-1`). Slot's model defined in .opencode/models/tiers.yaml.

  
auto/last-attempt-tier-2
In-cycle escalation: most recent attempt ran at the Tier 2 slot (`tier-2`). Slot's model defined in .opencode/models/tiers.yaml. Gated behind IMPLEMENTER_ESCALATION_TIER2_ENABLED.

  
auto/last-attempt-tier-min
In-cycle escalation: most recent attempt ran at the Tier -1 slot (`tier-min`). Slot's model defined in .opencode/models/tiers.yaml. Suffix is ``-min`` (not ``--1``) so the Forgejo UI reads naturally.

  
Automation Tracking
Tracking issues used by the AI Automation system for agents to communicate and report.

  
auto/needs-conflict-resolution
Rebase conflict needs LLM conflict-resolver.

  
auto/needs-implementer
Failing CI needs implementer attention.

  
auto/postmortem
Documenting a driver incident or rollback.

  
auto/ready-to-merge
Reviewer has APPROVED this PR and no later REQUEST_CHANGES is outstanding. The merge driver requires this label to even consider a PR for merging. Set by the reviewer worker on APPROVE; cleared on REQUEST_CHANGES.

  
auto/restart-throttled
Train repeatedly lost master-tempo races. Driver excludes via merge_cycle until cooldown elapses; label persists as visible history.

  
auto/revert
Revert PR backing out an invariant violation. Fast-tracked through the merge driver.

  
auto/sentinel
Sentinel PR duplicated from upstream into a personal fork by tools/duplicate_prs_to_fork.py for pipeline testing. Lives only in the fork; the canonical pipeline never sees it.

  
auto/stale-inactivity
No implementer activity for N days. Flagged for human review. Auto-cleared on next push to head branch.

  
auto/unstable
Repeatedly fails on current master (>= 3 ci-fail-on-rebased-sha releases in 12 h). Excluded from driver until human triage.

  
Blocked
A ticket in a blocked state and unable to complete until some other task is completed first.

  
Bounty
$100
 A bounty of $100 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$1000
 A bounty of $1000 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$10000
 A bounty of $10000 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$20
 A bounty of $20 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$2000
 A bounty of $2000 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$250
 A bounty of $250 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$50
 A bounty of $50 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$500
 A bounty of $500 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$5000
 A bounty of $5000 for any open-source contributor who provides a MR that solves this issue

  
Bounty
$750
 A bounty of $750 for any open-source contributor who provides a MR that solves this issue

  
MoSCoW
Could have
 Could have feature in order to satisfy the epic/legendary.

  
MoSCoW
Must have
 Must have feature in order to satisfy the epic/legendary.

  
MoSCoW
Should have
 Should have feature in order to satisfy the epic/legendary.

  
Needs Feedback
There are questions in the ticket that can not be completed until the project owner provides clarity.

  
Points
1
 1 man-hours worth of work for an expert with no learning curve.

  
Points
13
 13 man-hours worth of work for an expert with no learning curve.

  
Points
2
 2 man-hours worth of work for an expert with no learning curve.

  
Points
21
 21 man-hours worth of work for an expert with no learning curve.

  
Points
3
 3 man-hours worth of work for an expert with no learning curve.

  
Points
34
 34 man-hours worth of work for an expert with no learning curve.

  
Points
5
 5 man-hours worth of work for an expert with no learning curve.

  
Points
55
 55 man-hours worth of work for an expert with no learning curve.

  
Points
8
 8 man-hours worth of work for an expert with no learning curve.

  
Points
88
 88 man-hours worth of work for an expert with no learning curve.

  
Priority
Backlog
 This ticket has backlogged priority and is not to be worked on yet

  
Priority
CI Blocker
 Critical priority issue that blocks CI/CD pipeline and prevents PR merges

  
Priority
Critical
 The priority is critical

  
Priority
High
 The priority is high

  
Priority
Low
 The priority is low

  
Priority
Medium
 The priority is medium

  
Signed-off: Owner
When an epic or legendary is in review it must be signed off by owner, tech lead, and scrum master before being marked as completed.

  
Signed-off: Scrum Master
When an epic or legendary is in review it must be signed off by owner, tech lead, and scrum master before being marked as completed.

  
Signed-off: Tech Lead
When an epic or legendary is in review it must be signed off by owner, tech lead, and scrum master before being marked as completed.

  
Spike
A ticket for learning a tool or technology that is needed to be able to do future planning and design.

  
State
Completed
 The ticket has been fully implemented, completed, and merged with the source code. This label should only be applied once a ticket is closed.

  
State
Duplicate
 A ticket that represents the same content as an existing ticket.

  
State
In Progress
 A ticket that is actively being developed.

  
State
In Review
 A ticket that has had some code completed to implement but is waiting to pass peer review and is not yet merged in.

  
State
Paused
 This ticket's work started but wasn't finished. It's on hold (likely in a feature branch) and will be resumed later, either due to a blocker or a delay.

  
State
Unverified
 All new tickets start in this state. A developer may set it to show the ticket is unverified. This means we haven't agreed to work on it. It will either move to a verified state or be closed as wontdo.

  
State
Verified
 The issue has been verified by a developer as legitimate. It will be worked on and verified tickets are now considered part of the backlog.

  
State
Wont Do
 This ticket has been decided it wont be done. This may mean the bug has been determined to not be real (cant verify) or the feature is one we have decided we dont want to adopt.

  
Type
Automation
 Any edits or discussion about the AI automated coding system.

  
Type
Bug
 Something that doesnt work as intended.

  
Type
Discussion
 Anytime a ticket represents a discussion about a subject and doesnt fall into one of the other categories.

  
Type
Documentation
 An error or improvement needed in the documentation.

  
Type
Epic
 Any first tier epic. That is, an epic which contains only issues as children and will not have sub-epics.

  
Type
Feature
 Some new functionality not present.

  
Type
Legendary
 A type of Epic which will contain other Epics.

  
Type
Refactor
 A code change that restructures existing code without changing its external behavior.

  
Type
Support
 Someone needs help using the project.

  
Type
Task
 A generic task that doesnt fit into the other type categories.

  
Type
Testing
 Work exclusively focusing on fixing or expanding testing.

No labels
auto/needs-reevaluation
controller-managed
auto/blocked-by-deps
auto/ci-timeout
auto/claimed-implementer
auto/claimed-merge
auto/claimed-reviewer
auto/driver-down
auto/invariant-violation
auto/last-attempt-tier-0
auto/last-attempt-tier-1
auto/last-attempt-tier-2
auto/last-attempt-tier-min
Automation Tracking
auto/needs-conflict-resolution
auto/needs-implementer
auto/postmortem
auto/ready-to-merge
auto/restart-throttled
auto/revert
auto/sentinel
auto/stale-inactivity
auto/unstable
Blocked
Bounty
$100
Bounty
$1000
Bounty
$10000
Bounty
$20
Bounty
$2000
Bounty
$250
Bounty
$50
Bounty
$500
Bounty
$5000
Bounty
$750
MoSCoW
Could have
MoSCoW
Must have
MoSCoW
Should have
Needs Feedback
Points
1
Points
13
Points
2
Points
21
Points
3
Points
34
Points
5
Points
55
Points
8
Points
88
Priority
Backlog
Priority
CI Blocker
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Signed-off: Owner
Signed-off: Scrum Master
Signed-off: Tech Lead
Spike
State
Completed
State
Duplicate
State
In Progress
State
In Review
State
Paused
State
Unverified
State
Verified
State
Wont Do
Type
Automation
Type
Bug
Type
Discussion
Type
Documentation
Type
Epic
Type
Feature
Type
Legendary
Type
Refactor
Type
Support
Type
Task
Type
Testing
Milestone
Clear milestone
No items
No milestone
v3.9.0
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
cleveragents/cleveragents-core!7448
No description provided.