Cronos Framework v2.1 is out: what changed and why every change cites a production cycle

Cronos Framework v2.1, an open-source methodology for human-validated vibe coding, has been released with changes grounded in production evidence from four full cycles at a regulated SaaS company. The update introduces calendar-independent five-day cycles, a mandatory Technical Health Cycle after three delivery cycles, and an AI Toolkit for capturing learnings. It also formalizes a behavioral skill for Claude with six operating modes and enforces that any lesson appearing in two consecutive retros must be converted into an enforced mechanism.

TL;DR: Cronos https://github.com/OvidiuMM/cronos-framework — my open-source methodology for human-validated vibe coding — just shipped v2.1 . It's the first release grounded in production evidence: four full cycles on real systems at a regulated SaaS company, and every amendment in the release cites the cycle that forced it. Here's the tour. Five-day engineering cycles where an AI agent does the heavy implementation and humans hold the gates: a plan approved before any code Gate 1 , an independent human validation before any ship Gate 2 . v2.0 defined the loop. v2.1 fixes what production broke — and adds the layer v2.0 was missing. The rhythm is no longer Monday–Friday. A cycle is five relative working days — D1 through D5 — starting any day; weekends and holidays pause the clock. A Thursday start runs Thu, Fri, Mon, Tue, Wed. Kickoff on D1, Path Sync D2, verification D4, demo + release decision D5. The fixed five-day length stays: calendar independence is not permission to stretch to six. Why: "Monday kickoff" turned out to be a constraint with zero benefits — cycles ready on a Wednesday sat idle, and holidays broke the terminology. Max 3 consecutive delivery cycles per person. The next week is a mandatory Technical Health Cycle — and that cycle is the scheduled owner of the debt every retro defers. Why: Cronos blocks the implementer's calendar 100%. Chain that for a month and you get a tired, disconnected human operating your quality gates. Meanwhile, our E2E-testing gap was flagged in cycle 1, deferred in cycle 2, and still open in cycle 3 — because "Technical Health Cycle" existed in zero calendars. One rule fixes both: rest and debt repayment, same week. Three lines, async, end of each cycle day: Landed: row 6 green webhook signature verification Next: row 7 — retry queue Friction: none Explicitly not a standup — no meeting, no attendance. Two jobs: keep the deep-focus human visible to their team, and act as a soft tripwire — the same Friction: line two days running triggers a PM check-in before the hard reset trigger 4 hours in a loop fires. build:check && jest --runInBand , and any suite failure with zero failing assertions is treated as a compile error.Any lesson that appears in two consecutive retrosmust be converted into an enforced mechanism — a guardrail entry, a CI check, or a skill — in the following cycle. Why: cycle 1's retro said, in bold, "scope your formatter." Cycle 2's team read it and ran the repo-wide formatter anyway. Written lessons don't propagate; machinery does. A twice-written lesson is a process bug. v2.1 formalizes the AI Toolkit : a versioned repo where cycle learnings graduate into prompts/ threshold: 1 proven use , skills/ threshold: a recurred lesson , and knowledge/ threshold: seen in 3 cycles — so first-cycle noise doesn't calcify into doctrine . Promotion runs only against closed cycles — and a cycle isn't closed until its retro is filled, which quietly fixes the "retro never gets written" problem too. This also patches the theory: the efficiency model's speedup factor is now S n = S₀ + κ·K n — it grows with the toolkit's asset stock. Without the layer, K = 0 and your speedup flatlines. Handy heuristic from the doc: if you'd write a CLI for it, it's a skill; if it's a paragraph you keep retyping into chat, it's a prompt. And stamp every saved prompt with the model you tested it on — prompt libraries rot silently as models change. New in registry/claude-skills/cronos/ : a drop-in behavioral skill with six operating modes Bootstrap → Mission Control → Implementation → Verification → Validation → Close , the gates enforced in-session, a failure-modes catalog distilled from the retros, and six paste-ready phase prompts. examples/ — plan through retro, including a mid-cycle descope and a "Shipped with conditions" release. Cronos Framework v2.1.pdf with a new .cursorrules never amend commits, never commit .env , narrow formatting, one concept per change .→ github.com/OvidiuMM/cronos-framework — MIT, release v2.1 . The full amendment rationale with per-cycle citations is in doc/v2.1-amendments.md v2.0 was a hypothesis. Four production cycles were the experiment. v2.1 is the revised hypothesis — and if you run it, your retros are welcome input for v2.2. What broke for you ?