fix(queen): deploy through Railway's own hook, not a pipeline that never worked

[gHashTag]

The pipeline never worked

queen-deploy.yml ran 35 times between 2026-04-01 and 2026-04-03 and succeeded zero times — 32 failures, 3 cancellations, every failure on the same Build and Push to Railway step.

It could not have worked:

defect	evidence
pushes an image without authenticating	grep -c 'docker login' → 0
project id is a placeholder	workflow: 90c3f0c8-…-5e123abc4567 · real: e6dfacdc-3eed-48ae-929b-02e87f07f0aa
test job reads steps.deploy.outputs from another job	cross-job step outputs don't resolve
posts ✅ Queen deployed to issue 476 every run	including all 32 failures

There is no Queen backend to deploy

• deploy/Dockerfile.queen runs zig build … queen-backend. build.zig declares 67 steps and none is named that. The nearest is libqueen, which builds the libtrinity-queen C API library for the SwiftUI dashboard — not a server. So /usr/local/bin/queen-backend is never produced.
• The same Dockerfile copies /zig-linux-x86_64-0.15.2 out of a stage that extracted /zig-x86_64-linux-0.15.1 — different name order and different version. Only the latter exists on ziglang.org (200); the former 404s. That COPY is why the build died every time.
• src/server_main.zig, the nearest thing to a server, answers every request with one fixed JSON blob, is wired into no build step, binds 127.0.0.1, and says "for fly.io" in its header.

Dockerfile.queen is deliberately left untouched and still broken — that is the backend's problem, not this change's. The brain has no vehicle yet for the same reason: it is Zig and would ship inside that backend.

What this does

Railway builds from its own GitHub hook here, the way woody-weed-bot already ships. The workflow no longer deploys — it proves the artefact builds, and asserts the bundle was actually emitted, because a build that emits nothing still exits 0.

Deployed surface is apps/queen-web and only that.

Two rules restored

• Runtime entrypoint is no longer sh -c (no-shell-scripts) — this path has no custom container at all.
• The container carries SOUL.md, as the Queen Trinity Orchestrator Law requires.

That law was impossible to obey: .gitignore:315 ignores *.md and re-included only templates/SOUL.md, so a container's own soul could never be committed without -f. A !**/SOUL.md negation fixes the cause rather than forcing one file past it.

Measured before claiming: 1844 .md on disk against 1803 tracked — the existing !docs/** and !.github/ negations already cover nearly everything, so the gap was narrow, not the whole documentation tree.

Verified, not assumed

queen-web build          exit 0, 253.49 kB JS, 3.80 kB CSS
PORT=7311 npm start      localhost:7311      -> HTTP 200
                         192.168.1.100:7311  -> HTTP 200   (proves the 0.0.0.0 bind)
title served             "Queen UI — Self-Improving Container"

The LAN-address check is the point: a loopback bind is unreachable from outside a container, which is how a Railway service ends up serving 502 while looking healthy locally.

Still needed from a human

Railway CLI is unauthenticated on this machine and railway login is interactive. To finish: log in, point service 0457ebb4-aec3-4aa0-be6e-bcd8ef0d32e7 at this repo with root directory apps/queen-web, and let the hook build.

🤖 Generated with Claude Code