4.5 KiB
Rich discovery: files 2026-09-08 03:36:06
Sanitized rich discovery snapshot captured automatically from the completed turn.
Source paths observed
www.wisp.blog/compare/winter/keystaticgithub.com/wintercms/winterplugins/winter/demowww.luckymedia.dev/insights/decap-cmsusers/roles/authslug/meta/sitemap/RSS
Final answer snapshot
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: falsefront-matter → hidden from public, visible as preview onadmin.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?
Evidence
- Confidence: 86%
- Reason: Preserve full sanitized discovery detail from a rich investigation turn