feat(tui): base16 theme

[snelling-a]

fixes #8632

[snelling-a]

@rekram1-node thanks for keeping this up to date. is there anything else i need to do to get this reviewed?

[github-actions]

Thanks for your contribution!

This PR doesn't have a linked issue. All PRs must reference an existing issue.

Please:

1. Open an issue describing the bug/feature (if one doesn't exist)
2. Add Fixes #<number> or Closes #<number> to this PR description

See CONTRIBUTING.md for details.

[Nemo157]

How is this base16? A base16 theme would output only the 4-bit ansi color codes to allow the terminal's colorscheme to apply. The base16 standard is about having a more semantic shared understanding of what those colors mean between the application producing them and the terminal rendering them to ensure together they produce something readable.

And really base16 is too limiting, I would love to have a base24 colorscheme for opencode, since that gives the various "grayscale" colors that are important for the UI components like the sidebar.

But AFAICT both base16 and base24 are impossible with opencode right now as it translates 4-bit/256-color ansi color codes into truecolor codes using an internal mapping table.

[snelling-a]

How is this base16? A base16 theme would output only the 4-bit ansi color codes to allow the terminal's colorscheme to apply. The base16 standard is about having a more semantic shared understanding of what those colors mean between the application producing them and the terminal rendering them to ensure together they produce something readable.

And really base16 is too limiting, I would love to have a base24 colorscheme for opencode, since that gives the various "grayscale" colors that are important for the UI components like the sidebar.

But AFAICT both base16 and base24 are impossible with opencode right now as it translates 4-bit/256-color ansi color codes into truecolor codes using an internal mapping table.

@Nemo157

Thank you for the thoughtful feedback!

I agree that, in terminal-centric base16 workflows, themes often output ANSI color codes and let the terminal supply the colors, but that isn't required by the base16 “philosophy.” Many base16 themes for editors (like VSCode or Vim in GUI mode) use the palette’s hex values directly, mapping base00–base0F to UI slots without relying on the terminal.

This PR maps all theme slots to the official base16 default palettes, following the semantic slot mapping from the spec, and avoids “random” hardcoded hex values—so it matches the usual approach for base16 support in GUI apps.

I agree that supporting user-supplied terminal base16 colors would be ideal for true terminal theming (and would require outputting ANSI codes instead of truecolor), but for now, the goal here is to bring spec-compliant color structure and easy extensibility for both dark and light modes, as is typical for base16 themes in editors/GUI apps.

Happy to help discuss or plan support for real terminal-driven base16 in the future (which would be more involved)! For now, this PR ensures the theme matches the official base16 palette semantics.

[Nemo157]

Ah, I see now the actual filename is base16-default, I missed that with the PR name. That seems fine then, it's just a colorscheme that happens to have base16 in the name, not really a colorscheme that uses the base16 automatic mapping.