Please address the comments from this code review:

## Overall Comments
- The change in `ActionHelper::wait_freezes` from defaulting an empty `box` to full-screen, to now failing when `correct_roi(box, pre_image)` returns null, alters existing behavior; consider preserving the previous "empty box means full-screen" semantics by expanding an empty `box` before correction.
- By removing the ROI correction in `TemplateComparator::analyze` and assuming `roi_` is always valid for both images, you risk out-of-bounds access if capture dimensions change between `pre_image` and `cur_image`; consider reintroducing per-image bounds checking or documenting and enforcing that all callers must pass pre-corrected ROIs valid for both images.

## Individual Comments

### Comment 1
<location path="source/MaaFramework/Task/Component/ActionHelper.cpp" line_range="104-106" />
<code_context>
         break;

     case Target::Type::PreTask: {
-        auto& cache = tasker_->runtime_cache();
-        std::string name = std::get<std::string>(target.param);
-        MaaNodeId node_id = cache.get_latest_node(name).value_or(MaaInvalidId);
-        NodeDetail node_detail = cache.get_node_detail(node_id).value_or(NodeDetail { });
-        RecoResult reco_result = cache.get_reco_result(node_detail.reco_id).value_or(RecoResult { });
-        raw = reco_result.box.value_or(cv::Rect { });
+        const auto& name = std::get<std::string>(target.param);
+        raw = get_rect_from_node(name);
         LogDebug << "pre task" << VAR(name) << VAR(raw);
     } break;
</code_context>
<issue_to_address>
**issue (bug_risk):** Handle empty rects from get_rect_from_node before applying scaling/offsets in get_target_rect.

If `get_rect_from_node` returns an empty rect (`{0,0,0,0}`), the current math still applies `target.offset`, so `get_target_rect` can produce a non-empty rect from an invalid source. Callers that rely on `roi.empty()` to detect invalid targets (e.g., `Actuator::click`, `swipe`, `wait_freezes`) will then incorrectly act on this bogus rect instead of early-returning.

To preserve the contract that a non-empty rect from `get_target_rect` implies a valid source region, short-circuit when `raw` is empty, e.g.:

```cpp
case Target::Type::PreTask: {
    const auto& name = std::get<std::string>(target.param);
    raw = get_rect_from_node(name);
    if (raw.empty()) {
        LogWarn << "pre task has no rect" << VAR(name);
        return {};
    }
    LogDebug << "pre task" << VAR(name) << VAR(raw);
} break;
```

and similarly for the `Anchor` branch.
</issue_to_address>

### Comment 2
<location path="test/python/pipeline_test.py" line_range="967-976" />
<code_context>
+    def _test_roi_target_anchor(self, context: Context):
</code_context>
<issue_to_address>
**suggestion (testing):** Anchor tests only verify parsing, not that ROI/targets using anchors actually work at runtime

Please extend this test (or add a new one) so it also exercises the runtime anchor resolution path:

- Bind anchors to nodes in the `Context` using the real API and run a small pipeline that uses `[Anchor]...` in ROI/targets so recognitions/actions actually execute.
- Assert that the ROIs/points used by actions (click/scroll/swipe/wait_freezes, etc.) come from the anchor-resolved node boxes rather than hardcoded coordinates.

That will validate the end-to-end behavior of anchor-based ROI/target resolution, not just the config parsing/dumping.

Suggested implementation:

