feat(derive): add usage::Config derive for settings declared in code

.github/workflows/test.yml

@@ -111,7 +111,6 @@ jobs:
         run: |
           cargo clippy -p usage-lib --no-default-features -- -D warnings
           cargo clippy -p usage-rs --no-default-features -- -D warnings
-          cargo clippy -p usage-config-build -- -D warnings
           cargo clippy -p usage-config --no-default-features -- -D warnings
       - run: mise r render
       # Same reasoning as `render`: the shadow is checked in, so a change to the derive's
@@ -154,7 +153,7 @@ jobs:
           - version: "1.91"
             crates: usage-argv usage-derive usage-config usage-validation usage-rs usage-test
           - version: "1.95"
-            crates: usage-lib usage-config-build clap_usage usage-cli
+            crates: usage-lib clap_usage usage-cli
     steps:
       - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1 # v7.0.1
         with:

Cargo.toml

@@ -3,7 +3,6 @@ resolver = "2"
 members = [
     "argv",
     "config",
-    "config-build",
     "derive",
     "test",
     "usage-rs",
@@ -48,7 +47,7 @@ usage-config = { path = "./config", version = "5.1.0" }
 usage-derive = { path = "./derive", version = "5.1.0" }
 # No features, and defaults off. A feature named here is inherited by every member that writes
 # `workspace = true` and inlines into their published manifests — so `clap` and `validation`
-# reached `usage-config-build`, which runs in an adopter's build script and uses neither. Defaults
+# reached members that use neither, one of them an adopter's build script. Defaults
 # are off rather than absent because cargo *ignores* a member's `default-features = false` unless
 # the workspace declaration sets it too, and warns that it may become a hard error. Members name
 # what they need, `docs` included.

PLAN.md

@@ -13,7 +13,7 @@ already written, which is the failure mode a status file has to avoid.
    into the spec.
 
 The first is underway. The second is **underway too**, which this file said it was
-not: `usage-config` and `usage-config-build` are 8,220 lines, the spec's `config`
+not: `usage-config` and the `usage::Config` derive are the settings model, the spec's `config`
 block has a model behind it, and the derive lowers `#[usage(setting = …)]` into
 `SETTINGS_BINDINGS` with a `Registry::drift` check over it. What has _not_
 happened is adoption — none of mise, hk, pitchfork or fnox depends on the crate —
@@ -1791,7 +1791,9 @@ including telling you to delete the label afterwards.
 
 ## Config
 
-Not started. Design first, implementation after the parser gate.
+Implemented — the crates, the spec block, the derive, and the CLI binding all exist below.
+What has not happened is adoption, which is tracked per-CLI by the fleet effort rather than
+here.
 
 ### What the four CLIs already do
 
@@ -1828,17 +1830,24 @@ Where they differ is instructive, because it is mostly _drift_:
 
 ### The shape
 
-- [ ] **Declare props in code**, `#[derive(usage::Config)]`, lowered into the
+- [x] **Declare props in code**, `#[derive(usage::Config)]`, lowered into the
       spec's `config { prop ... }` block so settings documentation flows through
       the same pipeline as command documentation. Same canonicality rule as the
-      parser: code authors, the spec defines. **Decided (2026-08-21): the derive goes
-      on a registry-only declaration**, whose generated output feeds the CLI's existing
-      settings type rather than replacing it. Putting it on the final typed `Settings`
-      would be one source of truth, but it pushes layer bindings and merge policy onto
-      application fields and makes every adopter convert its whole registry in one step.
-      A registry-only declaration lets mise, hk, pitchfork and fnox adopt a layer at a
-      time, which is the migration path this section already judges likeliest to happen.
-      The cost is accepted and bounded: two declarations coexist during a migration.
+      parser: code authors, the spec defines. **Decided (2026-08-21, superseding the
+      registry-only decision of the same day): the derive goes on the real typed
+      `Settings` struct** — the same shape as `#[derive(usage::Cli)]`, which is the
+      argument that won. The author writes the struct the CLI already holds its settings
+      in; the derive generates `SETTINGS_PROPS`/`SETTINGS_REGISTRY`, `read(&Resolved)`,
+      and `spec_kdl()`, and a root's `#[usage(config = Settings)]` puts the block in its
+      emitted spec. One source of truth, no generated structs. The registry-only shape
+      was chosen for layer-at-a-time migration; the fleet's first adopters (pitchfork,
+      fnox, tak) are converting wholesale, so the incremental path's cost — two
+      coexisting declarations — was being paid for a benefit nobody scheduled. Nested
+      groups compose through `usage_config::Props` with compile-time `concat_props`
+      (duplicate keys refuse the build); `derive/src/config.rs`,
+      `conformance/tests/derive_config.rs`. The struct is the only declaration: the
+      build-time KDL-to-registry generator (`usage-config-build`) is gone, because a
+      second backend was a third description of every setting.
 - [x] **A prop vocabulary that is the union of the four registries** — `type`
       (bool, int, string, path, duration, list, map, plus a Rust-type escape
       hatch), `default`, `env` and `deprecated_env`, `docs`, `deprecated` with
@@ -1885,13 +1894,16 @@ Where they differ is instructive, because it is mostly _drift_:
       pipeline — `config/` and `SpecConfigProp` are here today, so this is also the
       status quo. A split would buy an independent stability and MSRV policy at the
       price of cross-repo coordination on every spec vocabulary change.
-- [ ] Whether the four CLIs migrate incrementally (one layer at a time, keeping
+- [x] Whether the four CLIs migrate incrementally (one layer at a time, keeping
       their generated `Settings`) or by regenerating from a converted registry.
-      Incremental looks far more likely to actually happen. **Owned by the fleet
-      adoption effort (2026-08-21), not decided here** — it is a question about what
-      each CLI does, and the answer sets whether the first public APIs must wrap
-      existing layers and settings types without owning them. The registry-only
-      derive above deliberately keeps the incremental path open either way.
+      **Answered by the fleet adoption effort (2026-08-21): wholesale, on the real
+      struct.** The first adopters — pitchfork, fnox, tak — convert their registries
+      into `#[derive(usage::Config)]` structs in one PR each, stacked on their clap-swap
+      PRs; hk and aube are deferred (git/pkl layers, `env_only` bootstrap, per-item
+      provenance; aube's managed-policy ratchet and two-axis sources). There is no
+      second path held open for a later incremental adopter: `usage-config-build` was
+      removed with this decision, since keeping a KDL-first backend alive meant keeping
+      two generators emitting one registry shape.
 - [x] fnox's model, where config files are not a settings source at all, is the
       one real behavior change rather than a consolidation. Worth confirming that
       is a fix and not a deliberate choice. **Decided (2026-08-21): preserve fnox's

argv/src/help.rs

@@ -490,7 +490,10 @@ fn flag_usage_masked(meta: &FlagMeta<'_>, show: &Shown) -> String {
             let mut buf = [0u8; 4];
             (*short as char).encode_utf8(&mut buf) == flag.name
         }
-        _ => false,
+        // A flag whose only spelling is its negation — clap's `SetFalse`, tak's
+        // `--no-credit` — is named after that spelling, so the prefix would repeat it:
+        // `no-credit: --no-credit`.
+        _ => show.negate && flag.negate == Some(flag.name),
     };
     if !implied_matches {
         let _ = write!(out, "{}:", flag.name);
@@ -1238,6 +1241,10 @@ pub(crate) fn flag_spelling(meta: &FlagMeta<'_>) -> String {
 fn display_usage_masked(meta: &FlagMeta<'_>, show: &Shown) -> String {
     let usage = flag_usage_masked(meta, show);
     match meta.flag.negate.filter(|_| show.negate) {
+        // A flag whose only spelling is its negation has nothing before it: the name prefix
+        // would repeat the spelling, so `flag_usage_masked` writes nothing and the negation
+        // is the whole entry. Joining with a space put one at the front of the column.
+        Some(negate) if usage.is_empty() => format!("--{negate}"),
         Some(negate) if show.long.is_none() && show.short.is_none() => {
             format!("{usage} --{negate}")
         }
@@ -2785,6 +2792,30 @@ mod style_tests {
         assert_eq!(display_usage_masked(&meta, &shown), "color: --no-color");
     }
 
+    #[test]
+    fn a_flag_spelled_only_as_its_negation_writes_that_spelling_and_nothing_before_it() {
+        // clap's `SetFalse`, tak's `--no-credit`: the flag is *named* after its negation, so
+        // the `name:` prefix would repeat the spelling and there is no positive form to join
+        // it to. Both halves wrote nothing, and the join put a space at the front of the
+        // column: `" --no-credit"`.
+        let flag = Flag {
+            name: "no-credit",
+            negate: Some("no-credit"),
+            ..Flag::BOOL
+        };
+        let meta = FlagMeta {
+            flag: &flag,
+            ..FlagMeta::EMPTY
+        };
+        let shown = Shown {
+            long: None,
+            short: None,
+            negate: true,
+        };
+
+        assert_eq!(display_usage_masked(&meta, &shown), "--no-credit");
+    }
+
     #[test]
     fn flattened_next_line_deprecation_follows_help_without_a_blank_row() {
         let flag = Flag {