Now I have all the context I need. Let me produce the section content.

# Section 4: CHECK_ERRORS -- False Positive Filtering (Confidence Annotation)

## Overview

Godot sometimes reports compilation errors at line 0, which are almost always false positives caused by Godot's internal cache/reload mechanism. These appear identical to real errors, confusing AI agents and developers. This section adds post-processing to the `check_errors` Python-side wrapper that annotates each error with a `confidence` field (`"low"` or `"high"`) based on whether the line number is 0 or missing, and adds a top-level `note` when any low-confidence errors are present.

No GDScript-side changes are required. The `line: 0` value is already set by the Godot bridge. All annotation happens in the Python `check_errors` function.

## Files to Modify

- **`/Users/salvatorefarruggio/Desktop/godotiq/src/godotiq/tools/bridge/check_errors.py`** -- Add confidence annotation logic after receiving bridge response
- **`/Users/salvatorefarruggio/Desktop/godotiq/tests/test_tools/test_check_errors.py`** -- Add new test class for confidence annotation behavior

## Dependencies

None. This section is fully independent and can be implemented in parallel with all other sections.

## Tests First

Add a new test class to the existing test file at `/Users/salvatorefarruggio/Desktop/godotiq/tests/test_tools/test_check_errors.py`. The tests use the same mock bridge pattern already established in that file.

```python
class TestCheckErrorsConfidenceAnnotation:
    """Tests for false-positive confidence annotation on check_errors results."""

    async def test_line_zero_gets_low_confidence(self) -> None:
        """Error at line 0 is annotated with confidence 'low'."""
        # Mock bridge returns an error with line == 0
        # After check_errors processes it, that error dict should have "confidence": "low"

    async def test_line_nonzero_gets_high_confidence(self) -> None:
        """Error at line 15 is annotated with confidence 'high'."""
        # Mock bridge returns an error with line == 15
        # After check_errors processes it, that error dict should have "confidence": "high"

    async def test_missing_line_key_gets_low_confidence(self) -> None:
        """Error dict with no 'line' key at all is annotated with confidence 'low'."""
        # Mock bridge returns an error dict like {"file": "res://a.gd", "error": "msg"}
        # (no "line" key) -- should get "confidence": "low"

    async def test_mixed_errors_adds_note(self) -> None:
        """When any error has line==0, top-level 'note' is present."""
        # Mock bridge returns two errors: one at line 0, one at line 15
        # Result should contain a top-level "note" key with text about false positives
        # The line-0 error should have confidence "low", the line-15 error "high"

    async def test_all_high_confidence_no_note(self) -> None:
        """When all errors have line > 0, no top-level 'note' is added."""
        # Mock bridge returns errors all at line > 0
        # Result should NOT contain a "note" key

    async def test_empty_errors_no_crash_no_note(self) -> None:
        """Empty errors array produces no crash and no note."""
        # Mock bridge returns {"errors": [], "total": 0, ...}
        # Result should have no "note" key and no crash
```

### Test Pattern

Each test should follow the existing pattern in the file:

1. Create an `AsyncMock` for the bridge
2. Set `mock_bridge.request.return_value` to a response dict with an `errors` array containing error dicts with various `line` values (or missing `line`)
3. Patch `godotiq.tools.bridge.check_errors.get_bridge` to return the mock
4. Call `check_errors()` (the raw wrapper, not the MCP-level `godotiq_check_errors`)
5. Assert the expected `confidence` values on each error in the returned `errors` array
6. Assert the presence or absence of a top-level `"note"` key

Example mock response structure for a bridge response with mixed errors:
```python
{
    "errors": [
        {"file": "res://player.gd", "line": 0, "error": "Identifier not found"},
        {"file": "res://enemy.gd", "line": 15, "error": "Type mismatch"},
    ],
    "total": 2,
    "scripts_checked": 10,
    "scope": "scene",
}
```

After processing, the first error should have `"confidence": "low"` added, the second should have `"confidence": "high"`, and a top-level `"note"` should be present.

## Implementation Details

### Changes to `check_errors.py`

The current `check_errors` function at `/Users/salvatorefarruggio/Desktop/godotiq/src/godotiq/tools/bridge/check_errors.py` is a straightforward pass-through:

```python
async def check_errors(scope: str = "scene") -> dict:
    bridge = await get_bridge()
    result = await bridge.request("check_errors", params={"scope": scope})
    return result
```

After receiving the bridge response, add a post-processing step before returning. The logic is:

1. Get the `errors` list from the result dict. If the key is missing or the value is not a list, skip annotation entirely (defensive).
2. Track whether any error has low confidence.
3. Iterate over each error dict in the list:
   - Read the `line` value from the error dict.
   - If `line` is `0`, or the `line` key is missing entirely, set `error["confidence"] = "low"` and mark that a low-confidence error was found.
   - Otherwise (line is a positive integer), set `error["confidence"] = "high"`.
4. After the loop: if any error had low confidence, add a top-level key to the result: `result["note"] = "line 0 errors are often false positives — try reloading the scene"`.
5. Return the annotated result.

### Key Design Decisions

- **Annotation happens on the raw wrapper (`check_errors`), not on the MCP wrapper (`godotiq_check_errors`)**: This ensures that any code calling `check_errors` directly (such as the `run` tool's pre-check) also benefits from the annotation. The MCP wrapper at `/Users/salvatorefarruggio/Desktop/godotiq/src/godotiq/tools/bridge/__init__.py` (line 797) calls `_check_errors(scope=scope)` which is this function, so annotations flow through automatically.

- **Mutating the result in-place is acceptable**: The bridge response dict is a fresh dict from JSON deserialization. There is no concern about shared references.

- **The `note` value is a fixed string**: `"line 0 errors are often false positives — try reloading the scene"`. This provides actionable guidance to the AI agent.

- **No GDScript changes**: The Godot side already reports `line: 0` for these false positives. The fix is entirely Python-side annotation.

- **Backward compatibility**: The annotation only adds new keys (`confidence` on each error, `note` on the result). No existing keys are modified or removed, so all existing tests and consumers continue to work.

### Edge Cases to Handle

- `result` has no `"errors"` key: Skip annotation, return as-is.
- `result["errors"]` is not a list: Skip annotation, return as-is.
- An error dict has `"line": 0` (integer zero): confidence is `"low"`.
- An error dict has no `"line"` key at all: confidence is `"low"`.
- An error dict has `"line": None`: Treat as missing, confidence is `"low"`.
- Empty `errors` list: No iteration occurs, no note added, no crash.

## Implementation Results

**Status:** Complete
**Files modified:**
- `src/godotiq/tools/bridge/check_errors.py` — added `_annotate_confidence()` helper
- `tests/test_tools/test_check_errors.py` — added `TestCheckErrorsConfidenceAnnotation` (6 tests)

**Deviations from plan:**
- Used `if not isinstance(line, int) or line <= 0` instead of truthiness-based `if not line` (code review auto-fix for robustness with negative line numbers and non-int types)

**Test results:** 23/23 tests pass in test_check_errors.py