How this encyclopedia evolves

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: Not a one-and-done document. The encyclopedia is a LIVING reference that grows from real project work, periodic quality reviews, and AI-assisted writing sessions. Built up to 16/16 sections; from here it stays current via small, ongoing updates.

In plain English

The encyclopedia was built across ~50 focused writing sessions in 2026 — Claude Code + George — going from skeleton (folder structure, glossary seeds, master files) to 16/16 sections complete + 12 how-tos + 8 reading paths + 6 cheat sheets + 11 common-error references + 12 decision frameworks + ~180 textbook entries.

But “complete” doesn’t mean “done forever.” A reference about modern web + AI development has to KEEP UP. Topics change. New tools emerge. Old patterns become deprecated. The encyclopedia is designed to evolve.

This entry describes:

How the encyclopedia got to its current state
How it stays current going forward
Who can add or change content
The cadence and discipline that keeps it useful

How it got here

The build pattern that worked, across the 34 sessions:

Session 0 (skeleton) — folder structure, README, CONVENTIONS, INDEX, ROADMAP, 26 letter files in glossary, ~30 starter glossary entries, 3 exemplar entries (HTML, JWT, Deploy-Vercel how-to), section index files.
Sessions 1-30 (content writes) — focused batches of 1-5 entries per session. Each session:
- Re-read CONVENTIONS.md + quality memory
- Re-read project-encyclopedia-current-state memory for context
- Spot-checked an exemplar entry to recalibrate quality
- Picked a coherent cluster (often a section batch)
- Wrote 1-5 substantive entries at the iron-clad quality bar
- Updated section index, ROADMAP, CHANGELOG, current-state memory each turn
Session 16ish — quality elevation — explicitly raising the bar from “good” to “iron-clad gold standard,” and applying a periodic-audit pattern to early entries.
Sessions 30-34 (closing optional sections) — CS foundations, broader tech bonus, navigation meta.

The pattern that scaled: SMALL BATCHES + STRICT QUALITY + INDEX UPDATES EVERY TURN. Trying to write 20 entries in one session always degraded quality. A soft cap of ~5–10 entries per turn — used as a quality-protection tool, not a rigid number — preserved consistency. The cap flexes when quality genuinely holds; it stops sooner when quality starts to slip. Quality is the rule; the cap is just a tool for protecting it.

How it stays current

The encyclopedia has cycled through several phases: build mode (sessions 1–34, getting to 16/16), maintenance + audit mode (sessions 36–42, the back-link sweep), then a second bonus-content build-out (sessions 43–50, adding cheat sheets / common-errors / decision frameworks / Bible Quest walkthrough / protocol formalization). It’s now in a sustained reactive-growth mode. Updates happen for one of three reasons:

1. New topics emerge

Examples of “new” topics that didn’t exist a few years ago: MCP (Model Context Protocol), QUIC, Vercel Fluid Compute, Cloudflare Durable Objects. As the field shifts, new entries get added to relevant sections.

The trigger: George hits something he doesn’t recognize while working on a project, or while reading. Adds an entry (or asks Claude to). Updates the section index. Adds to the glossary.

2. Existing topics evolve

🟦 LIVING entries especially need refreshes. Examples:

Next.js version bumps (Next.js 16 → 17 will have differences)
Claude models (new Sonnet / Opus releases)
Vercel platform features (Fluid Compute came in 2025; will keep evolving)
Pricing (free tiers change)

The trigger: George notices the entry is stale (its “Last updated” date is old + facts have moved). Updates the relevant facts. Bumps the “Last updated” date. Keeps the 🟩🟦 status.

3. Quality drift

Even with discipline, entries can drift from the quality bar over months:

Cross-links go stale (target entry moves or is removed)
Sources become 404
Code examples use deprecated syntax
Gotchas mention tools that no longer matter

The trigger: periodic audit. Re-read 3-5 random entries; verify they meet the current bar; update where needed.

Who’s involved

This encyclopedia is George’s personal reference. Roles:

George — owner, director, reviewer, principal stakeholder, final decision-maker on what’s in the encyclopedia, what gets added, what gets changed, what the standards are.
Claude Code — primary writer, collaborator, executor under George’s direction. In practice, Claude does the bulk of the actual writing in response to George’s direction; George reviews, approves, redirects, refines.

(Earlier framing called George “primary author” and Claude “secondary author” — that was generous to George and undersold how much of the actual writing Claude does. The corrected framing above reflects reality.)

In principle, the encyclopedia is portable: it could be:

Pushed to a Git repo (it’s already a folder)
Shared with others (the content is general-purpose, not Bible-Quest-specific)
Forked + customized for someone else’s stack

Practically, it’s a private reference that lives on George’s machine + Claude’s session memory.

The discipline that keeps it useful

A handful of rules, applied consistently:

Rule 1: Iron-clad quality bar for every 🟩 entry

The full bar lives in the feedback-encyclopedia-quality.md memory file (in Claude Code’s memory system, not in the encyclopedia itself). Key points:

Required sections present and meaningfully filled (per the format — textbook entries have 7 default sections; cheat sheets, common-errors, decision frameworks have their own shapes)
Specific, topic-relevant gotchas (5–15 typical; more or fewer as the topic genuinely warrants — quality > quantity)
Cross-links real and badged
At least one authoritative source
Soft per-turn cap of ~5–10 substantive entries as a quality-protection tool (flexes when quality holds, stops sooner when quality slips; never compromise quality for count)

