Audit of 2026.8.30.2: seven places where help text, warnings, or docs disagree with the code

[yspbwx2010]

While auditing 2026.8.30.2 (source at aef5191) against the documentation, we found seven places where help text, warnings, or docs disagree with what the code does. Line references are against that commit. Grouped by kind; happy to split into separate issues if that is easier to track.

Help text and docs vs. behavior:

1. --profile default. mcpp build --help and mcpp test --help say "release (default)" (src/cli.cppm:351, :414), but the resolver falls back to dev (resolve_profile_name, src/build/prepare.cppm:703-709), and the only caller passing "release" is mcpp pack (src/pack/pipeline.cppm:57, :89). docs/05-mcpp-toml.md:1574 documents dev, and mcpp's own mcpp.toml pins default-profile with a comment to the same effect. The help text is the odd one out.

2. mcpp index update [name] help says the name selects which index gets updated, but the filter only applies to project-level custom indices; the global repos always sync wholesale. The source already notes the discrepancy (src/pm/index_management.cppm:127-131) — filing it so it does not get lost.

3. Exit code 4 (global config load/init failure, e.g. src/doctor.cppm:87, src/pm/index_management.cppm:27) is missing from the exit-code table at docs/11-machine-output.md:105-110, which lists 0, 2, 70 and 127.

Schema checking:

4. [features] entries swallow unknown keys silently. The features parse region (modules/manifest/src/toml.cppm:439-508) emits no schemaWarnings at all, while [build], [target.<pred>], [target.<pred>.build] and [workspace.build] all warn on or reject unknown keys. Writing, say, include_dirs inside a feature builds successfully with zero diagnostics.

5. [build] std-module, std-compat-module and std-module-flags are read and take effect (toml.cppm:556-560) but are absent from kKnownBuildKeys (:1320-1328), so the parser reports "[build] has unsupported key 'std-module' (ignored)" — the opposite of what happens. Same shape as the bmi_schedule case recorded in the comment at :1334-1345.

Docs:

6. The example at docs/05-mcpp-toml.md:1380, [target.'cfg(c-abi = "musl")'.build] with std-module-flags, fails on both legs: the cfg parser's match_kv only knows os, arch, family and env, so a c-abi predicate never matches (src/build/prepare_inputs.cppm:113-119), and std-module-flags is not in kKnownConditionalBuildKeys (toml.cppm:1961-1964), so the key would be rejected even if the predicate matched.

7. Two passages predate the feat(xlings): provision [xlings] deps on first build, at global scope #531 behavior change and now say the opposite of what the code does: docs/13-baremetal.md:558 ("A declaration under [xlings] deps is not an install trigger") and docs/17-the-project-environment.md:113-115 ("mcpp will not do it"). Since feat(xlings): provision [xlings] deps on first build, at global scope #531, the first build provisions declared [xlings] deps into the registry (src/build/prepare.cppm:3094 onward), with no offline gate and no opt-out. If the new behavior is intended, these passages need updating; if the docs are the contract, the provision path needs a gate.