chore(project): update documentation

Author: krokoko

docs/guides/ROADMAP.md

@@ -160,7 +160,7 @@ These practices apply continuously across iterations and are not treated as one-
   - **Tier 2 — Code quality analysis** — Static analysis of the agent's diff against code quality principles: DRY (duplicated code detection), SOLID violations, design pattern adherence, complexity metrics (cyclomatic, cognitive), naming conventions, and repo-specific style rules (from onboarding config). Implemented as an LLM-based review step or a combination of static analysis tools (e.g. SonarQube rules, custom linters) and LLM judgment. Produces structured findings (severity, location, rule, suggestion) that the agent can act on in a fix cycle. Findings below a configurable severity threshold are advisory (included in the PR as comments) rather than blocking.
   - **Tier 3 — Risk and blast radius analysis** — Analyze the scope and impact of the agent's changes to detect unintended side effects in other parts of the codebase. Includes: dependency graph analysis (what modules/functions consume the changed code), change surface area (number of files, lines, and modules touched), semantic impact assessment (does the change alter public APIs, shared types, configuration, or database schemas), and regression risk scoring. Produces a **risk level** (low / medium / high / critical) attached to the PR as a label and included in the validation report. High-risk changes may require explicit human approval before merge (foundation for the HITL approval mode in Iteration 6). The risk level considers: number of downstream dependents affected, whether the change touches shared infrastructure or core abstractions, test coverage of the affected area, and whether the change introduces new external dependencies.
 - **PR risk level and validation report** — Every agent-created PR includes a structured **validation report** (as a PR comment or check run) summarizing: Tier 1 results (pass/fail per tool), Tier 2 findings (code quality issues by severity), Tier 3 risk assessment (risk level, blast radius summary, affected modules). The PR is labeled with the computed risk level (`risk:low`, `risk:medium`, `risk:high`, `risk:critical`). Risk level is persisted in the task record for evaluation and trending. See [EVALUATION.md](../design/EVALUATION.md#pr-risk-level).
-- **Other task types: PR review** — Support at least one additional task type beyond "implement from issue": **review pull request** (read-only or comment-only). The agent reads the PR diff, runs analysis (tests, lint, code review heuristics), and posts review comments. This uses a different blueprint (no branch creation, no PR creation — just analysis and comments) and a different system prompt. It validates that the platform is not hardwired to a single task type.
+- [x] **Other task types: PR review and PR-iteration** — Support additional task types beyond "implement from issue": **review pull request** (read-only or comment-only). The agent reads the PR diff, runs analysis (tests, lint, code review heuristics), and posts review comments. **iterate on pull request** read comments and address them (implement changes, ask clarifying questions).
 - **Multi-modal input** — Accept text and images (or other modalities) in the task payload; pass through to the agent. Gateway and schema support it; agent harness supports it where available. Primary use case: screenshots of bugs, UI mockups, or design specs attached to issues.
 
 **Builds on Iteration 3b:** Memory is operational; this iteration changes the orchestrator blueprint (tiered validation pipeline, new task type) and broadens the input schema. These are independently testable from memory.