---
type: context
id: context.kontra-day.individually
title: individually
status: active
source_of_truth: false
freshness: current
last_reviewed: 2026-09-08
tags:
  - pack/kontra-day
  - agent-memory/context
  - autolearn
  - rich-discovery
  - repo/individually
---

# 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
1. **Which host runs Garage S3** (needs confirming — it's not in the skill list yet).
2. **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.
3. **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.
4. **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).
5. **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

## Related

- [[packs/kontra-day/00-system/pi-agent/memory-manifest|Memory Manifest]]

## Related learned memories <!-- same-turn-2026-09-08 03:44:05 -->

- session: [[packs/kontra-day/80-sessions/rich-discovery-individually-2026-09-08-03-44-05|Rich discovery: individually 2026-09-08 03:44:05]]
- context: [[packs/kontra-day/20-context/individually|individually]]
- runbook: [[packs/kontra-day/70-runbooks/individually-deployment-operations|individually deployment operations]]
- observation: [[packs/kontra-day/60-observations/access-repository-structure-and-configuration-patterns|individually repository structure and configuration patterns]]