Data

{
  "owner": "mirendev",
  "repo": "runtime",
  "number": 1114,
  "verdict": "ready",
  "event": "comment",
  "summary": "This is a draft, so I'm judging whether it's ready to graduate to human review — and I think it is, with one observation I'd want the author to double-check before merge.\n\n**What the change does**\n\nThe PR propagates a platform capability throughout the docs: Miren can now run a container image directly (Bring Your Own Image / BYOI) without a Dockerfile or Procfile. The runtime synthesizes a `web` service from the image's `ENTRYPOINT`/`CMD`, and infers the web port from the image's `EXPOSE` metadata when there's exactly one TCP port. The changes span ~57 files: CLI help strings, conceptual docs, all language guides, and two recipes.\n\n**What I checked**\n\n- The CLI help strings in `commands.go` are consistent with the doc changes — the vocabulary shift from \"rebuilt\" to \"resolved or built\" is correct and internally coherent.\n- The deployment priority list in `guides/index.md` (line 143) now correctly inserts `services.web.image` at rank 3, between `Dockerfile.miren` and auto-detection — that matches the description in `deployment.md` and `services.md`.\n- Every Dockerfile guide that previously required a `Procfile` now carries a `CMD` instruction in the Dockerfile itself. I spot-checked a half-dozen (C, C++, Clojure, Elixir, PHP, static) and the `CMD` entries look correct for each stack.\n- The `CMD [\"app\"]` pattern used in C, C++, Nim, Zig, etc. works because the binary is copied to `/usr/local/bin/app`, which is on `PATH` in Debian images — this is a pre-existing pattern, unchanged and correct.\n- For PHP and static/Caddy guides, a minimal `[services.web]\\nport = 8080` block is still included to select the right port from a multi-port base image (FrankenPHP and Caddy each expose several ports). That's exactly the guidance the updated docs give elsewhere — good consistency.\n\n**One thing to verify before merge**\n\nThe `openhands-agent-server` recipe makes a specific claim I can't verify from the diff alone: it removes the three `OH_CONVERSATIONS_PATH` / `OH_WORKSPACE_PATH` / `OH_BASH_EVENTS_DIR` env-var overrides and the note about `PermissionError: 'workspace'`, asserting that the upstream image (`ghcr.io/openhands/agent-server:1.44.1-python`) already defaults those paths under `/workspace`. If the upstream image's defaults still point to a relative path from the working directory (as the old version warned), users will see the same `PermissionError` with no guidance to fix it. The author should confirm that the pinned image version actually uses `/workspace` as its default base for state paths before this lands.\n\nEverything else reads cleanly and consistently. The structural rework is well-executed: the priority ordering is correct across all references, the new \"Already have a runnable image?\" section in `guides/index.md` is well-placed, and the removal of the now-false \"Deploying without a service fails\" notes is unambiguously correct given the new behavior.",
  "comments": [
    {
      "path": "docs/docs/recipes/openhands-agent-server.md",
      "line": 110,
      "side": "RIGHT",
      "body": "The old recipe included explicit `OH_CONVERSATIONS_PATH`, `OH_WORKSPACE_PATH`, and `OH_BASH_EVENTS_DIR` overrides along with a warning about `PermissionError: 'workspace'`. This version removes them and asserts that the server's default state paths already live under `/workspace`.\n\nPlease confirm that `ghcr.io/openhands/agent-server:1.44.1-python` actually defaults its conversations, project, and bash-event paths to subdirectories of `/workspace` (not to relative paths from the working directory). If those defaults haven't changed in the upstream image, users will hit the same `PermissionError` with no recovery path."
    }
  ],
  "posted_to_pr": true,
  "draft": true
}