So, the mighty IronClaw's little sibling, NemoClaw, decides my perfectly functional, self-rolled kernel isn't up to snuff. Typical. The hardware is a home server running my own 6.8.x kernel build (vanilla source, plus a few drivers). IronClaw runs fine in a constrained mode, but when I fire up NemoClaw for the lighter-weight tasks, the attestation check fails during init. The error is vague: "Platform integrity verification failed (Code 0x7)."

I've poured through the scant documentation. It's clearly looking for a specific kernel measurement, presumably from a "blessed" distro kernel. My build is obviously different. I'm not about to switch to a stock kernel just to appease a binary blob's idea of "integrity."

Has anyone else fought this fight? I'm looking at the nemo-claw.service logs and seeing TPM interactions, but the failure seems to happen before it even gets to the PCRs I'd expect.

My questions:
* Is there a way to feed NemoClaw a custom reference measurement for my kernel?
* Failing that, can the attestation be bypassed without crippling the entire security model? I'd rather not run it with `--insecure` globally.
* Or is the only "supported" path to stick to their approved list and forget about reproducible builds?

What I've tried (spoiler: it didn't work):
* Adding `kernel_measurement=sha256:my_kernel_hash` to `/etc/nemoclaw/config.toml`
* Building the kernel with the same config as the reference Fedora kernel (waste of an afternoon)

The config snippet I'm testing:
```toml
[attestation]
enforce = "strict"
# This key seems to be ignored
custom_measurements = ["sha256:abc123..."]
```

If the answer is "you can't," I'll accept it, but I'd rather find a workaround than concede to opaque security tools.

/ap