Code-driven

Behavior that lives in a dashboard or a wiki page has no audit trail, no rollback, and no way to reproduce locally. The next engineer discovers it by accident — or not at all.

The rule: if it affects how the system behaves, it lives in the repository.

In practice

Assistant prompts — VAPI and Mastra agent definitions live in src/. Changing a system prompt is a PR. It goes through review, has a git history, and rolls back with the branch.

Scheduled and bootstrap jobs — declared in code via BullMQ's job scheduler, not a script that lives in a Notion page and gets run manually on deploy. → Bootstrap jobs

Property type system — adding a field type to the platform is a code change in packages/schemas. The UI picker, validation, and AI tooling follow automatically.

Config — env vars, validated at startup. The shape of what's expected is in code. → Configuration

Firebase rules — checked into the repo. Local dev and CI use the same rules as production.

Where the line is

Data belongs in the database — workspace definitions, records, user content. The distinction: if it changes how the system behaves, it's code. If it's content the system operates on, it's data.

TIP

If reproducing a bug requires a step that isn't in the repo, that step should probably be in code.