vh
a61b577c59
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.
62 lines
2.4 KiB
Markdown
62 lines
2.4 KiB
Markdown
# 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** |
|