```python
    def _test_roi_target_anchor(self, context: Context):
        """
        End-to-end test that verifies ROI/target anchors are actually resolved at runtime
        and that actions receive ROIs/points derived from the bound anchor node's box.
        """
        print("  Testing roi/target anchor reference...")

        # Work on a cloned context so we don't affect other tests
        new_ctx = context.clone()

        #
        # 1. Create a deterministic node box and bind it to an anchor.
        #
        # These numbers are arbitrary but should be obviously non-zero and non-symmetric
        # so it's easy to spot if anything degenerates to (0, 0, 0, 0) or similar.
        anchor_box = (13, 27, 111, 59)  # (x, y, w, h)

        # Create a node in the context that represents this box. The exact API may differ
        # in your code base; this assumes a minimal "add_node" + "bind_anchor" style API.
        anchor_node = new_ctx.add_node(
            name="AnchorNodeForRoiTargetTest",
            box=anchor_box,
        )
        new_ctx.bind_anchor("MyRoiAnchor", anchor_node)

        #
        # 2. Patch the click (or generic) action to record the ROI and point it receives.
        #
        recorded_rois = []
        recorded_points = []

        # Depending on your implementation, this may be something like:
        #   new_ctx.actions["Click"]
        #   new_ctx.action_registry["Click"]
        # or similar. Adjust the lookup if needed.
        original_click_cls = new_ctx.actions["Click"]

        class RecordingClick(original_click_cls):  # type: ignore[misc]
            def __call__(self, *args, **kwargs):
                # Different action implementations pass ROI/point differently.
                # Common patterns:
                #   __call__(self, roi, point, *args, **kwargs)
                #   __call__(self, point, *args, **kwargs)  with self.roi
                roi = getattr(self, "roi", None)
                point = getattr(self, "point", None)

                # Prefer explicit kwargs/args if present.
                if "roi" in kwargs:
                    roi = kwargs["roi"]
                if "point" in kwargs:
                    point = kwargs["point"]
                elif "pos" in kwargs:
                    # Some APIs use "pos" instead of "point".
                    point = kwargs["pos"]

                # Try positional fallbacks if we still don't have anything.
                if roi is None and args:
                    roi = args[0]
                if point is None and len(args) > 1:
                    point = args[1]

                recorded_rois.append(roi)
                recorded_points.append(point)
                return super().__call__(*args, **kwargs)

        new_ctx.actions["Click"] = RecordingClick

        #
        # 3. Define a small pipeline that uses the anchor in both ROI and target.
        #
        new_ctx.override_pipeline(
            {
                "RoiAnchorTest": {
                    "recognition": "TemplateMatch",
                    "template": ["test.png"],
                    # ROI is resolved from the anchor
                    "roi": "[Anchor]MyRoiAnchor",
                    # Target also uses the anchor so the click point should come from
                    # the same box. The exact schema may differ ("target", "pos", etc.).
                    "actions": [
                        {
                            "type": "Click",
                            "target": "[Anchor]MyRoiAnchor",
                        }
                    ],
                }
            }
        )

        #
        # 4. Run the pipeline so we exercise the runtime anchor resolution path.
        #
        # Depending on your framework, this could be:
        #   new_ctx.run("RoiAnchorTest")
        #   new_ctx.run_pipeline("RoiAnchorTest")
        # or something similar.
        new_ctx.run_pipeline("RoiAnchorTest")

        #
        # 5. Assert that ROI/point were derived from the anchor-resolved node box.
        #
        assert recorded_rois, "Anchor-based pipeline should have produced at least one action ROI"
        assert recorded_points, "Anchor-based pipeline should have produced at least one action point"

        # If ROI is represented as a box tuple, we can compare directly.
        roi = recorded_rois[0]
        if isinstance(roi, tuple) and len(roi) == 4:
            assert (
                roi == anchor_box
            ), f"Action ROI {roi} should match anchor node box {anchor_box}"
        else:
            # If ROI is a richer object, fall back to its box/rect/region attribute.
            roi_box = None
            for attr in ("box", "rect", "region", "bbox"):
                if hasattr(roi, attr):
                    roi_box = getattr(roi, attr)
                    break

            assert (
                roi_box is not None
            ), "Unable to determine ROI box for anchor ROI; please expose an attribute like 'box' or 'rect'"

            assert (
                tuple(roi_box) == anchor_box
            ), f"Action ROI box {roi_box} should match anchor node box {anchor_box}"

        point = recorded_points[0]
        # Normalize point if it's a richer object
        if not isinstance(point, tuple):
            for attr in ("point", "pos", "center"):
                if hasattr(point, attr):
                    point = getattr(point, attr)
                    break

        assert (
            isinstance(point, tuple) and len(point) == 2
        ), f"Expected point to be a 2-tuple, got {point!r}"

        px, py = point
        ax, ay, aw, ah = anchor_box
        assert ax <= px <= ax + aw and ay <= py <= ay + ah, (
            f"Click point {point} should lie inside anchor box {anchor_box}, "
            "indicating it was derived from the anchor-resolved node ROI"
        )

        print("    PASS: roi/target anchor runtime resolution")

```

The edited code assumes several concrete APIs that you may need to align with your existing code:

