individually

Rich discovery update (2026-09-08 03:44:05)

Confirmed the full topology. Here's the storage/sync reality and the plan for it.

The actual topology (verified)

Machine	Role	Relevant bits
.27 (this)	Main dev, Obsidian + Neovim live here	Obsidian vault at `/home/sam/obsidian/`
.13	Web host, always-on	Sites in `/var/www/`, runs PocketBase, Caddy sits upstream
.35	Gitea (Docker, web :3001, SSH :2222) + Caddy reverse proxy	`gitea.lab.audasmedia.com.au`
Garage S3	media bucket — need to confirm which host	(Phase One item)

Where things should live — the key decision

The mistake to avoid: coupling the live site to .27 (your dev machine). So:

Gitea repo on .35 = the single source of truth for content (.md + config + media references). This is the "origin".
.27 = authoring clients (Obsidian vault + Neovim) — it's a clone of that repo, pushes to .35.
.13 = the always-on production clone at /var/www/kontra_day/, which the Go binary serves.
Caddy on .35 routes kontra.day → Go on .13, admin.kontra.day → Decap on .13.
Garage S3 = media objects, referenced from .md via {{media:...}} shortcodes.

How sync actually works (this is the part that matters)

Editor on .27          Gitea on .35          Production on .13
Neovim / Obsidian  ──push──▶  origin  ──webhook/poll──▶  git pull
   (clone)                          ▲                        │
                                    │                        ▼
Decap (admin.kontra.day)  ──commit──┘                 Go binary renders .md → HTML

Any change from any editor (Neovim save, Obsidian sync, Decap save) lands on Gitea, then auto-deploys to .13 via webhook + systemd Path watcher that runs git pull.
.13 never needs your .27 — it pulls straight from Gitea. Your dev machine can be off and the site stays live. ✅ this addresses exactly your concern.
No build step: Go re-renders .md → HTML per request (with an optional cache), so a pull = instant content update.
This is a strict upgrade over the current manual lsyncd .27→.13 pattern — you'd retire that for this site (same wiring though: systemd on .13).

Things that must be decided/verified in Phase One

Which host runs Garage S3 (needs confirming — it's not in the skill list yet).
Where the Go binary + Decap run on .13 — as a systemd service (users group, /var/www/kontra_day per the existing perms note) or Docker.
Caddy config — which Caddy instance (skill says Caddy is on .35) owns the kontra.day/admin.kontra.day vhosts, and how it upstreams to .13.
Obsidian vault wiring — make /home/sam/obsidian/.../kontra_day a git clone of the Gitea repo (Obsidian already git-links to Gitea, so this is a natural fit).
Deploy trigger — Gitea webhook → .13 vs. a simple systemd timer git pull every 30s (fewer moving parts, good enough).

Recommendation

Gitea (.35) as origin → .13 always-on clone as live → .27 clients as editors. That keeps production decoupled from your dev box, gives you history/rollback on every .md, and matches the Gitea/Obsidian habits you already have.

Want me to fold this into PLAN.md now (with the open questions marked), and register the Phase One tasks in Vikunja/Outline?

Source paths observed

2222/sam/pi-config.git
.pi/agent/settings.json
home/sam/.agents
gitea.lab.audasmedia.com.au/sam/pi-config
sys/firmware/efi/efivars
.config/lsyncd/lsyncd.conf.lua
zola/sprinkler/public
.config/environment.d/10-secrets.conf
.27/.13/.51
Gitea/Obsidian/Caddy
home/sam/obsidian
var/www/kontra_day
home/sam/obsidian/.../kontra_day

Evidence

Confidence: 84%
Reason: Update component/repository context with detailed discovered structure and configuration

packs/kontra-day/00-system/pi-agent/memory-manifest

4.8 KiB Raw Blame History