Add blog section (4 draft posts) and social post drafts for /platform funnel

Continues the content-engine plan: /platform, the homepage link, and the
small-business-infrastructure course are already live. This adds the
remaining pieces — a content/blog/ section with 4 long-form posts (kept
draft:true, so nothing goes live until reviewed) and a committed set of
~12 ready-to-copy social posts in drafts/social-posts.md.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

drafts/social-posts.md

@@ -0,0 +1,219 @@
+# Social post drafts — /platform launch series
+
+Ready-to-copy LinkedIn/X posts. Suggested cadence: ~2-3x/week, alternating
+technical-guardrail posts (credibility with technical referral partners) and
+human/outcome posts (credibility with small-business owners). Posting order
+below follows that alternation. Each links to https://reground.org/platform/.
+
+All claims are sourced from real commits/incidents in this workspace —
+sourced-from note under each post for your own reference; drop those notes
+before posting.
+
+---
+
+## 1. [Guardrail] The CI check that blocks a public bucket
+
+I run object storage for five small businesses. Every one of those buckets
+defaults to private — and there's a CI check that fails the build if a change
+would make one public, unless there's a comment explaining exactly why.
+
+Not a policy. Not a reminder in a wiki somewhere. A build that won't go green
+until you either fix it or justify it in writing, right next to the code that
+does it.
+
+That's the difference between "we're careful about this" and "this system
+will not let you be careless about this by accident."
+
+More on how I run infra for five real businesses off one server →
+reground.org/platform
+
+*(sourced: reground-infrastructure .gitea/workflows/tf-lint.yml + scripts/check-public-buckets.sh, ACL gate on every linode_object_storage_bucket)*
+
+---
+
+## 2. [Human] Meet the five businesses
+
+Right now, one hub server runs the hosting, email, and checkout for:
+
+- An author's site
+- A short-fiction writer's site
+- A small-batch soap shop
+- A literary press running open submissions
+- A small press with multiple authors
+
+Same infrastructure underneath. Completely different businesses on top. None
+of them think about servers, deploy keys, or database backups — because
+that's the whole point.
+
+Curious what "one hub, five brands" actually looks like under the hood?
+reground.org/platform
+
+*(sourced: reground-site content/platform.md client description; kept anonymized to match how the live page describes them)*
+
+---
+
+## 3. [Guardrail] A `git push` can never send an email
+
+Every content repo I run campaigns out of has the same rule baked into the
+tooling: pushing to the repo can only ever produce a *draft* campaign. There
+is no field, no flag, no config value that lets a routine content push
+schedule or trigger a real send.
+
+Sending for real is a separate, deliberate command. Always. On purpose.
+
+If the worst that can happen from a typo'd commit is "an unsent draft
+appeared," you've designed the failure mode correctly.
+
+reground.org/platform
+
+*(sourced: eec-campaigns internal/campaign/send.go — Send() only transitions draft/paused → running; sync never touches status)*
+
+---
+
+## 4. [Human] The soap maker doesn't know what a deploy key is
+
+And that's exactly how it should be.
+
+One of the five businesses I run infrastructure for makes small-batch
+cold-processed soap. She doesn't need to know what a deploy key is, what
+Postgres is, or how her checkout flow is hosted. She needs her site up, her
+orders processed, and her email list intact.
+
+The technical decisions underneath are mine to be accountable for, not hers
+to worry about. That's the actual service.
+
+reground.org/platform
+
+---
+
+## 5. [Guardrail] Scoped keys, not shared trust
+
+Each of the five sites I run has its own deploy key, and each key can only
+touch that one site's files — nothing else on the server. It's enforced by
+the key itself, not by a policy someone has to remember to follow.
+
+So if one site's repo were ever compromised, the blast radius is that one
+site. Not the other four. Not the shared database. Not the mail server.
+
+"Scoped" isn't a nice-to-have when you're running multiple businesses from
+one place — it's the entire reason it's safe to do at all.
+
+reground.org/platform
+
+*(sourced: reground-infrastructure per-site forced-command rrsync deploy keys)*
+
+---
+
+## 6. [Human] Why a literary press's open-submissions inbox matters to me
+
+One of the businesses I run infra for is a literary press that runs open
+submissions — meaning strangers' work lands in their system every week,
+sight unseen, from writers hoping someone reads it.
+
+That's a real trust relationship on both ends: the press trusting their
+infrastructure won't lose or leak someone's submission, and the writer
+trusting the press with something they wrote. I don't get to see the
+manuscripts. I just make sure the plumbing holds.
+
+reground.org/platform
+
+---
+
+## 7. [Guardrail] Verify after every step, not just at the end
+
+Moving a production deploy key off the root account isn't a one-commit
+change if you're doing it carefully. I did it in three: move the key to a
+dedicated account, verify the deploy still works. Fix the account's shell
+from a locked-down nologin to bash so the key actually functions, verify
+again. Remove the old root-level key, verify a final time.
+
+Three commits, three separate verifications, because "I'm pretty sure that
+worked" isn't good enough on a production mail server for five businesses.
+
+reground.org/platform
+
+*(sourced: eec commits 9fa7895 / 4497e4e / b8759d0)*
+
+---
+
+## 8. [Human] A real incident: what "unconfirmed" protected
+
+One of the five businesses I run switched their list to double opt-in
+partway through. Their earlier import batch — people who'd already agreed to
+be on the list through a real prior relationship, just not yet
+Listmonk-confirmed — could have been swept up and auto-confirmed to make the
+numbers look clean.
+
+Instead, those subscribers stayed exactly as `unconfirmed`, honestly
+reflecting what was actually true about them, while the tooling was updated
+to explain why. Boring is correct. Correct beats clean.
+
+reground.org/platform
+
+*(sourced: reground-tools commit f03c36a, 2026-07-22, Two Squirrels Press double opt-in)*
+
+---
+
+## 9. [Guardrail] Nothing that touches real subscriber data runs by default
+
+Every ops script I use that could affect real subscribers — bulk name
+backfills, unsubscribes, list edits — defaults to "show me what this would
+do." Actually doing it requires a separate `--apply` flag, every time, no
+exceptions.
+
+The safe path is the path of least resistance. The dangerous path takes an
+extra, deliberate step. That's not a coding style — it's a decision about
+what a mistake is allowed to cost.
+
+reground.org/platform
+
+*(sourced: reground-tools backfill-names.sh / unsubscribe-subscriber.sh dry-run-by-default, --apply required)*
+
+---
+
+## 10. [Human] "Generate," not "fork"
+
+Every new client site I bring on starts from a clean slate — zero inherited
+git history, zero leftover config from whoever came before them. Not because
+forking is technically hard, but because a new client's site shouldn't carry
+another business's commit history, secrets, or half-finished experiments
+into their own repo on day one.
+
+Onboarding a new business should feel like a fresh start, because it is one.
+
+reground.org/platform
+
+*(sourced: campaigns-template / eec-courses-template — Gitea "Generate Repo" pattern)*
+
+---
+
+## 11. [Guardrail] One engine, five brands, one fix
+
+When RFC 8058 one-click unsubscribe needed to ship, it went out to every
+brand I run at the same time — because it lives in one shared engine, not
+five separate forks that would each need the same fix applied by hand, five
+times, with five chances to get it slightly wrong.
+
+That's the actual payoff of "shared engine, per-brand config": a real fix is
+one change, verified once, live everywhere.
+
+reground.org/platform
+
+*(sourced: eec + bookshop shared RFC 8058 one-click unsubscribe rollout)*
+
+---
+
+## 12. [Human] What used to be four vendors is now one afternoon
+
+Before this setup, a small business selling books needed a checkout
+processor, a separate storefront platform, a separate ebook delivery
+service, and a separate email platform — four vendors, four logins, four
+bills, none of which talk to each other on their own.
+
+Now it's one shared service, deployed once, configured per brand, running
+identically for every business that uses it. Same reliability, a fraction of
+the moving parts.
+
+reground.org/platform
+
+*(sourced: bookshop — replaces Stripe + Shopify + BookFunnel + ConvertKit-style stacking)*