Make Ruby resolution work without manual mise activation

[maebeale]

What is the goal of this PR and why is this important?

• Scripts with #!/usr/bin/env ruby (notably bin/setup) silently picked up the wrong Ruby — or failed entirely — when the caller's shell hadn't activated mise.
• Conductor workspaces hit this because bin/conductor-setup runs under /bin/sh, which does not source ~/.zshenv.
• Separately, the Ruby version was declared in two places (mise.toml and .ruby-version) which can drift.

How did you approach the change?

Make Ruby resolution work without manual mise activation:

• CONTRIBUTING.md — added shims-in-zshenv as a required step under the "Install mise" section of the local setup path, with a brief explanation of why (covers non-interactive shells, IDE runners, cron, bin/setup).
• CLAUDE.md — replaced the stale "run eval mise activate before any Ruby command" guidance with the same shims setup, so agents working in the repo follow the current install pattern.
• bin/conductor-setup — activates mise explicitly near the top (with a /opt/homebrew/bin/mise fallback for cases where Conductor's inherited PATH doesn't include it). This script runs under #!/bin/sh, so the ~/.zshenv approach doesn't apply here.
• bin/setup itself stays a plain Ruby script — no bash wrapper, no shebang tricks. Once shims are on PATH (or bin/conductor-setup has activated mise), #!/usr/bin/env ruby just works.

Make .ruby-version the single source of truth:

• mise.toml — added [settings] idiomatic_version_file_enable_tools = ["ruby"] and removed the duplicate ruby = "4.0.1" from [tools]. External tooling (CI, deploys, IDEs) already reads .ruby-version by convention; this makes mise read it too. Project-scoped so every contributor's mise picks it up regardless of their global config.

Anything else to add?

• Branch name (setup-bash-wrapper) is a leftover from an earlier approach that I abandoned in favor of the shims path. Not renaming since the PR exists.

[maebeale]

@jmilljr24 will mise still work with your setup if we remove ruby declaration from mise.toml in favor of ruby-version ruby?

[jmilljr24]

@jmilljr24 will mise still work with your setup if we remove ruby declaration from mise.toml in favor of ruby-version ruby?

This is from the mise docs. So it should be fine. Maybe needs a note in the contributing guide to enable the setting during initial setup.

.ruby-version and Gemfile support

mise uses a mise.toml or .tool-versions file for auto-switching between software versions. However, it can also read ruby-specific version files .ruby-version or Gemfile (if it specifies a ruby version).

Create a .ruby-version file for the current version of ruby:

ruby -v > .ruby-version

Enable idiomatic version file reading for ruby:

mise settings add idiomatic_version_file_enable_tools ruby

See [idiomatic version files](https://mise.jdx.dev/configuration.html#idiomatic-version-files) for more information.

[jmilljr24]

Is this specific to your computer?

[maebeale]

to the user's computer, yes. (whether they use zsh or bashrc)

[jmilljr24]

I get that but my question is why is this new? Like is the issue specific to your computer? I don't need to add a mise shim and I don't recall that being an issue when most people were setting up at r4g last year.

It's my understand that the point of mise is to handle the versions for us. Running a script just need to be done from the path of the project.

[maebeale]

@jmilljr24 good call — I ended up enabling that setting at the project level in mise.toml ([settings] idiomatic_version_file_enable_tools = ["ruby"]), so contributors don't need to set it globally. Just pushed a follow-up that also clarifies the CONTRIBUTING wording on which shell-startup file the PATH export should go in (~/.zshenv vs ~/.bash_profile, and why).

[jmilljr24]

@jmilljr24 good call — I ended up enabling that setting at the project level in mise.toml ([settings] idiomatic_version_file_enable_tools = ["ruby"]), so contributors don't need to set it globally. Just pushed a follow-up that also clarifies the CONTRIBUTING wording on which shell-startup file the PATH export should go in (~/.zshenv vs ~/.bash_profile, and why).

Awesome on the toml setting!

I don't think the comments in contributing setup instructions should be there if it's not a generic requirement. There is the potential to cause some system wide issues for a new contributor when it's not strictly required.

It seems you needed to export the path due to how conductor is working on your system? If so, maybe a comment on the AI section