Systems Conventions

Rules for systems/. This garden holds deployment tutorials: complete, tested walkthroughs a non-technical reader can follow end to end.

Frontmatter (required)

---
title: "Deploy a TAK Server on a VPS"
aliases: []
tags: [tutorial, <domain tags>]
date: YYYY-MM-DD
section: "0N-Section-Slug"
status: draft | tested
source: "original" or the upstream docs it distills
---

status: tested means the walkthrough was executed start to finish on a clean machine and every command behaved as written. Until then it is draft and says so.

Tutorial spine

  1. What you are building - one paragraph plus a diagram (mermaid or /diagrams/ SVG) of the finished system.
  2. Cost and prerequisites - hardware, accounts, monthly cost in dollars, skill assumed. No surprises later.
  3. Build - numbered steps with exact commands in fenced blocks. One action per step. State what each command does before showing it.
  4. Verification - “you know it works when”: concrete checks the reader runs before relying on the system.
  5. Failure modes - the ways this breaks and what each looks like.
  6. Teardown - how to remove it cleanly (and stop paying for it).

Hard rules

  • Every command is copy-pasteable and was actually run. No pseudo-steps (“configure the firewall appropriately”).
  • Scripts live next to the note in the same folder and are referenced by relative path. A script never embeds a secret; secrets are env-vars the reader sets, and the tutorial says exactly which.
  • Placeholders the reader must replace are SHOUTY: YOUR_DOMAIN, YOUR_SERVER_IP. List them all in one table before the Build.
  • Name real products and real prices; revisit dates in frontmatter tell the reader how stale a price might be. No affiliate framing.
  • No em dashes (check-enforced repo-wide). No emojis.
  • Sections are numbered folders with a folder note of the same name, like the other gardens: 01 Communications & C2/.