yamine 0.21.2 → 0.22.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 618e529eeea12aa43397e084455136a4062bd55a546e904a1cb4170e3fc1466f
-  data.tar.gz: aa598da83330345ca84a60b168539262aa516df7440d6d91611b5cc853c584ec
+  metadata.gz: 1f20b021d3a702ab4aef776ac24e10683b12c1b4ba58b7ad4e5b11b91316eb78
+  data.tar.gz: 4ff8a2e59f075f38aa81d084d9aea45041346790aefd687ef2fc08669bc34737
 SHA512:
-  metadata.gz: 848bb6e6cced84dc132e38dc2ce4828c3514b4fca2c4596e796e9e938b1b2f23d164aadea56e14aed9e8c13d7f732723ede5b377f443db068f74bfd7a9e88410
-  data.tar.gz: 453dd9432df8527eace777b7894abf8540b60f103243ce4917593cd021c38506a0aa76614ca0eb926caea5ebfca6f25177729148e5342f22e1b571f7571d104a
+  metadata.gz: 2e2542be9656d87375b9ab29ac2862f33b2be289c7932aa99f2f29abf3b2a47f40e24623f2ab8b902021e6b42fe4ed48ebe7dfc4a86a3184ddf4f859cb359d40
+  data.tar.gz: 85d76ec111ee796d23b89879d414bf5a248504f58983a0064c3d43ffaa88d532a0f3b5d6542f21b09d2fba5acb57f20e673fcb5f7d13490108f321adbf1eb896

data/CHANGELOG.md

@@ -2,6 +2,176 @@
 
 ## [Unreleased]
 
