Configurable macro

[cooper (czxtm)]

Summary

This PR implements the ability to make any parameter configurable via the settings UI by simply adding derive macro (Configurable ). The above is achieved with just a few lines added:

#[derive(Configurable, Debug, Clone)]
#[config(store_path = "settings.json")]
pub struct EvolutionLimits {
    #[config(default = 25, key = "maxIterations")]
    pub max_iterations: usize,

    #[config(default = 5, key = "maxBuildAttempts")]
    pub max_build_attempts: usize,
}

It also adds an import/export button that will contain these configurable values. This enables two important features:

1. We can share settings and include them in bug reports
2. If this file is placed inside of the user's nixmac repo at .nixmac/settings.json, then a user can sync their nixmac settings between machines as well!

Test Plan

• cargo test --manifest-path apps/native/src-tauri/Cargo.toml settings_io
• cargo test --manifest-path apps/native/src-tauri/Cargo.toml dev_configs
• cargo test --manifest-path apps/native/src-tauri/Cargo.toml configurable_scope
• cargo test --manifest-path apps/native/src-tauri/Cargo.toml default_matches_configured_field_defaults
• bunx vitest run --project=storybook src/components/widget/settings/auto-config-field.stories.tsx src/components/widget/settings/auto-tuning-section.stories.tsx
• Open Storybook and inspect Settings/AutoConfigField and Settings/AutoTuningSection.

Docs

• Docs updated (companion PR in darkmatter/nixmac-web: #___)
• No docs update needed

[github-actions]

	Warnings
⚠️	Please assign this PR to someone (usually yourself).
⚠️	❗ Big PR (3909 lines changed). Consider splitting it into smaller, focused changes.

	Messages
📖	No docs update needed — acknowledged.

📋 PR Overview

Lines changed	3909 (+3621 / -288)
Files	16 added, 22 modified, 0 deleted
Draft / WIP	no
Has Test Plan	yes
New UI components	yes (2)
New Storybook stories	yes (2)
New Rust modules	yes (5)
New TS source files	yes (2)
New tests	no
package.json touched	no
Cargo.toml touched	yes
Infra / CI touched	no

🔬 Coverage

Report	Lines	Statements	Functions	Branches
apps/native/coverage/coverage-summary.json	17.8%	17.8%	31.2%	54.0%

Generated by 🚫 dangerJS against 0c4a504

[Copilot]

Pull request overview

Adds a proof-of-concept Rust #[derive(Configurable)] proc-macro (plus small runtime helper crate) to simplify reading hot-reloadable developer settings from tauri-plugin-store, and migrates the evolution loop’s iteration/build-attempt limits to use it.

Changes:

• Introduces two new workspace crates: configurable (runtime helper + derive re-export) and configurable-derive (proc-macro generating Struct::load(app)).
• Migrates evolution limits (max_iterations, max_build_attempts) to a new EvolutionLimits struct loaded from settings.json, and threads the configured max_build_attempts into build-check logging/control flow.
• Updates workspace/native Cargo manifests and lockfile to include the new crates; closes the related beads issue.

Reviewed changes

Copilot reviewed 9 out of 10 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
Cargo.toml	Adds new workspace members for the macro + runtime crates.
Cargo.lock	Records the new crates and their dependencies in the lockfile.
apps/native/src-tauri/src/evolve/mod.rs	Loads EvolutionLimits via the new derive and threads max_build_attempts into processing/logging.
apps/native/src-tauri/src/evolve/config.rs	Defines EvolutionLimits annotated with #[derive(Configurable)] and store keys/defaults.
apps/native/src-tauri/configurable/src/lib.rs	Adds runtime helper read_field() and re-exports the derive.
apps/native/src-tauri/configurable/Cargo.toml	Declares the new runtime crate and dependencies.
apps/native/src-tauri/configurable-derive/src/lib.rs	Implements the Configurable derive that generates a load() method.
apps/native/src-tauri/configurable-derive/Cargo.toml	Declares the new proc-macro crate and dependencies.
apps/native/src-tauri/Cargo.toml	Adds the new configurable path dependency to the native Tauri crate.
.beads/issues.jsonl	Marks nixmac-8ka as closed and adds follow-up migration issues.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 26 out of 27 changed files in this pull request and generated 7 comments.

[Juanpe Bolívar (arximboldi)]

The overall idea of having ways to easily declare customization points that show up in the UI is cool, nice stuff.

First, this is a massive PR that it's a bit tricky to review. I would have loved to see it split in three parts:

1. The Configurable and auto-UI infrastructure.
2. The saving of settings.json in the config folder.
3. The new theme.

Going into the code itself, I see a big missed opportunity to start moving in the direction I suggest in my architecture review document. This would set the groundwork to eventually move all the preferences into Configurable infrastructure. This would imply:

1. Storing the configurable in tauri::State instead of store.
2. By doing that, we already remove a lot of code, since there is no need to marshall the configurable into/outo the store, since Serde can do that for us (and will give us versioning, etc.)
3. Adding an update channel to update the UI (via a regular API based on events, as described in the architecture review)
4. Using the an auto-updated zustand store (or store slice) as way to transparently interface between the UI and Rust.

The details on how to do this are already broadly in the architecture review document. If you don't have time to do this, perhaps Cas Linden (@CasLinden) can pick this up, as I know he wanted to get familiarity with the architecture and start implementing it in various parts of the application.

[Juanpe Bolívar (arximboldi)]

Not sure we should worry about "legacy" at this level since we haven't released yet, there's some risk of just acummulating lots of unneeded code. Eventually, we should think about versioning of various files (including settings.json) but this should be done using the versioning infrastructure of the serialization infrastructure (e.g. Serde.) Related to the general comment on moving away from tauri::store.

[Juanpe Bolívar (arximboldi)]

refresh is not used anywhere else if I'm understanding correctly, so the body could be brought in here

[Juanpe Bolívar (arximboldi)]

This seems to be the only place where we update the UI, there's no event driven to update the UI from changes from RS. This is risky.

[cooper (czxtm)]

Juanpe Bolívar (@arximboldi) agreed this PR got too big after I decided the channel between rust/js should be more strict - I'll split them up.

Regarding tauri::Store though, I'm not sure how that would work given that we want to store this as JSON so these settings can persist across devices? tauri::Store is a type-keyed map (TypeId → value) that lives in RAM for the process lifetime, not ideal for things we want to persist to disk, A Store is a HashMap<String, JsonValue> backed by a file on disk. Or did you mean for it to be used as a way to transmit data between the js/rust boundary?