feat(matrix): nest user metadata under metadata and drop serde_json_merge

- `cargo fc matrix` rows now expose cargo-fc-owned `name`, `target`,
  `features`, and `metadata`; user matrix config moves under `metadata`
  instead of being merged at the top level (breaking schema change).
- replace the `serde_json_merge` dependency with a small recursive
  `serde_json::Map` deep-merge (nested objects merge; arrays and scalars
  replace) and store matrix metadata as `serde_json::Map` so one merge
  serves every level.
- emit matrix rows with deterministically sorted keys, independent of
  serde_json's `preserve_order` feature.
- regenerate screenshots, refresh README/docs/plan, add CHANGELOG, and
  scope the `udeps` task to `--workspace --all-targets`.

Author: romnn

CHANGELOG.md

@@ -0,0 +1,68 @@
+# Changelog
+
+## [0.1.0]
+
+### Breaking Changes
+
+- Changed `cargo fc matrix` row shape. cargo-fc now owns the top-level
+  `name`, `target`, `features`, and `metadata` fields. Custom package matrix
+  fields from `[package.metadata.cargo-fc].matrix` or
+  `[package.metadata.cargo-fc.matrix]` now appear under `metadata` instead of
+  being merged at the top level.
+- Added `target` to every `cargo fc matrix` row. Matrix consumers should use
+  `row.target` for the effective target triple and `row.metadata.<key>` for
+  user-defined fields.
+- Made `targets`, workspace `target.'cfg(...)'`, and workspace `subcommands`
+  cargo-fc metadata keys active. Repositories that previously used those keys
+  for unrelated local data must rename them.
+- Configured target lists now apply to all target-capable Cargo commands by
+  default, including `build`, `check`, `clippy`, `doc`, `test`, and `run`.
+  Foreign-target `test` and `run` usually fail unless narrowed with
+  `--target`, disabled with `--no-targets`, or disabled for that command in
+  workspace metadata.
+- Unknown Cargo aliases and custom subcommands do not receive configured
+  targets unless explicitly opted in with
+  `[workspace.metadata.cargo-fc.subcommands.<name>] targets = true`.
+- Removed the redundant public target-detector API in favor of
+  `TargetEnvironment`, `parse_cli_target`, and `host_triple`.
+
+### Added
+
+- Added workspace-level configured targets:
+  `[workspace.metadata.cargo-fc] targets = ["<triple>", ...]`.
+- Added package-level configured targets:
+  `[package.metadata.cargo-fc] targets = ["<triple>", ...]`.
+- Added package-level target opt-out with `targets = []`, which falls back to
+  the single effective Cargo target for that package.
+- Added target-specific workspace package selection via
+  `[workspace.metadata.cargo-fc.target.'cfg(...)']` with `exclude_packages`
+  patches.
+- Added per-subcommand target capability overrides via
+  `[workspace.metadata.cargo-fc.subcommands.<name>] targets = true|false`.
+- Added `--no-targets` to ignore configured target lists for one invocation.
+- Added `--aggregate-targets` to batch compatible configured targets for the
+  same package and feature combination into one Cargo invocation.
+- Added per-target execution planning so `cargo fc check`, `cargo fc clippy`,
+  and other target-capable commands can cover each configured target's cfg view
+  in one command.
+- Added per-target attribution in command headers, summaries, diagnostics-only
+  output, and dedupe reporting when target selection is explicit or configured.
+- Added GitHub Actions documentation for generating target-aware matrices and
+  for using one `cargo fc check` or `cargo fc clippy` invocation in CI.
+
+### Changed
+
+- Explicit Cargo `--target <triple>` wins globally over configured target
+  lists. Without an explicit CLI target, configured package/workspace targets
+  take precedence over `CARGO_BUILD_TARGET`, then fall back to
+  `CARGO_BUILD_TARGET`, then the host target.
+- Matrix generation now goes through the same target and execution planning path
+  as command execution, so target-specific package config and workspace package
+  exclusions are resolved consistently.
+- Matrix JSON object keys are serialized in deterministic sorted order.
+- Target-specific matrix metadata merges tables recursively; arrays and scalar
+  values replace the base value.
+- Summary totals and pruned-combination summaries are keyed by package, target,
+  and feature set so identical feature sets across targets no longer collapse.
+- Invalid or unavailable target cfg evaluation errors now surface rustc's reason
+  at the cfg-evaluator boundary.

Cargo.lock

@@ -86,7 +86,6 @@ cfg-expr = "0.20"
 # serde
 serde = "1"
 serde_json = "1"
-serde_json_merge = "0"
 
 # terminal colors
 termcolor = "1.4"

Cargo.toml

@@ -43,7 +43,7 @@ cargo fc build
 cargo fc check -p <my-crate> --all-targets
 ```
 
-In addition, there are a few new flags and the `matrix` subcommand.
+In addition, cargo-fc provides these flags and the `matrix` subcommand.
 To get an idea, consider these examples:
 
 ```bash
@@ -142,14 +142,14 @@ For example:
 [package.metadata.cargo-fc]
 
 # Exclude groupings of features that are incompatible or do not make sense
-exclude_feature_sets = [ ["foo", "bar"], ] # formerly "skip_feature_sets"
+exclude_feature_sets = [["foo", "bar"]]
 
 # To exclude only the empty feature set from the matrix, you can either enable
 # `no_empty_feature_set = true` or explicitly list an empty set here:
 exclude_feature_sets = [[]]
 
 # Exclude features from the feature combination matrix
-exclude_features = ["default", "full"] # formerly "denylist"
+exclude_features = ["default", "full"]
 
 # Skip implicit features that correspond to optional dependencies from the
 # matrix.
@@ -180,7 +180,7 @@ only_features = ["default", "full"]
 # Non-existent features are ignored. Other configuration options are ignored.
 include_feature_sets = [
     ["foo-a", "bar-a", "other-a"],
-] # formerly "exact_combinations"
+]
 
 # Allow only the listed feature sets.
 #
@@ -213,22 +213,27 @@ isolated_feature_sets = [
     ["other-a", "other-b", "other-c"],
 ]
 
-# Optional: Additional metadata merged into `cargo fc matrix` output
+# Optional: Custom metadata for `cargo fc matrix` output.
+# It appears under the row's `metadata` key.
 # $ cargo fc matrix --pretty
 #   [
-#     { "name": "my-crate", "features": "", "kind": "ci" },
-#     { "name": "my-crate", "features": "a", "kind": "ci" },
-#     { "name": "my-crate", "features": "b", "kind": "ci" },
-#     { "name": "my-crate", "features": "a,b", "kind": "ci" },
+#     { "features": "", "metadata": { "kind": "ci" }, "name": "my-crate", "target": "x86_64-unknown-linux-gnu" },
+#     { "features": "a", "metadata": { "kind": "ci" }, "name": "my-crate", "target": "x86_64-unknown-linux-gnu" },
+#     { "features": "b", "metadata": { "kind": "ci" }, "name": "my-crate", "target": "x86_64-unknown-linux-gnu" },
+#     { "features": "a,b", "metadata": { "kind": "ci" }, "name": "my-crate", "target": "x86_64-unknown-linux-gnu" },
 #   ]
 matrix = { kind = "ci" }
 
-# Optional: The `matrix` metadata from before can also be its own section
+# Optional: Matrix metadata can also be configured in its own section.
 # $ cargo fc matrix --pretty
 #   [{
-#       "requires-gpu": false,
-#       "value-for-this-crate": "will show up in the feature matrix",
-#       ..
+#       "features": "",
+#       "metadata": {
+#         "requires-gpu": false,
+#         "value-for-this-crate": "will show up in the feature matrix"
+#       },
+#       "name": "my-crate",
+#       "target": "x86_64-unknown-linux-gnu"
 #    }, .. ]
 [package.metadata.cargo-fc.matrix]
 value-for-this-crate = "will show up in the feature matrix"
@@ -434,6 +439,9 @@ If a value appears in both `add` and `remove`, add wins.
 When multiple target override sections match (e.g. `cfg(unix)` and `cfg(target_os = "linux")`),
 their `add` and `remove` sets are unioned. Conflicting `override` values result in an error.
 
+Matrix metadata tables merge recursively. Other matrix metadata values,
+including arrays, replace the base value.
+
 ##### `replace = true`
 
 If a matching target override sets `replace = true`, resolution starts from a fresh default

README.md

@@ -66,6 +66,13 @@ jobs:
           --all-targets
 ```
 
+If you configure custom package matrix metadata, it is available under
+`matrix.package.metadata`:
+
+```yaml
+name: build ${{ matrix.package.name }} (${{ matrix.package.metadata.kind }})
+```
+
 Of course you can also apply the same approach for your `test.yaml` or `lint.yaml` workflows!
 Per job, up to 256 feature sets can be processed in parallel.
 
@@ -105,4 +112,3 @@ feature combination for you (no GitHub Actions matrix required):
 Add `--aggregate-targets` to batch each combination's targets into one Cargo
 invocation for extra throughput on many-core runners.
 
-