docs: clarify NativeAOT scope and regenerate conformance ledger

Documents NativeAOT as a native-analysis route with format/architecture limits, keeps the skill DOS-guide link inside the installed bundle convention, and regenerates the managed conformance manifest.

docs/managed-code-analysis.md

@@ -90,6 +90,51 @@ coverage, and route while retaining the outer bundle commitment.
 | Obfuscated assembly   | Same positive byte observations as its underlying deployment form            | Meaning inferred only from names                                                          |
 | Malformed/unsupported | Exact admitted regions and failure locations                                 | Completeness, successfully skipped rows, or semantics beyond the admitted parser boundary |
 
+### NativeAOT metadata recovery
+
+NativeAOT removes the ordinary CIL method bodies, so a CIL decompiler cannot
+reconstruct those bodies as C# source. The executable remains a native target
+for Hopper or Ghidra, where decompilation produces pseudocode and analyst
+inference. This is a different route from ordinary managed member inspection.
+
+NativeAOT is not limited to Windows `.exe` files. The native image can be PE,
+ELF, or Mach-O, and NativeAOT can also publish shared libraries (PE DLL, ELF
+`.so`, or Mach-O `.dylib`) with explicitly exported entry points. Identify the
+image from its bytes and loader metadata, not its filename extension. When the
+image is inside an application bundle, inventory or extract the bundle first
+and carry the component identity into native analysis. Matching PDB, ELF debug,
+or dSYM sidecars can add symbol evidence when the selected provider supports
+them; verify their identity and keep them separate from observations made from
+the executable itself. [Microsoft's NativeAOT overview](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/)
+lists supported OS/architecture targets and deployment limitations, while its
+[native library guide](https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/libraries)
+describes exported shared-library entry points.
+
+The [Ghidra NativeAOT analyzer](https://github.com/Washi1337/ghidra-nativeaot)
+is a useful optional companion for recovering ReadyToRun metadata. It
+rehydrates the `DEHYDRATED_DATA` section and annotates method tables, type
+relationships, vtable slots, frozen objects, and strings. It does not recover
+original C# method bodies. It is a separate Ghidra extension and interactive
+metadata browser; REA does not currently install or invoke it through its
+headless bridge. Its README describes ReadyToRun header discovery, including
+symbol-based and heuristic paths, so a missed header or unsupported binary
+should remain an explicit limitation rather than a failed claim about the
+binary's contents.
+
+The upstream analyzer currently gates its own analysis to x86-64. NativeAOT's
+broader platform matrix does not establish REA coverage: PE/COFF, ELF, Mach-O,
+shared libraries, target architectures, and runtime metadata versions each need
+their own provider verification. REA's experimental Windows Ghidra boundary is
+limited to admitted native x86-64 PE applications, so it does not currently
+establish coverage for PE DLLs. Mobile NativeAOT targets should remain
+experimental until REA has a matching provider and package-level verification.
+
+For REA's native analysis, preserve the same artifact path and digest used by
+`inspect_managed_artifact`, and report recovered type data as provider
+observations. Linking those types to native function addresses requires verified
+provider evidence; names or vtable similarity alone do not prove that a native
+function implements a specific managed method.
+
 ## Evidence record shape
 
 Every planned operation returns a provider result and Evidence with four

docs/verification/managed-conformance-manifest.json

@@ -1,5 +1,5 @@
 {
-  "manifest_id": "ecm_fbd47cbd3815d7e252ebcb60c4d086dcc1fc6b63f020e83513e28bf4d94c732c",
+  "manifest_id": "ecm_19cf4bddaf5311c3cda82a950883bbc028940ddae8a5e68eeb28374b88585095",
   "verifier": {
     "id": "rea-managed-conformance",
     "version": "1"
@@ -13,7 +13,7 @@
   "skill_digests": [
     {
       "skill_id": "reverse-engineer-anything",
-      "sha256": "b317babebb82157b46b4dff698a170045490bcb21aaf9af582e20908ba2bb998"
+      "sha256": "57f5af72a8f387cbc5249455492297a087a5fff81a986d47f58a7fc879485aef"
     }
   ],
   "claims": [

skills/reverse-engineer-anything/references/native-and-artifacts.md

@@ -37,29 +37,30 @@ assembly. Keep managed/native boundaries and unavailable reconstruction facts
 explicit. A bring-your-own reconstruction oracle is separate from the canonical
 parser and must not become an implicit setup dependency.
 
-## .NET NativeAOT
+### .NET NativeAOT
 
-A NativeAOT PE/ELF contains native code. Absence of PE/CLI metadata does not mean
-analysis must stop at assembly. Use native function analysis for recovered
-pseudocode; it is not reconstructed original C#.
+NativeAOT binaries contain native machine code, so ordinary CIL decompilers
+cannot recover the original method bodies. When managed metadata/CIL is absent,
+classify that as a native-analysis route rather than claiming source recovery.
+Open the native image with the selected deep provider and inspect functions,
+strings, calls, and references; describe decompiler output as pseudocode and
+inference.
 
-With an explicitly configured NativeAOT Ghidra adapter, call
-`inspect_native_load_image` after opening the target. Its optional
-`observations.metadata_recovery` returns the format, positive header evidence,
-coverage, derived-memory identity and type addresses/category paths inline.
-Then inspect a reported type with `inspect_native_data_type`, follow its
-`metadata_recovery.related_type`, interfaces and virtual slot addresses, and use
-`analyze_function` plus string/xref searches for implementation evidence. Keep
-`not_applicable`, partial recovery and unsupported layouts explicit. Generated
-`Class_address` names and inferred System.Object/String identities are not
-original names; custom field layouts remain unknown.
+NativeAOT images can be PE/COFF, ELF, or Mach-O executables and shared
+libraries. Use file bytes and loader metadata rather than suffixes to identify
+them. For packaged apps, inventory/extract with REA's artifact tools and retain
+the exact contained image identity. PDB, ELF debug, or dSYM sidecars are
+additional evidence only when the provider accepts and matches them.
 
-Recovery modifies an ephemeral analysis database and may replace loaded metadata
-bytes with derived content. Original executable files remain unchanged. Distinguish
-original file offsets from derived analysis memory. Windows x64 PE **targets**
-can be analyzed on a supported Linux host; Windows **host** P0 does not admit
-this database recovery. See the [NativeAOT guide](https://github.com/morluto/rea/blob/main/docs/ghidra-nativeaot.md)
-for the tested layout and optional bring-your-own adapter build.
+For deeper type recovery, the optional third-party
+[Ghidra NativeAOT analyzer](https://github.com/Washi1337/ghidra-nativeaot)
+rehydrates ReadyToRun metadata and can recover method tables, type relationships,
+frozen objects, and strings. This is a Ghidra extension with its own install and
+interactive workflow; it is not currently part of REA's managed parser or
+headless Ghidra bridge. Treat its annotations as analysis evidence, retain the
+binary identity, and do not present recovered types as original source. Header
+discovery may require a symbol or analyst identification of the ReadyToRun
+header, depending on the binary and analyzer version.
 
 ## Packages and extraction