Files
pi-devbox/.env.example
T
Joakim Persson d8b745c164
Lint / actionlint (push) Successful in 30s
Lint / hadolint (push) Successful in 40s
smoke+docs: pin the feeder's failed-remote-mine detection; REMOTE_PATH is server-visible
First boot of the 2026-08-15 image on EMB-7KJ4VR4G shipped 7 transcripts to the
palace host and filed none. Two causes, neither visible in the log:

- MEMPALACE_PI_REMOTE_PATH was unset, so the feeder used its /data/feed default,
  which assumes a CONTAINERIZED palace server. That fleet's primary runs
  natively (systemd user unit + uv tool), so it only sees host paths and the
  mine died with "source directory not found". rsync had already succeeded.
- The feeder decided success with `'"error"' in body`, but MCP escapes the
  tool's JSON inside result.content[].text, so the check was blind and the
  catch-up log said "Done. Wing updated." Fixed in mempalace-toolkit 6e1f4f3,
  which ships `--self-test` with fixtures pinning that exact response body.

- smoke-test.sh: run `mempalace-pi-session --self-test` against the BAKED
  toolkit, so a stale or reverted MEMPALACE_TOOLKIT_REF cannot reintroduce a
  feeder that mines nothing while reporting success.
- .env.example: spell out that MEMPALACE_PI_REMOTE_PATH is the path the SERVER
  PROCESS can open — container path for a dockerized server, and identical to
  the ssh-target path for a native one — and that a mismatch fails quietly.
2026-08-16 00:30:51 +02:00

140 lines
8.1 KiB
Bash

