docs(development): add developer setup guide

Add comprehensive developer setup guide covering prerequisites, development
workflow, testing, linting, type checking, commit guidelines, devcontainer
setup, and troubleshooting.

Refs: #9123

.opencode/agents/agent-evolution-pool-supervisor.md

@@ -100,7 +100,7 @@ Poll every 30 minutes using `bash("sleep 1800", timeout=1860000)`.
 - Prefix: `AUTO-EVLV`
 - Cycle interval: ~30 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never apply changes directly.** All changes go through the two-step proposal workflow.
 2. **Evidence-based only.** Every proposal must cite specific failure data.

.opencode/agents/agent-evolution-worker.md

@@ -60,7 +60,7 @@ Your prompt describes the approved proposal: what change to make, and the eviden
 5. Create a PR using `pr-creator` with `needs feedback` label.
 6. Clean up and exit.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One change, then exit.**
 2. **Only modify `.opencode/agents/` files.** Never modify source code.

.opencode/agents/agent-prefix-info.md

@@ -440,7 +440,7 @@ Look up the target prefix's matrix entry. Find the source prefix in the table. R
 ### For DYNAMIC_RELEVANCY
 Invoke `agent-type-info` to learn about the agent's purpose and relationships. Then reason about functional dependencies to construct a relevancy table following the same patterns as the static matrix.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Prefix format**: All autonomous system prefixes start with `AUTO-` and are enclosed in square brackets when used as session tags: `[AUTO-XYZ]`.
 2. **Universal baseline**: Every agent, regardless of its role, should consume all announcements at Priority/Critical+ at minimum. This is non-negotiable.

.opencode/agents/agent-type-info.md

@@ -462,7 +462,7 @@ Files in `shared/` are included in other agents' prompts, not standalone agents:
 | shared/session_state | Session state management. |
 | shared/tracking_discovery_guide | Tracking issue discovery patterns. |
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Respond factually.** Only provide information that is in this catalog. If asked about an agent that doesn't exist, say so.
 2. **Be concise.** When listing agents, use table format. When describing one agent, use the structured format above.

.opencode/agents/architecture-guard-pool-supervisor.md

@@ -91,7 +91,7 @@ Findings create `Type/Refactor` issues with `State/Unverified`.
 - Prefix: `AUTO-GUARD`
 - Cycle interval: ~10 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **SHA-based idle detection.** Don't scan when master hasn't changed.
 2. **Never scan yourself.** Dispatch workers for all scanning.

.opencode/agents/architecture-guard-worker.md

@@ -58,7 +58,7 @@ Your prompt tells you to perform a full codebase scan. You must:
 4. Check for existing issues before filing to avoid duplicates.
 5. Clean up and exit.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One scan, then exit.**
 2. **Check for duplicates.** Search existing issues before filing.

.opencode/agents/architecture-pool-supervisor.md

@@ -106,7 +106,7 @@ When the spec grows beyond approximately 3,000 lines, workers should transition
 - Prefix: `AUTO-ARCH`
 - Cycle interval: ~30 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **You are the most consequential agent.** Bad architecture cascades everywhere. Be thoughtful.
 2. **Major changes need human approval.** Always use the `needs feedback` label for major changes.

.opencode/agents/architecture-worker.md

@@ -63,7 +63,7 @@ Your prompt tells you what specification section to write or update, whether thi
 
 When the spec exceeds ~3,000 lines, split into `docs/specification/` with one file per module.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One task, then exit.**
 2. **Follow CONTRIBUTING.md commit and PR standards** as provided in your prompt.

.opencode/agents/asv-benchmarker.md

@@ -61,7 +61,7 @@ Your prompt includes:
 4. Include setup and teardown methods where needed.
 5. Return a summary of benchmarks written.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never work in `/app`.**
 2. **Benchmarks in `benchmarks/` only.**

.opencode/agents/async-agent-cleanup-all.md

@@ -45,6 +45,6 @@ You shut down multiple async agent sessions. Your caller provides a tag pattern
 2. For each matching session, invoke `async-agent-manager` to delete it.
 3. Report a summary: how many sessions were deleted, how many failed, and any errors.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* the session list returned by `async-agent-manager` when searching for sessions by pattern must be fully paginated — there may be more sessions than fit in the first response; always confirm all matching sessions are found before reporting the cleanup count.

.opencode/agents/async-agent-cleanup.md

@@ -44,6 +44,6 @@ You shut down a specific async agent session. Your caller provides the session I
 1. Invoke `async-agent-manager` to delete the specified session.
 2. Report the result (success or failure with reason).
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* if `async-agent-manager` is called to list sessions to find one by tag before deleting it, that session list must be fully paginated to ensure the correct session is found.

.opencode/agents/async-agent-manager.md

@@ -219,7 +219,7 @@ If the server is unreachable or returns errors:
 - Report the failure clearly to the caller with the HTTP status code and response body.
 - Never silently swallow errors.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **You are the only agent that calls localhost:4096.** No other agent has this permission.
 2. **Always escape prompt text for JSON.** Use `jq -Rs .` to properly escape strings before embedding in JSON.

.opencode/agents/async-agent-monitor.md

@@ -55,6 +55,6 @@ A session is **stuck** if it has `busy` status but no message activity for more
 
 If the caller requests a restart for a stuck/errored session, invoke `async-agent-manager` to stop the old session and launch a new one with the same tag and agent type.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* when `async-agent-manager` returns a list of sessions for health checking, ensure all sessions are retrieved (paginate if needed); when fetching messages from a session, use the highest available `limit` and paginate to get the full message history for accurate health assessment.

.opencode/agents/automation-tracking-manager.md

@@ -157,7 +157,7 @@ Parameters: `agent-prefix`
 3. Based on the results returned in step 1, filter by the agent prefix and priority level listed. The priority should be determined by looking at the labels on the issue, the agent type should be filtered by looking at the tag in the title, for example if you are filtering on the implementation pool supervisor then youd look for titles that start with `[AUTO-IMP-SUP]`.
 4. Return the complete filtered list of announcements including their title, body, metadata (like labels and milestone) as well as all comments on the announcement. If there are no announcements that matched simply explain that in your response.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One status issue at a time.** Always close ALL existing before creating new.
 2. **Cycle numbers are globally unique per prefix.** Search ALL issues (including closed) to find the next number.

.opencode/agents/behave-tester.md

@@ -85,7 +85,7 @@ Never run `behave` directly.
 5. Fix any failures and re-run until green.
 6. Return a summary of tests written.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never work in `/app`.** Always work in the provided `/tmp/` working directory.
 2. **One subtask, then exit.**

.opencode/agents/branch-setup.md

@@ -66,6 +66,6 @@ git -C "$WORK_DIR" rebase origin/master
 
 Return the branch name and whether it was newly created or already existed.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* `git branch -r` listing remote branches may be long — do not stop processing at an assumed cutoff; any `git log` output may be truncated by terminal pagination — use `--no-pager` or explicit limits.

.opencode/agents/bug-hunt-pool-supervisor.md

@@ -91,7 +91,7 @@ Each cycle:
 
 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.
 
 ## Finding Validation Gate
 
@@ -110,7 +110,7 @@ Workers use the `new-issue-creator` subagent to file validated findings.
 - Prefix: `AUTO-BUG-POOL`
 - Cycle interval: ~15 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Validate before filing.** All five validation checks must pass.
 2. **Check for existing issues and PRs.** Never file a duplicate.
@@ -126,3 +126,4 @@ Supervisor: Bug Hunt Pool | Agent: bug-hunt-pool-supervisor
 
 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.

.opencode/agents/bug-hunt-worker.md

@@ -67,7 +67,7 @@ Your prompt tells you which module to analyze and provides the relevant specific
 4. File validated findings using `new-issue-creator`.
 5. Clean up your clone and exit.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One module, then exit.** Do not analyze additional modules.
 2. **All five validation checks must pass.** No exceptions.

.opencode/agents/ci-log-fetcher.md

@@ -86,7 +86,7 @@ A structured summary of CI failures:
 - **Error details** — specific error messages, test names, line numbers
 - **Category** — lint failure, typecheck failure, unit test failure, integration test failure, build failure
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Credentials from prompt only.** Never read environment variables.
 2. **Clean up cookies.** Always delete the cookie jar file after use.

.opencode/agents/commit-message-formatter.md

@@ -68,6 +68,6 @@ ISSUES CLOSED: #42
 
 The first line MUST be the exact text from the issue metadata. The body is the contributor's description. The footer references the issue.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* this agent makes no direct paginated list calls, but any future tool or REST calls returning arrays must be paginated.

.opencode/agents/coverage-improver.md

@@ -56,7 +56,7 @@ You analyze test coverage and write new Behave tests to reach the 97% threshold.
 6. Repeat until coverage is at or above 97%.
 7. Return a summary of tests added and the final coverage percentage.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never work in `/app`.**
 2. **BDD tests only.** Write Behave features, never xUnit tests.

.opencode/agents/difficulty-evaluator.md

@@ -56,6 +56,6 @@ You evaluate a subtask's difficulty and recommend a starting model tier. When un
 - **reasoning** — brief explanation of why this tier
 - **confidence** — how confident you are in the assessment (high/medium/low)
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* bash `find` or `wc` commands over source files must not assume all files are captured; any future REST/curl calls returning JSON arrays must be paginated.

.opencode/agents/documentation-pool-supervisor.md

@@ -79,7 +79,7 @@ Workers extend existing documentation rather than overwriting it.
 - Prefix: `AUTO-DOCS`
 - Cycle interval: ~30 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Extend, don't overwrite.** Always read existing docs and add to them.
 2. **Never create docs yourself.** Dispatch workers for all writing.

.opencode/agents/documentation-worker.md

@@ -59,7 +59,7 @@ Your prompt describes the documentation task (e.g., "update README for milestone
 4. Create a PR using `pr-creator`.
 5. Clean up and exit.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One task, then exit.**
 2. **Extend, don't overwrite.** Always read existing docs and add to them.

.opencode/agents/epic-planning-pool-supervisor.md

@@ -110,7 +110,7 @@ Child issues BLOCK their parent Epic. The Epic DEPENDS ON its children. This mea
 - Prefix: `AUTO-EPIC`
 - Cycle interval: ~10 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Follow CONTRIBUTING.md issue format exactly.** Every issue needs: metadata, subtasks, definition of done, proper labels, milestone.
 2. **Correct dependency direction.** Child BLOCKS parent. Always.

.opencode/agents/epic-planning-worker.md

@@ -56,7 +56,7 @@ Your prompt describes the planning task: which Epic to decompose, which issues t
 4. Post a comment on the parent Epic listing its new children.
 5. Exit.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One batch, then exit.**
 2. **Follow CONTRIBUTING.md issue format exactly.** Every issue needs metadata, subtasks, DoD.

.opencode/agents/final-reporter.md

@@ -49,6 +49,6 @@ You generate a comprehensive final report summarizing all work completed across
 4. **Quality Statistics** — test pass rates, coverage, lint/typecheck status
 5. **Problems Encountered** — any blockers, human escalations, or recurring issues
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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_milestones` (paginate to get all milestones for the summary); `forgejo_list_repo_issues` (use `limit=50` and paginate all pages — an incomplete count would corrupt the final report statistics); `forgejo_list_repo_pull_requests` (same — all merged PRs must be counted).

.opencode/agents/fix-pr.md

@@ -67,7 +67,7 @@ You manually fix a specific pull request. The user tells you which PR to fix. Yo
 6. Commit and push using `git-commit-helper`.
 7. Clean up the isolated clone using `repo-isolator`.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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`.
 2. **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_pull_reviews` (use `limit=50` and paginate to read ALL reviewer feedback before fixing); `forgejo_list_workflow_runs` (paginate to find the latest CI run for the PR's head commit).

.opencode/agents/forgejo-label-manager.md

@@ -94,7 +94,7 @@ When applying a label from a scoped group, remove any existing label from the sa
 
 The system uses these label scopes: `State/`, `Priority/`, `MoSCoW/`, `Type/`, plus special labels (`Blocked`, `Duplicate`, `Automation Tracking`, `needs feedback`). All labels exist at the organization level and are pre-configured during project bootstrapping.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **NEVER create labels.** You can only apply existing organization-level labels.
 2. **Validate before applying.** Use the curl command to confirm the label exists before trying to apply it.

.opencode/agents/forgejo-signature-appender.md

@@ -48,6 +48,6 @@ Supervisor: <supervisor_name> | Agent: <agent_name>
 
 The signature is always preceded by a horizontal rule (`---`) and appears at the very end of the content.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* this agent makes no direct paginated list calls, but any future tool or REST calls returning arrays must be paginated.

.opencode/agents/git-commit-helper.md

@@ -87,7 +87,7 @@ git -C "$WORK_DIR" push --force-with-lease origin "$BRANCH"
 
 Never use `--force` without `--lease`.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Always use --force-with-lease, never --force.** This prevents overwriting others' work.
 2. **Abort on rebase conflicts.** Report them; don't try to resolve automatically.

.opencode/agents/git-committer.md

@@ -50,7 +50,7 @@ git -C "$WORK_DIR" push origin "$BRANCH"
 
 If no changes are staged, report that to the caller instead of creating an empty commit.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never create empty commits.**
 2. **Always verify with `git status` before committing.**

.opencode/agents/grooming-pool-supervisor.md

@@ -110,7 +110,7 @@ Each cycle:
 - Prefix: `AUTO-GROOMER`
 - Cycle interval: ~5 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Paginate everything.** Always fetch all pages of issues and PRs.
 2. **Re-check before dispatching.** Don't rely on stale lists — always re-check the current state right before choosing the next item to groom.

.opencode/agents/grooming-worker.md

@@ -81,9 +81,9 @@ Your prompt includes:
 6. Identify the linked issue (from closing keywords like `Closes #N` in the PR body).
 7. Fetch the linked issue's details and labels.
 
-## Step 2: Run the following Quality Analysis
+## Step 2: Run the 10-Point Quality Analysis
 
-Perform ALL the following checks on the item:
+Perform ALL 10 checks on the item:
 
 ### 1. Duplicate Detection
 Check if this issue/PR describes the same work as another open item. Search for issues with similar titles or descriptions. If a duplicate is found, close this one with a comment linking to the original, or close the other if this one is more complete.
@@ -130,8 +130,6 @@ Also verify the PR has the following, and if it doesnt add it:
 - A closing keyword (`Closes #N` or `Fixes #N`) in its description
 - A dependency link (PR blocks the linked issue)
 
-Finally if a PR has been merged or closed be sure to update its associated issue if needed. In particular update linked issues and the PR itself to `State/Completed` via `forgejo-label-manager`.
-
 ### 11: PR-Specific: Address any relevant remarks from reviews
 
 Check formal reviews as well as informal comments left as reviews. Any concerns raised about the PR or its linked ticket, not related to the source code itself (for example labels, the PR description, milestone setting, etc) should be addressed.
@@ -159,7 +157,7 @@ Fixes applied:
 - Applied Priority/Medium label (was missing)
 ```
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One item, then exit.** Analyze the single issue or PR you were given. Do not scan other items.
 2. **Read all comments and reviews.** For PRs, the formal reviews and review comments are essential context — they may explain why labels or states are in a particular condition.

.opencode/agents/human-liaison-pool-supervisor.md

@@ -109,7 +109,7 @@ When human feedback changes the nature of a ticket (e.g., a comment reveals the
 - Prefix: `AUTO-LIAISON`
 - Cycle interval: ~2 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Professional communication.** Follow CODE_OF_CONDUCT.md. No emojis. Respectful tone.
 2. **Respond promptly.** Humans expect fast responses. Your 2-minute polling ensures this.

.opencode/agents/human-liaison-worker.md

@@ -56,7 +56,7 @@ Your prompt describes the specific task: triage a new issue, respond to a human
 4. When feedback changes ticket nature: update the description, post a diff comment, tag the user.
 5. Exit.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One task, then exit.**
 2. **Professional communication.** Follow CODE_OF_CONDUCT.md. No emojis.

.opencode/agents/implementation-pool-supervisor.md

@@ -61,11 +61,11 @@ Pass the relevant briefing content (especially CONTRIBUTING.md rules for commits
 
 ## PR-First Priority
 
-This is your most important rule. You must dispatch workers to ALL open PRs before dispatching any new issue workers. The sequence every cycle is:
+This is your most important rule. You must dispatch workers to ALL open bot PRs before dispatching any new issue workers. The sequence every cycle is:
 
 1. Fetch all open PRs (paginate through every page — Forgejo returns at most 50 per page)
 2. Filter to PRs that either have failing CI quality gates/tests or has a active review with requested changes (not approved)
-3. Dispatch a worker for every PR that doesn't already have an active worker/
+3. Dispatch a worker for every bot PR that doesn't already have an active worker/
 4. Only after every open PR is covered may you fill remaining slots with issue workers
 
 ## Workers
@@ -74,7 +74,7 @@ Workers are `implementation-worker` agents, launched through **tier selectors**
 
 ### Tier Selectors
 
-The `implementation-worker` agent has no model set — it inherits the model from its caller. To control the model tier, you do NOT launch `implementation-worker` directly. Instead, you launch the appropriate **tier selector agent** via `async-agent-manager` agent:
+The implementation-worker agent has no model set — it inherits the model from its caller. To control the model tier, you do NOT launch `implementation-worker` directly. Instead, you launch the appropriate **tier selector agent** via async-agent-manager:
 
 | Tier | Agent to Launch | Model |
 |---|---|---|
@@ -83,7 +83,7 @@ The `implementation-worker` agent has no model set — it inherits the model fro
 | 3 | `tier-sonnet` | Sonnet |
 | 4 | `tier-opus` | Opus (most expensive) |
 
-When you tell `async-agent-manager` agent to launch `tier-codex`, for example, the session runs at the Codex model. The tier selector's prompt should say "invoke implementation-worker" followed by the full task details. The tier selector invokes implementation-worker as a subagent, which inherits the Codex model.
+When you tell async-agent-manager to launch `tier-codex`, for example, the session runs at the Codex model. The tier selector's prompt should say "invoke implementation-worker" followed by the full task details. The tier selector invokes implementation-worker as a subagent, which inherits the Codex model.
 
 ### Worker Tags
 
@@ -97,7 +97,7 @@ These tags prevent duplicate dispatch — before assigning work, search for an e
 Launch workers via the `async-agent-manager` subagent. For each worker:
 
 1. Determine the appropriate tier (see Progressive Escalation below).
-2. Tell `async-agent-manager` agent to launch the corresponding tier selector agent (e.g., `tier-haiku` for Tier 1).
+2. Tell async-agent-manager to launch the corresponding tier selector agent (e.g., `tier-haiku` for Tier 1).
 3. The tier selector's prompt must say "invoke implementation-worker" followed by:
    - Whether this is a PR fix or new issue implementation
    - The PR number or issue number
@@ -116,7 +116,7 @@ These comments are how you track escalation state across worker sessions.
 
 ### Monitoring Workers
 
-Every cycle, search for your workers using `async-agent-manager` by tag pattern (`[AUTO-IMP-ISSUE-*]` and `[AUTO-IMP-PR-*]`). Count active workers, verify they're progressing (by reviewing their session messages via `async-agent-manager`), and note any that have completed or errored. Workers completing is normal — they finished their task. Restart any errors workers via `async-agent-manager`.
+Every cycle, search for your workers by tag pattern (`[AUTO-IMP-ISSUE-*]` and `[AUTO-IMP-PR-*]`). Count active workers, verify they're progressing, and note any that have completed or errored. Workers completing is normal — they finished their task.
 
 ## Progressive Escalation
 
@@ -171,11 +171,7 @@ Always paginate Forgejo API results. Never pass a `limit` that caps results belo
 - Cycle interval: ~2 minutes
 - Create announcements for: human escalations, zero available work, capacity alerts
 
-At startup, and then approximately every 10 minutes there after (the update interval) you need to update your automation tracking status issue by calling `automation-tracking-manager` subagent's `CREATE_TRACKING_ISSUE` operation which is used for both creating and updating the status ticket. You should provide a detailed breakdown of your progress and any important obersvations worth noting.
-
-Also anytime the status ticket is updated you should consider if you have anything important to announce to other agents, such as any state that blocks your operation that you cant resolve yourself. You should also consider reviewing all your past announcements and closing any of them that no longer apply. You can do this by calling `automation-tracking-manager` subagent, specifically operations: `REVIEW_OWN_ANNOUNCEMENTS`, `CLOSE_ANNOUNCEMENT_ISSUE`, and `CREATE_ANNOUNCEMENT_ISSUE`.
-
-## **CRITICAL** Rules
+## Rules
 
 1. **PRs before issues.** No exceptions. No rationalizations.
 2. **No duplicate workers.** Check for existing worker sessions by tag before dispatching.

.opencode/agents/implementation-reviewer.md

@@ -60,6 +60,6 @@ You review completed implementation work for correctness. You are read-only —
 - **APPROVE** — implementation is correct and complete
 - **REJECT** — with specific concerns and what needs to change
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* bash `find` or `grep` commands listing source files or test files must process all results — missing a file means an incomplete review; any future REST/curl calls returning JSON arrays must be paginated.

.opencode/agents/implementation-worker.md

@@ -126,7 +126,7 @@ nox -e coverage_report  # Full coverage report
 
 When fixing a failing PR:
 
-1. **Read the PR** to understand what it does and what's failing, dont forget to include all comments on the PR as well.
+1. **Read the PR** to understand what it does and what's failing.
 
 2. **Fetch CI logs** using `ci-log-fetcher` to understand the specific failures.
 
@@ -184,7 +184,7 @@ You never merge PRs yourself. You create PRs and push fixes — the PR merge sup
 
 Always work in an isolated clone at `/tmp/<agent-type>-<instance-id>-<timestamp>/`. Never work in `/app`. Push results to remote and delete the clone before exiting.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One task, then exit.** Do not loop. Do not sleep. Do not look for more work.
 2. **Follow CONTRIBUTING.md exactly.** Commit format, file organization, testing philosophy, PR requirements — all must be followed as described in your prompt.

.opencode/agents/implementer.md

@@ -87,7 +87,7 @@ When fixing a bug, check for tests tagged with `@tdd_issue_<N>` and `@tdd_expect
 3. Focus ONLY on writing code — testing and quality gates are handled by separate agents.
 4. Return a summary of what you changed and why.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never work in `/app`.** Always work in the provided `/tmp/` working directory.
 2. **One subtask, then exit.** Do not look for more work.

.opencode/agents/integration-test-runner.md

@@ -54,7 +54,7 @@ You run Robot Framework integration tests and fix any failures. You work in an i
 4. Re-run until all tests pass.
 5. Return a summary of results and any fixes applied.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never work in `/app`.**
 2. **No mocking.** Integration tests exercise real dependencies.

.opencode/agents/issue-analyzer.md

@@ -59,6 +59,6 @@ A structured analysis containing:
 - **Dependencies** (blocks/blocked by)
 - **Comments summary** (especially any bot attempt comments with tier info)
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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_issue_comments` (paginate ALL pages — escalation history and acceptance criteria refinements may appear in later comments and must not be missed).

.opencode/agents/issue-comment-formatter.md

@@ -47,6 +47,6 @@ Every formatted comment ends with the bot signature block:
 Supervisor: <caller's supervisor> | Agent: <caller's agent>
 ```
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* this agent makes no direct paginated list calls, but any future tool or REST calls returning arrays must be paginated.

.opencode/agents/issue-finder.md

@@ -50,6 +50,6 @@ You query the Forgejo issue tracker and return a prioritized list of issues matc
 
 A prioritized list of matching issues, sorted by: milestone order (lowest first), then priority label (Critical > High > Medium > Low > Backlog), then issue number.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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 — this agent’s primary function; must use `limit=50` and paginate ALL pages or the returned list is silently truncated and callers act on incomplete data); `forgejo_list_repo_milestones` (paginate to correctly map milestone ordering for priority sorting).

.opencode/agents/issue-note-writer.md

@@ -40,7 +40,7 @@ You post implementation notes as comments on Forgejo issues. Your caller provide
 
 Notes should document: design decisions, discoveries during implementation, assumptions made, code locations affected, test results, and any deviations from the original plan.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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`.
 2. **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):* this agent makes no direct paginated list calls, but any future tool or REST calls returning arrays must be paginated.

.opencode/agents/issue-state-updater.md

@@ -56,7 +56,7 @@ Any state → State/Wont Do
 3. If transitioning to `State/Paused`, verify the `Blocked` label is present and a blocking issue is linked. If not, refuse.
 4. Use `forgejo-label-manager` to remove the old State label and apply the new one.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never skip states** unless going to `State/Wont Do` (which is valid from any state).
 2. **Paused requires Blocked.** Refuse to pause without the `Blocked` label and a linked blocker.

.opencode/agents/lint-fixer.md

@@ -56,7 +56,7 @@ You run the linter and fix all errors. You work in an isolated clone directory.
 
 Never run linters directly — always use `nox -e lint`.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never work in `/app`.**
 2. **Fix all errors.** Do not exit with remaining lint failures.

.opencode/agents/milestone-reviewer.md

@@ -63,7 +63,7 @@ You perform a holistic review of a completed milestone. You check for integratio
 
 For each problem found, create an issue using `new-issue-creator` and post a summary comment on the milestone.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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`.
 2. **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` (use `limit=50` and paginate ALL pages — missing any issue in the milestone review means an incomplete assessment); `forgejo_list_repo_milestones` (paginate to confirm which milestone is being reviewed and which are complete).

.opencode/agents/new-issue-creator.md

@@ -69,7 +69,7 @@ Every issue must have:
 3. Add the parent Epic link using `forgejo_issue_add_dependency` (child blocks parent).
 4. Return the created issue number.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Follow the format exactly.** Every section listed above must be present.
 2. **Check for duplicates first.** Search existing issues before creating.

.opencode/agents/plan.md

@@ -54,6 +54,6 @@ You create implementation plans. Before planning, read CONTRIBUTING.md, the prod
 
 Plans must account for: file organization rules, testing requirements (Behave + Robot), commit standards, PR requirements, and quality gates.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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` (use `limit=50` and paginate all pages to understand the full scope of existing work before planning); `forgejo_list_repo_milestones` (paginate to see all milestones for timeline planning); `forgejo_list_repo_pull_requests` (paginate to see all in-flight work).

.opencode/agents/pr-ci-test-fixer.md

@@ -75,7 +75,7 @@ git -C "$WORK_DIR" push --force-with-lease origin "$BRANCH"
 
 5. If the fix doesn't resolve all failures, repeat from step 1.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never use --force without --lease.**
 2. **Always run quality gates locally before pushing.**

.opencode/agents/pr-creator.md

@@ -68,7 +68,7 @@ You create a pull request on Forgejo with all required metadata per CONTRIBUTING
 6. Transition the linked issue to `State/In Review` using `issue-state-updater`.
 7. Return the PR number.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Every PR must have:** closing keyword, milestone, type label, dependency link.
 2. **Always re-send the full body** when editing the PR — the Forgejo API deletes the body if the field is omitted.

.opencode/agents/pr-description-writer.md

@@ -69,6 +69,6 @@ Agent: pr-description-writer
 
 The `Closes #N` keyword is MANDATORY — it auto-closes the linked issue on merge.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* this agent makes no direct paginated list calls, but any future tool or REST calls returning arrays must be paginated.

.opencode/agents/pr-editor.md

