Frameworks become maintenance debt the moment they stop updating. CRAFT versions itself with the same recipes you use on your own projects, ships releases through its own pipeline, and pulls updated files into your projects one at a time. The framework that does versioning is versioned by its own system.
Last week we covered CRAFT’s branding framework — the seventh folder where brand identity lives and gets enforced. This week, the closer: how CRAFT keeps itself current, and how those updates reach your projects.
The Stale Framework Problem
Every framework you adopt has the same lifecycle. You install version 1.0. You learn it. You build on it. Six months later, version 1.4 exists with patterns the community has settled on — different folder names, new recipes, deprecated functions. Your project is on 1.0.
You have three options. Freeze on what you started with and accumulate a gap between your project and the world. Do a manual sync that takes a weekend and risks breaking what works. Or skip the update and revisit next quarter.
None of these scale. The “next quarter” version of you is busy. Manual syncs are where projects go to stall. And freezing means you’ve turned the framework into a fixed artifact instead of living infrastructure.
CRAFT’s answer is to make updating cheap enough that you actually do it.
The Canonical Version Format
Every CRAFT framework file carries a version string in the same shape:
v.b{NNNN}.t{YYYYMM}.{NN}a
Build number · Date stamp · Increment · Status suffix
The session init recipe that loaded your handoff at the start of this session, the Brand Kit Builder you read about last week, the folder structure spec, the cookbook indexes, the lessons learned templates — all carry the same format.
This sounds like bookkeeping, but the format eliminates a question that used to take time: which version of this file is current? The answer is encoded in the filename. No comparing modification dates, no opening files to read headers, no guessing.
Seventeen framework files were migrated to this format in handoff H070. The migration itself is a footnote; what matters is what it makes possible.
The Versioning Recipes (VOL5)
The framework that handles version numbers is itself nine recipes (RCP-CWK-ADM-050 through 058):
Nine recipes for what used to be ad-hoc bookkeeping. Each runs the same way every time, on every project that uses the framework.
The Release Pipeline (VOL6)
Versioning produces an updated framework on disk. Releasing makes it available to others. CRAFT’s release pipeline is four recipes:
Distribution Manifest Manager is the source of truth for which files are production-ready — a single manifest that prevents accidental shipping of internal-only files (LL-125). Release Notes Generator scans the handoff history and produces release notes with change classification and TLDR summaries. Release Builder assembles production packages using manifest-driven staging. GitHub Release Publisher publishes to GitHub with sandbox-aware fallback — auto-DRY_RUN mode when the GitHub CLI isn’t available (LL-130).
The full path from “I have an updated framework” to “it’s published on GitHub” — automated, repeatable, audit-trailed.
The Update Pull
The other end of the pipeline is your project. When CRAFT updates a framework file, how does that change reach the projects already using it?
Cowork’s sandbox blocks the obvious answer (git pull) — it can’t overwrite files that already exist in the working tree (LL-001). Earlier framework versions treated this as a problem. CRAFT treats it as a feature.
Updates pull one file at a time using git fetch monorepo (which writes to .git/ without touching the working tree) followed by git show monorepo/main:{filepath} > {filepath} (which retrieves a single file’s contents). The Version Checker recipe surfaces what’s out of date; the File Puller fetches the specific files that need updating.
You don’t sync the whole framework. You sync the files that changed. The cost of staying current drops from a weekend to a minute.
The Recursive Proof
The versioning system versions itself. Every recipe in VOL5, VOL6, and the VOL7 promotional set carries a canonical version string. When the versioning system itself gets updated, it’s versioned and released using the recipes it ships.
This isn’t only elegance. It’s the test that proves the recipes work on a non-trivial subject. A versioning system that can’t version itself is a versioning system you wouldn’t trust on your own projects. CRAFT’s can, and does.
8 Weeks in 8 Sentences
The capability spotlight at a glance:
Each one builds on the previous. Memory needs files; files need a layout; the layout needs a brand layer; the brand layer needs to stay current as CRAFT itself updates. The whole stack is a stack because each piece holds up the next.
Why This Matters
Frameworks are infrastructure. Like all infrastructure, they have to maintain themselves or they become maintenance debt. The frameworks that survive are the ones where staying current costs less than diverging.
CRAFT moves the cost of currency down to one minute per affected file — and it does it using the same recipes that ship the rest of the framework. Versioning isn’t a side concern. It’s how CRAFT works.
