DEV Community: ovidiu MMG

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

ovidiu MMG — Sat, 18 Jul 2026 19:16:04 +0000

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

Swap weekday language for D-days in cycle docs.
Name a Validator ≠ Implementer on anything Medium+ risk.
Adopt the amendment taxonomy in active plans.
Append the new hard rules to your .cursorrules (never amend commits, never commit .env, narrow formatting, one concept per change).
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?

Introducing Cronos: A New Framework for Human-Validated Vibe Coding

ovidiu MMG — Fri, 19 Jun 2026 15:34:07 +0000

Hey dev.to community! 👋

Over the last few months, juggling my roles as a Project Manager, Scrum Master, and lead for QA, Support, and Documentation has been a wild ride. The sheer speed of "vibe coding"—a paradigm shift where the primary role of the developer transitions from manual code construction to high-level intent orchestration—is incredible. Tools like Cursor, Replit Agent, and Google Antigravity allow us to scaffold entire microservices in minutes.

However, while this transition offers unprecedented generative velocity, it introduces systemic risks concerning architectural integrity, long-term maintainability, and security.

That’s why I’m sharing Cronos (Version 2.0): a new, strategic methodology I’ve formalized for human-validated vibe coding and agentic software engineering.

Real-World Testing & The Multi-Track Approach

We have been rigorously testing this framework with our team over the last three months. The empirical results have been fantastic, tracking closely with the framework's theoretical efficiency models to deliver an almost 4x gain in productivity.

To maintain production stability while achieving this speed, we adopted a multi-track approach. We continue to use standard Scrum for our maintenance track, which handles smaller tasks, support requests, and standard bug fixes. Meanwhile, Cronos is deployed exclusively for our parallel feature track, tackling larger Epics and new feature development. This ensures production stability does not stall innovation velocity.

What is Cronos?

The genesis of Cronos lies in the recognition that traditional Agile methodologies often fail to keep pace with the collapsed feedback loops of AI-driven development. In the current agentic era, the bottleneck has shifted from implementation to validation and strategic alignment.

Cronos reconfigures the software development lifecycle (SDLC) around one-week "Cycles". Each cycle is a burst of high-intensity, AI-augmented creation coupled with a fixed duration of human oversight.

The Core Pillars of Cronos

The Vibe-to-Verify (VtV) Ratio: This metric calibrates the level of human scrutiny based on the risk profile of the component being built. It is calculated by dividing the time spent in the AI generation loop by the time spent in human-controlled quality gates.
The Strict 7-Day Rhythm: Development is organized into distinct, deterministic one-week cycles. This cadence includes a Monday Kickoff, a Tuesday Path Sync, a Thursday QA Sync, and a Friday Demo.
Extra Human Validation: To prevent the "Author's Bias" inherent in vibe coding, Cronos mandates a half-day of review by someone other than the original developer. The team utilizes specific roles—like a Solution Owner (SO) and a Peer Reviewer—to systematically run through logic, architecture, and security checklists.
The 72-Hour Modularisation Mandate: If an Epic is estimated to require more than 3 days of active development, it must be broken down into smaller functional chunks to prevent vibe drift and ensure rigorous verification.

What’s New in Version 2.0?

Version 2.0 extends the original framework with universal scalability guidance, making it applicable to any team, project type, or budget:

Team Size Scaling Model: Adapts the framework's roles and ceremonies from a solo developer tier up to a 10+ person enterprise pod.
The Hallucination Log & Cycle Autopsy: A formalized, time-boxed post-cycle retrospective is used to track AI hallucinations, such as non-existent APIs or logic errors. This log directly feeds your team's .cursorrules and prompt library to harden project-specific guardrails over time.
Regulated Industry Compliance Layer: Additional checkpoints and artifacts are appended for frameworks like HIPAA, SOC 2, and GDPR. This includes mandatory data classification in the PRD, threat model sketches, and automated accessibility scans.
Tooling-Agnostic Tiers: Every phase of Cronos can be executed regardless of your budget, cleanly mapping out workflows for Premium (Tier 1), Mid-Range (Tier 2), and Free/OSS (Tier 3) toolchains.

Why Bother?

Research indicates that while AI can make developers 50x to 100x faster on highly patterned tasks, the overall gain across a project lifecycle typically settles between 7x and 10x due to the complexities of debugging and architectural integration.

Cronos ensures that the creative speed of AI-driven generation is always balanced by the rigor of professional engineering standards. By shifting the developer's role from manual creator to curator and solution governor, we can harness AI as a powerful pair programmer rather than an uncontrolled code generator.

I've open-sourced the full methodology, and I hope people can contribute to it as we all figure out this new era of building software together. You can check it out and contribute here: https://github.com/OvidiuMM/cronos-framework .

(Note: The core framework and real-world testing are all human-driven, but to ensure this methodology is presented as clearly and comprehensibly as possible, I used Gemini 3.1 Pro to help refine and polish the writing of this post.)

Let's discuss in the comments!