Rule 2: ROW-BY-ROW edits on index files

When upgrading an entry’s status, edit only that row in the section index. NEVER use replace_all — it overpromises stubs as complete.

Rule 3: Update trackers every turn

Each session ends with:

Section index updated (row-by-row)
ROADMAP counts refreshed
CHANGELOG entry added (newest at top)
current-state memory file updated

This keeps the state honest. A drift between “what files exist” and “what trackers say” causes confusion months later.

Rule 4: Periodic audits

Every few sessions (or when George asks), re-read 3-5 older entries to verify they still meet the bar. Update what’s drifted. This caught real issues in earlier sessions (entries marked 🟩 that had thin gotchas, stale cross-links, etc.).

Rule 5: Don’t write what’s already there

Before starting a new entry: search the encyclopedia. If a similar one exists, decide if you’re writing a NEW entry or upgrading the existing one. Duplicates are worse than gaps.

When NOT to add to the encyclopedia

Some things explicitly don’t belong here:

Project-specific code or config. Bible Quest’s specific Supabase schema lives in the Bible Quest repo’s AGENT_GUIDE.md, NOT the encyclopedia. Encyclopedia is general-purpose knowledge.
Time-sensitive ephemera. “Last week I hit this bug” doesn’t go here. The bug’s RESOLUTION + general lessons might warrant an update; the bug itself doesn’t.
Internal personal opinions on people / companies. “I don’t like X’s design” doesn’t belong; “X’s design has these specific quality issues” might (in a gotcha).
Anything that’s already in the Claude Code memory system. The memory files cover personal preferences, project state, conversation history. The encyclopedia is for general knowledge.

The split: encyclopedia = “what concepts mean and how things work.” Memory = “what George likes, what Bible Quest does, what came up last week.”

The “feed-forward” pattern

A real practice: when George hits something new while working, he often:

Resolves the immediate problem (with Claude’s help)
Decides: “is this a one-off, or a general lesson?”
If general: writes (or upgrades) an encyclopedia entry
Bible Quest-specific: adds to Bible Quest’s PROGRESS.md instead

This bidirectional flow keeps the encyclopedia fed by real work AND fed back into future projects. It’s not just a passive reference; it’s an active learning system.

The 🟦 LIVING refresh protocol

For entries marked 🟦 (Vercel, Next.js, Claude models, etc.), an explicit refresh cadence helps:

Every 3-6 months — skim the entry; check version numbers, pricing, named features
On a major version bump of the underlying tool — refresh fully
When a fact you used recently was different from what the entry says — fix immediately

This isn’t automated yet (would need scheduled audits). It’s a discipline + a memory.

The “refresh living entries” pass was implemented in session 43 — the 5 highest-priority Section 10 LIVING entries (claude-models, claude-api-overview, mcp, multimodal-vision-audio, fine-tuning-vs-context) were verified current against 2026-06-21 reality. No refresh edits were needed at the time. The protocol now lives in the back-link bump section of CONVENTIONS.md and the maintenance protocol section of status-labels.md. Next scheduled review: 2026-09 to 2026-12 (unless a major model/product release happens sooner).

What the encyclopedia ISN’T

To be clear about scope:

Not a textbook. It doesn’t replace deep learning resources (Eloquent JavaScript, the SICP book, etc.). It’s a REFERENCE for someone who knows the basics or is willing to learn elsewhere.
Not a course. No exercises, no tests. Reading paths are the closest analog but they’re curated lists, not graded curricula.
Not a personal journal. Notes about specific projects, debugging sessions, or conversations go elsewhere.
Not a product manual. Vendor docs are authoritative for specific products. The encyclopedia summarizes + adds value through plain English + cross-linking.

It IS:

A plain-English reference covering modern web + AI development
Organized for fast lookup + structured learning
Maintained over time
George’s primary reference for the topics in scope

What’s been built since the original 16/16

Everything the original “future direction” list flagged has now been shipped (sessions 44–50):

Cheat sheets — 6 shipped (Git, npm, Vercel CLI, gh CLI, Supabase CLI, PowerShell)
Common-errors references — 11 shipped (build, Git, Supabase, browser, TypeScript, Vercel runtime, Node.js, OAuth, CSS/Tailwind, CI, performance)
Decision frameworks — 12 shipped (Server/Client, merge/rebase/squash, RLS, auth, tiers, TS strict, styling, tests, refactor, fetch/actions, self-host/SaaS, monorepo)
Bible Quest origin walkthrough — shipped as a case-study reading path (8th reading path total)

Future direction (reactive only)

The encyclopedia is now in reactive-growth mode. Future content emerges from real need:

New entries when George hits a genuinely novel concept in project work
LIVING entry refreshes every 3–6 months or when a major underlying tool release happens
Additional how-tos / reading paths / cheat sheets / common-errors references / decision frameworks only when a real pattern surfaces in actual work
Case-study walkthroughs when new substantial projects ship

No proactive build-out is planned. The bonus-content arc closed at session 50 with all originally-flagged categories filled to natural completion.

Sources

This entry is meta. It documents the encyclopedia’s own working model.

Tech & AI, Explained

Explorer

how-this-evolves