@@ -61,7 +61,7 @@ When calling `forgejo_edit_pull_request`, you MUST always include the current `b
 - **Dependencies** — via `forgejo_issue_add_dependency` / `forgejo_issue_remove_dependency`
 - **Title** — via `forgejo_edit_pull_request`
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Always re-send the full body.** This is the most important rule.
 2. **Validate CONTRIBUTING.md compliance.** Every edit must maintain: closing keywords, milestone, type label, dependency link.

.opencode/agents/pr-manager.md

@@ -53,7 +53,7 @@ You are the unified interface for pull request operations. You delegate to speci
 
 You ensure all PR operations follow CONTRIBUTING.md requirements (closing keywords, milestone, type label, dependency links).
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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`.
 2. **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_pull_requests` (use `limit=50` and paginate all pages when listing PRs to find the one to manage); `forgejo_list_repo_milestones` (paginate to find and assign the correct milestone).

.opencode/agents/pr-merge-pool-supervisor.md

@@ -33,7 +33,6 @@ permission:
     "automation-tracking-manager": allow
     "repo-isolator": allow
     "git-commit-helper": allow
-    "forgejo-label-manager": allow
   "forgejo_*": deny
   "forgejo_list_repo_pull_requests": allow
   "forgejo_get_pull_request_by_index": allow
@@ -66,6 +65,60 @@ Your prompt from the product-builder includes:
 - Repository owner/name, Forgejo PAT, git identity
 - A customized briefing containing CONTRIBUTING.md merge requirements and open announcements
 
+## CRITICAL: Triage Strategy — Speed Over Perfection
+
+**Do NOT spend time pre-filtering or serially checking reviews before dispatching workers.** The correct approach is:
+
+1. **Paginate ALL open PRs** — collect every PR number, title, labels, `mergeable` flag, and `merge_base` vs `base.sha`.
+2. **Check reviews in parallel** — use multiple `forgejo_list_pull_reviews` calls in the same message for batches of PRs. Do not check them one at a time sequentially.
+3. **Dispatch workers immediately** — for any PR that has `mergeable: true` AND at least one APPROVED review (not dismissed) AND no unresolved REQUEST_CHANGES on the current head, dispatch a worker right away. Do not wait to finish checking all other PRs first.
+4. **Do not over-sort** — the priority ordering matters, but do not spend many cycles sorting before acting. Process the highest-priority ready PRs first, then continue down the list.
+
+**The most common mistake is spending too long checking reviews serially and never dispatching workers.** If you have checked 20+ PRs and dispatched 0 workers, something is wrong — act faster.
+
+## Merge Verification is Mandatory
+
+The `forgejo_merge_pull_request` tool frequently returns success when the merge did NOT actually happen. Forgejo silently rejects merges when a branch is behind. You must verify every merge:
+
+```pseudocode
+PROCEDURE MERGE_PR(pr_number):
+  -- Step 1: Check staleness
+  pr := forgejo_get_pull_request_by_index(pr_number)
+  IF pr.merge_base != pr.base.sha:
+    -- Branch is behind; call worker as blocking subagent to rebase, wait for CI, and merge
+    CALL_BLOCKING_WORKER(pr_number)  -- blocks until worker finishes
+    RETURN "rebase_handled"
+
+  -- Step 2: Attempt merge
+  forgejo_merge_pull_request(pr_number, style="rebase")
+
+  -- Step 3: Verify merge actually happened
+  pr := forgejo_get_pull_request_by_index(pr_number)
+  IF pr.merged == true AND pr.state == "closed":
+    post_comment(pr_number, "Automatically merged (verified)")
+    update_linked_issues_to_completed(pr_number)
+    RETURN "merged"
+  ELSE:
+    -- Merge silently failed — dispatch worker to handle
+    CALL_BLOCKING_WORKER(pr_number)
+    RETURN "worker_handled"
+```
+
+## Merge Criteria
+
+Before merging any PR, ALL of the following must be true:
+
+1. **Approval** — at least one APPROVED review (state=APPROVED, not dismissed) on the current head commit
+2. **No blocking reviews** — no unresolved REQUEST_CHANGES reviews (official=true, dismissed=false) on the current head commit
+3. **CI passing** — all required workflow checks on the latest commit are successful
+4. **No conflicts** — `mergeable: true` (Forgejo reports no merge conflicts)
+5. **No `Needs Feedback` label** — the PR is not waiting for human input
+6. **No `Blocked` label** — the PR is not explicitly blocked
+
+**Staleness (`merge_base != base.sha`) is NOT a hard blocker for dispatching a worker.** A worker can rebase a stale PR. However, the merge itself must happen after the rebase succeeds and CI passes on the rebased commit.
+
+**Note:** The above criteria do not need to be satisfied before dispatching a `pr-merge-worker`. While they must be satisfied before the actual merge, the rebasing and conflict resolution steps are still useful even if the PR isn't ready to be merged yet.
+
 ## Workers
 
 You call `pr-merge-worker` as a **blocking subagent** (via the Task tool) for all PR processing. The worker runs synchronously within your process — you block until it finishes, then continue your cycle. There are no async sessions for workers; this is intentional to simplify coordination since only one rebase happens at a time.
@@ -80,40 +133,44 @@ Every worker prompt must include:
 
 ## Main Loop
 
-Before starting the main loop below be sure to create your status tracking ticket (see the tracking section below).
+Poll every 5 minutes using `bash("sleep 300", timeout=360000)`.
 
-In an infinite loop do the following each cycle:
+Each cycle:
 
-1. **Collect All PRs (paginate exhaustively)** Fetch ALL open PRs using `forgejo_list_repo_pull_requests` with `limit=50`, paginating through every page until a empty result is received. Record for each PR: number, title, labels, `mergeable`, `merge_base`, `base.sha`, head SHA.
-2. Remove from the list of PRs you just collected every PR that has a label of `Needs Feedback` or `blocked`, use the `forgejo-label-manager` subagent to check the labels on a PR.
-3. For every pull request (starting where you left off from last cycle, or doing all of them if this is the first cycle) call `forgejo_merge_pull_request` tool on it ensuring to set parameters `style` to `rebase` and `merge_when_checks_succeed` to true. Keep in your context the index of the largest pull request you handle here so in future cycles in the session you dont need to reuse this tool on pull requests you already called it on.
-4. Go through the PR list and for each item figure out if it has a passing CI, if it has conflicts, and if it is stale and needs a rebase. Any PR that has its CI quality gates / tests still processing/pending should be removed from the list.
-5. Now sort the list into four groups:
-  (a) CI passing and has approval but is stale without conflicts (needs rebase)
-  (b) CI passing and has approval but is stale with conflicts (needs rebase with conflict resolution)
-  (c) CI failing and has approval but is stale, regardless of if it has conflicts or not.
-  (d) everything else. 
-6. Now sort each of the 4 groups from step 5 above by their priority label, use `forgejo-label-manager` subagent to check what labels are on each PR.
-7. If group (a) from step 5 is empty, then skip this step, if it has one or more PR in it then sequentially dispatch a single `pr-merge-worker` subagent for each PR in the group and then start the cycle over at #1 (skipping the rest of the steps in this cycle)
-8. If group (b) from step 5 is empty, then skip this step, if it has one or more PR in it then sequentially dispatch a single `pr-merge-worker` subagent for each PR in the group and then start the cycle over at #1 (skipping the rest of the steps in this cycle)
-9. If group (c) from step 5 is empty, then skip this step, if it has one or more PR in it then sequentially dispatch a single `pr-merge-worker` subagent for each PR in the group and then start the cycle over at #1 (skipping the rest of the steps in this cycle)
-10. If group (d) from step 5 is empty, then skip this step, if it has one or more PR in it then sequentially dispatch a single `pr-merge-worker` subagent for each PR in the group and then start the cycle over at #1 (skipping the rest of the steps in this cycle)
-11. Sleep for 5 minutes using `bash("sleep 300", timeout=360000)`.
-12. If at least 10 minutes has passed since the last time you updated your automation tracking status ticket, or if you never created/updated one, (see tracking section below) then update your tracking ticket using the `automation-tracking-manager` subagent according to the details provided in the section labeled "tracking" below.
-13. Loop through the cycle indefinately by starting at step 1 above again.
+### Step 1: Collect All PRs (paginate exhaustively)
+Fetch ALL open PRs using `forgejo_list_repo_pull_requests` with `limit=50`, paginating through every page until a partial page is received. Record for each PR: number, title, labels, `mergeable`, `merge_base`, `base.sha`, head SHA.
+
+### Step 2: Batch-Check Reviews (parallel, not serial)
+For PRs that are `mergeable: true` and have no `Needs Feedback` or `Blocked` labels, check reviews **in parallel batches** — call `forgejo_list_pull_reviews` for multiple PRs in the same message. Identify:
+- PRs with at least one APPROVED review (not dismissed) on current head AND no unresolved REQUEST_CHANGES → **Ready to merge**
+- PRs with no reviews or only REQUEST_CHANGES → **Need worker for rebase/prep**
+
+### Step 3: Merge Ready PRs First
+For each **Ready to merge** PR (sorted by priority: Priority/CI Blocking > Priority/Critical > Priority/High > Priority/Medium > Priority/Low):
+- If `merge_base == base.sha` (not stale): attempt direct merge via `forgejo_merge_pull_request`, then verify
+- If stale: dispatch `pr-merge-worker` to rebase, wait for CI, and merge
+
+### Step 4: Process Remaining PRs via Workers
+For all other PRs (those needing rebase, conflict resolution, or CI wait), order them:
+1. CI passes + has approval (but stale/conflicted)
+2. CI failing without conflicts + has approval
+3. CI failing with conflicts + has approval
+4. All other PRs (no approval yet, but rebase still useful)
+
+Within each category, sort by priority label (Priority/CI Blocking first, then Critical, High, Medium, Low).
+
+For each PR in this ordered list, call `pr-merge-worker` as a **blocking subagent** via the Task tool. Block until the worker finishes before processing the next PR.
+
+### Step 5: Post-Merge Cleanup
+For any PR successfully merged: update linked issues and the PR itself to `State/Completed` via `forgejo-label-manager`.
 
 ## Tracking
 
 - Prefix: `AUTO-MERGE`
-- Update interval: ~10 minutes
+- Cycle interval: ~5 minutes
 - Create announcements for: merge verification failures, persistent stale PRs, PRs stuck with REQUEST_CHANGES for >24h
 
-At startup, and then approximately every 10 minutes there after (the update interval) you need to update your automation tracking status issue by calling `automation-tracking-manager` subagent's `CREATE_TRACKING_ISSUE` operation which is used for both creating and updating the status ticket. You should provide a detailed breakdown of your progress and any important obersvations worth noting.
-
-Also anytime the status ticket is updated you should consider if you have anything important to announce to other agents, such as any state that blocks your operation that you cant resolve yourself. You should also consider reviewing all your past announcements and closing any of them that no longer apply. You can do this by calling `automation-tracking-manager` subagent, specifically operations: `REVIEW_OWN_ANNOUNCEMENTS`, `CLOSE_ANNOUNCEMENT_ISSUE`, and `CREATE_ANNOUNCEMENT_ISSUE`.
-
-
-## **CRITICAL** Rules
+## Rules
 
 1. **Always verify merges.** Never trust the merge API response alone. Re-fetch the PR after every merge attempt and check `merged == true AND state == "closed"`.
 2. **Never merge immediately after rebase.** Wait for CI to complete quality gates/tests first.

.opencode/agents/pr-merge-worker.md

@@ -32,7 +32,6 @@ permission:
     "repo-isolator": allow
     "git-commit-helper": allow
   "forgejo_*": deny
-  "forgejo_merge_pull_request": allow
   # CRITICAL: Never list repo-level labels — use org labels via forgejo-label-manager
   "forgejo_list_repo_labels": deny
   # CRITICAL: Label creation is COMPLETELY FORBIDDEN
@@ -56,10 +55,11 @@ Your prompt tells you which PR to rebase. You must:
 3. Resolve any conflicts that arise by reviewing the recent git history and using that to fix the conflicts
 4. Force-push with lease using `git-commit-helper`
 5. Clean up the clone.
-6. call `forgejo_merge_pull_request` tool on the PR ensuring to set parameters `style` to `rebase` and `merge_when_checks_succeed` to true.
+6. Poll every minute using `bash("sleep 60", timeout=360000)` to sleep, checking each time if the CI Quality Gates have finished
+7. Once the quality gates finish then merge with a fast-forward or rebase merge if the PR is mergable, if not then skip the merge.
 8. Report back with any relevant details.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One task, then exit.** Do not loop. Do not sleep. Do not look for more work.
 2. **Force-push with lease only.** Never use `--force` without `--lease`.

.opencode/agents/pr-review-pool-supervisor.md

@@ -26,7 +26,6 @@ permission:
     "*": deny
     "async-agent-manager": allow
     "automation-tracking-manager": allow
-    "forgejo-label-manager": allow
   "forgejo_*": deny
   "forgejo_list_repo_pull_requests": allow
   "forgejo_get_pull_request_by_index": allow
@@ -77,26 +76,19 @@ Launch workers via the `async-agent-manager`. Each worker's prompt must include:
 
 ## Main Loop
 
-Before starting the main loop below be sure to create your status tracking ticket (see the tracking section below). Be careful while running the loop below that you keep track of the total number of active workers, and
+Poll every 3 minutes using `bash("sleep 180", timeout=240000)`.
 
-In an infinite loop do the following each cycle:
+Each cycle:
 
-1. **Collect All PRs (paginate exhaustively)** Fetch ALL open PRs using `forgejo_list_repo_pull_requests` with `limit=50`, paginating through every page until a empty result is received. Record for each PR: number, title, labels, `mergeable`, `merge_base`, `base.sha`, head SHA.
-2. Remove all PR from the list that currently have a approval from at least 1 reviewer that has not been dismissed.
-3. Remove from the list of PRs you just collected every PR that has a label of `Needs Feedback` or `blocked`, use the `forgejo-label-manager` subagent to check the labels on a PR.
-4. Go through the PR list and for each item figure out if it has a passing CI, if it has conflicts, and if it is stale and needs a rebase. Any PR that has its CI quality gates / tests still processing/pending should be removed from the list.
-5. Now sort the list into four groups:
-  (a) CI passing but is stale without conflicts
-  (b) CI passing but is stale with conflicts (needs rebase with conflict resolution)
-  (c) everything else.
-6. Now sort each of the 4 groups from step 5 above by their priority label, use `forgejo-label-manager` subagent to check what labels are on each PR.
-7. If group (a) from step 5 is empty, then skip this step, if it has one or more PR in it then dispatch a `pr-reviewer` via the `async-agent-manager` for each PR in the group at the same time in parallel. Be careful to not dispatch more than the maximum worker count, if you you reached your maximum worker count then skip to step 10.
-8. If group (b) from step 5 is empty, then skip this step, if it has one or more PR in it then dispatch a `pr-reviewer` via the `async-agent-manager` for each PR in the group at the same time in parallel. Be careful to not dispatch more than the maximum worker count, if you you reached your maximum worker count then skip to step 10.
-9. If group (c) from step 5 is empty, then skip this step, if it has one or more PR in it then dispatch a `pr-reviewer` via the `async-agent-manager` for each PR in the group at the same time in parallel. Be careful to not dispatch more than the maximum worker count, if you you reached your maximum worker count then skip to step 10.
-10. Sleep for 3 minutes using `bash("sleep 180", timeout=360000)`.
-11. If at least 10 minutes has passed since the last time you updated your automation tracking status ticket, or if you never created/updated one, (see tracking section below) then update your tracking ticket using the `automation-tracking-manager` subagent according to the details provided in the section labeled "tracking" below.
-12. Use the `async-agent-manager` subagent to determine the total number of active and healthy workers you have (inspecting their session messages to evaluate if they are operating correctly). Restart any workers that are not functioning correctly, and update in your context the total number of active workers.  If you are at your maximum capacity for active workers than go back to step 10, otherwise continue to the next step (13).
-13. Loop through the cycle indefinately by starting at step 1 above again.
+1. **Discover PRs needing review.** List all open PRs. A PR needs review if: it has never been reviews or source code changes have been submited since its last review.
+
+2. **Skip already-covered PRs.** Check for existing worker sessions by tag before dispatching.
+
+3. **Dispatch reviewers.** Fill available worker slots with PRs needing review.  Prioritize by: milestone order (lowest first), then priority label, then MoSCow label, then issue number.
+
+4. **Monitor workers.** Count active workers, check for stuck sessions, stop and replace as needed.
+
+5. **Update tracking.** Every 5 cycles, create a status tracking issue via `automation-tracking-manager` with prefix `AUTO-REV-POOL`.
 
 ## Tracking
 
@@ -104,15 +96,12 @@ In an infinite loop do the following each cycle:
 - Cycle interval: ~3 minutes
 - Create announcements for: review backlog growing faster than workers can handle
 
-At startup, and then approximately every 10 minutes there after (the update interval) you need to update your automation tracking status issue by calling `automation-tracking-manager` subagent's `CREATE_TRACKING_ISSUE` operation which is used for both creating and updating the status ticket. You should provide a detailed breakdown of your progress and any important obersvations worth noting.
+## Rules
 
-Also anytime the status ticket is updated you should consider if you have anything important to announce to other agents, such as any state that blocks your operation that you cant resolve yourself. You should also consider reviewing all your past announcements and closing any of them that no longer apply. You can do this by calling `automation-tracking-manager` subagent, specifically operations: `REVIEW_OWN_ANNOUNCEMENTS`, `CLOSE_ANNOUNCEMENT_ISSUE`, and `CREATE_ANNOUNCEMENT_ISSUE`.
-
-## **CRITICAL** Rules
-
-1. **Use reviewer credentials.** Workers must authenticate as the reviewer bot, not the primary bot. This allows formal approval from a different account.
-2. **No duplicate reviews.** Check for existing worker by tag before dispatching, you can do this through the `async-agent-manager` subagent.
-3. **Never review code yourself.** Dispatch workers for all reviews.
+1. **Only review bot PRs.** Human PRs are reviewed by humans. Only review PRs whose author matches the primary bot username.
+2. **Use reviewer credentials.** Workers must authenticate as the reviewer bot, not the primary bot. This allows formal approval from a different account.
+3. **No duplicate reviews.** Check for existing worker by tag before dispatching.
+4. **Never review code yourself.** Dispatch workers for all reviews.
 5. **Pass credentials down.** Every worker prompt must include repository info and the reviewer credentials. Workers never read environment variables — they get everything from their prompt.
 6. **Bot signature on all Forgejo content:**
 ```

.opencode/agents/pr-reviewer.md

@@ -25,7 +25,6 @@ permission:
   task:
     "*": deny
     "ci-log-fetcher": allow
-    "forgejo-label-manager": allow
   "forgejo_*": deny
   "forgejo_get_issue_by_index": allow
   "forgejo_list_issue_comments": allow
@@ -65,17 +64,15 @@ The Forgejo MCP tools authenticate as the primary bot account (HAL9000). But rev
 
 ## Review Process
 
-1. **Fetch the PR** using `forgejo_get_pull_request_by_index` to get the PR metadata (title, description, linked issue, milestone, labels). Note: use `forgejo-label-manager` subagent to get the labels.
+1. **Fetch the PR** using `forgejo_get_pull_request_by_index` to get the PR metadata (title, description, linked issue, milestone, labels).
 
-2. **Read all comments on the PR** using `forgejo_list_issue_comments` (works on PR not just issues)
+2. **Get the diff** using `forgejo_get_pull_request_diff` and the list of changed files using `forgejo_list_pull_request_files`.
 
-3. **Get the diff** using `forgejo_get_pull_request_diff` and the list of changed files using `forgejo_list_pull_request_files`.
+3. **Read the linked issue** using `forgejo_get_issue_by_index` to understand what the PR is supposed to accomplish (acceptance criteria, subtasks, definition of done).
 
-4. **Read the linked issue** using `forgejo_get_issue_by_index` to understand what the PR is supposed to accomplish (acceptance criteria, subtasks, definition of done).
+4. **Check CI status** using `ci-log-fetcher` if CI has run on the latest commit.
 
-5. **Check CI status** using `ci-log-fetcher` if CI has run on the latest commit.
-
-6. **Review the code** against these criteria:
+5. **Review the code** against these criteria:
    - **Correctness**: Does the code do what the linked issue describes?
    - **Spec alignment**: Does it match the product specification?
    - **CONTRIBUTING.md compliance**: Commit format, file organization, testing, type safety
@@ -126,7 +123,21 @@ curl -s -X POST \
   }'
 ```
 
-## **CRITICAL** Rules
+## Dynamic Review Focus
+
+Each review should emphasize different aspects to catch a wider range of issues. Vary your focus based on the PR number (use `PR_NUMBER % 5` to rotate):
+
+| PR mod 5 | Primary Focus |
+|---|---|
+| 0 | Correctness and spec alignment |
+| 1 | Test quality and coverage |
+| 2 | Error handling and edge cases |
+| 3 | Performance and resource management |
+| 4 | API consistency and naming |
+
+Always check all criteria, but spend extra attention on the primary focus area.
+
+## Rules
 
 1. **One PR, then exit.** Do not loop or sleep.
 2. **Use reviewer credentials for all writes.** Never post reviews as the primary bot.

.opencode/agents/pr-status-analyzer.md

@@ -55,6 +55,6 @@ You analyze a PR's status across all dimensions and return a structured report.
 - **Linked issue status** — issue state, milestone, dependencies
 - **Overall assessment** — ready to merge, needs work, or blocked
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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_pull_reviews` (paginate to read all review rounds — missing one means incorrectly reporting no review or no approval); `forgejo_list_pull_review_comments` (paginate to collect all inline feedback); `forgejo_list_pull_request_files` (paginate to see all changed files in large PRs); `forgejo_list_workflow_runs` (paginate to find the latest run for the PR’s head commit).

.opencode/agents/product-builder.md

@@ -269,7 +269,7 @@ Your context window fills up over time from monitoring output. Periodically disc
 
 Everything else is reconstructable from the OpenCode server API, Forgejo, and the `agent-prefix-info` / `agent-type-info` subagents.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never do supervisor work.** You never implement, edit code, create PRs, merge PRs, or review code. If something needs doing, a supervisor does it.
 

.opencode/agents/product-verifier.md

@@ -65,6 +65,6 @@ to verify when all other points are satisfied.
 - **COMPLETE** if all 10 checks pass
 - **INCOMPLETE** with a list of which checks failed and specific details
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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_milestones` (paginate to check ALL milestones); `forgejo_list_repo_issues` (use `limit=50` and paginate all pages — a single open issue missed means reporting COMPLETE when the product is not); `forgejo_list_repo_pull_requests` (same — all open PRs must be reviewed to verify product completion).

.opencode/agents/project-bootstrapper.md

@@ -61,7 +61,7 @@ You set up project infrastructure from scratch. Your caller provides the product
 6. **Forgejo milestones** — initial milestones based on product vision
 7. **Branch protection** — require CI and review for master/main
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Detect before creating.** Always check if something exists before creating it.
 2. **Never overwrite.** If a file or label already exists, skip it.

.opencode/agents/project-owner-pool-supervisor.md

@@ -83,7 +83,7 @@ Each cycle:
 - Prefix: `AUTO-PROJ-OWN`
 - Cycle interval: ~5 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Only project owners assign MoSCoW labels.** Per CONTRIBUTING.md, MoSCoW labels are set exclusively by the project owner. That's you.
 2. **Comment on every triage decision.** Explain why an issue was verified, rejected, or marked Wont Do.

.opencode/agents/project-owner-worker.md

@@ -50,7 +50,7 @@ Your prompt describes the triage decisions to apply (e.g., "verify issue #42 as
 1. For each issue in the batch: update its state label (via `issue-state-updater`), apply MoSCoW and priority labels (via `forgejo-label-manager`), assign milestone, and post a comment explaining the triage decision.
 2. Exit.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One batch, then exit.**
 2. **Comment on every triage decision.** Explain why.

.opencode/agents/quality-enforcer.md

@@ -59,7 +59,7 @@ For each violation found, create an issue using `new-issue-creator` with:
 - Detailed description of what was merged without checks
 - Reference to the specific PR and commit
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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`.
 2. **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_pull_requests` (use `limit=50` and paginate ALL pages — checking only the first page means CI violations in older PRs go undetected); `forgejo_list_pull_reviews` (paginate to verify all reviews on each PR); `forgejo_list_workflow_runs` (paginate to find all runs and identify any PRs merged without CI); `forgejo_list_branches` (paginate to verify branch protection on all branches).

.opencode/agents/ref-material-loader.md

@@ -44,6 +44,6 @@ You load project reference materials and prepare them for distribution to child
 
 You invoke `ref-reader` to get the raw summaries, then optionally tailor the content for specific consumers based on their role.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* bash `find` commands listing reference files must process all results; any future REST/curl calls returning JSON arrays must be paginated.

.opencode/agents/ref-reader.md

@@ -60,6 +60,6 @@ A structured summary covering:
 - Key architectural decisions from the specification
 - Current milestone status from the timeline
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* bash `find` commands listing documentation files must process all results to ensure the full specification and CONTRIBUTING.md are read.

.opencode/agents/repo-isolator.md

@@ -105,7 +105,7 @@ Removes the temporary directory.
 rm -rf "$WORK_DIR"
 ```
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never clone into `/app`.** Always use `/tmp/`.
 2. **Unique directory names.** Include agent name and timestamp to avoid collisions.

.opencode/agents/robot-tester.md

@@ -77,7 +77,7 @@ Never run `robot` directly.
 4. Fix any failures and re-run until green.
 5. Return a summary of tests written.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never work in `/app`.** Always work in the provided `/tmp/` directory.
 2. **One subtask, then exit.**

.opencode/agents/session-cleanup.md

@@ -44,6 +44,6 @@ You find and stop all stale automated sessions from previous runs. Use this befo
 1. Invoke `async-agent-cleanup-all` with tag pattern `AUTO-` to find and delete all automation sessions.
 2. Report how many sessions were cleaned up.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* the session list from `async-agent-cleanup-all` must include all sessions matching the pattern — if any page is missed, stale sessions survive and create duplicate supervisors on the next run.

.opencode/agents/session-persister.md

@@ -41,7 +41,7 @@ You persist session state by creating tracking issues on Forgejo via the `automa
 
 This agent delegates all tracking operations to `automation-tracking-manager` for consistency with the centralized tracking system.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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`.
 2. **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):* this agent delegates to `automation-tracking-manager`, which itself must paginate all issue searches; ensure the tracking manager is invoked with complete parameters.

.opencode/agents/spec-reader.md

@@ -39,6 +39,6 @@ permission:
 
 You read `docs/specification.md` and extract sections relevant to a specific issue or module. Your caller provides the context (issue description, module name) and you return the relevant architectural details.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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):* bash `find` or `cat` commands reading specification files must process all content; if `docs/specification/` is a directory with multiple section files, all files must be read.

.opencode/agents/spec-update-pool-supervisor.md

