## Problem

Introduced by `Stop an installed theme from running code`
([basecamp/omarchy@ef6d9e6](https://github.com/basecamp/omarchy/commit/ef6d9e6605b121df15bf310e630e04f0c1119fc8),
PR [#7884](https://github.com/basecamp/omarchy/pull/7884), merged 2026-08-23,
shipped as omarchy 4.0.0.r1803).

`omarchy-theme-set` drops every `.lua`, terminal config (`kitty.conf`,
`foot.ini`, `ghostty.conf`, `alacritty.toml`) and `vscode.json` from themes
installed from a git repo, then regenerates them from
`$OMARCHY_PATH/default/themed/*.tpl`.

That's the right security call for code, but it also means a theme author
cannot ship a Neovim integration at all — every repo theme gets the same
generic aether render, even when the author maintains a matching colorscheme
plugin. Community themes on omarchy.org therefore can never feel complete:
bar, terminals' palettes, and shell surfaces follow the theme, but Neovim,
terminal niceties (e.g. inactive border colors), and the VS Code extension
silently fall back to stock.

## Theme updates are broken by the same change

`omarchy theme update` only runs `git pull` inside the clone — it never
re-stages, so pulled changes stay invisible until the user happens to
re-select the theme. And when a re-stage does happen, the new filter strips
the same `.lua` / terminal configs / `vscode.json` all over again. Net
effect: a repo-installed theme can't deliver an update end-to-end either —
neither automatically nor through the supported flow.

Whatever lands from this proposal should also make `omarchy theme update`
re-stage (or simply invoke `omarchy-theme-set`) after pulling, and the
staging rules should leave room for themes to ship their integrations, so
updates actually reach the desktop.

## Proposal

Let an installed theme carry a `themed/` directory of templates:

```
~/.config/omarchy/themes/<name>/themed/neovim.lua.tpl
~/.config/omarchy/themes/<name>/themed/kitty.conf.tpl
```

`omarchy-theme-set-templates` already renders templates through pure sed
color substitution (`{{ key }}`, `{{ mix ... }}`, gradients). Adding one
glob to `template_files` is enough:

```bash
template_files=("$USER_TEMPLATES_DIR"/*.tpl "$TEMPLATES_DIR"/*.tpl)
```
→ include `$NEXT_THEME_DIR/themed/*.tpl` (the staging step already copies
subdirectories of repo themes verbatim, so no new trust boundary is crossed
to get them there).

Precedence stays: machine override > theme > built-in. The existing
"don't overwrite files already staged" rule keeps user-written themes
authoritative.

## Optional hardening

If arbitrary template output feels too open for stranger-supplied themes,
gate it behind explicit consent at install time (a gum prompt: "This theme
overrides N app configs — allow?"), persisted as a stamp file next to the
clone.

## Motivating example

Noir / Noir Dawn (https://github.com/tahadx/noir.nvim) ship a matching
Neovim colorscheme; today there is no way to deliver it through
`omarchy theme install`.