The Rules

FlowForge ships a compact rulebook — the operating system for how work is done. The rules are few, they are universal across every project, and the load-bearing ones are enforced by machine, not memory. This chapter covers the rules you’ll meet daily and the enforcement model behind them.

The universal core

A handful of rules travel with every FlowForge project, no matter the language or stack:

• Rule #5 — Every session runs on a ticket. Your work is tied to a traceable, measurable, billable unit. One right-sized ticket per deliverable.
• Rule #18 — Never commit to main/develop. Feature branch always; protected branches stay clean.
• Rule #3 — Test-driven development on code that matters. Tests first on core logic; judgment, not dogma, on spikes and throwaway UI.
• Rule #33 — No AI attribution in git history. Commits read as professional, human-authored history. (Docs and agent files may credit the assistant; commit messages may not.)
• Rule #12 — Don’t close a ticket without founder approval. Completion is a decision, not a side effect.
• Rule #35 — Reach for the specialist agents when they multiply you. Orchestrate when it pays; execute directly when that’s faster.

There are more (35 in the full set), but these are the ones that shape the texture of a normal day.

Judgment, not dogma

The rules are a discipline, not a straitjacket. Rule #3 asks for tests on code that matters and relaxes the coverage bar on throwaway spikes. Rule #35 says orchestrate when it pays and execute directly when spinning up a specialist would cost more than the work. The point is to make the right call cheap, not to replace thinking with ceremony.

Enforcement: machine, not memory

A rule that lives only in someone’s head is a rule that gets skipped under deadline. FlowForge’s answer is structural enforcement — the rule is true by construction at the point where it matters:

• Hooks check load-bearing rules on every relevant action. Try to commit to main and the pre-commit path stops you; dispatch a ticket down the wrong lane and the dispatch guard refuses it.
• The merge chokepoint structurally refuses a pull request that changes core logic but ships no tests — the TDD gate is enforced, not advisory.
• /flowforge:dev:checkrules runs the full rulebook on demand when you want a complete compliance read.

The principle is colado — “glued”: invariants are made true at the chokepoint, so a closed ticket is an enforced fact, not a hopeful one.

Self-healing over follow-up tickets

Where a rule protects something customer-visible, FlowForge prefers to repair the symptom automatically rather than file a note for later. Stale paths, missing hooks, and config drift heal on install, upgrade, and cockpit start. The founder won’t be there to type the fix, so the system fixes itself.

Why it matters

Rules make speed safe. Because the load-bearing ones are enforced by machine, you get the benefit of the discipline without having to remember it under pressure — and the history you produce is trustworthy precisely because the invariants behind it were never optional.