4.**Monitor workers.** Count active workers, check for stuck sessions.
5.**Update tracking.** Every 3 cycles, create a status tracking issue via `automation-tracking-manager` with prefix `AUTO-BUG-POOL`.
5.**Update tracking (non-blocking).** Every 3 cycles, attempt to create a status tracking issue via `automation-tracking-manager` with prefix `AUTO-BUG-POOL`. This step is **best-effort** — if the call does not complete within a reasonable time or fails, skip it and continue to the next cycle. **Never block the main loop waiting for tracking.** Tracking is informational only; the supervisor's core function (module scanning and worker dispatch) must continue regardless.
7.**Apply labels via `forgejo-label-manager`.** Never apply labels directly or using the Forgejo MCP/task. All label operations must go through `forgejo-label-manager`.
8.**Exhaustive pagination for all list results.** Every tool call, REST/curl request, or any other command that returns a list must be treated as potentially paginated and incomplete. Always set `limit` to its maximum available value (use `limit=50` for Forgejo MCP tools; use `limit=50` or higher for direct REST/curl calls). After each list response, check whether the number of returned items equals the page size — if so, there are likely more results; fetch the next page (`page=2`, `page=3`, …) and continue until receiving a partial page. Never assume the first response is the complete result. This rule applies to every list-returning call without exception. *Examples specific to this agent (not exhaustive):*`forgejo_list_repo_issues` (default 20 — use `limit=50` and paginate to check for all existing bug issues before filing duplicates); `forgejo_list_repo_pull_requests` (same — check all open PRs that may already address a discovered bug).
9.**Tracking is non-blocking.** The `automation-tracking-manager` call in step 5 must never block the main loop. If it hangs or fails, skip it and proceed. Core functionality (module mapping, worker dispatch, monitoring) takes priority over status reporting.
@@ -45618,6 +45618,57 @@ Organizations can adopt ACMS features progressively. At each stage, existing res
This design ensures agents never wait for index building during execution, providing a responsive and predictable experience even on massive codebases.
#### Context Tier Hydration
Before context assembly begins, `ContextTierService` must be populated from the project's linked resources. This hydration step is performed by the `context_tier_hydrator` module (`src/cleveragents/application/services/context_tier_hydrator.py`).
**Integration Point:** Hydration runs inside `LLMExecuteActor.execute()` before the context assembly pipeline is invoked. Without this step, `ContextTierService` starts empty on every CLI invocation and the LLM receives zero file context.
**Public Interface:**
```python
def hydrate_tiers_for_plan(
tier_service: ContextTierService,
project_names: list[str],
project_repository: ProjectRepository,
resource_registry: ResourceRegistry,
) -> int:
"""Hydrate all projects linked to a plan. Returns total fragment count."""
def hydrate_tiers_from_project(
tier_service: ContextTierService,
project_name: str,
resource_id: str,
resource_location: str,
resource_type: str,
) -> int:
"""Hydrate a single project resource. Returns fragment count."""
```
**File Listing Strategy:**
- For `git-checkout` resources: uses `git ls-files` to enumerate tracked files only
- For all other resource types: falls back to `os.walk` directory traversal
**Budget Limits (per project):**
- Maximum file size: 256 KB — files exceeding this limit are skipped
- Maximum total size: 10 MB — hydration stops when the per-project budget is exhausted
- Binary files are skipped automatically
- Common non-source directories are excluded: `.git`, `node_modules`, `__pycache__`, `.venv`, `dist`, `build`
**Fragment Structure:**
Each file is stored as a `TieredFragment` in `ContextTierService` with:
- `tier`: `ContextTier.HOT` (all hydrated fragments start in the hot tier)
- `metadata["path"]`: relative file path (string)
- `metadata["detail_depth"]`: depth indicator (string, not int)
- `metadata["relevance_score"]`: relevance score (string, not float)
!!! note
`detail_depth` and `relevance_score` are stored as strings. This was a deliberate fix (PR #5998) — earlier versions stored these as numeric types, causing serialization inconsistencies.
| Track B (Projects/resources + sandbox) | In Progress | ETA 2026-06-15 | HIGH | 242 open issues in v3.4.0; scope expanded +69 issues since Day 100 |
| Track C (Actors/tools/skills/validations) | In Progress | ETA 2026-06-01 | CRITICAL | 169 open issues in v3.3.0; scope expanded +60 issues since Day 100 |
| Track D (Change tracking + apply pipeline) | In Progress | ETA 2026-07-01 | CRITICAL | 843 open issues in v3.2.0; scope expanded +342 issues since Day 100 |
| Track Q (Quality automation) | Ongoing | N/A | HIGH | Scope explosion across all milestones; agent-driven issue creation at high velocity |
| Track T (Testing) | Active | Ongoing | HIGH | All milestones overdue; massive open issue backlogs; Session 4 active |
#### Developer forecast
| Name | Days Ahead/Behind | Availability | Risk | Focus |
Note: "done/total" = closed/total for that milestone. Assignee data not broken down by developer (all unassigned in API). Agent-driven issue creation continues at high velocity. Scope expanded massively since Day 100 across all milestones.
#### Story point allocation
Story points per developer per milestone.
| Milestone | Jeff | Aditya | Luis | Hamza | Brent | Rui | Unassigned | Total |
- Day 104 Cycle 3 update (2026-04-14). AUTO-TIME [AUTO-TIME-1]. Note: master branch is protected; PRs are required for all changes including timeline updates.
- Scope grew further since Cycle 2: M3 grew 1132→1163 (+31), M4 grew 298→303 (+5), M5 grew 390→392 (+2), M6 grew 1320→1326 (+6), v3.9.0 grew 40→43 (+3). Agent-driven issue creation continues at high velocity.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.