# pi-devbox environment configuration
# Copy this file to .env and fill in your values:
# cp .env.example .env
# ── Workspace ────────────────────────────────────────────────────────
# Path on host to mount as /workspace in the container
WORKSPACE_PATH=~/projects
# Path to SSH keys on host
SSH_KEY_PATH=~/.ssh
# ── MemPalace memory (local by default) ───────────────────────────
# By default the mempalace.ts extension spawns a LOCAL mempalace-mcp stdio
# server (palace at ~/.mempalace). Uncomment the devbox-palace volume in
# docker-compose.yml to persist it across container recreation — that one
# volume now covers the mined conversation transcripts too, since the pi and
# opencode feeders stage inside the palace root (<palace-root>/pi-stage), so
# the staged files and the palace dedup keys pointing at them cannot be
# separated.
#
# To instead share ONE MemPalace across containers/harnesses (pi + opencode
# + native), set the URL below. When set, the extension connects over HTTP
# and NO local mempalace-mcp is spawned; the devbox-palace volume is then
# irrelevant. MEMPALACE_REMOTE_TOKEN, if set, is sent as a bearer token.
#
# Serve it with: mempalace serve --host 172.17.0.1 --port 8765
#
# NOT `mempalace-mcp --transport http --host 0.0.0.0`: `serve` is the turnkey
# wrapper that mints/keeps a bearer token (0600, passed via env so it stays out
# of `ps`) and can terminate TLS. Two binds to avoid:
# 0.0.0.0 - exposes the palace to the whole LAN.
# 127.0.0.1 - behind a tunnel this 403s every proxied request (the Host pin
# is only enforced on loopback binds) AND silently starts with
# no token at all, since auto-minting is gated on the bind being
# non-loopback. Bind the docker0 gateway: reachable from the host
# and its containers (so a newt/proxy container works), not from
# the LAN. Set MEMPALACE_MCP_HTTP_TOKEN explicitly server-side.
# MEMPALACE_REMOTE_URL=https://mempalace.example.com/mcp
# MEMPALACE_REMOTE_TOKEN=
# ── MemPalace: automatic capture of pi sessions ───────────────────────
# The mempalace.ts extension feeds this container's pi transcripts into the
# palace by itself: on session_shutdown, and on a debounced agent_settled so a
# crash loses at most one window rather than the whole session. The entrypoint
# also runs a catch-up at container start, which is the only thing that can
# recover transcripts after a hard kill (no handler runs on SIGKILL).
# Nothing below is required for the local-palace case; the defaults work.
#
# MEMPALACE_FEED=0 # disable automatic capture entirely
# MEMPALACE_FEED_DEBOUNCE_MS=600000 # min gap between mid-session feeds (10 min)
# MEMPALACE_FEED_WING=wing_conversations
#
# REMOTE PALACE ONLY (MEMPALACE_REMOTE_URL set above): the palace is on another
# host, and `mempalace_mine` resolves its source path in the SERVER process, so
# the server cannot see this container's transcripts. The feeder therefore
# rsyncs its staged exports into a per-device inbox on the palace host and asks
# the server to mine its own local copy. Without MEMPALACE_PI_SSH_TARGET the
# feeder is skipped (a remote palace with no inbox has nothing to mine).
# MEMPALACE_PI_SSH_TARGET where to rsync to, as user@host:path
# MEMPALACE_PI_REMOTE_PATH what that inbox is called ON THE SERVER — i.e. the
# path the SERVER PROCESS can open. If the palace
# server runs in Docker, that is the container path
# (see docker-compose.mempalace.yml). If it runs
# NATIVELY (systemd unit / uv tool / plain
# `mempalace serve`), it sees host paths, so this
# must equal the path half of
# MEMPALACE_PI_SSH_TARGET. Getting this wrong is
# quiet: rsync still succeeds and only the mine
# fails with "source directory not found", so
# transcripts ship and are filed nowhere. The feeder
# warns in preflight when the two paths disagree.
# MEMPALACE_PI_DEVICE inbox subdirectory for this machine (default: hostname)
# MEMPALACE_PI_SSH_TARGET=user@palace-host:/srv/mempalace-feed
# MEMPALACE_PI_REMOTE_PATH=/data/feed
# MEMPALACE_PI_DEVICE=
# ── LAN access from the container (host-OS-agnostic) ─────────────────
# On VM-backed hosts (macOS OrbStack / Docker Desktop) the container can't
# reach the host's directly-attached LAN peers by default. The entrypoint
# then sets up the host as an SSH jump (use the `dssh` alias). Reach the host
# with `dssh host`; for named LAN peers put `ProxyJump host` overrides in a
# host-owned ~/.config/devbox-shell/ssh-lan.conf (bind-mounted in) rather than
# editing ~/.ssh/config. On native Linux Docker the LAN is reachable directly
# and this is a no-op.
# See the opencode-devbox README for the full walkthrough.
#
# DEVBOX_LAN_ACCESS: auto (default) | jump | off
# DEVBOX_LAN_ACCESS=auto
# HOST_SSH_USER: your username on the host (required for the jump). On first
# start the entrypoint prints the public key to authorize on the host.
# HOST_SSH_USER=
# DEVBOX_HOST_ALIAS: host hostname to reach (default host.docker.internal).
# DEVBOX_HOST_ALIAS=host.docker.internal
# DEVBOX_LAN_AUTOJUMP_PRIVATE: 1 = ProxyJump any private (RFC1918) IP through
# the host, so bare `dssh user@<ip>` works on whatever LAN you're roaming on.
# DEVBOX_LAN_AUTOJUMP_PRIVATE=0
# ── pi-atelier (TUI sidebar) ─────────────────────────────────────────
# The image vendors pi-atelier at a pinned, audited tag and registers it on
# container start. Set to 0 to opt out: the entrypoint then removes it from
# pi's `packages[]` instead of registering it. This lives here rather than
# being a `pi uninstall` because a broken TUI extension's failure mode is
# "pi will not start", which you cannot fix from inside pi.
# DEVBOX_ATELIER=1
# ── Git Configuration ────────────────────────────────────────────────
# Set BOTH. If unset, every repo inside the container fails with
# "Author identity unknown" on first commit, and an agent asked to commit
# will guess an identity from git log — often the wrong one. The e-mail is
# per-machine (work machines use the corporate address, personal machines the
# private one), so it belongs in this per-machine .env, never in a skill or a
# repo-local override. Consumed by entrypoint-user.sh -> ~/.gitconfig, which is
# NOT persistent across container recreate — this file is the source of truth.
GIT_USER_NAME=
GIT_USER_EMAIL=
# ── Gitea (for gitea-mcp MCP server) ────────────────────────────────
# GITEA_ACCESS_TOKEN=
# GITEA_HOST=https://gitea.example.com
# ── GitHub (optional, for GitHub MCP / git operations) ───────────────
# GITHUB_PERSONAL_ACCESS_TOKEN=
# ── AWS (optional, for AWS CLI / Bedrock) ────────────────────────────
# AWS_REGION=eu-west-1
# AWS_PROFILE=default
# AWS_ACCESS_KEY_ID=
# AWS_SECRET_ACCESS_KEY=
# ── Skillset (agent skills and instructions) ─────────────────────────
# If you have a skillset repo, the entrypoint auto-deploys skills and
# instructions on container start using relative symlinks.
# Detection is automatic if the skillset lives at WORKSPACE_PATH/skillset.
# SKILLSET_CONTAINER_PATH=
# ── Locale ───────────────────────────────────────────────────────────
# LANG=sv_SE.UTF-8
# LANGUAGE=sv_SE:sv
# LC_ALL=sv_SE.UTF-8