1. Anchor binding:
   - Adjust `new_ctx.add_node(...)` and `new_ctx.bind_anchor("MyRoiAnchor", anchor_node)` to match however you currently create nodes and bind anchors in `Context`.
   - If you use a different shape for boxes (e.g., `Box(x, y, w, h)` object), adapt `anchor_box` and the comparison logic accordingly.

2. Action registration:
   - Update `new_ctx.actions["Click"]` to the correct registry lookup in your context (e.g. `new_ctx.action_registry["Click"]`, `new_ctx._actions["Click"]`, etc.).
   - Ensure the base click action is class-like and can be subclassed; if it is a function, wrap it in a callable object instead of subclassing.

3. Pipeline execution:
   - Replace `new_ctx.run_pipeline("RoiAnchorTest")` with the correct method your framework uses to execute a named pipeline (e.g. `new_ctx.run("RoiAnchorTest")`).

4. Action call signature:
   - The `RecordingClick.__call__` method tries to be generic in how it extracts `roi` and `point`. If your click action uses a specific signature (e.g. `__call__(self, point)` with `self.roi` already resolved), simplify this method to match your actual signature and capture exactly the runtime ROI/point values.

5. ROI/point representation:
   - If your ROI or point types are custom classes, update the attribute names in the normalization logic (e.g., if you use `roi.rect.to_tuple()` or `point.x`, `point.y`).
   - If you have helper functions (e.g. `roi_to_box(roi)`), prefer using those instead of manual attribute inspection, to stay consistent with the rest of the codebase.

Integrate these adjustments so the test uses your real APIs while keeping the structure of this end-to-end anchor resolution check intact.
</issue_to_address>

### Comment 3
<location path="docs/en_us/3.1-PipelineProtocol.md" line_range="459" />
<code_context>
     Region of Interest (ROI), defining the image recognition boundary; related image processing is performed only within this area. Optional, default [0, 0, 0, 0], i.e. full screen.
   - *array<int, 4>*: Recognition area coordinates [x, y, w, h]. Supports negative values **💡 v5.6**: negative x/y means calculating from right/bottom edge; w/h of 0 means extending to edge, negative means taking absolute value and treating (x, y) as bottom-right corner.
-  - *string*: Fill in the node name, and identify within the target range identified by a previously executed node.
+  - *string*: Fill in the node name, and identify within the target range identified by a previously executed node. Also supports `[Anchor]AnchorName` format to reference the node corresponding to an anchor **💡 v5.9**. If the referenced pre-task or anchor has no recognition result, the recognition is treated as failed.  

 - `roi_offset`: *array<int, 4>*  
</code_context>
<issue_to_address>
**nitpick (typo):** Consider rephrasing to avoid the repeated use of "identify" in this sentence.

The phrase "identify within the target range identified by a previously executed node" is repetitive. Consider alternative wording (e.g., using a different verb the second time) to improve readability.

```suggestion
  - *string*: Fill in the node name to perform recognition within the target range produced by a previously executed node. Also supports `[Anchor]AnchorName` format to reference the node corresponding to an anchor **💡 v5.9**. If the referenced pre-task or anchor has no recognition result, the recognition is treated as failed.  
```
</issue_to_address>

### Comment 4
<location path="docs/en_us/3.1-PipelineProtocol.md" line_range="1082" />
<code_context>
     Position of the scroll target. The mouse will first move to this position before scrolling. Optional, default is `true`.  
   - *true*: Target is the position just recognized in this node (i.e., itself).  
-  - *string*: Fill in a node name; the target is the position recognized by a previously executed node.  
+  - *string*: Fill in a node name; the target is the position recognized by a previously executed node. Also supports `[Anchor]AnchorName` format to reference the node corresponding to an anchor **💡 v5.9**.  
   - *array<int, 2>*: Fixed coordinate point `[x, y]`.  
   - *array<int, 4>*: Fixed coordinate area `[x, y, w, h]`, a random point will be selected within the rectangle (with higher probability towards the center and lower probability at the edges). Use [0, 0, 0, 0] for full screen.
</code_context>
<issue_to_address>
**question:** Clarify behavior when the referenced pre-task or anchor has no recognition result for scroll targets.

The ROI and click target docs explicitly state what happens when the referenced node has no recognition result (treating it as a failed recognition/action). For scroll, could you document the equivalent behavior (or call out how it differs) to keep behavior and expectations consistent?
</issue_to_address>