Daily harness signal · September 14, 2026

A preview link
is not a running app.

One evergreen lesson · Amp Orbs · Operational guidance, not an executed canary

Remote previews need one service owner and a separate readiness check. Amp’s current guidance replaces detached portal servers with supervised services; a printed URL still does not prove the application works.

Evergreen · launch August 6, 2026 · current docs checked September 14

Let the supervisor own the preview

Use when

An Amp orb starts its preview through setup hooks, tmux, or detached shells, or an agent accepts a portal link as completion. Thorsten Ball’s July field report used tmux; the current portal reference explicitly says not to use it for portal servers.

Action

In an already authorized disposable preview environment, declare the server in .amp/services.yaml. Adapt this example to the repository’s actual command and implement /healthz so it checks required application dependencies: 

services:
  web:
    command: pnpm dev -- --host 0.0.0.0 --port "$PORT"
    health: /healthz
    portal: true

Keep .agents/setup for preparation, not server startup; do not restart declared services from .agents/resume. From the repository root, run amp orb services ensure --json. Use the exact printed URL and runtime PUBLIC_URL, not a constructed hostname. Keep the existing application authentication; this migration does not require magic-login routes or public sharing.

Acceptance check

In an owned fixture, run ensure twice: one healthy service must be reused, not duplicated. Check normal sleep/wake recovery. Then make /healthz return 503 while the port remains open. Readiness and review acceptance must fail, even if a URL appears. Inspect amp orb service status web and amp orb service logs web. Restore real readiness, open the exact portal URL, and exercise the requested feature. Retain status, logs, and browser evidence; a listening socket alone cannot pass.

Evidence

Amp’s official reference publishes the YAML, commands, service lifecycle, and failure semantics. It explicitly warns that portal metadata can exist after failed readiness. The dated August launch confirms the declarative service surface; Ball’s earlier post provides inspectable historical configuration, not current supervisor instructions.

Caveat

No runtime canary was executed here. The current documentation has no revision date, so this is not a September release claim. Amp accepts both 2xx and 3xx health responses: a login redirect can therefore look ready. Inside an orb, PUBLIC_URL bypasses portal sign-in, not application authentication. Test external viewer access separately; an internal fetch does not establish that a reviewer can sign in.

Compact source notes

  1. Amp: Portals reference — undated current documentation, retrieved September 14, 2026. Exact service manifest, ensure/status/log commands, health semantics, lifecycle warnings, and internal-versus-external authentication distinction. No supervisor source or test suite inspected.
  2. Amp: Portals into Orbs — August 6, 2026. Dated launch and declarative service interface; not evidence that every current documentation detail shipped that day.
  3. Thorsten Ball: Putting an Agent in an Orb — July 2, 2026. Exact earlier tmux guidance and ensure-dev-server contract. Current portal-specific lifecycle guidance takes precedence over this historical example.
  4. Anchor lens: published commands, manifest, readiness criteria, and documented failure. Unity lens: one lifecycle owner plus an independent application outcome check; proposed general invariant, not cross-harness equivalence. confidence_confirmed for inspected documentation; confidence_likely for the untested deployment procedure. A failed application accepted from its URL, or duplicate servers after ensure, falsifies the proposed control.