Please address the comments from this code review:
## Overall Comments
- The add/remove command handlers are now very lengthy with repeated PEP 735 branching—extract the core dependency-group logic into dedicated helper methods or classes to simplify and DRY up the code.
- There’s a lot of duplicated test setup for PEP 735 vs legacy behavior; consolidate that into fixtures or helper functions to reduce boilerplate and make the intent clearer.

## Individual Comments

### Comment 1
<location> `tests/console/commands/self/test_add_plugins.py:27` </location>
<code_context>
 def assert_plugin_add_result(
     tester: CommandTester,
     expected: str,
</code_context>

<issue_to_address>
Test assertion helper updated for new dependency group format.

Please add a test case with multiple plugins to verify correct array handling.
</issue_to_address>

Please address the comments from this code review:
## Overall Comments
- Extract the repeated pep_735 parameterization and assertion blocks in tests into shared fixtures or helper functions to reduce boilerplate and improve maintainability.
- Refactor the add/remove command handle() methods to encapsulate PEP 735 vs legacy group manipulation into helper utilities, reducing deep branching and improving readability.
- Unify or parameterize the two factory methods create_pyproject_from_package and create_legacy_pyproject_from_package to avoid duplicating similar pyproject generation logic.

## Individual Comments

### Comment 1
<location> `tests/console/commands/test_add.py:671` </location>
<code_context>
+    ]
+
+
+def test_add_to_group_with_latest_overwrite_existing(
+    app: PoetryTestApplication, tester: CommandTester
+) -> None:
</code_context>

<issue_to_address>
Consider adding a test for adding a dependency with a lower version than the existing one.

Please add a test to confirm that adding a lower version does not unintentionally downgrade the dependency, unless this is the desired behavior.
</issue_to_address>

<suggested_fix>
<<<<<<< SEARCH
def test_add_to_group_with_latest_overwrite_existing(
    app: PoetryTestApplication, tester: CommandTester
) -> None:
=======
def test_add_to_group_with_latest_overwrite_existing(
    app: PoetryTestApplication, tester: CommandTester
) -> None:

def test_add_to_group_with_lower_version_does_not_downgrade(
    app: PoetryTestApplication, tester: CommandTester
) -> None:
    # Setup: Add a dependency with a higher version first
    tester.execute(
        "add cachy@^0.2.0 --group example",
        app=app,
    )
    # Try to add a lower version
    tester.execute(
        "add [email protected] --group example",
        app=app,
    )
    pyproject = app.poetry.file.read()
    pyproject = cast("dict[str, Any]", pyproject)
    # Assert that the dependency is not downgraded
    assert "example" in pyproject["dependency-groups"]
    # The version should still be >=0.2.0,<0.3.0, not downgraded to 0.1.0
    assert any("cachy (>=0.2.0,<0.3.0)" in dep for dep in pyproject["dependency-groups"]["example"])
    assert not any("cachy (==0.1.0)" in dep for dep in pyproject["dependency-groups"]["example"])
>>>>>>> REPLACE

</suggested_fix>

### Comment 2
<location> `tests/console/commands/test_add.py:732` </location>
<code_context>
+    ]
+
+
+def test_add_to_group_uses_existing_legacy_group(
+    app: PoetryTestApplication, tester: CommandTester
+) -> None:
</code_context>

<issue_to_address>
Consider adding a test for conflicting dependency names between legacy and PEP 735 groups.

Please add a test to verify that updates target the correct group when a dependency name appears in both a legacy and a PEP 735 group.
</issue_to_address>

<suggested_fix>
<<<<<<< SEARCH
def test_add_to_group_uses_existing_legacy_group(
    app: PoetryTestApplication, tester: CommandTester
) -> None:
=======
def test_add_to_group_uses_existing_legacy_group(
    app: PoetryTestApplication, tester: CommandTester
) -> None:
    # existing test code...

def test_add_to_group_with_conflicting_dependency_names(
    app: PoetryTestApplication, tester: CommandTester
) -> None:
    """
    Test that updates target the correct group when a dependency name appears in both
    a legacy and a PEP 735 group.
    """
    # Setup: Add 'requests' to both a legacy group and a PEP 735 group
    pyproject = app.poetry.file.read()
    pyproject["dependency-groups"] = {
        "legacy": [
            "requests (>=2.20.0,<3.0.0)",
        ],
        "pep735": [
            "requests (>=2.25.0,<2.26.0)",
        ],
    }
    app.poetry.file.write(pyproject)

    # Add 'requests' to the 'pep735' group with a new constraint
    result = tester.execute(
        ["add", "requests@^2.25.1", "--group", "pep735"],
        app=app,
    )
    assert result == 0

    updated_pyproject = app.poetry.file.read()
    # Only the 'pep735' group should be updated
    assert updated_pyproject["dependency-groups"]["legacy"] == [
        "requests (>=2.20.0,<3.0.0)",
    ]
    assert updated_pyproject["dependency-groups"]["pep735"] == [
        "requests (^2.25.1)",
    ]
>>>>>>> REPLACE

</suggested_fix>

### Comment 3
<location> `tests/console/commands/test_add.py:1332` </location>
<code_context>


-def test_add_to_dev_section(app: PoetryTestApplication, tester: CommandTester) -> None:
+def test_add_to_dev_group(app: PoetryTestApplication, tester: CommandTester) -> None:
     tester.execute("cachy --dev")

</code_context>

<issue_to_address>
Consider adding a test for adding to a custom group with special characters in the name.

Test group names containing dots, dashes, or reserved TOML characters to verify proper escaping in pyproject.toml.
</issue_to_address>

### Comment 4
<location> `tests/console/commands/test_remove.py:210` </location>
<code_context>
+    assert expected_poetry_string in string_content
+
+
[email protected]("pep_735", [True, False])
 def test_remove_without_specific_group_removes_from_all_groups(
+    pep_735: bool,
     tester: CommandTester,
</code_context>

<issue_to_address>
Consider adding a test for removing a dependency that does not exist in any group.

This will verify that the CLI handles non-existent dependencies gracefully and prevents unintended modifications to pyproject.toml.
</issue_to_address>

<suggested_fix>
<<<<<<< SEARCH
    assert expected_pep735_string in string_content
    assert expected_poetry_string in string_content
=======
    assert expected_pep735_string in string_content
    assert expected_poetry_string in string_content


@pytest.mark.parametrize("pep_735", [True, False])
def test_remove_nonexistent_dependency_does_not_modify_pyproject(
    pep_735: bool,
    tester: CommandTester,
    app: PoetryTestApplication,
    repo: TestRepository,
    installed: Repository,
) -> None:
    # Setup: pyproject.toml with some dependencies
    repo.add_package(Package("foo", "2.0.0"))
    repo.add_package(Package("bar", "1.0.0"))

    pyproject_before = app.poetry.file.read()
    pyproject_before_str = app.poetry.file.as_string()

    # Try to remove a dependency that does not exist
    result = tester.execute(["remove", "nonexistent-package"])

    # Assert: CLI should report not found
    assert "nonexistent-package" in result.stdout.lower()
    assert "not found" in result.stdout.lower() or "does not exist" in result.stdout.lower()

    # Assert: pyproject.toml is unchanged
    pyproject_after_str = app.poetry.file.as_string()
    assert pyproject_before_str == pyproject_after_str
>>>>>>> REPLACE

</suggested_fix>

### Comment 5
<location> `tests/console/commands/self/utils.py:11` </location>
<code_context>


-def get_self_command_dependencies(locked: bool = True) -> TOMLTable:
+def get_self_command_dependencies(locked: bool = True) -> Array | None:
     from poetry.console.commands.self.self_command import SelfCommand
     from poetry.locations import CONFIG_DIR
</code_context>

<issue_to_address>
Consider adding a test for the case where no dependency-groups are present in the system pyproject.

This ensures the function correctly returns None without errors when dependency-groups are absent.
</issue_to_address>

### Comment 6
<location> `tests/test_factory.py:167` </location>
<code_context>
     poetry = Factory().create_poetry(fixture_dir(project))
     package = poetry.package

-    pyproject: dict[str, Any] = Factory.create_pyproject_from_package(package)
+    pyproject: dict[str, Any] = Factory.create_legacy_pyproject_from_package(package)

     result = pyproject["tool"]["poetry"]
</code_context>

<issue_to_address>
Consider adding a test for the new PEP 735 pyproject generation method.

Only the legacy method is currently tested. Please add a test for the PEP 735-compliant pyproject generation to ensure both formats are validated and to prevent future regressions.

Suggested implementation:

```python
    poetry = Factory().create_poetry(fixture_dir(project))
    package = poetry.package

    # Test legacy pyproject generation
    pyproject_legacy: dict[str, Any] = Factory.create_legacy_pyproject_from_package(package)
    result_legacy = pyproject_legacy["tool"]["poetry"]
    expected = poetry.pyproject.poetry_config
    assert result_legacy == expected

    # Test PEP 735-compliant pyproject generation
    pyproject_pep735: dict[str, Any] = Factory.create_pyproject_from_package(package)
    # Adjust the assertion below as needed to match the expected structure for PEP 735
    result_pep735 = pyproject_pep735["project"]
    # You may need to define the expected PEP 735 structure if it differs from legacy
    # For now, we check that the project name matches
    assert result_pep735["name"] == expected["name"]

```

If the expected structure for PEP 735 differs significantly from the legacy format, you should define a separate `expected_pep735` variable with the correct expected data for the PEP 735 format and adjust the assertion accordingly.
</issue_to_address>