engine/tests/project_init_e2e.rs (1)

25-35: 🎯 Functional Correctness | 🔵 Trivial | ⚡ Quick win

Also lock the Dockerfile 9464 removal in these e2e checks.

This helper covers the new compose-volume contract, but the PR also changes the generated Dockerfile to drop 9464. Neither e2e path asserts that, so the stale expose can come back without failing these tests.

Suggested shape

 fn assert_compose_mounts_engine_data_volume(project: &Path) {
     let compose = std::fs::read_to_string(project.join("docker-compose.yml")).unwrap();
     assert!(
         compose.contains("- iii_data:/app/data"),
         "docker-compose.yml should mount writable engine data, got:\n{compose}"
     );
     assert!(
         compose.contains("volumes:\n  iii_data:"),
         "docker-compose.yml should declare the iii_data named volume, got:\n{compose}"
     );
 }
+
+fn assert_dockerfile_drops_9464(project: &Path) {
+    let dockerfile = std::fs::read_to_string(project.join("Dockerfile")).unwrap();
+    assert!(
+        !dockerfile.contains("9464"),
+        "Dockerfile should not expose 9464, got:\n{dockerfile}"
+    );
+}

     assert_compose_mounts_engine_data_volume(dir.path());
+    assert_dockerfile_drops_9464(dir.path());

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@engine/tests/project_init_e2e.rs` around lines 25 - 35, The e2e coverage in
assert_compose_mounts_engine_data_volume only checks the compose volume contract
and does not guard the generated Dockerfile change. Update the project init e2e
assertions to also verify the Dockerfile no longer exposes 9464, using the
existing project initialization test helpers and the generated Dockerfile
content so the stale port cannot regress unnoticed.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes