Which settings are this fork's

Nothing in the running program said which behaviour is this fork's and which is upstream Tabby's — every settings row is drawn identically either way. Two switches on the Upstream page mark them: a filled diamond for a setting upstream does not have, and a hollow one for a setting it has but gives no control for. The list is recomputed from git rather than written by hand, and a checker fails when it drifts.

Nothing in the running program said which behaviour is this fork's and which is upstream Tabby's. Every row in the settings window is drawn identically whether Tabby shipped it or this fork added it, which makes the divergence invisible at exactly the moment you are deciding whether to change something.

Two switches on Settings → Upstream, both off by default. One marks every setting upstream does not have with a filled diamond; the other marks, with a hollow one of the same size, a setting upstream does have and gives no control for. Each switch's own row carries the mark it controls, so turning it on previews itself.

• upstream.showForkMarks: false

  The filled mark: this setting does not exist upstream.

• upstream.showConfigOnlyMarks: false

  The hollow mark: upstream has it and hides it in config.yaml.

• The list is derived, not judged: the keys this build declares minus the keys master declares, recomputed from git by scripts/dev/check-docs.mjs's sibling, check-fork-marks.mjs, which fails when the checked-in list disagrees in either direction.
• A page that is entirely ours is marked once on its entry in the list, not on each of its rows — six such pages carry about eighty-five rows between them, and marking all of them would be noise. On shared pages that leaves exactly three marked rows.
• The hollow mark was given something to mark: appearance.cycleTabs and terminal.detectProgress are real upstream settings with no control anywhere, and now have one.
• The marks are drawn in CSS rather than typed as a character, so they do not depend on font coverage or on this file's encoding, and the two are guaranteed the same size.

• Settings where this fork only changed the default — vertical tabs, the colour-scheme mode, the contrast floor, the Windows font — are deliberately not marked. They exist upstream, so they are not ours; the rule is a difference of keys.
• The marks are CSS pseudo-elements, which means they are not in the accessibility tree. The meaning lives in each switch's description instead, and a translator cannot drop the glyph the way the Windows Terminal fork's resource-file approach allows.
• The sweep that finds settings with no control is a review gate, not an oracle. It is wrong in both directions — a setting reached by a computed key looks unexposed, and a read in an *ngIf looks like a control — so every entry was confirmed by hand, and the cases it cannot reason about are named with their reasons rather than left to look like missing marks.