+## [0.22.1] - 2026-09-29
+
+### Fixed
+
+- **macOS trusts the local CA now, instead of merely filing it.** A
+  non-elevated `yamine trust` added the certificate without naming any
+  policies, so macOS recorded a trust-store entry with no settings at
+  all: the CA sat in the login keychain trusted for nothing, and every
+  browser answered `ERR_CERT_AUTHORITY_INVALID` on every
+  `https://*.localhost` route. The add now passes `-p ssl -p basic` —
+  the same thing Keychain Access writes for Secure Sockets Layer + X.509
+  Basic — and `yamine trust` re-reads the trust store afterwards rather
+  than believing the exit status, so an add that recorded nothing is a
+  failure that names the exact `security add-trusted-cert` to run
+  instead of a success the browser will contradict.
+- **A CA that is in the keychain but untrusted repairs itself.** The
+  check that decided whether to trust compared fingerprints alone, so
+  once that bare certificate was in a keychain every later boot
+  concluded it was trusted and never touched it again — the check that
+  should have caught the broken state was the one hiding it. It now
+  needs both halves: the certificate in a keychain *and* a trust
+  setting recorded for its fingerprint. A machine left with a
+  policy-less entry therefore self-heals on the next `yamine trust` or
+  proxy boot, and one whose trust store cannot be read is left alone
+  rather than re-adding on every boot.
+- **A proxy running as a normal user trusts the CA too.** Trust used to
+  be attempted only when the proxy was root, so a first run without
+  `sudo` never tried and installed a CA that could not work. Every proxy
+  now ensures trust, elevated or not, and reports a failed attempt
+  rather than swallowing it. `YAMINE_SKIP_CA_TRUST` is the escape
+  hatch for machines whose CA arrives by MDM or a hand-run
+  `security add-trusted-cert`.
+- **`yamine doctor` names a CA the OS does not trust.** The recorded
+  marker says yamine trusted this certificate; it says nothing about
+  whether macOS agreed. `doctor` asks the OS too, so a CA that is
+  installed but untrusted — the state where every route fails TLS —
+  reads as "CA is installed but macOS does not trust it" and points at
+  `yamine trust` instead of passing as healthy.
+## [0.22.0] - 2026-09-29
+
+### Added
+
+- **`yamine start --detach` — boot in the background and get your prompt
+  back.** An agent (or a script) that needs an app running had one
+  option: block, or reach for `nohup` — which leaves a process tree
+  whose owner the first Ctrl-C cannot reach. `--detach` forks the boot:
+  the child takes its own session, records its pid in
+  `~/.yamine/start-<hostname>.pid`, sends its own output to
+  `~/.yamine/start-<hostname>.log`, boots, keeps the tree supervised and
+  outlives the shell that started it. The parent waits for the app to
+  answer, prints the URL, that pid and the log path, and exits 0.
+  The boot happens in the child on purpose: `add_route` records
+  `Process.pid`, and `load_routes` prunes any route whose pid is dead, so
+  a parent that registered the routes and exited would have its own route
+  pruned on the next read and the proxy would 503 an app that is running
+  perfectly well. It is idempotent — a tree already running for the
+  directory (detached, or foreground) is reported, not started again —
+  and a boot that never becomes healthy exits 1 with the log instead of
+  a tree that is not there. `--json` gets the same three facts
+  as a payload. `--no-wait` is ignored with `--detach`: returning before
+  the app answers is the lie this flag exists to stop.
+
+### Fixed
+
+- **`yamine list` and `yamine get --all` report the app, not the CLI
+  that started it.** A route's `pid` is the yamine process that
+  registered it, and it outlives the app it booted, so `alive_state` was
+  asking the wrong process whether the app was alive: every crashed
+  backend read as `running`, in the one command an agent would reach for
+  to find out. Liveness now comes from the sidecar the boot already
+  writes (`backend-<hostname>.pid`, the same file `yamine stop` reads),
+  and the vocabulary says what it knows:
+  `running` (the app's process is there), `backend-gone` (the CLI is
+  still up, the app it booted is not), `owner-gone` (nothing is there
+  and no app pid was recorded), `unknown` (no app pid recorded, and the
+  route's own process is — a route written before sidecars existed, or
+  by a boot that died between registering the route and writing the
+  file: `unknown`, never "down", so no pre-existing route reads as
+  broken after an upgrade), and `reachable` / `unreachable` for a static
+  alias, which names no process and keeps reporting the probe.
+  `list --json` gained `backend_pid` beside `pid` so the state and the
+  process it is about travel together, and the human line prints the
+  backend's pid rather than the owner's.
+- **`yamine restart` works for the apps yamine started.** Supervision
+  required `kind == "socket"`, and `yamine start` registers `kind
+  "tcp"`, so a `yamine start` tree was invisible to the daemon:
+  `yamine restart` touched `tmp/restart.txt`, printed "managed app
+  restarts on next request", and nothing was watching the file. Any
+  route carrying a spec is now watched, so restart.txt and crash
+  detection reach both kinds. Two things that were broken *inside* the
+  socket case went with it: the restart baseline was re-derived while
+  `restart.txt` did not exist, so the *first* `yamine restart` an app
+  ever got was absorbed as the new baseline and did nothing; and the
+  "restarting" latch was never cleared, so a route was supervised for
+  exactly one event in the life of the daemon. The kill now signals the
+  process group when the pid leads one, because a tcp route's sidecar
+  names the `sh -c` shell the boot wrapped the app in.
+- **A child that dies no longer ends `yamine start` with exit 0.**
+  `supervise_tree` exited 0 with the routes already removed and the rest
+  of the tree being killed, so a zero read as "the app came up" to
+  anything scripted — which then blamed the app for the 503 it was
+  about to get. It exits 1, the same code `--wait` already uses for a
+  boot that never became healthy, and the message names the process, its
+  exit status (or the signal that took it down — a reaped child is the
+  only place that answer exists, so the reaper keeps it) and the tail of
+  the app log. `--json` gets the same as
+  `{"ok": false, "error": "child-exited", …}`. `yamine stop`'s
+  0/2/3/4 are untouched: those answer "what did the stop do", and this
+  answers "is the app up".
+- **`yamine restart` no longer promises a reboot it cannot perform.**
+  A managed socket app is rebooted on the next request; a `yamine start`
+  app is stopped and has to be started again, because the daemon cannot
+  rebuild a tcp backend (its port is a free port chosen at boot and the
+  route records no command to re-run). The command and the daemon's own
+  events now say which one you have.
+- **A boot that started nothing no longer reports `ready:` and hangs.**
+  A process whose `cmd` is a compound line is refused with an error and
+  leaves the spawn plan empty; the boot then printed `ready:` and sat in
+  the supervision loop for ever with nothing to watch — a hang that looks
+  exactly like a healthy start. It exits 1 instead, naming the error
+  above it.
+
+### Changed
+
+- **A `yamine start` app is watched by the proxy daemon, but is not
+  idle-killed.** This is the one visible consequence of the supervision
+  fix above, so it is called out rather than buried: previously *no*
+  `yamine start` app was ever idle-killed, and now restart.txt and crash
+  detection work — but the idle clock still does not touch them, because
+  idle-kill is the half of puma-dev that depends on the other half
+  ("stopped, boots on next request"), and the daemon cannot keep that
+  promise for a tcp route. Killing one would take a developer's app down
+  for an afternoon and leave a 503 where it was. Set `YAMINE_IDLE_TCP=1`
+  for the puma-dev behaviour on `yamine start` apps, with the same
+  `YAMINE_IDLE_TIMEOUT` clock (15 minutes by default; that is the
+  supervisor's clock, distinct from the proxy's own
+  `YAMINE_PROXY_IDLE_TIMEOUT`). For the same reason `yamine proxy stop`
+  no longer stops `yamine start` apps along with the socket ones the
+  daemon booted: those have a supervising process of their own.
+
+### Fixed
+
+- **A slow app and a dead app no longer come back as the same useless
+  502.** Waiting for the backend's response *head* and waiting for body
+  bytes shared one clock, and `read_head` swallowed its own timeout into
+  the same `[nil, ...]` a dead backend returns — so `pipe_request` could
+  not tell them apart and every one of them got the same 60-byte page,
+  "The target app is not responding." A font request that took 60,068ms
+  came back with no hostname, no target, no owner, no directory and no
+  next step. The head now has its own budget
+  (`YAMINE_PROXY_HEAD_TIMEOUT`, default 60s — the same bound it already
+  got, so nothing that works today starts failing), the body keeps
+  `YAMINE_PROXY_IDLE_TIMEOUT` untouched, and a silent backend is reported
+  as what it is: *the backend at 127.0.0.1:3000 accepted the connection,
+  then sent no response for 60 seconds*, with the owning agent, the app's
+  own directory (`spec.dir`, not the proxy's cwd — inside a worktree that
+  is the wrong checkout), the path to its `log/development.log`, and the
+  `cd <dir> && yamine start` that fixes it. Machines get the same split
+  in a header: `x-yamine-error: backend-refused` or `backend-silent`.
+  A body clock that was tuned tight for one and a head clock that is not
+  are no longer the same dial, so a streaming response that goes quiet
+  between bytes still runs indefinitely.
+- **A request that was merely slow now gets a second attempt.** One
+  retry, and only where a retry cannot duplicate work: a refused dial
+  never reached the app, so any method replays; a head timeout means the
+  head *did* arrive, so only bodiless GET, HEAD and OPTIONS replay. A
+  GET that takes 61 seconds to answer now serves instead of 502ing. A
+  POST never replays — the body is already consumed off the client socket
+  and cannot be resent faithfully, and a duplicated message is worse than
+  a slow page.
 ## [0.21.2] — 2026-09-29
 
 ### Fixed

