docs: replace "inherit" terminology with config layering

docs/architecture.md

@@ -178,7 +178,7 @@ Helpers for working with environment variables:
 - `EnvDiff` - Tracks and applies environment changes
 - `EnvDirective` - Configuration-based environment variable management
 - `PathEnv` - Intelligent PATH manipulation with precedence rules
-- Context-aware resolution with inheritance
+- Context-aware resolution with config layering
 
 For environment setup and configuration, see [Environment Documentation](environments/).
 

docs/configuration.md

@@ -286,7 +286,7 @@ experimental_monorepo_root = true
 When enabled:
 
 - Tasks in subdirectories are available with namespaced paths (e.g., `//projects/frontend:build`)
-- Subdirectory tasks inherit tools from parent configs
+- Subdirectory tasks use tools from parent configs
 - Tasks are only loaded when needed (e.g., when running them, or with `mise tasks ls --all`)
 - All descendant config files are **implicitly trusted** when the root is trusted
 - Eliminates the need to individually trust each subdirectory's configuration

docs/shell-aliases.md

@@ -47,7 +47,7 @@ $ cd ~
 
 ## Hierarchy
 
-Like other mise config, shell aliases are inherited from parent directories. A child directory can override a parent's alias:
+Like other mise config, shell aliases from parent directories are available in child directories. A child directory can override a parent's alias:
 
 ```toml
 # ~/projects/mise.toml

docs/tasks/architecture.md

@@ -119,7 +119,7 @@ mise discovers tasks from multiple sources in this order:
 
 1. **File tasks**: Executable files in task directories
 2. **TOML tasks**: Defined in `mise.toml` files
-3. **Inherited tasks**: From parent directories
+3. **Parent directory tasks**: Available from parent directories
 
 ### Task Resolution Process
 
@@ -131,9 +131,9 @@ When you run `mise run build`, mise:
 4. **Validates graph** (checks for circular dependencies)
 5. **Executes in dependency order** with parallelism
 
-### Task Inheritance
+### Task Resolution Across Directories
 
-Tasks are inherited from parent directories but can be overridden:
+Tasks from parent directories are available in subdirectories and can be overridden:
 
 ```
 project/
@@ -142,7 +142,7 @@ project/
     └── mise.toml          # overrides: test, adds: bundle
 ```
 
-In `frontend/`, you have access to: `lint` (inherited), `test` (overridden), `build` (inherited), `bundle` (local).
+In `frontend/`, you have access to: `lint` (from parent), `test` (overridden), `build` (from parent), `bundle` (local).
 
 ## Advanced Dependency Features
 

docs/tasks/monorepo.md

@@ -15,7 +15,7 @@ The directory containing a `mise.toml` file is called the **config_root**. In mo
 - **Consistent execution**: Run tasks from any location in the monorepo using the mise config that would be set if called from the task's directory
 - **Clear task namespacing**: Tasks are prefixed with their location from the monorepo root
 - **Pattern-based execution**: Use wildcards to run tasks across multiple projects
-- **Tool and environment inheritance**: Subdirectory tasks inherit tools and environment variables from parent configs, but can also define their own in their config_root
+- **Tool and environment layering**: Subdirectory tasks use tools and environment variables from parent configs, but can also define their own in their config_root
 - **Automatic trust propagation**: When the monorepo root is trusted, all descendant configs are automatically trusted
 
 ## Configuration
@@ -29,7 +29,7 @@ Add `experimental_monorepo_root = true` to your root `mise.toml`:
 experimental_monorepo_root = true
 
 [tools]
-# Tools defined here are inherited by all subdirectories
+# Tools defined here apply to all subdirectories
 node = "20"
 ```
 
@@ -175,26 +175,26 @@ mise '//...:test*'
 mise //.../frontend:build
 ```
 
-## Tool and Environment Inheritance
+## Tool and Environment Layering
 
-Subdirectory tasks automatically inherit tools and environment variables from parent config files in the hierarchy. However, each subdirectory can also define its own tools and environment variables in its config_root. This allows you to:
+Subdirectory tasks automatically use tools and environment variables from parent config files in the hierarchy. However, each subdirectory can also define its own tools and environment variables in its config_root. This allows you to:
 
 1. Define common tools and environment at the monorepo root
 2. Override tools or environment in specific subdirectories
 3. Add additional tools or environment in subdirectories
 
-### Inheritance Example
+### Layering Example
 
 ```toml
 # /myproject/mise.toml
 experimental_monorepo_root = true
 
 [tools]
-node = "20"      # Inherited by all subdirectories
-python = "3.12"  # Inherited by all subdirectories
+node = "20"      # Available to all subdirectories
+python = "3.12"  # Available to all subdirectories
 
 [env]
-LOG_LEVEL = "info"  # Inherited by all subdirectories
+LOG_LEVEL = "info"  # Available to all subdirectories
 ```
 
 ```toml
@@ -212,13 +212,13 @@ run = "npm run build"  # Uses node 18 and LOG_LEVEL=debug
 
 ```toml
 # /myproject/projects/backend/mise.toml
-# No tools or env section - inherits node 20, python 3.12, and LOG_LEVEL=info from root
+# No tools or env section - uses node 20, python 3.12, and LOG_LEVEL=info from root
 
 [tasks.build]
 run = "npm run build"  # Uses node 20 and LOG_LEVEL=info from root
 ```
 
-### Inheritance Rules
+### Layering Rules
 
 1. **Base toolset and environment**: Tasks start with tools and environment from all global config files (including parent configs in the hierarchy)
 2. **Subdirectory override**: Tools and environment defined in the subdirectory's config file are merged on top, allowing overrides
@@ -320,7 +320,7 @@ Only override tools in subdirectories when they genuinely need different version
 # /myproject/legacy-app/mise.toml
 [tools]
 node = "14"  # Override only for legacy app
-# python and go inherited from root
+# python and go from root
 ```
 
 ### 3. Use Descriptive Task Names
@@ -368,7 +368,7 @@ The monorepo ecosystem offers many excellent tools, each with different strength
 
 ### Simple Task Runners
 
-**Taskfile** and **Just** are fantastic for single-project task automation. They're lightweight and easy to set up, but they weren't designed with monorepos in mind. While you can have multiple Taskfiles/Justfiles in a repo, they don't provide unified task discovery, cross-project wildcards, or automatic tool/environment inheritance across projects.
+**Taskfile** and **Just** are fantastic for single-project task automation. They're lightweight and easy to set up, but they weren't designed with monorepos in mind. While you can have multiple Taskfiles/Justfiles in a repo, they don't provide unified task discovery, cross-project wildcards, or automatic tool/environment layering across projects.
 
 **mise's advantage:** Automatic task discovery across the entire monorepo with a unified namespace and powerful wildcard patterns.
 
@@ -416,7 +416,7 @@ mise's Monorepo Tasks aims to hit the sweet spot between simplicity and power:
 | Unified task discovery  | ❌             | ✅         | ✅            | ✅   |
 | Wildcard patterns       | ❌             | ⚠️         | ✅            | ✅   |
 | Tool version management | ❌             | ❌         | ⚠️            | ✅   |
-| Environment inheritance | ❌             | ⚠️         | ❌            | ✅   |
+| Environment layering    | ❌             | ⚠️         | ❌            | ✅   |
 | Minimal setup           | ✅             | ⚠️         | ❌            | ✅   |
 | Task caching            | ❌             | ✅         | ✅            | ❌   |
 

docs/tasks/task-configuration.md

@@ -580,7 +580,7 @@ mise supports monorepo-style task organization with target path syntax. Enable i
 For complete documentation on monorepo tasks including:
 
 - Task path syntax and wildcards
-- Tool inheritance from parent configs
+- Tool layering from parent configs
 - Performance tuning
 - Best practices and troubleshooting
 

docs/tasks/templates.md

@@ -62,7 +62,7 @@ When a task extends a template, fields are merged according to these rules:
 | `dir`                                   | Local overrides; defaults to config_root if not in template |
 | `sources`, `outputs`                    | Local overrides completely                                  |
 | `description`, `shell`, `timeout`, etc. | Local overrides template (if set)                           |
-| `quiet`, `hide`, `raw`                  | Not inherited (must be set explicitly in task)              |
+| `quiet`, `hide`, `raw`                  | Not carried over (must be set explicitly in task)           |
 
 ### Example: Deep Merge for Tools
 

src/prepare/engine.rs

@@ -84,8 +84,8 @@ impl PrepareEngine {
     /// Discover all applicable prepare providers for the current project
     ///
     /// Each config file's prepare providers are scoped to that config file's directory.
-    /// Prepare configs are NOT inherited from parent directories - a `[prepare.pnpm]`
-    /// defined in a root mise.toml only runs from the root, not from subdirectories.
+    /// For example, a `[prepare.pnpm]` defined in the root `mise.toml` only applies when
+    /// running from the root directory, not from subdirectories.
     fn discover_providers(config: &Config) -> Result<Vec<Box<dyn PrepareProvider>>> {
         let project_root = config
             .project_root
@@ -99,7 +99,7 @@ impl PrepareEngine {
         // Process each config file's prepare config independently, using that
         // config file's directory as the project root for its providers.
         // Only include config files that belong to the current project root
-        // (not inherited from parent directories).
+        // (skip config files outside the current project root, e.g. from parent directories).
         for cf in config.config_files.values() {
             let Some(prepare_config) = cf.prepare_config() else {
                 continue;