# Config mode (`F12`)
The Config mode is one surface for every setting the TUI can change. It opens
with **`F12`** (or by clicking its entry in the vertical navigation) and is one of
the six top-level modes; the shell is described in
[navigation](navigation.md), and the underlying `tix.toml` keys in
[configuration](configuration.md).
The surface has a **section rail** on the left and the active section's rows on
the right:
| Dashboards | the active board's columns, its display settings, and the editor and viewer overrides |
| Cycles | every cycle, with its issue count |
| Milestones | every milestone, with its issue count |
| Types | the `custom_types` list `tix lint` checks an issue's `type:` against |
| Attributes | the effective attribute list: the declared `[custom_attributes].keys`, or the built-in attributes tix models when none are declared |
The **Types** and **Attributes** sections show one row per entry; **`n`**
prompts for a new name and **`x`** removes the selected one. Both persist to
`tix.toml`: adding a type to a project that never declared `custom_types`
materializes the default set plus the new name, and adding an attribute to a
project that never declared `[custom_attributes]` materializes the built-in
attributes plus the new name. A blank or duplicate name is refused with a
message rather than written.
## Moving around
The surface is two panes: the **section rail** on the left and the active
section's **body** on the right. One pane has the focus at a time — its border
is accented, the other is dimmed — and the movement keys follow that split,
exactly as they do on the board and in the Cycle listing:
- **`h` / `l`** (or **`←` / `→`**) — move the focus between the rail and the
body, clamped at the ends. The rail starts focused.
- **`j` / `k`** (or **`↓` / `↑`**) — move inside the focused pane: the selected
section (Dashboards / Cycles / Milestones / Types / Attributes) when the
rail is focused, the row cursor in the active section's body when the body is
focused. Changing section puts the new section's cursor back at its first row.
- **`Enter`** — from the rail, step into the body; in the body, activate the
selected row (toggling a column or display setting, editing a cycle or
milestone). **`Space`** keeps its dashboards meaning in the body: it toggles
the row under the cursor.
- **Click** a section in the rail to focus the rail and switch to it, or a row
in the body to focus the body and select that row. Clicks run the same
actions the keys do.
- **`q` / `Esc`** — leave the Config mode for the board.
## Dashboards
The dashboards section is the former settings modal, unchanged in meaning:
- **`Space`** on a column row toggles whether that column is hidden on the
board; once the body is focused, `Enter` does the same. Both run on the
cursor row.
- The three **display rows** below the columns control title wrapping, the title
line limit, and card ordering; `Space` flips or cycles them (as does `Enter`
once the body is focused).
- The **`Editor:`** row sets the `$EDITOR` override used by `tix edit`. An empty
value restores the automatic editor resolution.
- The **`Viewer:`** row sets the `viewer` used by the board's and the detail
pane's **`v`** key, which opens the issue read-only in that program. The
default, `auto`, probes `mdterm`, then `batcat`, then `most`, then `less`,
then `more`, in that order, and uses the first one installed; any other value
names the viewer directly. An empty value restores the auto chain. The row
shows what `v` will actually run — `Viewer: mdterm (auto)` when the chain
resolves, or the configured name when the `viewer` key is set.
- **`a`** adds a column, **`n`** adds a board, **`e`** renames the current board,
**`x`** deletes it (after a confirmation that reports how many issues reference
it — zero today, because nothing in issue frontmatter names a board).
- **`Tab` / `Shift+Tab`** (or `[` / `]`) switch which board is active.
The board's own commands remain on the board (`F1`); the Config mode edits the
board you are on.
## Cycles and milestones
Choosing the Cycles or Milestones section reuses the same planning list the
`m` management surface shows, with the reference count on every row:
- **`n`** — create; the create form takes a name, description, and dates.
- **`e`** — edit the selected row; changing the name renames the record.
- **`x`** — delete, after a confirmation that names the number of referencing
issues. Deletion never modifies the issues that referenced it.
Renaming a cycle or milestone **cascades**: every issue that references the old
name is rewritten to the new one, and no other issue field changes.
## Where changes are stored
| Board columns, display settings, card order | `docs/boards/<name>.md` |
| Cycle name, description, start/due date | `docs/cycles/<name>.md` |
| Milestone name, target date, description | `docs/milestones/<name>.md` |
| Anything else (e.g. the editor or viewer override) | `tix.toml` |
`tix.toml` remains the single authoritative file for everything that is not a
per-record metadata file. When a store directory does not exist, the matching
`tix.toml` tables are still read, so an existing project keeps working with no
migration; the first write of a record file switches that store over. See
[navigation](navigation.md#project-metadata-stores) for the store layout.
Directories are created lazily: reading never creates one, and adding a second
board or cycle is what creates `docs/boards/` or `docs/cycles/`.