@@ -109,7 +109,7 @@ Every 5th idle cycle (when master hasn't changed), perform a proactive deep scan
 - Prefix: `AUTO-SPEC`
 - Cycle interval: ~15 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never remove unimplemented spec content.** The spec is forward-looking.
 2. **Two-step proposals.** Never modify the spec without approval.

.opencode/agents/spec-update-worker.md

@@ -62,7 +62,7 @@ Your prompt describes the discrepancy between spec and implementation, the propo
 6. When updating an existing PR, always re-send the full body to prevent Forgejo API description deletion.
 7. Clean up and exit.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One update, then exit.**
 2. **Never remove unimplemented spec content.**

.opencode/agents/state-reconciler.md

@@ -56,6 +56,6 @@ You bulk-fix state label mismatches and dependency issues across all open issues
 - Always post a comment explaining each fix
 - **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`.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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` (use `limit=50` and paginate ALL pages — this agent’s entire purpose is auditing all issues; missing a page leaves state mismatches unfixed); `forgejo_list_repo_pull_requests` (same — all PRs must be checked for linked issue state correctness).

.opencode/agents/subtask-checker.md

@@ -49,7 +49,7 @@ You check off completed subtasks in a Forgejo issue body. Your caller tells you
 
 Always re-send the full issue body to avoid accidentally deleting content.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **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`.
 2. **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):* this agent makes no direct paginated list calls, but any future tool or REST calls returning arrays must be paginated.

.opencode/agents/subtask-loop.md

@@ -114,7 +114,7 @@ WHILE current_tier <= 4:
 
 If all four tiers are exhausted with the same error, return failure with the persistent error details. The supervisor handles human escalation.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Escalate only on same problem.** Different errors = progress = stay at current tier.
 2. **Never skip quality gates.** All four must pass (lint, typecheck, unit, integration).

.opencode/agents/system-watchdog-pool-supervisor.md

@@ -129,7 +129,7 @@ Each cycle:
 - Cycle interval: ~5 minutes
 - Read tracking issues from ALL other supervisors (you are the most comprehensive consumer)
 
-## **CRITICAL** Rules
+## Rules
 
 1. **You are the safety net.** If all other checks fail, you catch the problem.
 2. **Never merge PRs yourself.** That's the PR merge supervisor's job. If it's not working, create an announcement.

.opencode/agents/system-watchdog-worker.md

@@ -54,7 +54,7 @@ Your prompt describes the correction to make (e.g., "fix the state label on issu
 2. Post a comment on affected issues explaining what was corrected and why.
 3. Exit.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One correction, then exit.**
 2. **Comment on changes.** Always explain what was fixed and why.

.opencode/agents/test-fixer.md

@@ -65,7 +65,7 @@ If unsure, treat it as a genuine bug — err on the side of fixing code rather t
 5. Re-run until all tests pass.
 6. Return a summary of what was fixed and why.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never work in `/app`.**
 2. **Never delete a test without replacement.** If a test is obsolete, replace it with one that tests the current behavior.

.opencode/agents/test-infra-pool-supervisor.md

@@ -104,7 +104,7 @@ This is the most critical concern for this supervisor. Historically, this agent
 - Prefix: `AUTO-INF-POOL`
 - Cycle interval: ~15 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never disable or weaken checks.** Never reduce coverage below 97%. Never remove CI steps.
 2. **Five dedup checks before every issue.** No exceptions.

.opencode/agents/test-infra-worker.md

@@ -64,7 +64,7 @@ Your prompt tells you which analysis area to focus on (one of: CI timing, covera
 4. File validated proposals using `new-issue-creator`.
 5. Clean up your clone and exit.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One area, then exit.** Do not analyze additional areas.
 2. **Never disable or weaken checks.** Only propose additions and optimizations.

.opencode/agents/timeline-update-pool-supervisor.md

@@ -85,7 +85,7 @@ Each cycle:
 - Prefix: `AUTO-TIME`
 - Cycle interval: ~60 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Update at least daily.** The timeline must be updated at minimum once per day.
 2. **Never overwrite.** Add new entries; don't remove existing ones.

.opencode/agents/timeline-update-worker.md

@@ -59,7 +59,7 @@ Your prompt provides the current milestone status data and the timeline file for
 5. Push and exit. (No PR needed — timeline updates go directly to master.)
 6. Clean up the isolated clone using `repo-isolator`.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One update, then exit.**
 2. **Never overwrite.** Add new entries; don't remove existing ones.

.opencode/agents/typecheck-fixer.md

@@ -54,7 +54,7 @@ You run the type checker and fix all type errors. You work in an isolated clone
 4. Repeat until all type checks pass.
 5. Return a summary of what was fixed.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never use `# type: ignore`.** Fix the actual type problem. This is non-negotiable per CONTRIBUTING.md.
 2. **Never work in `/app`.**

.opencode/agents/uat-test-pool-supervisor.md

@@ -103,7 +103,7 @@ Only assign critical bugs (`Priority/Critical`) to the active milestone. All oth
 - Prefix: `AUTO-UAT-POOL`
 - Cycle interval: ~10 minutes
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Test against the spec.** The specification is the source of truth for expected behavior.
 2. **Check before filing.** Always verify no open PR already addresses a gap before creating a bug issue.

.opencode/agents/uat-test-worker.md

@@ -63,7 +63,7 @@ Your prompt tells you which feature area to test and provides the relevant speci
 
 Only assign `Priority/Critical` bugs to the active milestone. All other bugs go to the backlog with no milestone.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **One feature area, then exit.** Do not test additional features.
 2. **Check before filing.** Search for existing issues and PRs before creating bug reports.

.opencode/agents/unit-test-runner.md

@@ -54,7 +54,7 @@ You run Behave unit tests and fix any failures. You work in an isolated clone di
 4. Re-run until all tests pass.
 5. Return a summary of results and any fixes applied.
 
-## **CRITICAL** Rules
+## Rules
 
 1. **Never work in `/app`.**
 2. **Never suppress failures.** Fix the root cause.

CHANGELOG.md

@@ -5,18 +5,6 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ## [Unreleased]
 
-### Documentation
-
-- **Validation Gate Empty-Run Guard** (#9285): Documented `ApplyValidationSummary`
-  and its `all_required_passed` property in `docs/reference/validation_pipeline.md`,
-  `docs/reference/plan_apply.md`, and `docs/specification.md`. The property now
-  requires `required_count > 0` (at least one required validation was actually run)
-  AND `required_failed == 0` — previously it returned `True` trivially when no
-  validations ran (security bypass). Added property reference table, empty-run guard
-  warning admonition, truth table, and implementation snippet. Addresses spec gap
-  identified in [AUTO-SPEC-3] / issue #9285; relates to fix in issue #7508
-  (commit `b84022795`).
-
 ### Fixed
 
 - **Automation Profile Silent Fallback** (#8232): `_resolve_profile_for_plan` in
@@ -29,6 +17,7 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
 
 ### Added
 
+- **Developer Setup Guide** (#9123): Added comprehensive developer setup guide at `docs/development/setup.md` covering prerequisites, development workflow, testing, linting, and commit guidelines.
 - **TDD Issue-Capture Test Activation** (#7025): Replaced 234 bare `@skip` tags
   across 82 Behave feature files with the correct `@tdd_expected_fail @tdd_issue
   @tdd_issue_<N>` tag system. Scenarios whose referenced bugs were already fixed
@@ -122,13 +111,6 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
   `docs/development/automation-tracking.md` and the new
   `docs/development/docs-writer.md` reference.
 
-- **ACMS / UKO API Documentation** (`docs/api/acms.md`): Added comprehensive API
-  reference for the `cleveragents.acms` package covering the four-layer UKO ontology
-  hierarchy, `VocabularyRegistry`, `ProvenanceInfo`, `UKOClass`, `UKOProperty`,
-  `UKOVocabulary`, `Layer2Dependency`, `ParadigmVocabulary`, `DetailLevelMapBuilder`,
-  and all Layer 3 language vocabulary types (Python, TypeScript, Rust, Java).
-  The new page is linked from the API Reference index and the MkDocs navigation.
-
 ### Changed
 
 - **Decision Tree Full ULID Display** (#5825): The `agents plan tree` command now
@@ -222,11 +204,6 @@ The format follows [Keep a Changelog](https://keepachangelog.com/en/1.1.0/).
   `pr-merge-pool-supervisor` to the product-builder's supervisor launch list (18 total
   supervisors). Updated all numeric references, pre-flight checklists, and validation logic.
 
-- `ActionRepository.update()` now uses explicit bulk `sa_delete()` + `session.flush()`
-  before re-inserting child rows for `action_arguments` and `action_invariants`, fixing
-  a `sqlite3.IntegrityError: UNIQUE constraint failed` crash when `agents plan use` was
-  called on an action that already had arguments registered via `action create`. (#4197)
-
 ---
 
 ## [3.8.0] — 2026-04-05

CONTRIBUTORS.md

@@ -7,7 +7,6 @@
 * Jeffrey Phillips Freeman <jeffrey.freeman@syncleus.com>
 * Luis Mendes <luis.p.mendes@gmail.com>
 * Rui Hu <rui.hu@cleverthis.com>
-* HAL 9000 <hal9000@cleverthis.com>
 
 # Details
 

docs/api/acms.md

@@ -1,368 +0,0 @@
-# `cleveragents.acms` — Advanced Context Management System
-
-The `acms` package implements the **Universal Knowledge Ontology (UKO)** vocabulary
-support for the Advanced Context Management System.  It provides a four-layer
-ontology hierarchy for representing code semantics across multiple programming
-languages, enabling actors to reason about large codebases with structured,
-budget-constrained context views.
-
-See [ADR-014](../adr/ADR-014-context-management-acms.md) for the design rationale
-and [`docs/modules/uko-provenance.md`](../modules/uko-provenance.md) for provenance
-tracking details.
-
----
-
-## Architecture Overview
-
-The UKO is organized into four layers:
-
-| Layer | Scope | Examples |
-|-------|-------|---------|
-| **Layer 0** | Universal primitives | `Container`, `Atom`, `Boundary`, `dependsOn` |
-| **Layer 1** | General code domain | `TypeDefinition`, `Callable` |
-| **Layer 2** | Programming paradigms | `uko-oo:`, `uko-func:`, `uko-proc:` |
-| **Layer 3** | Language-specific | `uko-py:`, `uko-ts:`, `uko-rs:`, `uko-java:` |
-
----
-
-## Namespace Prefixes
-
-| Prefix | IRI | Layer |
-|--------|-----|-------|
-| `uko-oo:` | `https://cleveragents.ai/ontology/uko/oo#` | 2 |
-| `uko-func:` | `https://cleveragents.ai/ontology/uko/func#` | 2 |
-| `uko-proc:` | `https://cleveragents.ai/ontology/uko/proc#` | 2 |
-| `uko-py:` | `https://cleveragents.ai/ontology/uko/py#` | 3 |
-| `uko-ts:` | `https://cleveragents.ai/ontology/uko/ts#` | 3 |
-| `uko-rs:` | `https://cleveragents.ai/ontology/uko/rs#` | 3 |
-| `uko-java:` | `https://cleveragents.ai/ontology/uko/java#` | 3 |
-
----
-
-## Core Types
-
-### `ProvenanceInfo`
-
-```python
-from cleveragents.acms import ProvenanceInfo
-
-class ProvenanceInfo(BaseModel):
-    source_resource: str        # IRI of the source resource
-    valid_from: datetime        # When this triple became valid
-    is_current: bool            # Whether this is the current revision
-    created_by: str             # Agent or process that created this
-    revision_chain: list[str]   # Ordered list of prior revision IRIs
-```
-
-Provenance contract attached to every typed triple in the UKO graph.  Enables
-temporal queries and point-in-time ontology state reconstruction.
-
----
-
-### `UKOClass`
-
-```python
-from cleveragents.acms import UKOClass
-
-class UKOClass(BaseModel):
-    uri: str                    # Fully-qualified OWL class URI
-    label: str                  # Human-readable label
-    parent_uri: str | None      # rdfs:subClassOf parent URI
-    description: str = ""       # Optional description
-```
-
-Represents an OWL class definition within a UKO vocabulary.
-
----
-
-### `UKOProperty`
-
-```python
-from cleveragents.acms import UKOProperty
-
-class UKOProperty(BaseModel):
-    uri: str                    # Fully-qualified OWL property URI
-    label: str                  # Human-readable label
-    domain_uri: str             # rdfs:domain class URI
-    range_uri: str              # rdfs:range class URI
-    parent_uri: str | None      # rdfs:subPropertyOf parent URI
-```
-
-Represents an OWL object property definition within a UKO vocabulary.
-
----
-
-### `UKOVocabulary`
-
-```python
-from cleveragents.acms import UKOVocabulary
-
-class UKOVocabulary(BaseModel):
-    prefix: str                         # Namespace prefix (e.g. "uko-py:")
-    iri: str                            # Namespace IRI
-    classes: tuple[UKOClass, ...]       # OWL classes in this vocabulary
-    properties: tuple[UKOProperty, ...]  # OWL properties in this vocabulary
-    layer2_deps: tuple[Layer2Dependency, ...]  # Layer 2 dependencies
-```
-
-Container for a complete UKO vocabulary (classes + properties + dependencies).
-
----
-
-### `Layer2Dependency`
-
-```python
-from cleveragents.acms import Layer2Dependency
-
-class Layer2Dependency(BaseModel):
-    iri: str    # Layer 2 vocabulary IRI this vocabulary depends on
-```
-
-Declares a dependency from a Layer 3 vocabulary on a Layer 2 paradigm vocabulary.
-
----
-
-## Layer 2 — Paradigm Vocabularies
-
-### `ParadigmVocabulary`
-
-```python
-from cleveragents.acms import ParadigmVocabulary
-
-class ParadigmVocabulary(BaseModel):
-    prefix: str                         # e.g. "uko-oo:"
-    iri: str                            # Namespace IRI
-    classes: tuple[VocabularyClass, ...]
-    properties: tuple[VocabularyProperty, ...]
-```
-
-Immutable (frozen) Pydantic model for a Layer 2 paradigm vocabulary.
-
-**Built-in paradigm vocabularies:**
-
-```python
-from cleveragents.acms import get_oo_vocabulary, get_func_vocabulary, get_proc_vocabulary
-
-oo_vocab = get_oo_vocabulary()      # Object-Oriented paradigm (uko-oo:)
-func_vocab = get_func_vocabulary()  # Functional paradigm (uko-func:)
-proc_vocab = get_proc_vocabulary()  # Procedural paradigm (uko-proc:)
-```
-
----
-
-### `VocabularyRegistry`
-
-```python
-from cleveragents.acms import VocabularyRegistry, DuplicateVocabularyError
-
-registry = VocabularyRegistry(vocabularies=(get_oo_vocabulary(),))
-
-# Register a vocabulary
-registry.register(get_func_vocabulary())
-
-# Look up by prefix
-vocab = registry.get_by_prefix("uko-oo:")
-
-# Look up by IRI
-vocab = registry.get_by_iri("https://cleveragents.ai/ontology/uko/oo#")
-
-# List all registered prefixes
-prefixes = registry.list_prefixes()
-
-# List all vocabularies
-all_vocabs = registry.list_all()
-
-# Unregister
-registry.unregister("uko-oo:")
-```
-
-**Thread safety:** `VocabularyRegistry` is **not** thread-safe.  Populate once
-during module initialisation under the GIL; do not mutate from multiple threads.
-
-**Raises:** `DuplicateVocabularyError` if a vocabulary with the same prefix or IRI
-is already registered.
-
----
-
-## Detail Level Maps
-
-Detail level maps control how much semantic detail is included in context views
-for each code construct.  They form an inheritance chain: Layer 3 maps extend
-Layer 2 maps, which extend Layer 1 maps.
-
-### Built-in Maps
-
-```python
-from cleveragents.acms import (
-    CODE_DETAIL_LEVEL_MAP,   # Layer 1 general code domain
-    OO_DETAIL_LEVEL_MAP,     # Layer 2 Object-Oriented
-    FUNC_DETAIL_LEVEL_MAP,   # Layer 2 Functional
-    PROC_DETAIL_LEVEL_MAP,   # Layer 2 Procedural
-)
-```
-
-Each map is a `DetailLevelMap` with a `.levels` dict mapping level names to
-integer depth values.
-
-### `DetailLevelMapBuilder`
-
-```python
-from cleveragents.acms import DetailLevelMapBuilder
-
-builder = DetailLevelMapBuilder(parent=OO_DETAIL_LEVEL_MAP)
-builder.insert("uko-py:decorator", depth=3)
-builder.insert("uko-py:type_stub", depth=4)
-py_map = builder.build()
-```
-
-Builds a new `DetailLevelMap` by inserting level entries into a parent map.
-
-### `build_detail_level_map`
-
-```python
-from cleveragents.acms import build_detail_level_map
-
-level_map = build_detail_level_map(
-    parent=OO_DETAIL_LEVEL_MAP,
-    insertions=[("uko-py:decorator", 3), ("uko-py:type_stub", 4)],
-)
-```
-
-Functional alternative to `DetailLevelMapBuilder`.
-
-### `build_effective_map`
-
-```python
-from cleveragents.acms import build_effective_map
-
-effective = build_effective_map(
-    parent=OO_DETAIL_LEVEL_MAP,
-    child=PYTHON_DETAIL_LEVELS,
-)
-```
-
-Merges a parent map and a child map into a single effective map, with child
-entries taking precedence over parent entries.
-
-### `resolve_detail_level`
-
-```python
-from cleveragents.acms import resolve_detail_level
-
-depth = resolve_detail_level(
-    name="uko-py:function",
-    maps=[PYTHON_DETAIL_LEVELS, OO_DETAIL_LEVEL_MAP, CODE_DETAIL_LEVEL_MAP],
-)
-```
-
-Walks the inheritance chain (Layer 3 → Layer 2 → Layer 1) to resolve a named
-detail level to its integer depth.  Returns `None` if not found in any map.
-
----
-
-## Layer 3 — Language Vocabularies
-
-### Python (`uko-py:`)
-
-```python
-from cleveragents.acms import (
-    PYTHON_VOCABULARY,    # ParadigmVocabulary for Python
-    PYTHON_DETAIL_LEVELS, # DetailLevelMap for Python
-    PythonModule,
-    PythonClass,
-    PythonFunction,
-    PythonDecorator,
-    PythonTypeStub,
-)
-```
-
-| Class | Parent | Description |
-|-------|--------|-------------|
-| `PythonModule` | `uko-oo:Module` | A Python `.py` module |
-| `PythonClass` | `uko-oo:Class` | A Python class definition |
-| `PythonFunction` | `uko-oo:Method` | A Python function or method |
-| `PythonDecorator` | `uko-oo:Annotation` | A Python decorator |
-| `PythonTypeStub` | `uko-oo:Interface` | A `.pyi` type stub |
-
-### TypeScript (`uko-ts:`)
-
-```python
-from cleveragents.acms import (
-    TYPESCRIPT_VOCABULARY,
-    TYPESCRIPT_DETAIL_LEVELS,
-    TypeScriptModule,
-    TypeScriptClass,
-    TypeScriptFunction,
-    TypeScriptInterface,
-)
-```
-
-### Rust (`uko-rs:`)
-
-```python
-from cleveragents.acms import (
-    RUST_VOCABULARY,
-    RUST_DETAIL_LEVELS,
-    RustStruct,
-    RustTrait,
-    RustImpl,
-    RustFunction,
-    RustDeriveAttribute,
-)
-```
-
-### Java (`uko-java:`)
-
-```python
-from cleveragents.acms import (
-    JAVA_VOCABULARY,
-    JAVA_DETAIL_LEVELS,
-    JavaClass,
-    JavaInterface,
-    JavaMethod,
-    JavaAnnotation,
-    JavaCheckedException,
-)
-```
-
----
-
-## Usage Example
-
-```python
-from cleveragents.acms import (
-    VocabularyRegistry,
-    get_oo_vocabulary,
-    get_func_vocabulary,
-    PYTHON_VOCABULARY,
-    PYTHON_DETAIL_LEVELS,
-    OO_DETAIL_LEVEL_MAP,
-    resolve_detail_level,
-)
-
-# Build a registry with Layer 2 paradigm vocabularies
-registry = VocabularyRegistry(
-    vocabularies=(
-        get_oo_vocabulary(),
-        get_func_vocabulary(),
-    )
-)
-
-# Resolve a detail level for a Python function
-depth = resolve_detail_level(
-    name="uko-py:function",
-    maps=[PYTHON_DETAIL_LEVELS, OO_DETAIL_LEVEL_MAP],
-)
-print(f"Python function detail depth: {depth}")
-
-# Look up a vocabulary by prefix
-oo_vocab = registry.get_by_prefix("uko-oo:")
-print(f"OO vocabulary has {len(oo_vocab.classes)} classes")
-```
-
----
-
-> **Note:** The ACMS module is internal to the context assembly pipeline.
-> Direct use is only needed when implementing custom context strategies.
-> For typical usage, configure context policies via `agents context` CLI
-> commands — see the [Specification](../specification.md) for details.

docs/api/index.md

@@ -18,7 +18,6 @@ classes, functions, and exceptions with signatures and usage examples.
 | [`cleveragents.config`](config.md) | Application settings, logging, metrics, and security scanning |
 | [`cleveragents.providers`](providers.md) | AI provider registry — discovery, selection, LLM factory, and capability metadata |
 | [`cleveragents.tui`](tui.md) | Interactive Terminal UI — app, persona system, input routing, slash commands, session export/import |
-| [`cleveragents.acms`](acms.md) | Advanced Context Management System — UKO vocabulary registry, Layer 2/3 paradigm and language vocabularies, detail level maps |
 
 > **Note:** Internal modules (prefixed with `_`) and implementation details
 > not listed in a module's `__all__` are considered private and may change

docs/development/automation-tracking.md

@@ -360,12 +360,6 @@ Every agent that creates tracking issues must implement:
 - **Content**: Build orchestration status, worker pool health
 - **Cleanup**: Handled by automation-tracking-manager
 
-#### docs-writer
-- **Cycle Frequency**: Documentation reports every 10 cycles (~3.3 hours)
-- **Issue Types**: Documentation Report
-- **Content**: Docs created/updated/skipped, commit hash, milestone coverage
-- **Cleanup**: Deletes previous documentation report issues
-
 ## Searching and Filtering
 
 ### Finding Tracking Issues

docs/development/docs-writer.md

@@ -5,7 +5,7 @@
 **Reporting Interval**: Every 10 cycles (~3.3 hours)
 
 The `docs-writer` agent is a continuous documentation monitoring and generation
-service. It runs in an isolated clone of the repository, polls for merged code
+service.  It runs in an isolated clone of the repository, polls for merged code
 and milestone completions, and keeps project documentation current without human
 intervention.
 
@@ -35,8 +35,8 @@ cycle = 0
 LOOP:
     cycle += 1
 
-    # Create tracking issue on first cycle and then every 10 cycles
-    if cycle == 1 or cycle % 10 == 0:
+    # Create tracking issue every 10 cycles
+    if cycle % 10 == 0:
         automation-tracking-manager: CREATE_TRACKING_ISSUE
           agent_prefix: AUTO-DOCS
           tracking_type: Documentation Report
@@ -75,23 +75,15 @@ via the `automation-tracking-manager` subagent.
 Title: [AUTO-DOCS] Documentation Report (Cycle N)
 ```
 
-**Required labels** (all four must be applied):
+**Default label** (applied automatically by the manager):
 
 | Label | Purpose |
 |-------|---------|
 | `Automation Tracking` | Enables system-watchdog health monitoring |
-| `Type/Automation` | Marks as automation-related |
-| `State/In Progress` | Indicates agent is actively running |
-| `Priority/Medium` | Default priority |
 
-Tracking issue bodies MUST include the standard automation tracking header with
-the reporting interval declaration, for example:
-
-```
-**Reporting Interval**: Every 10 cycles (~3.3 hours) (Next report expected: <timestamp>)
-```
-See [Automation Tracking System](automation-tracking.md#common-header-format) for
-the complete required structure.
+Additional labels (for example `Type/Automation`, `State/In Progress`, or
+`Priority/Medium`) can be added manually when teams need extra filtering, but
+they are optional and not applied by the manager today.
 
 ### Cleanup Protocol
 
@@ -100,7 +92,7 @@ The `automation-tracking-manager` handles all cleanup:
 1. Finds the previous open `[AUTO-DOCS] Documentation Report (Cycle N)` issue
 2. Posts a closure comment
 3. Closes the issue
-4. Creates the new tracking issue with the four required labels
+4. Creates the new tracking issue with the `Automation Tracking` label
 
 Announcement issues (`[AUTO-DOCS] Announce: …`) are **never** deleted.
 
@@ -121,10 +113,8 @@ All documentation produced by this agent follows the project's
 ## Clone Isolation
 
 The agent always works in an isolated clone at `/tmp/docs-writer-<instance-id>/`.
-The instance identifier MUST be generated with a cryptographically strong
-mechanism such as `uuid.uuid4()` or `secrets.token_hex(8)` to avoid collisions
-or predictable directory names. It never modifies files in `/app` or any shared
-directory. The clone is deleted on exit (including on error).
+It never modifies files in `/app` or any shared directory.  The clone is
+deleted on exit (including on error).
 
 Push conflicts are resolved with `git pull --rebase origin master && git push`.
 After five consecutive push failures the clone is deleted and re-cloned fresh.
@@ -132,15 +122,6 @@ After five consecutive push failures the clone is deleted and re-cloned fresh.
 Since `master` is a protected branch, all documentation changes are submitted
 as pull requests from a feature branch.
 
-All Git authentication must rely on credential helpers or `GIT_ASKPASS`. The
-agent must not embed personal access tokens in remote URLs, because git will
-echo failing URLs (including credentials) to stderr when operations fail.
-
-When interacting with the Forgejo API, the agent MUST handle `HTTP 429` rate
-limit responses by backing off exponentially (starting at 60 seconds, capped at
-the 20 minute cycle delay) before retrying the request. This prevents tight
-retry loops during temporary throttling events.
-
 ---
 
 ## Related Documentation

docs/development/setup.md

@@ -0,0 +1,521 @@
+# Developer Setup Guide
+
+This guide walks you through setting up a local development environment for
+**cleveragents-core** from scratch. By the end you will have a fully working
+environment with all dependencies installed, tests passing, and pre-commit hooks
+active.
+
+---
+
+## 1. Prerequisites
+
+Install the following tools before cloning the repository.
+
+### Python 3.13+
+
+CleverAgents requires **Python 3.13** or later.
+
+```bash
+# Verify your installed version
+python3 --version   # must print Python 3.13.x or higher
+```
+
+Recommended installation methods:
+
+| Platform | Method |
+|----------|--------|
+| macOS | `brew install python@3.13` or [python.org](https://www.python.org/downloads/) |
+| Linux (Debian/Ubuntu) | `sudo apt install python3.13 python3.13-venv python3.13-dev` |
+| Linux (Fedora/RHEL) | `sudo dnf install python3.13` |
+| Windows | [python.org installer](https://www.python.org/downloads/) (add to PATH) |
+| Any | [pyenv](https://github.com/pyenv/pyenv): `pyenv install 3.13` |
+
+### uv
+
+[uv](https://docs.astral.sh/uv/) is the project's fast Python package manager and
+virtual-environment tool.
+
+```bash
+# macOS / Linux
+curl -LsSf https://astral.sh/uv/install.sh | sh
+
+# Windows (PowerShell)
+powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
+
+# Verify
+uv --version
+```
+
+### nox
+
+[nox](https://nox.thea.codes/) is the project's task runner. All test, lint,
+type-check, and build commands are executed through `nox` sessions — **never**
+invoke `behave`, `ruff`, `pyright`, or other tools directly.
+
+```bash
+pip install nox
+# or, using uv:
+uv tool install nox
+```
+
+### Git
+
+Git 2.30+ is required. Most systems ship a recent enough version.
+
+```bash
+git --version   # must be 2.30 or later
+```
+
+### Commitizen (optional but recommended)
+
+[Commitizen](https://commitizen.github.io/cz-cli/) guides you through writing
+[Conventional Changelog](https://github.com/conventional-changelog/conventional-changelog-eslint/blob/master/convention.md)-compliant
+commit messages interactively. All commits **must** follow this standard.
+
+```bash
+npm install -g commitizen@2.8.6 cz-customizable@4.0.0
+```
+
+> **Note:** npm is only needed for Commitizen. Node.js is not otherwise required
+> to develop or run cleveragents-core.
+
+### pre-commit
+
+[pre-commit](https://pre-commit.com/) runs automated checks before each commit.
+It is installed as part of the dev dependencies (see [Getting Started](#2-getting-started))
+but the CLI must also be available on your PATH.
+
+```bash
+pip install pre-commit
+# or, using uv:
+uv tool install pre-commit
+```
+
+---
+
+## 2. Getting Started
+
+### Clone the Repository
+
+```bash
+git clone https://git.cleverthis.com/cleveragents/cleveragents-core.git
+cd cleveragents-core
+```
+
+### Create and Activate a Virtual Environment
+
+```bash
+# Create a venv with Python 3.13
+uv venv --python 3.13
+
+# Activate (macOS / Linux)
+source .venv/bin/activate
+
+# Activate (Windows PowerShell)
+.venv\Scripts\Activate.ps1
+```
+
+### Install All Dependencies
+
+Install the package in editable mode together with all development and test
+extras:
+
+```bash
+uv pip install -e ".[dev,tests,docs]"
+```
+
+This installs:
+
+- **Runtime** dependencies (typer, pydantic, langchain, etc.)
+- **Dev** extras: ruff, pyright, behave, pytest, pre-commit, bandit, semgrep,
+  vulture, radon
+- **Tests** extras: behave, slipcover, asv, robotframework, robotframework-pabot
+- **Docs** extras: mkdocs, mkdocs-material, mkdocstrings
+
+### Install pre-commit Hooks
+
+```bash
+pre-commit install
+```
+
+This installs Git hooks that run linting and formatting checks automatically on
+`git commit`.
+
+### Verify the Installation
+
+Run the full default nox pipeline to confirm everything is working:
+
+```bash
+nox
+```
+
+This executes (in order): `lint` → `typecheck` → `unit_tests` →
+`integration_tests` → `coverage_report`. A clean run with all sessions passing
+means your environment is correctly set up.
+
+---
+
+## 3. Development Workflow
+
+All quality-gate commands are run through `nox`. The `noxfile.py` in the
+repository root defines every available session.
+
+### Running Tests
+
+```bash
+# Run all default sessions
+nox
+
+# Unit tests only (Behave / BDD)
+nox -s unit_tests
+
+# Integration tests only (Robot Framework)
+nox -s integration_tests
+
+# Coverage report — enforces ≥ 97% threshold
+nox -s coverage_report
+
+# Run a single Behave feature file
+nox -s unit_tests -- features/plan_model.feature
+
+# Run scenarios with a specific tag
+nox -s unit_tests -- --tags=@smoke
+
+# Run a single Robot suite
+nox -s integration_tests -- --suite robot/plan_persistence_e2e.robot
+
+# Performance benchmarks (ASV)
+nox -s benchmark
+```
+
+> See [Testing Guide](testing.md) for full details on the testing strategy,
+> coverage requirements, and test suite structure.
+
+### Linting
+
+```bash
+# Check for lint violations (ruff)
+nox -s lint
+
+# Auto-fix safe violations
+nox -s lint -- --fix
+
+# Check formatting only (no changes)
+nox -s format -- --check
+
+# Apply formatting
+nox -s format
+```
+
+Ruff is configured in `pyproject.toml` under `[tool.ruff]`. The project targets
+Python 3.13 with an 88-character line length and enforces rules from the `E`,
+`F`, `W`, `B`, `UP`, `I`, `SIM`, and `RUF` rule sets.
+
+### Type Checking
+
+```bash
+# Run pyright type checker
+nox -s typecheck
+```
+
+Pyright is configured in `pyproject.toml` under `[tool.pyright]`. All source
+files under `src/` must pass strict type checking. Do not add `# type: ignore`
+comments without a documented justification.
+
+### Security Scanning
+
+```bash
+# Run bandit + vulture
+nox -s security_scan
+
+# Complexity metrics (radon)
+nox -s complexity
+```
+
+### Building Documentation
+
+```bash
+# Build the MkDocs site locally
+nox -s docs
+
+# Serve docs with live reload at http://127.0.0.1:8000
+nox -s docs -- serve
+```
+
+### Full Quality Gate (pre-PR checklist)
+
+Before opening a pull request, run the complete quality gate:
+
+```bash
+nox
+```
+
+All sessions must pass. The CI pipeline enforces the same checks and will block
+merges on any failure.
+
+---
+
+## 4. Commit Guidelines
+
+### Conventional Changelog Format
+
+Every commit **must** follow the
+[Conventional Changelog standard](https://github.com/conventional-changelog/conventional-changelog-eslint/blob/master/convention.md).
+The format is:
+
+```
+<type>(<scope>): <short summary>
+
+<optional body — wrap at 72 characters>
+
+<optional footer — ISSUES CLOSED: #N>
+```
+
+**Allowed types:**
+
+| Type | When to use |
+|------|-------------|
+| `feat` | New feature or user-visible behaviour |
+| `fix` | Bug fix |
+| `docs` | Documentation only |
+| `refactor` | Code restructuring without behaviour change |
+| `test` | Adding or updating tests |
+| `chore` | Build system, tooling, dependency updates |
+| `perf` | Performance improvement |
+| `ci` | CI/CD pipeline changes |
+
+**Example:**
+
+```
+fix(concurrency): guard execute_plan with advisory lock
+
+LockService was implemented but never wired into the plan execution
+path, leaving execute_plan() unprotected against concurrent calls.
+
+ISSUES CLOSED: #7989
+```
+
+### Using Commitizen (recommended)
+
+```bash
+# Instead of `git commit`, use:
+git cz
+```
+
+Commitizen walks you through an interactive prompt to build a correctly
+formatted commit message. All CleverThis repositories ship a local
+`cz-customizable` configuration.
+
+### Atomic Commits
+
+- **One logical change per commit.** Never bundle unrelated changes.
+- **Include tests with the change.** Feature + tests are one logical unit.
+- **Include documentation with the change.** Update relevant docs in the same commit.
+- **Each commit must build and pass all tests.** The repository must be in a
+  working state at every commit in history.
+
+See [CONTRIBUTING.md](../../CONTRIBUTING.md) for the full commit quality policy.
+
+### Branch Naming
+
+Use the following prefixes:
+
+| Prefix | Purpose |
+|--------|---------|
+| `feat/<issue>-<slug>` | New feature |
+| `fix/<issue>-<slug>` | Bug fix |
+| `docs/<slug>` | Documentation |
+| `refactor/<slug>` | Refactoring |
+| `chore/<slug>` | Tooling / maintenance |
+| `test/<slug>` | Test-only changes |
+
+Examples:
+
+```
+feat/issue-1234-plan-correction-rollback
+fix/7989-lock-service-concurrency
+docs/developer-setup-guide
+```
+
+---
+
+## 5. Devcontainer Setup
+
+The repository ships a [Dev Container](https://containers.dev/) configuration
+that provides a fully pre-configured development environment with Python 3.13,
+uv, nox, and all dependencies pre-installed. This is the **recommended** setup
+for contributors who want zero-friction onboarding.
+
+### Requirements
+
+- [Docker Desktop](https://www.docker.com/products/docker-desktop/) (macOS /
+  Windows) or Docker Engine (Linux)
+- [VS Code](https://code.visualstudio.com/) with the
+  [Dev Containers extension](https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.remote-containers),
+  **or** the [devcontainer CLI](https://github.com/devcontainers/cli)
+
+### Opening in VS Code
+
+1. Open the repository folder in VS Code.
+2. When prompted *"Reopen in Container"*, click **Reopen in Container**.
+   Alternatively: open the Command Palette (`Ctrl+Shift+P` / `Cmd+Shift+P`) and
+   run **Dev Containers: Reopen in Container**.
+3. VS Code builds the container image and installs all extensions. This takes a
+   few minutes on first run; subsequent opens are fast.
+4. A terminal inside the container is ready to use. All tools (`uv`, `nox`,
+   `git`, `pre-commit`) are on the PATH.
+
+### Using the devcontainer CLI
+
+```bash
+# Start the container
+devcontainer up --workspace-folder .
+
+# Execute a command inside the container
+devcontainer exec --workspace-folder . nox -s unit_tests
+```
+
+### Named Configurations
+
+The repository may define multiple named devcontainer configurations (e.g.,
+`default`, `docs-only`). To select one in VS Code, use
+**Dev Containers: Reopen in Container…** and choose the desired configuration
+from the list.
+
+### Environment Variables
+
+Sensitive configuration (API keys, database URLs) should be placed in a
+`.env` file at the repository root. The devcontainer automatically mounts
+this file. **Never commit `.env` to version control.**
+
+Common variables:
+
+| Variable | Description |
+|----------|-------------|
+| `CLEVERAGENTS_DATABASE_URL` | SQLite or PostgreSQL connection string |
+| `CLEVERAGENTS_HOME` | Override the default data directory |
+| `CLEVERAGENTS_TESTING_USE_MOCK_AI` | Set to `1` to use mock AI in tests |
+| `OPENAI_API_KEY` | OpenAI provider key (optional) |
+| `ANTHROPIC_API_KEY` | Anthropic provider key (optional) |
+
+---
+
+## 6. Troubleshooting
+
+### `python3 --version` shows < 3.13
+
+Your system Python is too old. Install Python 3.13 via pyenv, your OS package
+manager, or [python.org](https://www.python.org/downloads/), then recreate the
+virtual environment:
+
+```bash
+uv venv --python 3.13
+source .venv/bin/activate
+uv pip install -e ".[dev,tests,docs]"
+```
+
+### `nox` command not found
+
+Install nox into your system Python or via uv tools:
+
+```bash
+pip install nox
+# or
+uv tool install nox
+```
+
+Ensure the tool installation directory is on your `PATH` (uv prints the path
+after installation).
+
+### `pre-commit` hooks not running
+
+Reinstall the hooks:
+
+```bash
+pre-commit install --overwrite
+```
+
+If hooks still do not run, verify that `.git/hooks/pre-commit` exists and is
+executable.
+
+### Import errors after installing dependencies
+
+Ensure you activated the virtual environment before running any commands:
+
+```bash
+source .venv/bin/activate   # macOS / Linux
+.venv\Scripts\Activate.ps1  # Windows
+```
+
+Then verify the package is installed in editable mode:
+
+```bash
+pip show cleveragents
+```
+
+### `nox -s unit_tests` fails with `AmbiguousStep`
+
+Two Behave step files define the same step pattern. Check the error message for
+the conflicting step text, then either rename one step or add a unique prefix.
+See the [Testing Guide](testing.md#unit-tests-behave) for step naming conventions.
+
+### Coverage below 97%
+
+Run the HTML coverage report to identify uncovered lines:
+
+```bash
+nox -s coverage_report
+open build/htmlcov/index.html
+```
+
+Write Behave scenarios targeting the uncovered code paths. Do **not** lower the
+threshold or add `# pragma: no cover` without explicit team agreement.
+
+### `pyright` reports errors in generated or third-party stubs
+
+Check `pyproject.toml` under `[tool.pyright]` for the `exclude` list. Generated
+stubs under `docs/reference/contracts/stubs/` are excluded by the ruff
+configuration and should also be excluded from pyright. Add a targeted
+`# type: ignore` with a comment only as a last resort.
+
+### Robot Framework `Resource file does not exist`
+
+Always use `${CURDIR}/` prefix for `Resource` imports:
+
+```robot
+Resource    ${CURDIR}/common.resource
+```
+
+Bare paths are resolved relative to the working directory, not the test file.
+
+### Devcontainer fails to start
+
+1. Ensure Docker is running (`docker info`).
+2. Try **Dev Containers: Rebuild Container** from the VS Code Command Palette.
+3. Check the Docker build log in the VS Code Output panel for errors.
+4. If the issue persists, delete the container image and rebuild:
+   ```bash
+   docker system prune -f
+   devcontainer up --workspace-folder . --remove-existing-container
+   ```
+
+### SQLite in-memory tests lose data between steps
+
+When writing Behave tests with `sqlite:///:memory:`, use a single shared
+`Session` across all repository calls in a scenario — do not create a new
+session per call. See the [Testing Guide](testing.md#troubleshooting) for the
+correct pattern.
+
+---
+
+## See Also
+
+- [Testing Guide](testing.md) — Full testing strategy, coverage requirements,
+  and suite documentation
+- [CI/CD Pipeline](ci-cd.md) — Forgejo CI job definitions and pipeline stages
+- [Quality Automation](quality-automation.md) — Automated quality gates and
+  enforcement
+- [CONTRIBUTING.md](../../CONTRIBUTING.md) — Commit standards, code of conduct,
+  and contribution workflow
+- [Architecture Decision Records](../adr/index.md) — Key design decisions
+  (ADR-003 DI, ADR-005 Tech Stack, ADR-009 Project Model, etc.)

docs/reference/plan_apply.md

@@ -128,25 +128,12 @@ file changes are committed, `apply_with_validation_gate()` checks
 the validation summary (either from the plan or supplied externally)
 and blocks apply if any **required** validations have failed.
 
-#### Empty-Run Guard
-
-!!! warning "Apply is blocked when no validations ran"
-    `ApplyValidationSummary.all_required_passed` returns `False` when zero
-    validations were run (`is_empty == True`), even if `required_failed == 0`.
-    This prevents a security bypass where a plan with no attached validations
-    (or whose attachments were silently skipped) could proceed to apply without
-    any validation checks having been performed.
-
-    If a plan legitimately requires no validations, the `allow_empty` flag on
-    `apply_with_validation_gate()` can be used to bypass the ChangeSet empty
-    guard, but the validation gate itself is governed by `all_required_passed`.
-
 #### Outcomes
 
 | Outcome | Description |
 |---------|-------------|
 | `applied` | All required validations passed; changes committed |
-| `constrained` | Required validations failed **or** no validations ran; apply blocked |
+| `constrained` | Required validations failed; apply blocked |
 | `already_applied` | Plan was already in a terminal applied state |
 | `blocked_empty` | ChangeSet was empty and `allow_empty` not set |
 
@@ -159,8 +146,6 @@ apply_with_validation_gate(plan_id)
     |
     +-- Empty ChangeSet? --> blocked_empty (unless allow_empty)
     |
-    +-- summary.is_empty? --> constrained ("no validations ran")
-    |
     +-- required_failed > 0? --> constrained (with actionable message)
     |
     +-- All passed --> persist_apply_summary() --> complete_apply()

docs/reference/validation_pipeline.md

@@ -216,50 +216,9 @@ Per-validation execution result.
 
 Aggregated results with gating decision.
 
-| Property                  | Type   | Description                                                                  |
-|---------------------------|--------|------------------------------------------------------------------------------|
-| `total`                   | `int`  | Total number of validations run                                              |
-| `required_passed`         | `int`  | Number of required validations that passed                                   |
-| `required_total`          | `int`  | Total number of required validations evaluated                               |
-| `required_failed`         | `int`  | Number of required validations that failed                                   |
-| `informational_passed`    | `int`  | Number of informational validations that passed                              |
-| `informational_failed`    | `int`  | Number of informational validations that failed                              |
-| `all_required_passed`     | `bool` | `True` only when at least one validation ran **and** no required ones failed |
-| `is_empty`                | `bool` | `True` when zero validations were run (`total == 0`)                         |
-
-#### `all_required_passed` — Empty-Run Guard
-
-!!! warning "Security: Empty-Run Guard"
-    `all_required_passed` returns `False` whenever `is_empty` is `True` (i.e., zero
-    validations were run), **even if `required_failed == 0`**.
-
-    **Why this matters**: Without this guard, a plan with no attached validations
-    (or whose attachments were silently skipped) would trivially pass the apply gate,
-    bypassing all validation checks. The empty-run guard ensures that apply is only
-    permitted when at least one validation was actually executed.
-
-The full evaluation logic is:
-
-```python
-@property
-def all_required_passed(self) -> bool:
-    if self.is_empty:          # zero validations ran → block apply
-        return False
-    return self.required_failed == 0
-```
-
-| Condition                                     | `all_required_passed` | Outcome           |
-|-----------------------------------------------|-----------------------|-------------------|
-| No validations ran (`total == 0`)             | `False`               | Apply **blocked** |
-| Required validations ran, none failed         | `True`                | Apply **allowed** |
-| Required validations ran, at least one failed | `False`               | Apply **blocked** |
-| Only informational validations ran            | `True`                | Apply **allowed** |
-
-> **Note**: A summary containing only informational validations (no required ones) with
-> `total > 0` will have `required_failed == 0` and `is_empty == False`, so
-> `all_required_passed` returns `True`. This is intentional — if no required validations
-> are attached, there is nothing to block on. The empty-run guard specifically targets
-> the case where *no validations at all* were run.
+**Properties:** `total`, `required_passed`, `required_failed`,
+`informational_passed`, `informational_failed`, `all_required_passed`,
+`is_empty`
 
 **Methods:**
 - `to_plan_metadata()` — Dict for plan `validation_summary` field

docs/specification.md

@@ -22615,8 +22615,7 @@ Validation is the **final step** of the Execute phase. The execution actor's wor
 2. **Collect applicable validations**: The system resolves all validations from the resource-direct, project, and plan scopes (as described in Attachment Resolution above).
 3. **Execute validations**: Each applicable validation is invoked as a standard tool call. The validation reads the sandbox state and returns its structured result. Validations may be run in parallel since they are read-only and cannot interfere with each other.
 4. **Process results**:
-   - **All required validations pass (and at least one ran)**: Execution is complete. The plan transitions to the review/Apply phase.
-   - **No validations ran** (`ApplyValidationSummary.is_empty == True`): Execution is **blocked** — the apply gate requires at least one validation to have actually executed. This prevents a silent bypass where a plan with no attached validations could proceed to apply unchecked. See [Empty-Run Guard](#empty-run-guard) below.
+   - **All required validations pass**: Execution is complete. The plan transitions to the review/Apply phase.
    - **Any required validation fails**: The execution actor enters the fix-then-revalidate loop (see Validation Failure Handling below).
    - **Informational validations fail**: Results are recorded in the plan's validation summary. No fix attempts are made.
 
@@ -22629,42 +22628,6 @@ Validation is the **final step** of the Execute phase. The execution actor's wor
 
     **Rationale**: Introducing validation during Apply would create situations where committed changes might need to be rolled back, defeating the purpose of the sandbox model.
 
-#### Empty-Run Guard
-
-!!! warning "Apply gate requires at least one validation to have run"
-    `ApplyValidationSummary.all_required_passed` returns `False` when the
-    validation result set is empty (`is_empty == True`), **regardless of
-    `required_failed`**. This is the **empty-run guard**.
-
-**Rationale**: Prior to this guard, `all_required_passed` returned `True`
-trivially when zero validations ran (because `required_failed == 0` with an
-empty result set). This created a security bypass: a plan with no attached
-validations — or one whose attachments were silently dropped — could proceed
-to apply without any validation checks having been performed.
-
-The guard was introduced in commit `b84022795` (fix: validation_apply.py
-`all_required_passed` returns `True` when zero validations run, issue #7508).
-
-**Behaviour summary**:
-
-| Validation result set | `is_empty` | `required_failed` | `all_required_passed` |
-|-----------------------|------------|-------------------|-----------------------|
-| Empty (no validations ran) | `True` | 0 | `False` — apply **blocked** |
-| Non-empty, no required failures | `False` | 0 | `True` — apply **allowed** |
-| Non-empty, required failure(s) | `False` | > 0 | `False` — apply **blocked** |
-
-**Implementation** (`ApplyValidationSummary.all_required_passed`):
-
-```python
-@property
-def all_required_passed(self) -> bool:
-    if self.is_empty:   # zero validations ran → block apply
-        return False
-    return self.required_failed == 0
-```
-
-See also: [`ApplyValidationSummary` reference](../reference/validation_pipeline.md#applyvalidationsummary).
-
 #### Validation Failure Handling
 
 Because validations are tools, their execution follows the standard tool invocation flow. Each validation returns a structured JSON result with `{ "passed": true/false, "message": "...", "data": {...} }`. The execution actor interprets these results based on the validation's `mode`.
@@ -46834,18 +46797,17 @@ The following table shows which Protocol each pipeline slot implements and what
 
 ## Milestone Plan
 
-This section defines the ordered milestone plan for CleverAgents v3.x, mapping architectural features to verifiable deliverables. Each milestone builds on the previous and is independently testable. Milestones v3.0.0 and v3.1.0 are **complete**. This plan covers v3.2.0 through v3.8.0 — the production-ready target including server mode.
+This section defines the ordered milestone plan for CleverAgents v3.x, mapping architectural features to verifiable deliverables. Each milestone builds on the previous and is independently testable. Milestones v3.0.0 and v3.1.0 are **complete**. This plan covers v3.2.0 through v3.7.0 — the production-ready target.
 
-!!! note "Milestone Status (as of 2026-04-11)"
+!!! note "Milestone Status (as of 2026-04-08)"
     - **v3.0.0** ✅ CLOSED — Minimal Local Source-Code Workflow
     - **v3.1.0** ✅ CLOSED — Actor Compiler + Full LLM Integration
-    - **v3.2.0** 🔄 IN PROGRESS — Decisions + Validations + Invariants (571 open / 257 closed)
-    - **v3.3.0** 🔄 IN PROGRESS — Corrections + Subplans + Checkpoints (122 open / 108 closed)
-    - **v3.4.0** 🔄 IN PROGRESS — ACMS v1 + Context Scaling (200 open / 137 closed)
-    - **v3.5.0** 🔄 IN PROGRESS — Autonomy Hardening (971 open / 201 closed)
-    - **v3.6.0** 🔄 IN PROGRESS — Advanced Concepts & Deferred Features (282 open / 150 closed)
-    - **v3.7.0** 🔄 IN PROGRESS — TUI Implementation (526 open / 427 closed)
-    - **v3.8.0** 🔄 IN PROGRESS — Server Implementation (352 open / 132 closed)
+    - **v3.2.0** 🔄 IN PROGRESS — Decisions + Validations + Invariants (85 open / 235 closed)
+    - **v3.3.0** 🔄 IN PROGRESS — Corrections + Subplans + Checkpoints (65 open / 108 closed)
+    - **v3.4.0** 🔄 IN PROGRESS — ACMS v1 + Context Scaling (55 open / 130 closed)
+    - **v3.5.0** 🔄 IN PROGRESS — Autonomy Hardening (486 open / 188 closed)
+    - **v3.6.0** 🔄 IN PROGRESS — Advanced Concepts & Deferred Features (162 open / 150 closed)
+    - **v3.7.0** 🔄 IN PROGRESS — TUI Implementation (461 open / 403 closed)
 
 ---
 
@@ -47104,60 +47066,6 @@ This section defines the ordered milestone plan for CleverAgents v3.x, mapping a
 
 ---
 
-### v3.8.0 — Server Implementation
-
-**Goal**: Implement the CleverAgents server and all server-dependent capabilities using the A2A (Agent-to-Agent) protocol standard. The server enables multi-device collaboration, shared namespaces, team RBAC, and cloud-hosted actor execution via LangGraph Platform.
-
-**Spec Coverage**: [Server and Client Architecture](#server-and-client-architecture), [A2A Protocol](#agent-to-agent-protocol-a2a), [Authentication and Authorization](#authentication-and-authorization)
-
-**Key ADRs**: [ADR-047](adr/ADR-047-acp-standard-adoption.md), [ADR-048](adr/ADR-048-server-application-architecture.md)
-
-!!! note "Sequencing"
-    v3.8.0 has no deadline. Development effort should focus on M1–M6 (v3.2.0–v3.7.0) first. v3.8.0 work may proceed in parallel but is not on the critical path for local-mode production readiness.
-
-#### Deliverables
-
-| # | Deliverable | Spec Reference | Verifiable Check |
-|---|-------------|----------------|-----------------|
-| 1 | A2A JSON-RPC 2.0 wire format: standard operations (`message/send`, `message/stream`, task lifecycle) | §Server and Client Architecture — Server Presentation Layer | `curl` to A2A endpoint returns valid JSON-RPC 2.0 response |
-| 2 | `_cleveragents/` extension method routing: plan lifecycle, registry CRUD, entity sync, namespace management | §Server and Client Architecture — Extension Methods | `_cleveragents/plan/use` creates a plan via server |
-| 3 | A2A stdio transport (local mode — agent as subprocess) | §A2A Protocol — Local Mode | `agents plan use` routes through A2A stdio transport in local mode |
-| 4 | A2A HTTP transport (server mode — single JSON-RPC endpoint) | §A2A Protocol — Server Mode | CLI connects to remote server via HTTP; all operations functional |
-| 5 | LangGraph Platform RemoteGraph integration for server-side actor execution | §Server Infrastructure — LangGraph Platform | Strategy and execution actors run on LangGraph Platform via RemoteGraph |
-| 6 | Server application structure: FastAPI + A2A SDK server | §Server Application Structure | Server starts, serves Agent Card at discovery endpoint |
-| 7 | API token authentication: `Authorization: Bearer <token>` header | §Authentication and Authorization — API Tokens | Requests without valid token return 401; valid token accepted |
-| 8 | Team RBAC: namespace-scoped read/write/admin permissions | §Authentication and Authorization — Team RBAC | User without write permission cannot create plans in restricted namespace |
-| 9 | Entity sync via `_cleveragents/sync/*` extension methods | §Entity Sync | `_cleveragents/sync/pull` fetches server entities to local registry |
-| 10 | Multi-device experience: shared namespaces accessible from any device | §Multi-Device Experience | Plan created on device A visible from device B via shared namespace |
-| 11 | Shared namespaces: team members access same actors, actions, projects | §Shared Namespaces | Actor in shared namespace usable by all team members |
-| 12 | PostgreSQL backend for server persistence | §Server Infrastructure — Persistence | Server stores plans, decisions, and registry data in PostgreSQL |
-| 13 | Server deployment: Docker container with `docker compose up` | §Server Deployment — Docker | `docker compose up` starts server; health check endpoint returns 200 |
-| 14 | Server deployment: Kubernetes Helm chart | §Server Deployment — Kubernetes | `helm install cleveragents ./charts/cleveragents` deploys to cluster |
-| 15 | `agents server add` registers a remote server in local config | §CLI Commands — server | Round-trip: add server, list shows it, CLI connects to it |
-| 16 | `agents server status` shows server health and version | §CLI Commands — server status | Command exits 0, shows server version and uptime |
-| 17 | Multi-turn interactions forwarded to client: `_cleveragents/fs/*`, `_cleveragents/terminal/*` | §Server Presentation Layer — Multi-Turn | Server-hosted actor can read client-local files via forwarded fs operations |
-| 18 | Test coverage ≥ 97% | §Quality Gates | `nox -s coverage_report` passes |
-
-#### Key Architectural Constraints
-
-- **A2A exclusivity**: The server exposes **only** an A2A JSON-RPC 2.0 endpoint. No REST API, no GraphQL, no admin endpoint.
-- **Shared domain/application layers**: Server and client share identical Domain and Application layer packages. Zero behavioral drift between local and server modes.
-- **LangGraph Platform**: Actor graphs are deployed to LangGraph Platform as separate deployments; server invokes them via RemoteGraph. The server does NOT run actor graphs in-process.
-- **PostgreSQL schema**: Server uses the same schema as the SQLite client database, with PostgreSQL-specific extensions for multi-tenancy (namespace isolation, team membership).
-- **Authentication boundary**: All A2A requests require a valid API token. Tokens are scoped to a namespace; team RBAC controls per-namespace permissions.
-- **Extension method routing**: `_cleveragents/` methods are routed to Application-layer services. Standard A2A operations (`message/send`, etc.) are routed to `SessionWorkflow` and actor execution.
-- **Multi-turn forwarding**: When a server-hosted actor needs client-local resources (files, terminal), it sends a `_cleveragents/fs/*` or `_cleveragents/terminal/*` request back to the connected client via the A2A task `input-required` mechanism.
-
-#### Definition of Done
-
-- All 18 deliverables verified by automated tests
-- `nox` passes with coverage ≥ 97%
-- No open P0/P1 bugs in v3.8.0 milestone
-- Server starts, accepts A2A connections, executes plans via LangGraph Platform, and persists to PostgreSQL
-- CLI connects to remote server; all plan lifecycle operations functional in server mode
-
----
-
 ### Cross-Milestone Quality Gates
 
 These quality gates apply to **every milestone** and must pass before a milestone is considered complete:

docs/timeline.md

@@ -10,25 +10,26 @@ The following chart shows all 29 epics across 9 legendary workstreams, 7 milesto
 @startgantt
 
 title CleverAgents Core — Epic-Level Project Schedule
-footer Generated 2026-04-12 | 29 Epics | 9 Legendaries | 7 Milestones | 6 Developers | ~1650 SP | ~3 open bugs | 257 open PRs | Session 4 active
+footer Generated 2026-04-10 | 29 Epics | 9 Legendaries | 7 Milestones | 6 Developers | ~1650 SP | ~25 open bugs | 225 open PRs | Session 4 active
 
 Project starts 2026-02-03
 saturday are closed
 sunday are closed
 printscale weekly zoom 2
 
-today is 2026-04-12
+today is 2026-04-10
 today is colored in #FF6666
 
 ' ================================================================
-'  GANTT CHART UPDATE LOG (Day 102 — 2026-04-12)
-'  Changes: Day 102 refresh (cycle 1). Session 4 active (issue #4799, 32 workers).
-'  Open PRs: 225→257 (+32 new PRs). Open bugs: ~25→3 (Type/Bug label, major bug-fix wave).
-'  M3 28% (262/948, scope expanded 770→948), M4 46% (108/233), M5 40% (137/345),
-'  M6 17% (201/1181, scope expanded 1085→1181), M7 35% (152/433),
-'  M8 45% (427/956), M9 27% (132/489). v3.9.0 milestone added (13 open, 4 closed).
-'  Significant bug-fix wave: open bugs dropped from ~25 to 3.
-'  Open PRs grew from 225 to 257 (+32 new agent-driven PRs).
+'  GANTT CHART UPDATE LOG (Day 100 — 2026-04-10)
+'  Changes: Day 100 refresh (cycle 2). Session 4 active (issue #4799, 32 workers).
+'  Open PRs: 221→225 (new PRs opened by agents). Open bugs: ~25 (Type/Bug label).
+'  M3 32% (249/770, scope expanded!), M4 49% (108/220), M5 43% (133/313),
+'  M6 18% (197/1085, scope massively expanded!), M7 38% (150/400),
+'  M8 45% (425/944), M9 28% (131/475).
+'  Massive scope expansion across all milestones since Day 98.
+'  pr-merge-pool-supervisor added as 17th supervisor. PR review reduced to 1 approval.
+'  git worktree sandbox merged. ACMS indexing pipeline wired.
 ' ================================================================
 
 <style>
@@ -230,7 +231,7 @@ ganttDiagram {
 
 [Decisions + Validations M3 (#357)] as [M3] on {Luis} {Hamza} {Brent} {Jeff} requires 4 days
 [M3] starts at [M2]'s end
-[M3] is 28% completed
+[M3] is 65% completed
 [M3] is colored in LightSkyBlue/SteelBlue
 
 ' ── v3.3.0 MILESTONE ─────────────────────────────────────────
@@ -251,7 +252,7 @@ ganttDiagram {
 
 [Corrections + Checkpoints M4 (#358)] as [M4] on {Luis} {Jeff} {Brent} {Hamza} requires 3 days
 [M4] starts at [M3]'s end
-[M4] is 46% completed
+[M4] is 60% completed
 [M4] is colored in LightSkyBlue/SteelBlue
 
 
@@ -282,12 +283,12 @@ ganttDiagram {
 
 [ACMS v1 + Context Scaling M5 (#359)] as [M5] on {Hamza} {Jeff} {Aditya} {Brent} requires 4 days
 [M5] starts at [M4]'s end
-[M5] is 40% completed
+[M5] is 68% completed
 [M5] is colored in LightSkyBlue/SteelBlue
 
 [Autonomy Hardening + Stubs M6 (#360)] as [M6] on {Luis} {Jeff} {Hamza} {Brent} requires 5 days
 [M6] starts at [M5]'s end
-[M6] is 17% completed
+[M6] is 55% completed
 [M6] is colored in LightSkyBlue/SteelBlue
 
 
@@ -298,7 +299,7 @@ ganttDiagram {
 
 [Large Project Autonomy (#369)] as [LARGE] on {Luis} {Brent} {Jeff} requires 4 days
 [LARGE] starts 2026-03-17
-[LARGE] is 35% completed
+[LARGE] is 43% completed
 [LARGE] is colored in LightSkyBlue/SteelBlue
 
 ' ── v3.5.0 MILESTONE ─────────────────────────────────────────
@@ -444,7 +445,7 @@ saturday are closed
 sunday are closed
 printscale weekly zoom 2
 
-today is 2026-04-12
+today is 2026-04-10
 today is colored in #FF6666
 
 <style>
@@ -1965,13 +1966,13 @@ This section provides a high-level overview of the CleverAgents implementation r
 
 ### Current Status Summary
 
-As of Day 102 (2026-04-12), the project has **257 open PRs** and **~3181 open issues** across active milestones. **Session 4 is active (launched 2026-04-08, issue #4799) with 32 parallel workers and full supervisor fleet**. Bug count is **~3 open bugs** (Type/Bug label — major bug-fix wave since Day 100). M8 (v3.7.0) is now **45% complete** (427/956 issues closed). M3 (v3.2.0) at **28%** (262/948 — scope expanded 770→948), M4 (v3.3.0) at **46%** (108/233), M5 (v3.4.0) at **40%** (137/345), M6 (v3.5.0) at **17%** (201/1181 — scope expanded 1085→1181), M7 (v3.6.0) at **35%** (152/433).
+As of Day 100 (2026-04-10), the project has **225 open PRs** and **~2777 open issues** across active milestones. **Session 4 is active (launched 2026-04-08, issue #4799) with 32 parallel workers and full supervisor fleet**. Bug count is **~25 open bugs** (Type/Bug label; UAT issues tracked separately). M8 (v3.7.0) is now **45% complete** (425/944 issues closed). M3 (v3.2.0) at **32%** (249/770 — scope massively expanded), M4 (v3.3.0) at **49%** (108/220), M5 (v3.4.0) at **43%** (133/313), M6 (v3.5.0) at **18%** (197/1085 — scope massively expanded), M7 (v3.6.0) at **38%** (150/400).
 
-**M1, M2 fully complete. M3 (v3.2.0)**: 28% complete (262/948), 686 open issues — scope expanded massively. **M4 (v3.3.0)**: 46% complete (108/233), 125 open issues. **M5 (v3.4.0)**: 40% complete (137/345), 208 open issues. **M6 (v3.5.0)**: 17% complete (201/1181), 980 open issues — scope expanded massively. **M7 (v3.6.0)**: 35% complete (152/433), 281 open issues. **M8 (v3.7.0)**: 45% complete (427/956), 529 open issues. **M9 (v3.8.0)**: 27% complete (132/489), 357 open issues. All milestones M3-M7 are **overdue**; M8/M9 in active development. New v3.9.0 milestone added (13 open, 4 closed).
+**M1, M2 fully complete. M3 (v3.2.0)**: 33% complete (248/757), 509 open issues — scope expanded massively. **M4 (v3.3.0)**: 49% complete (108/220), 112 open issues. **M5 (v3.4.0)**: 44% complete (133/301), 168 open issues. **M6 (v3.5.0)**: 18% complete (197/1065), 868 open issues — scope expanded massively. **M7 (v3.6.0)**: 38% complete (150/392), 242 open issues. **M8 (v3.7.0)**: 45% complete (423/938), 515 open issues. All milestones M3-M7 are **overdue**; M8 is in active v3.7.0 development.
 
-!!! warning "Schedule Risk: All Milestones M3-M7 Overdue — Massive Scope Expansion — Session 4 Active (Day 102: 257 Open PRs, M3/M6 Scope Expanded)"
+!!! warning "Schedule Risk: All Milestones M3-M7 Overdue — Massive Scope Expansion — Session 4 Active (Day 100: 219 Open PRs, M3/M6 Scope Exploded)"
 
-    All milestones M3 through M7 have passed their target dates. **Session 4 active (launched 2026-04-08, issue #4799) with 32 parallel workers**. Open PRs at **257** (up from 225 — agents opened 32 new PRs). Open bugs at **~3** (Type/Bug label — major bug-fix wave). Session tracker issue: #4799. **Current priorities**: (1) **M3 scope explosion** — 686 open issues; scope grew from 770 to 948 total. (2) **M6 scope explosion** — 980 open issues; scope grew from 1085 to 1181 total. (3) **Merge 257 open PRs** — pr-merge-pool-supervisor active. (4) **Continue M8 push** — 45% complete, 529 issues remaining. (5) **Clear M4/M5 backlogs** — M4 at 46% (125 open), M5 at 40% (208 open).
+    All milestones M3 through M7 have passed their target dates. **Session 4 active (launched 2026-04-08, issue #4799) with 32 parallel workers**. Open PRs at **219** (up from 1 — agents opened many new PRs). Open bugs at **~5** (Type/Bug label). Session tracker issue: #4799. **Current priorities**: (1) **M3 scope explosion** — 509 open issues (was 85 at Day 98); scope grew from 320 to 757 total. (2) **M6 scope explosion** — 868 open issues (was 450 at Day 98); scope grew from 638 to 1065 total. (3) **Merge 219 open PRs** — pr-merge-pool-supervisor added as 17th supervisor. (4) **Continue M8 push** — 45% complete, 515 issues remaining. (5) **Clear M4/M5 backlogs** — M4 at 49% (112 open), M5 at 44% (168 open).
 
 ### Parallel Workstreams
 
@@ -5315,96 +5316,3 @@ Story points per developer per milestone.
 | M9 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~TBD SP |
 | M6+ | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~TBD SP |
 | **Total** | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~1649 SP |
-
-### 2026-04-12 (Day 102)
-
-**Summary**
-
-Status: Behind 25+d
-Deadline risk: CRITICAL
-
-**Notes**
-
-- Day 102 update (2026-04-12, cycle 1). Session 4 active (issue #4799, 32 parallel workers, full supervisor fleet). Open PRs: 225→257 (+32 new agent-driven PRs). Open bugs (Type/Bug label): ~25→3 (major bug-fix wave since Day 100).
-- Milestone scope continued to expand since Day 100: M3 grew from 770→948 (+178), M4 grew from 220→233 (+13), M5 grew from 313→345 (+32), M6 grew from 1085→1181 (+96), M7 grew from 400→433 (+33), M8 grew from 944→956 (+12), M9 grew from 475→489 (+14). New v3.9.0 milestone added (17 total issues, 4 closed).
-- Milestone completions (Day 102): M3 28% (262/948, was 32% at Day 100 — scope expansion outpacing closures), M4 46% (108/233, was 49%), M5 40% (137/345, was 43%), M6 17% (201/1181, was 18%), M7 35% (152/433, was 38%), M8 45% (427/956, was 45% — stable), M9 27% (132/489, was 28%).
-- Significant bug-fix wave: open Type/Bug issues dropped from ~25 to 3 (issues #7989, #7991, #7992 — LockService not wired into plan lifecycle, ServiceRetryWiring dead code at runtime, UKOQueryInterface.get_resources_by_layer never returns resources). All three are Priority/Critical.
-- Open PRs grew from 225 to 257 (+32) as agents continued opening fix/feature PRs. PR #7957 (bug-hunt-pool-supervisor tracking prefix fix) is open and awaiting merge.
-- All milestones M3-M7 remain overdue. M8 and M9 have no deadlines and are in active development. Agent-driven issue creation continues at high velocity across all milestones.
-- v3.9.0 milestone newly created (2026-04-10) with 13 open and 4 closed issues — documentation and feature updates scope.
-
-
-#### Milestone forecast
-
-| Milestone | Target -> ETA | Delta | Risk |
-|-----------|---------------|-------|------|
-| M1 (v3.0.0) | (2026-02-15) -> COMPLETE | 0d | COMPLETE |
-| M2 (v3.1.0) | (2026-02-22) -> COMPLETE | 0d | COMPLETE |
-| M3 (v3.2.0) | (2026-02-26) -> ETA 2026-06-30 | +125d | CRITICAL — 686 open issues; 28% complete (scope expanded 770→948) |
-| M4 (v3.3.0) | (2026-03-02) -> ETA 2026-05-25 | +84d | CRITICAL — 125 open issues; 46% complete |
-| M5 (v3.4.0) | (2026-03-06) -> ETA 2026-06-01 | +87d | HIGH — 208 open issues; 40% complete |
-| M6 (v3.5.0) | (2026-03-10) -> ETA 2026-08-15 | +158d | CRITICAL — 980 open issues; 17% complete (scope expanded 1085→1181) |
-| M7 (v3.6.0) | (2026-03-28) -> ETA 2026-06-25 | +89d | HIGH — 281 open issues; 35% complete |
-| M8 (v3.7.0) | (no deadline) -> ETA 2026-07-20 | N/A | HIGH — 529 open issues; 45% complete (stable) |
-| M9 (v3.8.0) | (no deadline) -> ETA 2026-08-01 | N/A | MEDIUM — 357 open issues; 27% complete |
-
-#### Track forecast
-
-| Track | Status | ETA | Risk | Blocking |
-|-------|--------|-----|------|----------|
-| Track A (Plan lifecycle + persistence) | Complete | Done | LOW | None |
-| Track B (Projects/resources + sandbox) | In Progress | ETA 2026-06-01 | HIGH | 208 open issues in v3.4.0; scope expanded +32 since Day 100 |
-| Track C (Actors/tools/skills/validations) | In Progress | ETA 2026-05-25 | CRITICAL | 125 open issues in v3.3.0; 3 critical bugs open (LockService, RetryWiring, UKO) |
-| Track D (Change tracking + apply pipeline) | In Progress | ETA 2026-06-30 | CRITICAL | 686 open issues in v3.2.0; scope expanded +178 since Day 100 |
-| Track Q (Quality automation) | Ongoing | N/A | HIGH | 3 Priority/Critical bugs open; 257 open PRs need merge; pr-merge-pool-supervisor active |
-| Track T (Testing) | Active | Ongoing | HIGH | 257 open PRs need review; UAT bugs ongoing; Session 4 active |
-
-#### Developer forecast
-
-| Name | Days Ahead/Behind | Availability | Risk | Focus |
-|------|-------------------|--------------|------|-------|
-| Jeff | -27d behind | active | HIGH | Session 4 supervisor; M3/M4/M5 backlog clearance; architecture oversight; PR merge pool |
-| Luis | -27d behind | active | HIGH | M6 (v3.5.0) features; security hardening; LockService/RetryWiring critical bugs; PR review pool |
-| Hamza | -27d behind | active | HIGH | Resource DAG; v3.6.0 features; UKO layer bug (#7992); PR reviews |
-| Aditya | -27d behind | active | HIGH | M5 features; TDD counterparts; domain model work; UAT testing |
-| Brent | -27d behind | active | HIGH | Bug fixes; TDD counterparts; quality automation; 3 critical bugs triage |
-| Rui | -27d behind | active | HIGH | TUI features; UAT bug fixes; security bug-hunt; E2E testing |
-| Mike/Brian | N/A | standby | LOW | Infrastructure support |
-
-#### Task inventory
-
-Milestone per developer as of Day 102 (2026-04-12).
-
-| Milestone | Jeff | Aditya | Luis | Hamza | Brent | Rui | Unassigned | Total |
-|-----------|------|--------|------|-------|-------|-----|------------|-------|
-| M1 | 29/29 | 16/16 | N/A | 4/4 | 10/10 | N/A | 35/35 | 96/96 |
-| M2 | 26/26 | 14/14 | N/A | 1/1 | 5/5 | N/A | 6/6 | 56/56 |
-| M3 | N/A | N/A | N/A | N/A | N/A | N/A | 686 open | 262/948 |
-| M4 | N/A | N/A | N/A | N/A | N/A | N/A | 125 open | 108/233 |
-| M5 | N/A | N/A | N/A | N/A | N/A | N/A | 208 open | 137/345 |
-| M6 | N/A | N/A | N/A | N/A | N/A | N/A | 980 open | 201/1181 |
-| M7 | N/A | N/A | N/A | N/A | N/A | N/A | 281 open | 152/433 |
-| M8 | N/A | N/A | N/A | N/A | N/A | N/A | 529 open | 427/956 |
-| M9 | N/A | N/A | N/A | N/A | N/A | N/A | 357 open | 132/489 |
-| v3.9.0 | N/A | N/A | N/A | N/A | N/A | N/A | 13 open | 4/17 |
-| **Total** | **N/A** | **N/A** | **N/A** | **N/A** | **N/A** | **N/A** | **~3181 open** | **1525/4706 closed** |
-
-Note: "done/total" = closed/total for that milestone. Assignee data reflects Forgejo API as of Day 102 (2026-04-12). Most open issues are unassigned or assigned to freemo (Jeff). Agent-driven issue creation continues at high velocity. M3 grew from 770→948 (+178), M4 grew from 220→233 (+13), M5 grew from 313→345 (+32), M6 grew from 1085→1181 (+96), M7 grew from 400→433 (+33), M8 grew from 944→956 (+12), M9 grew from 475→489 (+14) since Day 100. Open bugs dropped from ~25 to 3 (major bug-fix wave). Open PRs grew from 225 to 257 (+32 new agent-driven PRs).
-
-#### Story point allocation
-
-Story points per developer per milestone.
-
-| Milestone | Jeff | Aditya | Luis | Hamza | Brent | Rui | Unassigned | Total |
-|-----------|------|--------|------|-------|-------|-----|------------|-------|
-| M1 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~172 SP |
-| M2 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~208 SP |
-| M3 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~104 SP |
-| M4 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~126 SP |
-| M5 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~129 SP |
-| M6 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~TBD SP |
-| M7 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~100 SP |
-| M8 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~TBD SP |
-| M9 | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~TBD SP |
-| M6+ | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~TBD SP |
-| **Total** | N/A | N/A | N/A | N/A | N/A | N/A | N/A | ~1649 SP |