## TL;DR
Kernel configs are generated artifacts with version-specific structure: new symbols appear, defaults flip, and the file header and ordering change, so a naive text diff or a strict parser melts down exactly when a kernel update happens. Parse the config into a symbol-to-value map (set, unset, module, built-in, string), compare maps semantically, and classify changes into expected-new-version noise (new symbols at defaults) versus meaningful changes (a previously set symbol removed or flipped). Report only the meaningful set, with the full map diff available as evidence.

```text
agent's diff parser failed on kernel config changes
```

## Use this when
- The agent errors out reading the new kernel config, or reports thousands of changed lines after a routine kernel update.
- The flagged changes are almost all new symbols or reordered entries.
- A symbol the fleet actually cares about (a filesystem, a security option) changing would be invisible in the flood.

## Not for this skill when
- The config file is missing because the distro does not ship one in boot. Read the running config from proc config.gz or the package files instead.
- The comparison is between two hand-maintained configs for the same kernel. A plain diff is appropriate there.

## Steps
1. Collect sample config pairs (previous and new kernel) from representative hosts and reproduce the parser failure or flood offline. Verify: the failure mode is reproduced with real files
2. Rewrite the comparison as a semantic map diff: parse each config into symbol states, ignoring comments, ordering, and header lines. Verify: identical-semantics files with different ordering produce an empty diff
3. Define meaningful change rules with the platform owner: a set symbol becoming unset or absent, a value flip on a watchlist of security and filesystem symbols, versus new symbols appearing at defaults. Verify: the rules are written down and the watchlist is explicit
4. Classify and re-run on the sample pairs. Verify: the output is a short list of meaningful changes with the noise summarized as counts
5. Wire the classifier into the wave post-checks and add the sample pairs as regression fixtures. Verify: the next kernel update produces a readable kernel-change note in the wave report

## Variant phrasings
### kernel config diff parser fails new version semantic diff
The main phrasing.
### config symbol map compare built-in module unset
The implementation phrasing.
### kernel update config changes noise vs meaningful watchlist
The triage phrasing.

Compatibility: Compatibility: Linux kernels shipping config in boot or via proc config.gz (IKCONFIG); symbol semantics are kconfig-standard across distros.

## Why it happens
Kernel configuration is a database wearing a text file costume. Each release adds and occasionally removes symbols, and the generated file reflects the whole kconfig tree, not just your choices. Text-diff tooling measures the file; the agent needs to measure the choices. The semantic map approach also makes the watchlist idea possible: a handful of symbols (SELinux, filesystems, virtualization options) deserve human eyes when they change, and everything else deserves a count, not an alarm.

## Edge cases / pitfalls
- A symbol that disappears entirely can mean a feature was removed or renamed and split; check the new symbol set for the successor before declaring a regression.
- Distros patch their kernels, so the same version number on two distros can have different symbol sets; keep fixtures per distro.
- The running config and the boot file can differ after a partial update; record which source each reading came from.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Qp6_LYXJNJngLE0kENJr1g