> ## Documentation Index
> Fetch the complete documentation index at: https://docs.flowdeck.studio/llms.txt
> Use this file to discover all available pages before exploring further.
# Coding Standards
> The engineering rules FlowDeck holds every agent session to, and how to change them
A capable model already writes reasonable code. What it does not do reliably is stay
inside the change you asked for, ship the test with it, keep your docs honest, or avoid
the handful of Apple mistakes that only show up on a slow device.
Coding Standards are the rules FlowDeck can add to the instructions of
every agent session in the app, so you stop repeating them in chat. They apply
to code sessions, Plan sessions, and every Team role, including the QA Reviewer
and UI Designer.
**Every standard starts on by default.** After the first substantial Swift turn
in an Apple project, FlowDeck presents that recommendation with the full set
enabled. Turn its switch off to opt out, or fine-tune the set later in Settings.
## Where to change them
**Settings ▸ AI Workflows ▸ Coding Standards.**
Every rule has its own switch and an info button showing the exact text FlowDeck adds to
the agent's instructions. Nothing is hidden from you, and turning one off removes it from
the prompt entirely. There is no separate baseline engineering-rules block underneath
your selection. There is an **All standards** switch at the top of the page, and each
section has its own, so you can turn off a whole category in one click.
The first time an agent does real Swift work in an Apple project, meaning a couple of
files and a diff worth reading, FlowDeck recommends the standards with one switch.
That is the only time it interrupts you. The switch starts on and saves immediately;
turn it off to opt out. The choice takes effect from your next session, so sessions
already running are not changed.
## What they cover
Changes only what you asked for, debugs from evidence instead of guesses, and tells you honestly what it changed and what it actually verified.
Ships tests with behavior changes, tests observable outcomes instead of private implementation, keeps refactors behavior-preserving, justifies new dependencies, and leaves your commits, comments, and docs clean.
Never publishes state during a view update, keeps continuous animation off the view graph, owns every task it starts, labels controls, and writes tests that can actually fail.
## Why these and not others
Every rule in the catalog has to clear two bars.
**It has to change something.** A rule that restates what a current model already does is
not included, because it would cost context on every session and change nothing. Telling
an agent to write clear code is wasted breath; telling it not to publish state during a
SwiftUI view update is not.
**It has to be a principle, not a preference.** These are written to be things a working
engineer would agree with regardless of how their team operates. Where a genuine choice
exists — test-first or implementation-first, coordinators or native navigation, one
composition root or a container — the standards defer to what your project already does
rather than picking for you.
That matters because you remain in control of the set. A standard that argues with
your codebase is worse than no standard, and every rule can be disabled in Settings.
## If you already keep your own rules
If you maintain a detailed `CLAUDE.md`, `AGENTS.md`, or a skill, expect some overlap.
These standards stay general precisely so they sit underneath your own instructions
rather than fighting them, but on a specific enough setup a contradiction is possible.
When that happens, turn the offending rule off in Settings. Your own file should win,
and switching one off removes it from the prompt completely.
## The Apple rules
Seventeen of the rules only apply to Apple projects, and FlowDeck leaves them out of the
prompt entirely when the session's project is not one. They are the highest-value part of
the catalog, because they cover what a model is good at skipping — the work that has no
effect on whether the demo runs, and every effect on whether the app survives contact
with a real device.
**Crash safety.** Force unwraps, force casts, and `try!` are how a model gets past a
compiler complaint, and how your app dies in someone's hand.
**Memory and lifetime.** Retain cycles from escaping closures, full-resolution images in
a scrolling list, unbounded caches, tasks that outlive the screen that started them.
**Every state, not just the happy path.** Loading, empty, failure, offline, permission
denied, and content longer than the test data. A screen built for the successful case is
finished for the demo, not for the user.
**Sensitive data.** Tokens in the Keychain rather than `UserDefaults`, no secrets in
source, nothing personal in logs, and permission prompts asked at a moment that makes
sense.
**Layout that survives real devices.** Dynamic Type, dark mode, safe areas, the keyboard,
tap-target sizes, and translated strings that are twice as long as yours.
**SwiftUI correctness.** Never publishing state during a view update, keeping continuous
animation off the view graph, and tests that can actually fail.
Switching an Apple rule on in a Rust or TypeScript repository costs nothing and changes
nothing. The gate is the project, not the setting.
## What they cost
Each rule adds its text to the system prompt of every session. The Apple rules — the
larger half of the catalog — are only spent in Apple projects.
If you want that back, turn off the ones you do not need. The catalog is deliberately
small for this reason: everything in it earns its place, or it would not be there.
## When changes take effect
The prompt is composed when a session starts or is restored, so a change applies to your
next session rather than one already running. Start a new session to pick it up
immediately.