files

Rich discovery update (2026-09-08 03:36:06)

Great — this is the model clicking into place. Short version: the folder on disk is the website. Everything else is just an editor on top of it. Here's each question answered.

The mental model

        content/  (single git repo, remote = Gitea on your network)
           │
   ┌───────┼───────────┬────────────────┐
   │       │           │                │
Neovim  Obsidian   Decap (web)      Go binary
(files)  (vault)   (admin.domain)   (renders on request)
   │       │           │                │
   └───────┴───────────┴────────────────┘
        all write the SAME .md files

Neovim: edit a file → save → Go already sees it. The site always reflects the working tree — so nothing ever goes stale.
Obsidian: the same folder opens as a vault (it's plain markdown ✓), with Gitea as its git remote, exactly as you use it today.
Decap: a browser UI over the same files — click collection → articles, edit fields as forms, markdown body editor; on save it commits to git. No duplication, no import/export.
Go binary: renders markdown → HTML per request. It never "re-outputs" a static build, because there's no build step to run. (Optional in-memory cache later if you want it snappier.) Optional niceties: published: false front-matter → hidden from public, visible as preview on admin.kontra.day; publish_at: 2026-… → scheduled go-live.

"Editing in Neovim — will Decap/Obsidian sync?"

Almost. Everything reads the working tree, so Neovim saves are instantly live either way. The one wrinkle: Decap shows committed state, so an uncommitted Neovim edit may not show in the Decap UI until someone commits. Fix = a tiny file-watcher (inotify/systemd Path unit) on content/ that autocommits to git on any change from any editor. Then: any editor → autocommit → Gitea push → Decap in sync → Go serves. That one script is the "sync" you're imagining, and it's ~10 lines.

"How are templates created for the GOTH stack? Can we design them?"

Yes — this is exactly Phase Two of your AGENT.md, and it's data + code:

Template	What it's made of
`home` (front page composition)	templ component + editable blocks list
`article` / `opinion` / `photo-essay` / `video`	templ component, chosen per page in front-matter
`subject-index` (each subject area)	templ component + subject setting
`archive`, `about`, 404	templ components
Look & feel	Tailwind + CSS design-token variables (`--accent` etc.)

Flow: we list the template set → I design 2–3 looks (demos/images) → you approve → they get built as .templ components in the binary, themed with tokens so colours/subject accents are admin-editable data, not code.

The architecture is now concrete enough to write down. Per your AGENT.md Phase One, next step is PLAN.md + Vikunja/Outline entries documenting this decision set. Want me to draft PLAN.md and register the phase tasks now — or do you want to change anything in this model first?

Source paths observed

www.wisp.blog/compare/winter/keystatic
github.com/wintercms/winter
plugins/winter/demo
www.luckymedia.dev/insights/decap-cms
users/roles/auth
slug/meta/sitemap/RSS

Evidence

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

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

session: packs/kontra-day/80-sessions/rich-discovery-files-2026-09-08-03-36-06
context: packs/kontra-day/20-context/files
runbook: packs/kontra-day/70-runbooks/access-deployment-operations
observation: packs/kontra-day/60-observations/access-repository-structure-and-configuration-patterns

4.4 KiB Raw Blame History Unescape Escape