# v8 feedback — substrate friction hit while building this project

> Friction caused by the *server framework, standards library, or gateway* —
> not bugs in this project's own code (those go in `handoff.md`).
> Compiled into the evolution plan or the ops queue.

## 2026-08-25 — gateway assumes ONE container per project

**What happened.** This project is one codebase deployed as three instances
(three sites). Its `docker-compose.yml` therefore defines six services
(3 web + 3 db). The gateway models a project as a single container named
`<project>-app`, so:

- `srv-gw security-audit` reports the five non-matching containers as
  **"Orphaned container running"** — a false positive. They are declared in the
  project's own compose file and started by `srv-gw deploy`.
- `srv-gw status/restart/logs --project X` only ever addresses `<project>-app`;
  there is no way to target a sibling service. `docker` directly is the only
  route, which a *developer* (non-owner) could not do at all.
- The port registry allocates exactly one `PORT` per project. The extra two
  instances had to bind hardcoded ports (3151/3152) that the registry does not
  know about, so a future allocation could collide with them.

**Cost.** ~20 minutes of working around it, plus recurring audit noise that
trains the reader to ignore warnings — the real risk.

**Candidate fix.** Let a project declare additional services/ports it owns
(e.g. an optional `services:`/`ports:` list in `.project.json`) so the audit's
orphan check and the port registry both account for them, and so
`status/restart/logs` can take an optional `--service`. Multi-instance and
app+sidecar layouts are both common enough to be first-class.

## 2026-08-25 — `remove-dns` deletes the Cloudflare record to change a port

**What happened.** Repointing an existing domain from one project's port to
another required `remove-dns --domain X` (which deletes the DNS record, the
Caddy config, AND the Cloudflare entry) followed by
`add-dns-record --domain X --port N`. There is no "repoint" that changes only
the Caddy upstream. Deleting and recreating a live DNS record to change a
reverse-proxy port is a wider blast radius than the change needs, and on a
production domain it would risk a propagation gap.

Also: `add-dns` / `remove-dns` / `add-dns-record` reject `--help` ("Unknown
option") and dump the full command list instead, so per-command usage has to be
found by grepping the global help. `remove-dns` takes only `--domain` (passing
`--project` silently prints help rather than erroring).

**Candidate fix.** A `srv-gw repoint-dns --domain X --port N` (or
`--project Y`) that rewrites only the Caddy upstream and the registry entry,
leaving Cloudflare untouched. And per-command `--help`.