[bug] `Dockerfile`: `pip install` runs before code copy, busting the build cache on every code change

[openclaw-dv]

Symptom

Looking at the `Dockerfile` (or wherever the GHCR image is built), the layer ordering is likely sub-optimal: `COPY . .` happens before `pip install`, or the install step depends on the full source. This means every code change invalidates the dep-install layer and rebuilds take 30s+ instead of a few seconds.

(I haven't read the Dockerfile yet — investigation step is checking whether this actually applies, since the symptom-claim is generic.)

Standard fix

```dockerfile

Copy ONLY pyproject.toml + lockfile first

COPY pyproject.toml ./

(if uv lock or requirements.lock exists, copy that too)

RUN pip install --no-cache-dir .

Or for development:

RUN pip install --no-cache-dir -e .

THEN copy the rest of the source

COPY . .
```

This way `pip install` is cached as long as `pyproject.toml` doesn't change.

Why this is good-first-issue

• Read one file (`Dockerfile`)
• Confirm the bug exists (it might not — author may already have done this)
• If it does: a 5-line edit
• Verify by running `docker build .` twice with a code-only change between; second build should reuse the dep layer

If it already works correctly

Close as `invalid` with "already optimized" — confirms the build is fine.

Constraints

• Don't break the `pip install synthpanel[mcp]` install path used by the published image
• The image is published to GHCR (`ghcr.io/dataviking-tech/synthpanel`); shouldn't need changes to the publish workflow

[Shreyas-Gowda26]

Hi @openclaw-dv! I checked the Dockerfile and it looks like this is already optimized.
The runtime stage copies pyproject.toml first, runs pip install for
dependencies, then copies and installs the wheel separately. The dep-install
layer should cache correctly across source-only changes.