data/README.md

@@ -355,11 +355,12 @@ as the app answering 404. `yamine status` reports which mode an app is in.
 
 ```bash
 yamine                        # boot app (waits until healthy, then supervises)
+yamine start --detach         # boot in the background; returns once healthy, prints url/pid/log
 yamine start --no-wait        # fire-and-forget (register routes immediately)
 yamine start --json           # machine-readable wait result (--wait default)
 yamine get <name>             # print URL for cross-service wiring
 yamine alias <name> <port>    # static route (e.g. Docker)
-yamine list [--json]          # show active routes (+ backend liveness)
+yamine list [--json]          # show active routes (+ the APP's liveness)
 yamine status [--json]        # show effective naming context here
 yamine doctor [--json]        # machine-readable health checks
 yamine open [name]            # open the app URL in a browser
@@ -369,7 +370,7 @@ yamine prune                  # remove stale routes
 yamine db list|create|drop|describe    # per-worktree databases (multi-database aware)
 yamine worktree list|add|remove|clean   # worktree lifecycle
 yamine stop                   # stop this app's backend + routes
-yamine restart                # touch tmp/restart.txt (managed apps reboot)
+yamine restart                # touch tmp/restart.txt (a supervised app's backend is stopped)
 yamine log [-F] [n]           # tail (or follow) log/development.log
 yamine proxy start|stop       # control the proxy
 yamine service install|status|uninstall   # root-owned OS startup service
@@ -413,7 +414,19 @@ in-process). Hostnames that fall outside the configured TLDs get a bare
 (healthcheck path when declared, TCP accept otherwise). On failure it
 exits 1 with the failed process, its phase, and the tail of its own log
 — no guessing, no polling, no half-booted routes. `--no-wait` keeps the
-old fire-and-forget path.
+old fire-and-forget path. A child that dies later ends the run the same
+way: exit 1, naming the process, its exit status (or the signal that
+took it down) and the tail of its log. Zero means the app is up.
+
+`yamine start --detach` boots the same tree into the background and
+returns once it is healthy, printing the URL, the pid that owns the tree
+and its log path under the state dir (`start-<hostname>.pid` /
+`start-<hostname>.log`). The boot runs in the child, so that pid is the
+one recorded in `routes.json` — the route outlives the command. It is
+idempotent (a tree already running for the directory is reported, not
+restarted), it ignores `--no-wait` (returning before the app answers is
+the thing it exists to prevent), and `--json` returns
+`{ok, url, pid, log_path, started}`.
 
 ## Log rotation
 
@@ -424,15 +437,29 @@ lose the tail. `doctor` warns when the state dir passes 100MB.
 
 ## Supervision
 
-Managed apps are supervised by the proxy daemon, not the CLI:
-
-- idle backends stop after 15 minutes (`YAMINE_IDLE_TIMEOUT`
-  seconds; `0` disables) and boot transparently on the next request
-- touching `tmp/restart.txt` stops the backend; next request reboots it
-- crashed backends are detected and rebooted on the next request
-- daemon shutdown stops every supervised backend (no orphans)
-
-Run-mode (TCP) routes and static aliases are never supervised.
+Apps are supervised by the proxy daemon, not the CLI. A route is
+supervised when it names a directory to boot from (`spec.dir`), which
+is every app yamine boots — managed socket apps *and* `yamine start`
+trees. Static aliases are not.
+
+- touching `tmp/restart.txt` stops the backend. A managed socket app
+  then reboots on the next request; a `yamine start` app has to be
+  started again (`yamine restart` says which one you have)
+- crashed backends are detected, and a managed app is rebooted on the
+  next request
+- a managed app idle-kills after 15 minutes (`YAMINE_IDLE_TIMEOUT`
+  seconds; `0` disables) and boots transparently on the next request
+- daemon shutdown stops the backends the daemon booted (no orphans)
+
+A `yamine start` app is **watched but not idle-killed**, and is not
+stopped when the proxy stops. Idle-kill is the half of puma-dev that
+depends on the other half — "stopped, boots on next request" — and the
+daemon can only keep that promise for a socket app: a tcp route's port
+is a free port chosen at boot and the route records no command to
+re-run, so nothing could bring it back. Set `YAMINE_IDLE_TCP=1` to get
+the puma-dev behaviour for `yamine start` apps too (same
+`YAMINE_IDLE_TIMEOUT` clock — the supervisor's, distinct from the
+proxy's own `YAMINE_PROXY_IDLE_TIMEOUT`).
 
 ## Ask ecosystem integration
 

data/lib/ask/skills/yamine/SKILL.md

@@ -36,6 +36,7 @@ no extra gem — the proxied hostname is allowed automatically via
 yamine start              # setup if needed, then boot every process (waits until healthy)
 yamine start --no-wait   # fire-and-forget (register routes immediately)
 yamine start --json       # machine-readable wait result (--wait default)
+yamine start --detach    # boot in the background; returns once healthy, prints url/pid/log
 yamine                    # same as start
 yamine stop               # stop this app's backend + routes
 yamine status             # show service, processes, and URLs
@@ -44,7 +45,16 @@ yamine log [-F]           # tail log/development.log (every process)
 
 `$PORT` and `YAMINE_URL` are injected per process; HTTP processes get
 stable URLs, background ones are supervised without routes. A process
-that exits cleans up the whole tree.
+that exits cleans up the whole tree — and ends the run with exit 1,
+naming that process, its exit status and the tail of its log. Zero from
+`yamine start` means the app is up.
+
+`--detach` is the one to use from a tool: it forks the boot, so the
+command returns with the URL, the pid that owns the tree (recorded in
+`routes.json`, so the route outlives the command) and that tree's log
+path under `~/.yamine/`. Run it again and it reports the running tree
+instead of starting a second one; `yamine stop` stops it. Do not reach
+for `nohup` — the tree yamine starts is the one `yamine stop` can reach.
 
 The boot narrates every phase — deps, db, schema, and each process's
 healthcheck — one line per phase, so a slow boot is never a black box:
@@ -193,6 +203,15 @@ yamine prune                  # clear stale routes from crashed sessions
 yamine start --json           # boot readiness payload (pass/fail + log tail)
 ```
 
+`yamine list` reports the state of the **app**, not of the yamine
+process that started it: `running`, `backend-gone` (the app died, the
+process that booted it is still there), `owner-gone` (both gone),
+`unknown` (no backend pid recorded — nothing is known, it is not a
+failure), and `reachable` / `unreachable` for a `yamine alias`, which
+points at a port rather than a process. `yamine restart` stops the
+backend; a managed app reboots on the next request, a `yamine start` app
+has to be started again.
+
 If a hostname does not resolve — or boot/doctor report it as not in
 `/etc/hosts` and you use clients that read only that file (CGO-disabled
 Go binaries): `yamine hosts sync`. If the browser warns about TLS: