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

TL;DR: Cronos — 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.

What Cronos is, in one paragraph

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.

What's new in v2.1

🗓️ D1–D5: cycles decoupled from the calendar

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.

⛔ The Cycle Chaining Limit (new Mandate 4)

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.

📟 The Daily Pulse

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.

🚧 Gate hardening

• Gate 1 — amendment taxonomy. Plan changes are now classified Material / Verification-fix / Cosmetic, and only Material re-arms human approval. Our approval gate was firing on typo-level rows; gates that cry wolf stop being respected. Plans over ~20 KB also get a ≤2 KB session-start digest — fresh agent contexts shouldn't re-read a 32 KB plan every morning.
• Gate 2 — mandatory at Medium+ risk. Validator ≠ Implementer, no exceptions without a written, time-bounded deviation. The one cycle that ran solo shipped its two riskiest changes untested-by-anyone-else and paid for it across the next two cycles. Plus a new fresh-eyes audit step between "tests pass" and demo — with the counter-rule that audit findings are claims to verify, not facts (one audit confidently "found" a race condition that didn't exist).
• Gate 3 — named explicitly. The agent never pushes, merges, or opens PRs. Release is human-owned.

🧪 Verification standards (each one is a scar)

• Proven-red regression tests: a regression guard that's never been observed failing counts as nothing. Re-break the bug, watch red, then trust.
• Explicit type-check gate: a parallel test runner silently dropped a compiling-broken suite and reported "94 passed" on a red build. Verify command is now build:check && jest --runInBand, and any suite failure with zero failing assertions is treated as a compile error.
• Loud-fail parameters (no silent defaults), just-in-time construction (no endpoints scaffolded from the spec before a caller exists), narrow-scope formatting, and a sibling-repo check before designing any external integration — proven in-org code beats web research; it reversed one of our integration designs before a line was written.

🔁 The Recurrence Rule (new Mandate 6) — my favorite

Any lesson that appears in two consecutive retros must 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.

🧠 Learning propagation — the new second layer

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.

🤖 Run it with Claude Code

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.

📁 Plus

• New cycle-folder templates: kickoff (with hot spots that tell the Validator where to attack), Mission Control plan, prompt log, ADR log, validation report, retro.
• A complete anonymized worked example cycle in examples/ — plan through retro, including a mid-cycle descope and a "Shipped with conditions" release.
• Four-state release decision (adds Shipped with conditions — because that's what half of real releases are).
• Roles simplified to three: PM / Implementer / Validator.
• Updated paper: Cronos_Framework_v2.1.pdf with a new Part D covering all of the above, D.1–D.10.

Upgrading from v2.0

1. Swap weekday language for D-days in cycle docs.
2. Name a Validator ≠ Implementer on anything Medium+ risk.
3. Adopt the amendment taxonomy in active plans.
4. Append the new hard rules to your .cursorrules (never amend commits, never commit .env, narrow formatting, one concept per change).
5. Start the Daily Pulse — and schedule the first Technical Health Cycle before anyone hits three chained cycles.

Get it

→ 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?