How we work — the knowledge gradient & developing in the open

Two practices keep Cynario coherent while it’s built in public: a temperature gradient for knowledge, and a develop-in-the-open model that stays safe by construction. They’re complementary — the gradient decides when a note is ready to surface; the open-dev model decides what’s always safe to surface.

---

The knowledge gradient — hot to frozen

All working knowledge lives under knowledge-base/ and flows in one direction, from hot (raw, volatile) to frozen (filed, permanent). The numbered prefixes make the direction explicit: lower number = hotter = more volatile.

HOT ──────────────────────────────────────────────── FROZEN

00-inbox    01-working    02-learnings    03-reference    04-archive
  raw         active         distilled        stable          filed

Zone	Temperature	What lives there	Lifespan
00-inbox/	Hot	Raw captures, session notes, quick thoughts	Hours to days
01-working/	Warm	Active synthesis — decisions, drafts, trackers	Days to weeks
02-learnings/	Cool	Distilled insights, patterns, post-mortems	Weeks to months
03-reference/	Cold	Stable cross-cutting reference	Months to years
04-archive/	Frozen	Filed knowledge, by Johnny Decimal area	Permanent

The flow: capture in 00-inbox → process into 01-working → distill into 02-learnings → stabilize into 03-reference → file in 04-archive. Not everything travels the whole way; a clear one-off can jump straight to filed. The gradient is a guide, not a pipeline.

The key move: promotion up the gradient is the cleanup moment. A note becomes shareable by maturing, not by someone deciding to sanitize it later.

docs/ vs knowledge-base/: docs/ is the cold/reference zone for the product (architecture, data model, decisions). knowledge-base/03-reference/ is the cold zone for how we work (workflow, tooling, environment). They don’t duplicate — they link.

The agent-facing pages you’re reading are a curated landing over this material — the doorways, not a mirror of every note.

---

Developing in the open — config vs content

Building publicly means deciding, over and over, what’s safe to expose. Doing that by hand is unsustainable and error-prone, and a crude public/private flag on every file is the wrong mental model. The reframe: two axes, not one.

Axis 1 — machine/personal specifics are config, never content

Tailnet hosts, IP addresses, personal filesystem paths, secrets, tokens: small, bounded, isolatable. They live in gitignored config / env. In prose we always write placeholders:

Real thing	Placeholder you write
A tailnet host	<host>.<tailnet>.ts.net
A tailnet IP	<tailnet-ip>
A personal repo path	<repo-root>

Axis 2 — everything else is content that matures

Nothing is “secret.” Raw work just isn’t done. The same gradient above is reused as the publish-readiness axis: we surface what has cooled and settled.

---

The three rules

1. Infra/secrets = config + an automated guard. Keep machine specifics in gitignored config; write placeholders in prose. A guard (scripts/check-sensitive.mjs) rejects any commit — and any CI run — that contains a tailnet host, a Tailscale CGNAT IP, a real personal path, or a key/token signature. The patterns are generic (no real value is hardcoded), so the guard leaks nothing and nudges you toward the placeholder convention. It’s wired into the pre-commit hook (staged files) and CI (full tree). This is what makes “stay defanged” automatic — by construction, not by memory. The guard scans the current tracked tree; it does not prove that older Git history, release artifacts, or external deployment inventories are clean.

2. Maturity is the publish line — framed as readiness, not secrecy. We publish the cooled zones (02-learnings, 03-reference, the concept docs) and the 01-working reasoning trail — the decisions and trackers, the exploration. We hold back 00-inbox, because it’s raw and pre-synthesis, not because it’s private; it gets promoted or discarded, never shipped. Also held back: the red-team security analyses (*security* / *threat* / *defang* notes) — published, they’d be a map of open holes. That’s a security call, distinct from candor.

3. CLAUDE.md / AGENTS.md / skills = defang once, then stay clean via rule 1. They’re authored config, public-safe once scrubbed. We summarize and link them under Agent config; the guard keeps them clean afterward.

---

Public website vs public repository

Publishing a reviewed static build or container is not the same action as publishing the source repository. A deployment platform may read a private repository through scoped provider access while the website is public; only the built artifact is exposed.

Changing repository visibility exposes the tracked tree and reachable history. Treat that as a separate reviewed release: inspect tracked-ignored files, scan all history with an approved history-capable secret scanner, review Actions/releases/LFS and working documentation, remove private operational references, rotate anything ever committed, and verify the exact candidate from a fresh clone. Public documentation describes trust boundaries with placeholders—not the operator’s actual hostnames, identifiers, routes, key paths, certificate layout, or credentials.

---

What this yields

Day to day, you stop asking “is this safe to expose.” You write content with placeholders, the guard backstops infra and secrets, and you publish what you promote. The only things deliberately held back are the raw inbox (not done) and the red-team docs (security). Everything else — the reasoning trail included — can live here, behind a click, and it stays defanged on its own.