vh/esh-pfi-infrastructure
1
0
Fork 0
Code Issues 7 Pull Requests Actions Packages Projects Releases Wiki Activity

vor: stack + playbook + workflow template for ana-docker deploy

Browse Source 
Same shape as task-board: build-on-host from vh/vor, bind-mounted
persistence for sessions/ and responses/ (the user-published markdown
files), exposed at port 7879 (adjacent to task-board's 7878 since both
are claude-tooling sidecars).

Workflow template assumes the same DEPLOY_SSH_KEY + MGMT_REPO_TOKEN
secrets at user scope; nothing new to provision. Playbook accepts SHA
or branch refs (same fix as deploy-task-board.yaml) so manual runs
and CI runs share the same code path.

Centralized vs upstream-local: README documents the trade. Claude
fetches response markdown via /api/sessions/{id} JSON instead of a
local file read — the only API-flow change from the upstream README.
This commit is contained in:
vh
2026-04-29 21:31:59 -07:00
parent f44a1d1c02
commit a61b577c59
5 changed files with 300 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
stacks/vor/README.md
+61
View File
@@ -0,0 +1,61 @@
# vor
[Inquisitor UI](https://gitea.phasefinal.com/vh/vor) deployed centrally.
A FastAPI sidecar that renders Claude's `/inquisitor` markdown as a
fillable form — Claude POSTs sessions, user fills + publishes via
browser, Claude reads the response back.
**Server:** ana-docker
**Port:** 7879 (configurable via `.env`)
**Upstream repo:** [vh/vor](https://gitea.phasefinal.com/vh/vor)
**Image:** `vor:local` — built on the host from the git repo by the
deploy playbook. Not pulled from a registry.
## Centralized vs local
The upstream README describes a **local** deployment pattern (Claude
on the workstation posts to `127.0.0.1:8765`, response file lives on
the local filesystem). Running vor on ana-docker changes that:
- Claude POSTs to `http://10.250.50.70:7879/api/sessions`
- The browser opens `http://10.250.50.70:7879/?session=<id>`
- The response markdown is **not** written to a path Claude can read
off its own disk; Claude reads it back via
`GET /api/sessions/{id}` (`response_markdown` field) instead.
Trade: central + always-on + multi-device (phone, tablet, second
workstation) at the cost of a network round-trip and an HTTP-fetch
step in Claude's flow instead of a file read.
## Deploy
Two paths — automated (preferred) and manual.
### Automated (Gitea Actions, push-to-main)
Every push to `main` on `vh/vor` triggers a deploy via the central
gitea-runner. Workflow template lives next to this README at
[`gitea-workflow-deploy.yaml.example`](gitea-workflow-deploy.yaml.example);
copy into the vor repo at `.gitea/workflows/deploy.yaml` (already
done on first wiring). Reuses the `DEPLOY_SSH_KEY` and
`MGMT_REPO_TOKEN` secrets at user scope; no per-repo setup needed
once those exist.
### Manual (elway from a workstation)
```bash
# First deploy / update to latest main
scripts/elway ana-docker --playbook playbooks/deploy-vor.yaml
# Pin to a specific ref
scripts/elway ana-docker --playbook playbooks/deploy-vor.yaml --var ref=v0.2.0
```
## Path layout (on ana-docker)
| Host path | Container path | Purpose | Restic? |
|---|---|---|---|
| `/opt/docker/build/vor/` | — | git checkout used as docker build context | excluded |
| `/opt/docker/compose/vor/` | — | compose.yaml + .env | included (via `/opt/docker`) |
| `/opt/docker/conf/vor/sessions/` | `/app/sessions` | Claude-posted markdown | **included** |
| `/opt/docker/conf/vor/responses/` | `/app/responses` | user-published response markdown | **included** |