Merge remote-tracking branch 'origin/main' into fix/8284-zero-argument-parameter-bindings

fix(native): keep fixed zero-parameter calls out of missing-binding unknowns
trace_native_values reported "Parameter bindings ... are unavailable or omitted" for every call whose callee had no recovered parameter nodes. A Ghidra function with an authored int f(void) signature therefore looked as unresolved as one whose decompiler recovered nothing, and no structured fact distinguished the two or a variadic prototype. The Ghidra bridge now reports native_api.parameter_list: basis "signature" when Ghidra fixes the HighFunction inputs from a non-default signature (an empty one as its void-input lock, otherwise every valid parameter type-locked) and "recovered" otherwise, plus the prototype's varargs flag. The Ghidra adapter requires the fact; the provider-neutral schema keeps it optional so older retained Evidence stays readable with arity unknown. The shared trace omits the unknown only for an analyzed callee whose boundary and value flow have no parameters and whose list has a signature basis and is not variadic. Recovered, variadic or unreported lists, and callees that were not analyzed, keep it. A new Ghidra profile commitment stops replay of snapshots recorded without the fact, and a bridge CI probe checks the basis and varargs flag on real Ghidra decompilations. Fixes #8284 Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-07 05:56:19 -10:00 · 2026-10-31 16:33:56 +00:00 · 2026-10-31 16:33:56 +00:00 · 2026-11-01 00:15:28 +08:00 · 2026-10-31 09:01:06 -07:00 · 2026-10-31 09:00:48 -07:00
1856 changed files with 136323 additions and 31947 deletions
@@ -1,6 +1,6 @@
 ---
 name: rea-tool-design
-description: Design or change REA investigation tools, CLI/MCP contracts, provider capabilities, and Evidence semantics.
+description: Audit, investigate, design, or change REA investigation tools, CLI/MCP contracts, provider capabilities, and Evidence semantics.
 ---

 # REA tool design
@@ -10,6 +10,18 @@ contract semantics, provider ownership, and discoverability. Inspect the current
 contract and nearest existing tool relevant to the analyst question; source,
 documentation, and live catalogs may describe different versions.

+For provider-backed work, exercise the analyst's task through REA and compare
+relevant native provider and independent artifact observations where available.
+Check applicable partial results, recovery and session boundaries; report what
+was not exercised. Use [workflow verification](../../../docs/testing.md#provider-backed-workflow-verification)
+to select evidence for the proposed contract instead of seeking provider API
+parity.
+
+For an audit, follow [audit existing tools](../../../docs/tool-design.md#audit-existing-tools):
+scope representative tasks, exercise the live workflow, and distinguish
+reproduced bugs, supported limitations, design opportunities and unverified
+claims. Report working alternatives and evidence limits as well as findings.
+
 For a design request, return the proposed boundary, input/result shape, Evidence
 semantics, nearest alternative, and verification approach. Implement when
 requested, preserving the user's scope and existing authorization.
@@ -2,7 +2,7 @@
 name: reverse-engineer-anything
 description: Reverse engineer native, managed, Electron/JavaScript, packaged, firmware, and browser targets with REA, and build agent environments (AgentEnv bundles) of web applications from a live instance or a capture. Use shipped-artifact or requested runtime evidence to explain features, compare versions, decompile code, or guide a reconstruction. Skip REA for ordinary source-repository architecture analysis.
 metadata:
-  version: "53"
+  version: "59"
 ---

 # REA
@@ -94,6 +94,9 @@ explicit path or endpoint and do not need it.
  than extra calls and schemas. Runtime options are metadata, not files.
  Compact delivery still inventories and hashes members. See the
  [Python packaged applications guide](https://github.com/morluto/rea/blob/main/docs/python-packaged-applications.md).
+- Bun `--compile` executable: `open_binary`, then `inspect_artifact`; the Bun
+  module graph is the application layer. Extract stored modules and analyze the
+  JavaScript. See [Bun standalone executables](https://github.com/morluto/rea/blob/main/docs/bun-standalone.md).
 - Apple app plist, Interface Builder, asset catalog, or keyed archive resources:
  `open_bundle_resources`, then the selected resource tool. This does not
  require `CFBundleExecutable` or a deep provider. Resource sessions have no
@@ -106,6 +109,8 @@ explicit path or endpoint and do not need it.
  `extract_firmware` when extraction is requested, with a caller-selected new
  absolute output directory. These tools use caller-supplied Binwalk/Unblob on
  Linux; see the [firmware guide](https://github.com/morluto/rea/blob/main/docs/firmware-analysis.md).
+- ESP32-family app or bootloader image (`0xE9` magic): `inspect_artifact`
+  without a provider; see the ESP section of `references/native-and-artifacts.md`.
 - .NET NativeAOT PE/ELF: native Ghidra analysis. Native code can yield pseudocode;
  consult the NativeAOT workflow in `references/native-and-artifacts.md` for
  optional metadata recovery and its supported host/layout boundary.
@@ -145,7 +150,9 @@ explicit path or endpoint and do not need it.
  and field names/types before choosing fields for `inspect_packet_capture`.
  Query/page the relevant records; registrations do not establish observed traffic.
 - Recorded packet captures: `inspect_packet_capture` with selected TShark fields,
-  display filters and decode-as rules. Requires Linux, util-linux prlimit and `REA_TSHARK_COMMAND`; see
+  display filters and decode-as rules. Requires Linux, util-linux prlimit and
+  TShark 4.x on an absolute `PATH` entry or via the optional absolute
+  `REA_TSHARK_COMMAND` override; see
  [capture guide](https://github.com/morluto/rea/blob/main/docs/packet-captures.md).
  Packet limits count input packets before filtering. Output defaults to 50 matching
  frames; use `match_offset` / `match_limit` for later pages, or explicit null
@@ -394,9 +401,18 @@ call `analyze_javascript_application` or `inspect_binary_layout` with
 a flag: its default reply is the summary, and the complete dossier stays
 retained under `parent_evidence_id` for facet paging. Pass that ID as a
 `retained-evidence` reference to `compare_functions`, or inside
-`match_native_functions` `left_observations`/`right_observations`; request
-`"detail": "complete"` only when the dossier must travel inline, as
-`build_call_path` requires.
+`match_native_functions` `left_observations`/`right_observations` or
+`build_call_path.functions`; request `"detail": "complete"` only when the
+dossier must travel inline.
+Use the same exact-reference form in other advertised logical Evidence inputs,
+including optional sources, arrays and nested sources across domains. Each
+source can independently be inline or retained; preserve its source identity,
+coverage, partial facts and unknowns. A summary or inspection page has its own
+Evidence ID: use `normalized_result.parent_evidence_id` when the consumer needs
+the complete source. For portable CLI follow-ups, commands advertising
+`--evidence-bundle` resolve references from that selected exported bundle.
+See [Evidence composition](references/evidence-workflows.md) for scope and
+recovery; file selectors are supported only where explicitly advertised.
 Page module identities and select the returned `node_id` before requesting an
 item; a single file path can represent several graph roles. Do not repeat an
 identical analysis or rejected call without a changed input or resolved blocker.
@@ -124,9 +124,11 @@ shape, with the application's own locators, paths and headers:
 }
 ```

-Give every step a `timeout_ms`. A step without one waits until the scenario
-is cancelled, so a locator that never matches hangs the capture, and the
-client with it. Match `wait_for` locators to exactly one element.
+Give each step that accepts `timeout_ms` a deadline. Without one, a step waits
+until it completes or the scenario is cancelled, so a locator that never
+matches hangs the capture and the client with it. The `wait_for_timeout` pause
+instead uses `duration_ms` and does not accept `timeout_ms`. Match `wait_for`
+locators to exactly one element.

 1. Sign in through the UI: `fill` the user and password fields (the password
   as a secret reference), submit, then `wait_for` an element only a signed-in
@@ -153,13 +155,17 @@ client with it. Match `wait_for` locators to exactly one element.
   with varied free text. After each write, and before the next one, read the
   object back by id and then its list: create 1, read 1, list, create 2,
   read 2, list; never several writes before their reads.
-4. Leave more than a second between a create and its first edit
-   (`wait_for_timeout` with `duration_ms: 1100`).
+4. Leave more than a second between two creates and between a create and its
+   first edit (`wait_for_timeout` with `duration_ms: 1100`), so lists sorted
+   by creation time show them in order.
 5. Update both objects and read each back, changing the fields a person
   would change (a name, an email address, a status, a due date) rather than
   only a description: a served update accepts only the members a recorded
-   update stored. Delete both and read each back (expect 404, or the object
-   marked deleted) and the list.
+   update stored. Run an action that turns something on or off (star,
+   bookmark, archive) twice in a row on one object, reading it back after
+   each: the second call shows whether it sets or flips the field, and the
+   environment serves the action only once a call has shown it. Delete both
+   and read each back (expect 404, or the object marked deleted) and the list.
 6. Vary what the two creates send, however you write them: the first every
   field the application takes, the second only what a person must give (its
   title or name), with the other fields left out or empty. A served create
@@ -235,17 +241,17 @@ Re-record a withheld write at most twice, and only for a recording gap. Stop at
 once when the reason is application behaviour, and report the write as
 withheld with its hint:

-| Reason                | What to do                                                                                    |
-| --------------------- | --------------------------------------------------------------------------------------------- |
-| `no-state-target`     | Re-record: read the collection or item the write changes.                                     |
-| `no-observation`      | Re-record: read the entity back by id after the write; read it first for an update or delete. |
-| `unconfirmed`         | Re-record: read the entity and its list after the write.                                      |
-| `incomplete-entities` | Re-record: read the entity through every view that lists it.                                  |
-| `unexplained-change`  | Re-record once with a second, different call of the same write.                               |
-| `no-call`             | Re-record once with a write that succeeds.                                                    |
-| `side-effect`         | Stop: the application changes other entities.                                                 |
-| `contradicted`        | Stop: a later read disagrees with the modelled effect.                                        |
-| `body-unusable`       | Re-record a UI write once with `request` steps (its body was not exposed); else stop.         |
+| Reason                | What to do                                                                                                                  |
+| --------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| `no-state-target`     | Check the path template and recorded views; record missing reads. The route form may not be supported as a mutation target. |
+| `no-observation`      | Re-record: read the entity back by id after the write; read it first for an update or delete.                               |
+| `unconfirmed`         | Re-record: read the entity and its list after the write.                                                                    |
+| `incomplete-entities` | Re-record: read the entity through every view that lists it.                                                                |
+| `unexplained-change`  | Re-record once with a second, different call of the same write.                                                             |
+| `no-call`             | Re-record once with a write that succeeds.                                                                                  |
+| `side-effect`         | Stop: the application changes other entities.                                                                               |
+| `contradicted`        | Stop: a later read disagrees with the modelled effect.                                                                      |
+| `body-unusable`       | Re-record a UI write once with `request` steps (its body was not exposed); else stop.                                       |

 Use new scratch names on each attempt, and delete what an earlier attempt
 created before recording again (through the UI, or a `request` step with the
@@ -11,6 +11,44 @@ returned inline. When complete `inspect_binary_layout` or
 `inspect_analysis_view` for a summary, one section/symbol/module, or a stable
 page instead of repeating the producer.

+For any logical Evidence source that advertises retained references, pass
+`{kind: "retained-evidence", evidence_id}` instead of copying the complete
+record back into a call. The same contract covers individual, optional, array
+and nested sources across native, process, JavaScript, managed, mobile and WASM
+workflows. Sources can independently mix inline records and exact references.
+Resolution preserves the source's identity, provenance, coverage, partial facts
+and unknowns; it neither reruns analysis nor makes incomplete facts complete.
+Keep domain role and identity requirements: a native dossier cannot substitute
+for a managed member observation, for example.
+
+When starting from a summary or inspection page, use its
+`normalized_result.parent_evidence_id` to reference the complete source.
+The view's own `evidence_id` names
+only that view. `compare_artifacts` explicitly supports artifact summary inputs
+and resolves their parents; do not assume every consumer does. When a workflow
+follows source links, keep those linked records available too.
+
+MCP references belong to the current connection's ledger. If the ID is known,
+pass it directly; no discovery call or provider setup is needed. If it is missing,
+import the exported bundle or supply complete inline Evidence. Do not retry an
+unchanged reference or rerun a producer merely to move an existing record.
+Export before closing the session when the source must survive it. For CLI JSON
+workflows that advertise `--evidence-bundle`, the same reference JSON resolves
+against one explicitly selected authenticated bundle:
+
+```bash
+rea trace-application-feature request.json --evidence-bundle /absolute/path/evidence.json --json
+```
+
+This includes JavaScript traces/comparisons and runtime reconciliation, managed
+reconstruction/native verification/graph projection, Android/Apple/Harmony graph
+projection, WASM interface comparison and retained analysis views. The managed
+member comparison CLI still takes two assembly paths; process comparison takes
+two capture Evidence JSON paths. Check command help for the installed version.
+An input bundle grants no implicit file lookup: `evidence-file` and historical
+graph file selectors are accepted only by contracts advertising them. See the
+[CLI reuse guide](https://github.com/morluto/rea/blob/main/docs/cli.md#import-export-and-compare-evidence).
+
 Completed `inspect_artifact` inventory also supports a summary and
 `view: {kind: "inventory", collection: "occurrences", logical_paths: ["package.json", "main.js"]}`.
 Omit `logical_paths` to page all available occurrences; `[]` selects none.
@@ -46,18 +84,22 @@ Use comparisons with complete, compatible page sets when claiming equivalence
 or absence:

 - `compare_artifacts` compares inventory pages by occurrence path, content,
-  metadata, and graph relations.
+  metadata, and graph relations. Name each side as
+  `{kind: "retained-evidence", evidence_id}` (an `inspect_artifact` result,
+  its nested inventory or its summary) or
+  `{kind: "evidence-file", path, evidence_id?}` instead of resending Evidence.
 - `compare_functions` compares explicit function Evidence, not fuzzy
  whole-binary matches. It rejects an `analyze_function` summary reply; pass
  the summary's `parent_evidence_id` as a `retained-evidence` reference or
  the complete dossier.
 - `compare_bundles` compares canonical bundle membership and unknown history.
 - `find_changed_behavior` combines existing comparisons; static differences
-  remain candidates, not causal proof.
+  remain candidates, not causal proof. Its `comparisons` accept exact references.
 - `build_call_path` needs explicit function dossiers from one artifact/provider;
-  an incomplete frontier makes absence unknown.
+  pass complete parent IDs in `functions`. An incomplete frontier makes absence
+  unknown.
 - `correlate_static_and_runtime` uses explicit mappings; matching patterns are
-  hypotheses, not causality.
+  hypotheses, not causality. Both comparison arrays accept exact references.
 - `verify_reconstruction` evaluates a finite typed specification. A pass covers
  only declared comparable claims, not global equivalence.

@@ -236,8 +236,13 @@ This notation is
 a template: replace it with the actual returned ID. Versions before 4.1.0 accept only full
 inline Evidence. Use the exact ID
 returned by the producer on the same MCP connection. Resolution does not run
-analysis or select a provider; findings remain inline. Native observation
-arrays still take full Evidence. `close_binary` clears retained references;
+analysis or select a provider; findings remain inline. For summary or inspection
+replies, select the complete `normalized_result.parent_evidence_id`. Native
+observation arrays and runtime reconciliation's `static_layers[].analysis` and
+`runtime_observations[]` also accept exact references where advertised. Each
+source can independently be inline or retained, preserving identity, coverage
+and unknowns. CLI workflows advertising `--evidence-bundle` resolve these inputs
+from the explicitly selected bundle. `close_binary` clears retained references;
 export a bundle before closing, or supply portable inline Evidence in another
 connection. A missing reference includes its ID and recovery guidance.

@@ -13,6 +13,13 @@ Select columns, batch IDs and page individual facts; aliases remain unresolved.
 Unpaired observations do not prove additions/removals. Existing matched dossier
 pairs include inputs for `compare_functions`; otherwise analyze just chosen pairs.

+Aggregate completed comparisons with `find_changed_behavior`, selecting each
+comparison's exact `retained-evidence` ID instead of resending full records.
+Inline comparison Evidence remains accepted. References belong to the current
+server: after handoff, import the original bundle including its source closure.
+Do not substitute dossier IDs or summary views. Static differences remain
+behavior candidates, with runtime behavior unknown unless separately observed.
+
 For a matching representation refusal, inspect `details.limit` and raise
 `native.matching_representation_bytes` with `update_analysis_settings` before
 retrying the unchanged MCP request. CLI launch seed:
@@ -516,6 +523,11 @@ names), coverage and per-collection counts. Page rows with
 `view: {kind: "managed-members", collection: "call_edges", offset: 0, limit: 64}`
 over `types`, `exported_types`, `fields`, `methods`, `member_refs`, `call_edges`,
 `field_accesses` or `user_strings`.
+Use exact `names` and `declaring_types` filters before paging supported
+collections. For a compact method lookup, request `fields: ["name",
+"declaring_type", "signature"]`; omit `body` to avoid anchors. Identity tokens,
+original `source_index`, module/MVID and source coverage remain. Check
+`unresolved_filter_rows` before interpreting an empty match as absence.

 ### .NET NativeAOT

@@ -573,6 +585,16 @@ REA. Symlinks and encrypted entries are inventory facts, not extractable files.
 The result reports the materialized directory; callers do not choose the
 destination. No separate permission grant is needed.

+For classic iNES cartridges, `open_binary` recognizes the byte signature without
+an executable architecture. `inspect_artifact` retains header facts and each
+PRG/CHR file unit's offset, length and SHA-256; its nested inventory's
+`ines.reconstruction` verifies the actual ordered region bytes against the
+whole-file digest. Extraction includes the original header, optional trainer
+and uninterpreted trailing bytes. These file units are not mapper/CPU bank
+maps. NES 2.0, UNIF, dirty legacy headers and truncated payloads are explicitly
+refused. No emulator or 6502 analysis is performed. See the
+[iNES guide](https://github.com/morluto/rea/blob/main/docs/ines-containers.md).
+
 Native DMG traversal automatically uses a read-only mount on supported macOS
 hosts, with an owned temporary mount directory and cleanup. It needs no approval
 flag. Unsupported hosts or mount failures remain explicit limitations; do not
@@ -601,10 +623,27 @@ semantics are unsupported. `m68k` requires an even entry and decodes the 68040
 superset of the 68000 family; Amiga/Atari containers and vector-table entry
 discovery are unsupported. Windows Ghidra P0 admits raw images only for `6502`. See [raw binary guide](https://github.com/morluto/rea/blob/main/docs/raw-binary.md).

+Intel HEX, S-record, UF2 and DfuSe files are containers, not raw images:
+`inspect_artifact` lists address regions (UF2 per familyID, DfuSe per element
+with its alternate setting), and `extract_artifact` writes each region. Open an
+extracted region as `raw-binary` with its start address as `entry_point`. UF2
+numbering gaps leave coverage unknown; a DfuSe suffix CRC mismatch follows
+`integrity_policy`. See [UF2 and DfuSe](https://github.com/morluto/rea/blob/main/docs/uf2-dfuse.md).
+
 ### Function annotations in Ghidra

 Fresh-import sessions admit annotations; existing-project reuse is read-only.
-Use `annotate_native_function` for one function name and/or entry comments, with at least one explicit change. Review its annotation readback and refreshed dossier inline. Changes are atomic and session-scoped; empty comments clear them, omitted fields preserve them. Later MCP calls observe edits until close. CLI `annotate-native-function` returns the updated analysis before discarding the session. Original executable bytes are unchanged; edits invalidate immutable snapshots. Windows P0 does not admit database mutations. For naming only, `set_address_name` / `set_addresses_names` also work with Ghidra: they name function entries or data addresses (primary labels) and return compact per-address success booleans instead of a dossier.
+Use `annotate_native_function` for one function name and/or entry comments, with at least one explicit change. Review its annotation readback and refreshed dossier inline. Changes are atomic and session-scoped; empty comments clear them, omitted fields preserve them. Later MCP calls observe edits until close. CLI `annotate-native-function` returns the updated analysis before discarding the session. Original executable bytes are unchanged; edits invalidate immutable snapshots. Windows P0 does not admit database mutations. For naming only, `set_address_name` / `set_addresses_names` also work with Ghidra: they name function entries or data addresses (primary labels) and return compact per-address success booleans instead of a dossier. Ghidra rejects batch addresses that request the same name or a name another selected address holds; `raw_result.failures` gives each failure's reason.
+
+For `compare_functions`, obtain `analyze_function` Evidence before and after the
+edit while the MCP session is open; annotation Evidence is not a comparison
+input. Export the needed Evidence before close if comparison will happen later.
+Authenticated same-artifact coordinates preserve renamed entries as
+`matched / same-entry`, with the canonical `entry_address` inline; name and
+exact-text changes remain separate dimensions. This requires compatible
+architecture, provider-owned mapping and selected-image commitments. Equal
+numeric addresses alone cannot establish correspondence; inspect retained
+source Evidence and coverage when the match remains ambiguous.

 ## Offline PE resource inventory

@@ -632,7 +671,9 @@ For exact core-module import/export differences, use `compare_wasm_interfaces`
 with two complete inspection Evidence records (or current-session retained
 references) and explicit scope. Preserve unknown types/duplicate names; static
 interface equality is not runtime compatibility. CLI accepts complete inline
-Evidence in `rea compare-wasm-interfaces input.json --json`.
+Evidence in `rea compare-wasm-interfaces input.json --json`, or exact references
+with `--evidence-bundle /absolute/path/evidence.json`. Use the complete parent
+ID when the inspection returned a summary.

 ## Godot PCK

@@ -669,3 +710,67 @@ IDs. Header addresses/CPU/OS are declarations; payloads remain as stored.
 Multi-file components retain their aligned physical ranges; the full payload
 is also materialized. Unknown name text retains its original 32 bytes. See
 [U-Boot uImage](https://github.com/morluto/rea/blob/main/docs/uimage.md).
+
+## ESP images
+
+For an ESP32-family app or bootloader image, `open_binary` then
+`inspect_artifact` with `detail: "summary"`. `root_format_metadata` holds the
+observed `header` and `descriptor` (its `kind` is the app or bootloader role)
+and the derived `chip`, `checksum`, `appended_sha256` and
+`undescribed_trailing` ranges. Segment rows (`segment-NN.bin`) carry
+`load_addr`, `classification` (`mapped`, `loaded`, `not-loaded` or `unknown`,
+per ESP-IDF `should_map`/`should_load`; RAM ranges are not checked) and
+`source_location`; select them with `inspect_analysis_view` and
+`logical_paths`. Signature blocks are `unverified`; `public_key_sha256`
+matches eFuse key digests.
+
+Unknown `source_coverage` means truncation or undescribed trailing bytes, such
+as the flash segments of a `--ram-only-header` image; do not infer absence
+from it. Erased flash is described. Integrity mismatches are facts, not
+refusals. ESP8266 images are refused, and flash-encrypted images are not
+recognized. Segments are not disassembled, and RISC-V or Xtensa segments
+cannot be opened as raw-binary. See
+[ESP images](https://github.com/morluto/rea/blob/main/docs/esp-image.md).
+
+## ESP flash images
+
+A whole-flash dump opens as `esp-flash-image`. `root_format_metadata` holds
+`partition_table` (its `method`: `default`, `caller` or a derived
+`scan`), `bootloader` and `apps` ESP image facts, the `otadata` records,
+`partitions_outside_dump` and `boot_selection`. Every table has a
+`boot_selection`: its `basis` names the bootloader's branch (`no-otadata`
+without otadata, `none` when the bootloader rejects the table, `unknown`
+when a record is missing), and it lists its `assumptions`;
+`running_partition` is always `unknown`. Each image names its entry
+`path`. With `detail: "summary"` the root kind is `esp-flash-image-summary`
+and each image is a compact `summary` (chip, entry point, segment count,
+classified load ranges, signature block count, descriptor identity,
+integrity); complete detail keeps every segment. Partition rows
+(`partitions/<label>.bin`) carry the declared `type`, `subtype`, names,
+`flash_address`, `size` and flags; `encrypted` is a storage flag, not
+proof of ciphertext. `written_offset`/`written_end` bound the bytes that
+are not erased: an app slot whose facts say `erased` can still hold an older
+image, and a limitation says so. For a dump read from another flash address, call
+`open_binary` with `format: "esp-flash-image"` and `flash_offset`; an
+`esp-image` whose `flash_dump` is set names that offset in a next probe; a
+relocated table can be named with `partition_table_offset`. No table found
+means unknown, often flash encryption. Extraction writes `nvs_keys` as
+ordinary data. See
+[ESP flash images](https://github.com/morluto/rea/blob/main/docs/esp-flash-image.md).
+
+## Bun standalone executables
+
+A `bun build --compile` executable stores its module graph in Mach-O
+`__BUN,__bun`, a PE or ELF `.bun` section, or an appended trailer.
+`open_binary` then `inspect_artifact` reports root format `bun-standalone` with
+the carrier, structural layout, module count, entry point, raw flags and
+compile exec-argv; each module keeps its `/$bunfs/...` source name, loader,
+encoding, sizes and SHA-256, with sourcemap, bytecode and module-info regions as
+separate children. Use summary root metadata `entry_point_logical_path` as the
+exact inventory `logical_paths` selector, then read the selected content node by
+its artifact ID; the reader owns virtual-name normalization and indexed fallback. `extract-artifact` writes stored contents through the safe
+output tree; route extracted JavaScript to `analyze_javascript_application`.
+Layout labels describe record shapes, not a detected compiler version; unknown
+or ambiguous layouts are unsupported. Bytecode is retained, not decoded, and the
+executable is never run. See
+[Bun standalone executables](https://github.com/morluto/rea/blob/main/docs/bun-standalone.md).
@@ -0,0 +1,12 @@
+# Review changes to security-sensitive automation and dependency inputs.
+/.github/CODEOWNERS @morluto @kaoru0822-kitauji @N0zoM1z0 @gensokyo-dev
+/.github/dependabot.yml @morluto @kaoru0822-kitauji @N0zoM1z0 @gensokyo-dev
+/.github/workflows/ @morluto @kaoru0822-kitauji @N0zoM1z0 @gensokyo-dev
+/.github/actions/ @morluto @kaoru0822-kitauji @N0zoM1z0 @gensokyo-dev
+/package.json @morluto @kaoru0822-kitauji @N0zoM1z0 @gensokyo-dev
+/package-lock.json @morluto @kaoru0822-kitauji @N0zoM1z0 @gensokyo-dev
+/scripts/verify-tools/skills/package.json @morluto @kaoru0822-kitauji @N0zoM1z0 @gensokyo-dev
+/scripts/verify-tools/skills/package-lock.json @morluto @kaoru0822-kitauji @N0zoM1z0 @gensokyo-dev
+/scripts/fixtures/http3-lab-requirements.txt @morluto @kaoru0822-kitauji @N0zoM1z0 @gensokyo-dev
+/website/requirements.txt @morluto @kaoru0822-kitauji @N0zoM1z0 @gensokyo-dev
+/third_party/ @morluto @kaoru0822-kitauji @N0zoM1z0 @gensokyo-dev
@@ -0,0 +1,33 @@
+version: 2
+updates:
+  - package-ecosystem: npm
+    directories:
+      - /
+      - /scripts/verify-tools/skills
+    schedule:
+      interval: weekly
+    cooldown:
+      default-days: 7
+    open-pull-requests-limit: 5
+    groups:
+      npm-minor-and-patch:
+        update-types:
+          - minor
+          - patch
+
+  - package-ecosystem: pip
+    directory: /website
+    schedule:
+      interval: weekly
+    open-pull-requests-limit: 5
+
+  - package-ecosystem: github-actions
+    directory: /
+    schedule:
+      interval: weekly
+    open-pull-requests-limit: 5
+    groups:
+      actions-minor-and-patch:
+        update-types:
+          - minor
+          - patch
@@ -61,6 +61,9 @@ jobs:
      qualification_run_id: ${{ steps.qualification.outputs.run_id }}
      code: ${{ steps.plan.outputs.code }}
      reverse_tools: ${{ steps.plan.outputs.reverse_tools }}
+      python: ${{ steps.plan.outputs.python }}
+      packet_capture: ${{ steps.plan.outputs.packet_capture }}
+      signal_recording: ${{ steps.plan.outputs.signal_recording }}
      sqlite: ${{ steps.plan.outputs.sqlite }}
      runtime: ${{ steps.plan.outputs.runtime }}
      package: ${{ steps.plan.outputs.package }}
@@ -144,6 +147,9 @@ jobs:
      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
        with:
          node-version-file: .nvmrc
+      - name: Validate source architecture before dependency installation
+        if: needs.changes.outputs.code == 'true'
+        run: node scripts/verify/architecture-guards.mjs
      - name: Cache npm package downloads
        id: npm-cache
        uses: ./.github/actions/npm-cache
@@ -264,6 +270,27 @@ jobs:
          if-no-files-found: ignore
          retention-days: 7

+  python:
+    name: Python producer tests
+    needs: changes
+    if: needs.changes.outputs.python == 'true' && needs.changes.outputs.tier == 'fast'
+    runs-on: ubuntu-latest
+    timeout-minutes: 10
+    steps:
+      - uses: actions/checkout@11d5960a326750d5838078e36cf38b85af677262 # v4.4.0
+      - uses: actions/setup-node@49933ea5288caeca8642d1e84afbd3f7d6820020 # v4.4.0
+        with:
+          node-version-file: .nvmrc
+      - name: Cache npm package downloads
+        id: npm-cache
+        uses: ./.github/actions/npm-cache
+      - run: npm ci
+      # Analysis-efficiency checks import compiled process modules.
+      - name: Reuse portable build outputs across runs
+        uses: ./.github/actions/portable-build-cache
+      - run: npm run test:prepare
+      - run: npm run test:python
+
  test-source:
    name: Source tests
    needs: changes
@@ -391,7 +418,9 @@ jobs:
      needs.changes.outputs.web_network == 'true' ||
      needs.changes.outputs.web_runtime == 'true' ||
      needs.changes.outputs.web_source_map == 'true' ||
-      needs.changes.outputs.agentenv == 'true'
+      needs.changes.outputs.agentenv == 'true' ||
+      needs.changes.outputs.packet_capture == 'true' ||
+      needs.changes.outputs.signal_recording == 'true'
    runs-on: ubuntu-latest
    timeout-minutes: 10
    permissions:
@@ -750,6 +779,12 @@ jobs:
          npm run verify:legacy-simulator
          npm run verify:apple-dispatch
          npm run verify:interface-builder
+      - name: Verify portable iNES CLI, MCP and source boundaries
+        run: >-
+          npm run test:focused --
+          tests/acceptance/inesContainer.test.ts
+          tests/boundary/filesystem/inesArtifact.test.ts
+          tests/boundary/filesystem/inesCancellation.test.ts
      - name: Run native Apple and process boundary regressions
        run: >-
          npm run test:focused --
@@ -770,9 +805,11 @@ jobs:
          tests/boundary/cli/nativeDemangleCli.test.ts
          tests/boundary/cli/nativeDispatchPropertyAttributes.test.ts
          tests/boundary/mcp/nativeDemangleMcp.test.ts
+          tests/boundary/mcp/nativeMachoSummaryMcp.test.ts
          tests/boundary/providers/native/nativeSignatureTargetBinding.test.ts
          tests/boundary/cli/nativeSignatureCli.test.ts
          tests/boundary/cli/nativeMachoArm64_32Cli.test.ts
+          tests/boundary/cli/nativeMachoEncryptionCli.test.ts
          tests/boundary/mcp/nativeSignatureTargetBindingMcp.test.ts
          src/process/capture/FilesystemSnapshot.test.ts
          tests/process-global/filesystemSnapshotFallbackCancellation.test.ts
@@ -1091,6 +1128,26 @@ jobs:
      build_cache_artifact: rea-build-cache
      remote_cache_write: ${{ inputs.remote_cache_write == true || (github.ref == format('refs/heads/{0}', github.event.repository.default_branch) && (github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch')) }}

+  packet_capture:
+    needs: [changes, static, build]
+    if: needs.changes.outputs.packet_capture == 'true'
+    secrets:
+      TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
+    uses: ./.github/workflows/real-packet-capture.yml
+    with:
+      build_cache_artifact: rea-build-cache
+      remote_cache_write: ${{ inputs.remote_cache_write == true || (github.ref == format('refs/heads/{0}', github.event.repository.default_branch) && (github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch')) }}
+
+  signal_recording:
+    needs: [changes, static, build]
+    if: needs.changes.outputs.signal_recording == 'true'
+    secrets:
+      TURBO_TOKEN: ${{ secrets.TURBO_TOKEN }}
+    uses: ./.github/workflows/real-signal-recording.yml
+    with:
+      build_cache_artifact: rea-build-cache
+      remote_cache_write: ${{ inputs.remote_cache_write == true || (github.ref == format('refs/heads/{0}', github.event.repository.default_branch) && (github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch')) }}
+
  nativeaot:
    needs: [changes, static]
    if: needs.changes.outputs.nativeaot == 'true'
@@ -1117,6 +1174,9 @@ jobs:
        static-deep,
        build,
        reverse-tools-quality,
+        python,
+        packet_capture,
+        signal_recording,
        test-shard,
        test-source,
        sqlite-runtime,
@@ -62,3 +62,63 @@ jobs:
            > "${probe_root}/output.log" 2>&1 || { cat "${probe_root}/output.log"; exit 1; }
          cat "${probe_root}/output.log"
          grep -F 'REA_ARM_CONTEXT_OK arm=0 thumb=1 unavailable=null (injected provider value)' "${probe_root}/output.log"
+      # Each probe imports source-owned bytes at 0x1000, away from the Cortex-M
+      # vector symbols that ARMCortex.pspec defines at 0, and decodes them from
+      # the language's default context, so M-profile Thumb state must hold at
+      # the first byte. The bytes are never executed.
+      - name: Decode M-profile ARM and Xtensa bytes in their default context
+        shell: bash
+        run: |
+          java_home_variable="JAVA_HOME_${GHIDRA_JAVA_MAJOR}_X64"
+          export JAVA_HOME="${!java_home_variable}"
+          probe_root="${RUNNER_TEMP}/rea-decode"
+          mkdir -p "${probe_root}"
+          # mrs r0, msp; bx lr
+          printf '\357\363\010\200\160\107' > "${probe_root}/cortex.bin"
+          # mrs r0, msplim (ARMv8-M only); bx lr
+          printf '\357\363\012\200\160\107' > "${probe_root}/v8m.bin"
+          # entry a1, 32; retw.n
+          printf '\066\101\000\035\360' > "${probe_root}/xtensa.bin"
+          decode() {
+            local name="$1" language="$2"
+            shift 2
+            mkdir -p "${probe_root}/${name}-project"
+            timeout 180s "${GHIDRA_INSTALL_DIR}/support/analyzeHeadless" "${probe_root}/${name}-project" Decode \
+              -import "${probe_root}/${name}.bin" -loader BinaryLoader -loader-baseAddr 0x1000 \
+              -processor "${language}" -noanalysis -readOnly -deleteProject \
+              -scriptPath "${GITHUB_WORKSPACE}/tests/conformance/ghidra" \
+              -postScript ReaDecodeProbe.java "${language}" "$@" \
+              > "${probe_root}/${name}.log" 2>&1 || { cat "${probe_root}/${name}.log"; exit 1; }
+            cat "${probe_root}/${name}.log"
+            grep -F "REA_DECODE_OK ${language} $*" "${probe_root}/${name}.log"
+          }
+          decode cortex ARM:LE:32:Cortex mrs/4/msp bx/2/lr
+          decode v8m ARM:LE:32:v8-m mrs/4/msplim bx/2/lr
+          decode xtensa Xtensa:LE:32:default entry/3/a1 retw.n/2
+      # Authored void, variadic and one-parameter signatures fix Ghidra's
+      # HighFunction inputs; default signatures are recovered from uses. Only
+      # the signatures are authored. The source-owned x86-64 bytes are never
+      # executed.
+      - name: Distinguish fixed from recovered HighFunction parameter lists
+        shell: bash
+        run: |
+          java_home_variable="JAVA_HOME_${GHIDRA_JAVA_MAJOR}_X64"
+          export JAVA_HOME="${!java_home_variable}"
+          probe_root="${RUNNER_TEMP}/rea-parameter-list"
+          mkdir -p "${probe_root}/project"
+          {
+            printf '\270\001\000\000\000\303\314\314' # 0x1000: mov eax, 1; ret (default)
+            printf '\270\001\000\000\000\303\314\314' # 0x1008: int f(void)
+            printf '\270\001\000\000\000\303\314\314' # 0x1010: int f(...)
+            printf '\270\001\000\000\000\303\314\314' # 0x1018: int f(int x)
+            printf '\215\004\017\303\314\314\314\314' # 0x1020: lea eax, [rdi + rcx]; ret (default)
+          } > "${probe_root}/parameter-list.bin"
+          test "$(wc -c < "${probe_root}/parameter-list.bin")" -eq 40
+          timeout 180s "${GHIDRA_INSTALL_DIR}/support/analyzeHeadless" "${probe_root}/project" ParameterList \
+            -import "${probe_root}/parameter-list.bin" -loader BinaryLoader -loader-baseAddr 0x1000 \
+            -processor x86:LE:64:default -noanalysis -readOnly -deleteProject \
+            -scriptPath "${GITHUB_WORKSPACE}/tests/conformance/ghidra;${GITHUB_WORKSPACE}/bridge/ghidra" \
+            -postScript ReaParameterListProbe.java "${GITHUB_WORKSPACE}/bridge/ghidra" \
+            > "${probe_root}/output.log" 2>&1 || { cat "${probe_root}/output.log"; exit 1; }
+          cat "${probe_root}/output.log"
+          grep -F 'REA_PARAMETER_LIST_OK default=recovered void=signature varargs=variadic one=signature used=recovered' "${probe_root}/output.log"
@@ -11,6 +11,7 @@ on:
      - tests/conformance/android/**
      - tests/fixtures/android/static-initializers/**
      - tests/fixtures/android/direct-invokes/**
+      - tests/fixtures/android/external-invokes/**
      - .nvmrc
  workflow_dispatch:
  workflow_call:
@@ -44,7 +45,8 @@ jobs:
          "$JAVA_HOME/bin/javac" -J-Xmx512m -J-XX:ActiveProcessorCount=2 \
            -classpath "$jar" -d "$classes" \
            bridge/android/ReaJadxBridge.java \
-            tests/conformance/android/ReaJadxMetadataRegression.java
+            tests/conformance/android/ReaJadxMetadataRegression.java \
+            tests/conformance/android/ReaJadxExternalReferencesRegression.java
          "$JAVA_HOME/bin/java" -Xmx512m -XX:ActiveProcessorCount=2 \
            -classpath "$classes:$jar" ReaJadxMetadataRegression \
            "$android_root/ApiDemos-debug.apk" \
@@ -53,3 +55,9 @@ jobs:
            | tee "$android_root/metadata.log"
          grep -F 'RAW_CLASS_SELECTOR_REGRESSION_PASS nested=true metadata=true references=true' \
            "$android_root/metadata.log"
+          "$JAVA_HOME/bin/java" -Xmx512m -XX:ActiveProcessorCount=2 \
+            -classpath "$classes:$jar" ReaJadxExternalReferencesRegression \
+            "$GITHUB_WORKSPACE/tests/fixtures/android/external-invokes" "$classes" \
+            | tee "$android_root/external-references.log"
+          grep -F 'EXTERNAL_REFERENCE_REGRESSION_PASS prototypes=2 using_nodes=3 sites=4' \
+            "$android_root/external-references.log"
@@ -53,3 +53,8 @@ jobs:
        env:
          REA_BROWSER_EXECUTABLE: /usr/bin/google-chrome
          REA_BROWSER_NO_SANDBOX: "true"
+      # The preceding verifier builds the runtime used by this request journey.
+      - run: dbus-run-session -- node scripts/verify-browser-request.mjs
+        env:
+          REA_BROWSER_EXECUTABLE: /usr/bin/google-chrome
+          REA_BROWSER_NO_SANDBOX: "true"
@@ -1,39 +1,35 @@
 name: Real packet capture
 on:
+  workflow_call:
+    inputs:
+      build_cache_artifact:
+        description: Portable build cache artifact from the calling CI run.
+        required: false
+        type: string
+        default: ""
+      remote_cache_write:
+        description: Trusted release qualification may publish the remote cache.
+        required: false
+        type: boolean
+        default: false
+    secrets:
+      TURBO_TOKEN:
+        description: Remote cache token. Only trusted callers pass it.
+        required: false
  workflow_dispatch:
-  pull_request:
-    paths:
-      - "tests/boundary/captures/**"
-      - "tests/boundary/cli/captureCleanup.test.ts"
-      - "tests/boundary/mcp/packetCaptureMcp.test.ts"
-      - "src/captures/**"
-      - "src/pcap/**"
-      - "src/domain/pcap/**"
-      - "src/domain/analysisView/pcapCaptureView.ts"
-      - "src/application/pcap/**"
-      - "src/contracts/pcap/**"
-      - "src/server/registerPcapTools.ts"
-      - "tests/boundary/pcap/**"
-      - "src/domain/captures/**"
-      - "src/application/captures/**"
-      - "src/contracts/captures/**"
-      - "src/composition/captures.ts"
-      - "src/cli/captureCommands.ts"
-      - "src/server/registerCaptureTools.ts"
-      - "scripts/verify-packet-capture.mjs"
-      - ".github/workflows/real-packet-capture.yml"
-permissions:
-  contents: read
+
 env:
  HUSKY: "0"
-  # Writes only on the default branch for push, schedule, manual dispatch,
-  # and workflow_call. Pull requests get an empty token and remote read-only mode.
-  TURBO_TOKEN: "${{ (github.ref == format('refs/heads/{0}', github.event.repository.default_branch) && (github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' || github.event_name == 'workflow_call')) && secrets.TURBO_TOKEN || '' }}"
+  # A called workflow sees the caller event, so workflow_call is not an event
+  # name here. Writes when remote_cache_write is set, or on the default branch
+  # for push, schedule, and manual dispatch. Open pull requests stay empty-token
+  # and use the local cache only.
+  TURBO_TOKEN: "${{ (inputs.remote_cache_write == true || (github.ref == format('refs/heads/{0}', github.event.repository.default_branch) && (github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'))) && secrets.TURBO_TOKEN || '' }}"
  TURBO_TEAM: ${{ vars.TURBO_TEAM }}
-  TURBO_CACHE: "${{ (github.ref == format('refs/heads/{0}', github.event.repository.default_branch) && (github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' || github.event_name == 'workflow_call')) && 'local:rw,remote:rw' || 'local:rw,remote:r' }}"
-concurrency:
-  group: real-packet-capture-${{ github.event.pull_request.number || github.ref }}
-  cancel-in-progress: true
+  TURBO_CACHE: "${{ (inputs.remote_cache_write == true || (github.ref == format('refs/heads/{0}', github.event.repository.default_branch) && (github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'))) && 'local:rw,remote:rw' || 'local:rw' }}"
+
+permissions:
+  contents: read
 jobs:
  tshark:
    runs-on: ubuntu-24.04
@@ -48,8 +44,18 @@ jobs:
        uses: ./.github/actions/npm-cache
      - run: sudo apt-get update && sudo DEBIAN_FRONTEND=noninteractive apt-get install -y tshark util-linux python3
      - run: npm ci
+      - uses: ./.github/actions/portable-build-cache
+        with:
+          build_cache_artifact: ${{ inputs.build_cache_artifact }}
      - run: npm run build:cached
-      - run: npm run test:focused -- tests/boundary/captures/fieldDiscovery.test.ts src/process/LinuxResourceLimits.test.ts tests/boundary/captures/captureProvider.test.ts tests/boundary/captures/captureDescriptorCleanup.test.ts tests/boundary/pcap/pcapProvider.test.ts tests/boundary/pcap/pcapProviderCrossPlatform.test.ts tests/boundary/captures/resourceLimits.test.ts tests/boundary/captures/packetOutput.test.ts tests/boundary/mcp/packetCaptureMcp.test.ts tests/boundary/cli/captureCleanup.test.ts
+      - name: Run focused tests and require Linux resource and cleanup cases
+        run: |
+          report=".cache/rea-packet-required-tests.json"
+          mkdir -p .cache
+          rm -f "$report"
+          node scripts/run-exact-tests.mjs run --reporter=default --reporter=json --outputFile.json="$report" \
+            tests/boundary/captures/fieldDiscovery.test.ts src/process/LinuxResourceLimits.test.ts tests/boundary/captures/captureProvider.test.ts tests/boundary/captures/captureDescriptorCleanup.test.ts tests/boundary/pcap/pcapProvider.test.ts tests/boundary/pcap/pcapProviderCrossPlatform.test.ts tests/boundary/captures/resourceLimits.test.ts tests/boundary/captures/packetOutput.test.ts tests/boundary/mcp/packetCaptureMcp.test.ts tests/boundary/cli/captureCleanup.test.ts tests/acceptance/pcapVerifier.test.ts
+          node scripts/ci/require-provider-tests.mjs packet "$report"
      - run: node scripts/verify-packet-capture.mjs
        env:
          REA_TSHARK_COMMAND: /usr/bin/tshark
@@ -1,32 +1,35 @@
 name: Real signal recording
 on:
+  workflow_call:
+    inputs:
+      build_cache_artifact:
+        description: Portable build cache artifact from the calling CI run.
+        required: false
+        type: string
+        default: ""
+      remote_cache_write:
+        description: Trusted release qualification may publish the remote cache.
+        required: false
+        type: boolean
+        default: false
+    secrets:
+      TURBO_TOKEN:
+        description: Remote cache token. Only trusted callers pass it.
+        required: false
  workflow_dispatch:
-  pull_request:
-    paths:
-      - "tests/boundary/signals/**"
-      - "tests/boundary/cli/signalCleanup.test.ts"
-      - "tests/boundary/mcp/signalRecordingMcp.test.ts"
-      - "src/signals/**"
-      - "src/domain/signals/**"
-      - "src/application/signals/**"
-      - "src/contracts/signals/**"
-      - "src/composition/signals.ts"
-      - "src/cli/signalCommands.ts"
-      - "src/server/registerSignalTools.ts"
-      - "scripts/verify-signal-recording.mjs"
-      - ".github/workflows/real-signal-recording.yml"
-permissions:
-  contents: read
+
 env:
  HUSKY: "0"
-  # Writes only on the default branch for push, schedule, manual dispatch,
-  # and workflow_call. Pull requests get an empty token and remote read-only mode.
-  TURBO_TOKEN: "${{ (github.ref == format('refs/heads/{0}', github.event.repository.default_branch) && (github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' || github.event_name == 'workflow_call')) && secrets.TURBO_TOKEN || '' }}"
+  # A called workflow sees the caller event, so workflow_call is not an event
+  # name here. Writes when remote_cache_write is set, or on the default branch
+  # for push, schedule, and manual dispatch. Open pull requests stay empty-token
+  # and use the local cache only.
+  TURBO_TOKEN: "${{ (inputs.remote_cache_write == true || (github.ref == format('refs/heads/{0}', github.event.repository.default_branch) && (github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'))) && secrets.TURBO_TOKEN || '' }}"
  TURBO_TEAM: ${{ vars.TURBO_TEAM }}
-  TURBO_CACHE: "${{ (github.ref == format('refs/heads/{0}', github.event.repository.default_branch) && (github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch' || github.event_name == 'workflow_call')) && 'local:rw,remote:rw' || 'local:rw,remote:r' }}"
-concurrency:
-  group: real-signal-recording-${{ github.event.pull_request.number || github.ref }}
-  cancel-in-progress: true
+  TURBO_CACHE: "${{ (inputs.remote_cache_write == true || (github.ref == format('refs/heads/{0}', github.event.repository.default_branch) && (github.event_name == 'push' || github.event_name == 'schedule' || github.event_name == 'workflow_dispatch'))) && 'local:rw,remote:rw' || 'local:rw' }}"
+
+permissions:
+  contents: read
 jobs:
  sigrok:
    runs-on: ubuntu-24.04
@@ -41,8 +44,18 @@ jobs:
        uses: ./.github/actions/npm-cache
      - run: sudo apt-get update && sudo apt-get install -y sigrok-cli util-linux python3
      - run: npm ci
+      - uses: ./.github/actions/portable-build-cache
+        with:
+          build_cache_artifact: ${{ inputs.build_cache_artifact }}
      - run: npm run build:cached
-      - run: npm run test:focused -- tests/boundary/signals/decoderDiscovery.test.ts src/process/LinuxResourceLimits.test.ts src/domain/signals/annotationTextWindow.test.ts tests/boundary/signals/recordingProvider.test.ts tests/boundary/signals/recordingDescriptorCleanup.test.ts tests/boundary/signals/resourceLimits.test.ts tests/boundary/mcp/signalRecordingMcp.test.ts tests/boundary/cli/signalCleanup.test.ts
+      - name: Run focused tests and require Linux resource and cleanup cases
+        run: |
+          report=".cache/rea-signal-required-tests.json"
+          mkdir -p .cache
+          rm -f "$report"
+          node scripts/run-exact-tests.mjs run --reporter=default --reporter=json --outputFile.json="$report" \
+            tests/boundary/signals/decoderDiscovery.test.ts src/process/LinuxResourceLimits.test.ts src/domain/signals/annotationTextWindow.test.ts tests/boundary/signals/recordingProvider.test.ts tests/boundary/signals/recordingDescriptorCleanup.test.ts tests/boundary/signals/resourceLimits.test.ts tests/boundary/mcp/signalRecordingMcp.test.ts tests/boundary/cli/signalCleanup.test.ts
+          node scripts/ci/require-provider-tests.mjs signal "$report"
      - run: node scripts/verify-signal-recording.mjs
        env:
          REA_SIGROK_COMMAND: /usr/bin/sigrok-cli
@@ -232,6 +232,8 @@ Use the development toolchain pinned in `.nvmrc` and
 `package.json#packageManager`. Run `nvm use` before installing dependencies;
 installed-package runtime support is documented in
 [installation](docs/installation.md#start-setup).
+Use Node.js and npm for source builds and verifier scripts; the installed
+package's Bun runtime support does not extend to those development scripts.

 ```bash
 npm ci
@@ -246,6 +248,15 @@ catalogs, documentation projections, or managed verification evidence. Turbo
 caches deterministic builds and static checks across Git worktrees. After a package, lockfile, or managed-skill version change, run
 `npm run metadata:generate` before building.

+Dependabot proposes updates for the npm lockfiles, website Python requirements,
+and GitHub Actions. Review dependency changes and run the checks relevant to
+their consumers. For dependencies maintained outside Dependabot, including
+`third_party/` and the HTTP/3 lab's pinned requirements, the maintainer should
+review upstream security advisories when updating or using them. Preserve source
+and version provenance, update license notices when needed, and report which
+verification was actually repeated. The lab requirements describe a recorded
+environment; a dependency update does not verify the revised environment.
+
 Repository invariants live in [AGENTS.md](AGENTS.md). Keep provider-specific
 protocols in adapters and shared CLI/MCP workflows in the application layer.

@@ -272,7 +283,10 @@ The general source suite (`npm run test:fast`, `npm run test:changed`, and
 On a Windows checkout, some source tests fail because fixtures use POSIX paths,
 `#!/bin/sh` tool stubs, or POSIX rename semantics. Compare failures against the
 base revision, or run the suite on Linux or WSL, before attributing them to a
-change. See [testing](docs/testing.md#developer-commands) for command scopes
+change. The embedded-artifact parent-swap tests exercise the selected-path
+replacement when the rename succeeds; if Windows refuses it while the admitted
+file is open, they instead verify the refusal and cleanup. See
+[testing](docs/testing.md#developer-commands) for command scopes
 and lane selection.

 `git submodule update --init --recursive` fails at the pinned Unblob submodule
@@ -62,7 +62,7 @@ See a feature in an app that you want in your own product? Ask your agent to inv

 REA connects your agent to tools for inspecting native binaries, JavaScript and Electron apps, .NET assemblies, and websites. You can also use the same tools from your terminal. Analysis runs locally, and results include the evidence and limitations behind each conclusion.

-Setup registers REA with your agent and installs matching workflow instructions. Native analysis can use an existing Hopper, Ghidra, or IDA installation; setup can optionally install Hopper with approval. Static JavaScript analysis needs no native analysis engine.
+Setup registers REA with your agent and installs matching workflow instructions. Native analysis can use an existing Hopper, Ghidra, IDA or Kuna installation; setup can optionally install Hopper with approval. Static JavaScript analysis needs no native analysis engine.

 > **[Visit the REA website](https://rea.tools/)** for setup instructions, illustrated guides, and real case studies.

@@ -192,7 +192,7 @@ Additional tools and host support depend on the target:
 | Target                  | What REA returns                                                                                  | Requirements and guide                                                                                                                |
 | ----------------------- | ------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
 | Desktop installations   | Runtime candidates, supporting files, component markers and next probes                           | Built-in bounded directory/header inspection; [desktop applications](docs/desktop-applications.md)                                    |
-| Native binaries         | Pseudocode, assembly, strings, symbols, calls and references                                      | Hopper, Ghidra or IDA; [native analysis](docs/native-investigation.md)                                                                |
+| Native binaries         | Pseudocode, assembly, strings, symbols, calls and references                                      | Hopper, Ghidra, IDA or Kuna; [native analysis](docs/native-investigation.md)                                                          |
 | Offline ELF layout      | Sections, segments, original symbols/relocations and static mitigation candidates                 | Caller-supplied pwntools on Linux x64; [binary diagnostics](docs/binary-diagnostics.md)                                               |
 | Go binaries             | Embedded compiler version, modules, replacements and build settings                               | Built-in static ELF/PE/thin Mach-O inspection; no Go installation required                                                            |
 | GPU code objects        | CUDA/HIP targets, selected kernel parameters and resources, retained PTX text                     | Built-in static ELF/PE/fatbin/CUBIN/PTX inspection; [GPU code objects](docs/gpu-code-objects.md)                                      |
@@ -344,11 +344,13 @@ Any agent that supports local MCP servers. Setup configures the
 </details>

 <details>
-<summary><strong>Do I need Hopper, Ghidra or IDA?</strong></summary>
+<summary><strong>Do I need a native analysis engine?</strong></summary>

-Deep native analysis uses one of them. Static JavaScript and .NET inspection
-work without a native analysis engine. Setup can install Hopper after approval;
-Ghidra and IDA use your existing installations. See [provider setup](docs/installation.md#hopper).
+Deep native analysis uses Hopper, Ghidra, IDA or Kuna, depending on the target
+and operation. Static JavaScript and .NET inspection work without a native
+analysis engine. Setup can install Hopper after approval; Ghidra, IDA and Kuna
+use your existing installations. See [provider setup](docs/installation.md#hopper)
+for the options and their supported targets.

 </details>

@@ -17,6 +17,7 @@ notices supplied with the software you actually obtain or redistribute.
 | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | npm dependencies         | [Complete inventory](licenses/npm-dependencies.txt) of every entry in `package-lock.json`, including transitive, optional platform, development, and website dependencies. [Runtime notices](licenses/npm-runtime-notices.txt) preserve the copyright, license, and NOTICE documents from integrity-verified release archives, plus the MIT notice for Rolldown's generated runtime helpers. Development dependencies are inventoried but are not all distributed in REA's npm package.                                                                                                                                                                                                                       |
 | pefile ordinal tables    | Import-hash ordinal names are derived from [pefile 2024.8.26](https://github.com/erocarrera/pefile/tree/4b3b1e2e568a88d4f1897d694d684f23d9e270c4), copyright 2004–2024 Ero Carrera. Preserve the [MIT license](licenses/pefile-2024.8.26-LICENSE.txt). The Python package is not a runtime dependency.                                                                                                                                                                                                                                                                                                                                                                                                        |
+| UF2 family names         | UF2 family IDs and short names are copied from [microsoft/uf2 `utils/uf2families.json`](https://github.com/microsoft/uf2/blob/cf3bd7f9c274b949528f8cd6a19eef2502a687d2/utils/uf2families.json), copyright Microsoft Corporation. Preserve the [MIT license](licenses/microsoft-uf2-MIT.txt).                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | NativeAOT parser         | REA's derived parser uses the MIT-licensed [ghidra-nativeaot](https://github.com/Washi1337/ghidra-nativeaot/tree/effeb734fc570c32650f88b159608979dc7b423e) work of Washi and the NativeAOT layout definitions in [dotnet/runtime](https://github.com/dotnet/runtime/tree/a3b2d40328be0be3f8dd43f0e5cc925b8827b044). Preserve [Washi's MIT notice](licenses/nativeaot-parser-MIT.txt) and the [.NET Foundation MIT notice](licenses/dotnet-runtime-MIT.txt).                                                                                                                                                                                                                                                   |
 | EVM analysis             | `[email protected]`, MIT, copyright 2023 Maxim Andreev. The published npm archive omits its license document; REA retains the [original upstream license](third_party/evmole/LICENSE) and [provenance](third_party/evmole/README.md). It is also included in the runtime notices.                                                                                                                                                                                                                                                                                                                                                                                                                                  |
 | Windows native addon     | The release addon is compiled with MinGW-w64 and statically links GCC runtime libraries. Preserve the [MinGW-w64 runtime notices](licenses/MinGW-w64-runtime.txt), [GPLv3 text](licenses/GPL-3.0.txt), and [GCC Runtime Library Exception 3.1](licenses/GCC-Runtime-Library-Exception-3.1.txt). The exception governs eligible compiled combinations; it does not relicense the runtime itself under MIT. The Node-API build headers are from Node 22.19.0; its [original license and component notices](licenses/Node-22.19.0-LICENSE.txt) are retained. Node itself is supplied by the user. Snapshot provenance and release-toolchain review requirements are in [licenses/README.md](licenses/README.md). |
@@ -59,7 +60,7 @@ pin inspection sources; they are not included in the npm package.
 | ghidra-nativeaot               | [MIT](https://github.com/Washi1337/ghidra-nativeaot/blob/effeb734fc570c32650f88b159608979dc7b423e/LICENSE.md)                                                                                                                                            | Pinned inspection source; derived parser attribution above.                                                                                                                                                                                                                        |
 | JADX                           | [Apache-2.0](https://github.com/skylot/jadx/blob/v1.5.6/LICENSE)                                                                                                                                                                                         | The audited jadx-headless-mcp source uses JADX 1.5.6 for Android decompilation; the engine JAR is separately supplied.                                                                                                                                                             |
 | jadx-headless-mcp              | [Apache-2.0](https://github.com/1013503897/jadx-headless-mcp/blob/5844800a486d2248fa949b74c9896285f5b54de2/LICENSE)                                                                                                                                      | v0.7.1; pinned submodule and user-supplied JAR.                                                                                                                                                                                                                                    |
-| Kuna                           | [Apache-2.0](https://github.com/Noelo-Lab/kuna/blob/v1.833/LICENSE), with its [NOTICE](https://github.com/Noelo-Lab/kuna/blob/v1.833/NOTICE)                                                                                                             | Bring your own `kuna`; REA verified 1.833 and never downloads, installs or bundles it. REA invokes it as a separate process.                                                                                                                                                       |
+| Kuna                           | [Apache-2.0](https://github.com/Noelo-Lab/kuna/blob/v1.986/LICENSE), with its [NOTICE](https://github.com/Noelo-Lab/kuna/blob/v1.986/NOTICE)                                                                                                             | Bring your own `kuna`; REA verified 1.986 and never downloads, installs or bundles it. REA invokes it as a separate process.                                                                                                                                                       |
 | Apktool                        | [Apache-2.0](https://github.com/iBotPeaches/Apktool/blob/master/LICENSE.md)                                                                                                                                                                              | User-supplied Android resource decoder.                                                                                                                                                                                                                                            |
 | Binwalk                        | [MIT](https://github.com/ReFirmLabs/binwalk/blob/4fdab3d464d97b68e0af9088df3f9e2e1545b21c/LICENSE)                                                                                                                                                       | v3.1.0; pinned submodule and user-supplied firmware engine.                                                                                                                                                                                                                        |
 | Unblob                         | [MIT](https://github.com/onekey-sec/unblob/blob/1fcc7a0a584a70a96c31f5a276c20944d199a089/LICENSE)                                                                                                                                                        | 26.6.4; pinned submodule and user-supplied firmware engine.                                                                                                                                                                                                                        |
@@ -15,7 +15,9 @@ import jadx.api.plugins.input.insns.InsnIndexType;
 import jadx.api.plugins.input.insns.Opcode;
 import jadx.core.codegen.TypeGen;
 import jadx.core.dex.info.MethodInfo;
+import jadx.core.dex.instructions.args.ArgType;
 import jadx.core.dex.nodes.*;
+import jadx.core.xmlgen.BinaryXMLParser;
 import java.io.PrintStream;
 import java.io.StringReader;
 import java.io.InputStream;
@@ -50,17 +52,25 @@ class ReaJadxBridge {
  private Map<String, List<ClassSnapshot>> classes = Map.of();
  private JadxSession manifestSession;
  private ManifestSnapshot manifestSnapshot;
+  private ExternalInventory externalInventory;

  private record MethodSnapshot(String name, String rawName, String shortId, List<String> bodyAbsenceMarkers,
      Map<String, Object> summary) {}
  private record ClassSnapshot(JavaClass node, List<MethodSnapshot> methods, Map<String, Object> summary,
      Map<String, Object> summaryWithValues) {}
  private record ManifestSnapshot(String text, Map<String, Object> summary) {}
+  private record ExternalMethod(MethodInfo info, Map<String, Object> summary) {}
+  private record ExternalInventory(JadxSession session, String className, String methodName,
+      List<ExternalMethod> methods) {}

  private static final class InputFailure extends IllegalArgumentException {
    final String field;
    InputFailure(String field, String message) { super(message); this.field = field; }
  }
+  private static final class ReferenceLimit extends IllegalArgumentException {
+    final String stage;
+    ReferenceLimit(String stage) { super("External reference representation limit"); this.stage = stage; }
+  }

  private ReaJadxBridge(SessionHolder holder) { this.holder = holder; }

@@ -187,6 +197,7 @@ class ReaJadxBridge {
  private void clearManifest() {
    manifestSession = null;
    manifestSnapshot = null;
+    externalInventory = null;
  }

  // One bounded DEX at a time, beside the already admitted analysis JVM. The
@@ -400,10 +411,7 @@ class ReaJadxBridge {
        selected = resource;
      }
      if (selected == null) throw new IllegalArgumentException("Root AndroidManifest.xml not found");
-      var content = selected.loadContent();
-      if (content == null || content.getDataType() != jadx.core.xmlgen.ResContainer.DataType.TEXT)
-        throw new IllegalArgumentException("Root AndroidManifest.xml did not decode as text");
-      String xml = content.getText().getCodeStr();
+      String xml = manifestText(selected);
      ManifestSnapshot snapshot = new ManifestSnapshot(xml, manifestSummary(xml));
      manifestSnapshot = snapshot;
      manifestSession = current;
@@ -411,6 +419,23 @@ class ReaJadxBridge {
    return manifestSnapshot;
  }

+  /** Decode with resource names but without JADX's class alias substitution. */
+  static String manifestText(ResourceFile resource) {
+    var decompiler = resource.getDecompiler();
+    // BinaryXMLParser resolves android:name against its root's class identities
+    // and replaces raw '$' and relative names with Java-style aliases. A fresh
+    // root owns no classes, while its resource-name table preserves reference
+    // rendering from the loaded target.
+    RootNode root = new RootNode(decompiler.getArgs());
+    root.getConstValues().setResourcesNames(decompiler.getRoot().getConstValues().getResourcesNames());
+    try {
+      return ResourcesLoader.decodeStream(resource,
+          (size, input) -> new BinaryXMLParser(root).parse(input).getCodeStr());
+    } catch (jadx.core.utils.exceptions.JadxException failure) {
+      throw new IllegalArgumentException("Root AndroidManifest.xml did not decode as text", failure);
+    }
+  }
+
  /** One parsed XML owner supplies namespace-aware values alongside the exact decoded text. */
  static Map<String, Object> manifestSummary(String xml) {
    Element root;
@@ -454,7 +479,7 @@ class ReaJadxBridge {
    return Collections.unmodifiableMap(summary);
  }

-  private ClassSnapshot selected(JsonObject args) {
+  private void indexClasses() {
    JadxSession current = session();
    if (indexedSession != current) {
      Map<String, List<ClassSnapshot>> index = new LinkedHashMap<>();
@@ -530,6 +555,10 @@ class ReaJadxBridge {
      classes = Collections.unmodifiableMap(index);
      indexedSession = current;
    }
+  }
+
+  private ClassSnapshot selected(JsonObject args) {
+    indexClasses();
    String name = string(args, "class_name");
    List<ClassSnapshot> candidates = classes.get(name);
    if (candidates == null) throw new InputFailure("class_name", "Exact class not found: " + name
@@ -629,12 +658,18 @@ class ReaJadxBridge {
  // JSON-RPC/CallToolResult envelope and generated numeric request id, and
  // account for JSON text being escaped again inside TextContent.
  private static final int MAX_XREF_TEXT_BYTES = 8 * 1024 * 1024 - 1024;
+  // Leave room for the prototype reply, reference reply, retained raw calls,
+  // normalized Evidence and their text/structured MCP copies, not just one frame.
+  private static final int MAX_EXTERNAL_XREF_BYTES = MAX_XREF_TEXT_BYTES / 8;
  private static int escapedJsonBytes(Object value) {
    return JSON.toJson(JSON.toJson(value)).getBytes(StandardCharsets.UTF_8).length;
  }
  private static final class InvokeBudget {
    long remaining;
    InvokeBudget(long remaining) { this.remaining = Math.max(0, remaining); }
+    boolean fitsText(long characters) {
+      return remaining >= 256 && characters <= (remaining - 256) / 12;
+    }
    boolean admit(Map<String, Object> site) {
      // Check a conservative two-layer escape bound before serialization.
      long bound = 256;
@@ -649,26 +684,55 @@ class ReaJadxBridge {
  }
  private record DirectInvokes(List<Map<String, Object>> sites, boolean exhaustive) {}

-  /** Raw DEX invokes within one JADX using method; offsets are code units from its code start. */
-  private static DirectInvokes directInvokes(JavaMethod source, MethodInfo target, InvokeBudget budget) {
-    MethodNode node = source.getMethodNode();
+  @FunctionalInterface private interface InvokeVisitor {
+    void accept(MethodInfo target, int offset, int index, Opcode opcode);
+  }
+
+  /** Decode raw invoke identity once at the shared bridge boundary, without generating source. */
+  private static void visitInvokes(MethodNode node, InvokeVisitor visitor) {
+    checkNativeInterrupted();
    ICodeReader code = node.getCodeReader();
-    if (code == null) return null;
-    List<Map<String, Object>> sites = new ArrayList<>();
-    boolean[] exhaustive = {true};
+    if (code == null) return;
    code.visitInstructions(insn -> {
+      checkNativeInterrupted();
      insn.decode();
      if (insn.getIndexType() != InsnIndexType.METHOD_REF) return;
      Opcode opcode = insn.getOpcode();
      if (!opcode.name().startsWith("INVOKE_")) return;
      IMethodRef ref = insn.getIndexAsMethod();
      ref.load();
-      if (!MethodInfo.fromRef(node.root(), ref).getRawFullId().equals(target.getRawFullId())) return;
+      visitor.accept(MethodInfo.fromRef(node.root(), ref), insn.getOffset(), insn.getIndex(), opcode);
+    });
+  }
+
+  /** Raw DEX invokes within one JADX using method; offsets are code units from its code start. */
+  private static DirectInvokes directInvokes(JavaMethod source, MethodInfo target, InvokeBudget budget) {
+    return directInvokes(source.getMethodNode(), target, budget);
+  }
+
+  private static void visitDirectInvokes(MethodNode node, MethodInfo target, InvokeVisitor visitor) {
+    visitInvokes(node, (referenced, offset, index, opcode) -> {
+      if (referenced.getRawFullId().equals(target.getRawFullId()))
+        visitor.accept(referenced, offset, index, opcode);
+    });
+  }
+
+  private static boolean referencesMethod(MethodNode node, MethodInfo target) {
+    boolean[] found = {false};
+    visitDirectInvokes(node, target, (referenced, offset, index, opcode) -> found[0] = true);
+    return found[0];
+  }
+
+  private static DirectInvokes directInvokes(MethodNode node, MethodInfo target, InvokeBudget budget) {
+    if (node.getCodeReader() == null) return null;
+    List<Map<String, Object>> sites = new ArrayList<>();
+    boolean[] exhaustive = {true};
+    visitDirectInvokes(node, target, (referenced, offset, index, opcode) -> {
      Map<String, Object> site = Map.of(
          "dex_entry", node.getInputFileName(),
          "source_raw_method_id", node.getMethodInfo().getRawFullId(),
-          "dex_code_unit_offset", insn.getOffset(),
-          "dex_method_index", insn.getIndex(),
+          "dex_code_unit_offset", offset,
+          "dex_method_index", index,
          "opcode", opcode.name());
      if (budget.admit(site)) sites.add(site);
      else exhaustive[0] = false;
@@ -676,6 +740,143 @@ class ReaJadxBridge {
    return new DirectInvokes(sites, exhaustive[0]);
  }

+  private List<ClassSnapshot> sourceClasses() {
+    indexClasses();
+    Set<ClassSnapshot> seen = Collections.newSetFromMap(new IdentityHashMap<>());
+    List<ClassSnapshot> result = new ArrayList<>();
+    for (List<ClassSnapshot> group : classes.values())
+      for (ClassSnapshot source : group) if (seen.add(source)) result.add(source);
+    result.sort(Comparator.comparing(source -> source.node().getRawName()));
+    return result;
+  }
+
+  private static long displayTypeCharacters(ArgType type) {
+    if (type.isArray())
+      return 2L * type.getArrayDimension() + displayTypeCharacters(type.getArrayRootElement());
+    if (type.isPrimitive()) return type.getPrimitiveType().getLongName().length();
+    if (type.isObject() && !type.isGeneric() && !type.isGenericType()) return type.getObject().length();
+    throw new IllegalArgumentException("External prototype contains a non-DEX type");
+  }
+
+  private static Map<String, Object> externalMethodSummary(MethodInfo info, InvokeBudget budget) {
+    String name = info.getName();
+    long signatureCharacters = name.length() + 4L + displayTypeCharacters(info.getReturnType())
+        + 2L * Math.max(0, info.getArgsCount() - 1);
+    for (ArgType type : info.getArgumentsTypes()) signatureCharacters += displayTypeCharacters(type);
+    long descriptorCharacters = info.getShortId().length() - (long) name.length();
+    // Use parsed type facts and the existing short-id length before copying/joining strings.
+    if (!budget.fitsText(2L * name.length() + descriptorCharacters + signatureCharacters))
+      throw new ReferenceLimit("method_inventory");
+    String descriptor = info.getShortId().substring(name.length());
+    String signature = name + "(" + info.getArgumentsTypes().stream()
+        .map(Object::toString).collect(Collectors.joining(", "))
+        + "): " + info.getReturnType();
+    Map<String, Object> summary = Map.of("name", name, "raw_name", name, "signature", signature,
+        "dex_descriptor", descriptor, "is_constructor", info.isConstructor(), "def_pos", 0);
+    if (!budget.admit(summary)) throw new ReferenceLimit("method_inventory");
+    return summary;
+  }
+
+  /** Only directly referenced prototypes, not invented definitions or an external classpath. */
+  private List<ExternalMethod> externalMethods(JsonObject args) {
+    String className = string(args, "class_name");
+    String methodName = string(args, "method_name");
+    JadxSession current = session();
+    if (externalInventory != null && externalInventory.session() == current
+        && externalInventory.className().equals(className) && externalInventory.methodName().equals(methodName))
+      return externalInventory.methods();
+    // Retain only the latest bounded selection, never results from a replaced APK/session.
+    externalInventory = null;
+    SortedMap<String, ExternalMethod> methods = new TreeMap<>();
+    boolean[] observedClass = {false};
+    InvokeBudget budget = new InvokeBudget(MAX_EXTERNAL_XREF_BYTES
+        - 4096L - 12L * (className.length() + (long) methodName.length()));
+    for (ClassSnapshot source : sourceClasses()) {
+      for (MethodSnapshot selected : source.methods()) {
+        visitInvokes(method(source, selected).getMethodNode(), (info, offset, index, opcode) -> {
+          if (!info.getDeclClass().getRawName().equals(className)) return;
+          observedClass[0] = true;
+          if (!info.getName().equals(methodName) || methods.containsKey(info.getShortId())) return;
+          methods.put(info.getShortId(), new ExternalMethod(info, externalMethodSummary(info, budget)));
+        });
+      }
+    }
+    if (!observedClass[0]) throw new InputFailure("class_name",
+        "No APK definition or direct DEX invoke references the exact class: " + className);
+    if (methods.isEmpty()) throw new InputFailure("method_name",
+        "No direct DEX invoke references " + className + "." + methodName);
+    List<ExternalMethod> result = List.copyOf(methods.values());
+    externalInventory = new ExternalInventory(current, className, methodName, result);
+    return result;
+  }
+
+  private Map<String, Object> externalSummary(JsonObject args) {
+    List<ExternalMethod> methods = externalMethods(args);
+    return Map.of("class_name", string(args, "class_name"), "reference_target", "external",
+        "observed_method_count", methods.size(),
+        "prototypes", methods.stream().map(ExternalMethod::summary).toList());
+  }
+
+  private record ExternalCaller(MethodNode node, Map<String, Object> row) {}
+
+  /** Reserve the complete using-node inventory before optional instruction positions. */
+  private List<ExternalCaller> externalCallers(MethodInfo target, InvokeBudget budget) {
+    List<ExternalCaller> callers = new ArrayList<>();
+    for (ClassSnapshot source : sourceClasses()) {
+      String className = String.valueOf(source.summary().get("full_name"));
+      Map<String, Integer> overloads = new HashMap<>();
+      for (MethodSnapshot candidate : source.methods()) {
+        int overload = overloads.merge(candidate.name(), 1, Integer::sum) - 1;
+        MethodNode node = method(source, candidate).getMethodNode();
+        if (!referencesMethod(node, target)) continue;
+        if (classes.get(className).size() != 1)
+          throw new IllegalArgumentException("External caller has an ambiguous APK class identity: " + className);
+        Map<String, Object> row = new LinkedHashMap<>(Map.of(
+            "kind", "method", "name", candidate.name(), "full_name", className + "." + candidate.name(),
+            "containing_class", className, "top_class", source.node().getTopParentClass().getFullName(),
+            "def_pos", 0, "source_selector", Map.of("class_name", className,
+                "method_name", candidate.name(), "overload_index", overload),
+            "direct_invokes", List.of(), "direct_invokes_exhaustive", false));
+        if (!budget.admit(row)) throw new ReferenceLimit("caller_inventory");
+        callers.add(new ExternalCaller(node, row));
+      }
+    }
+    return List.copyOf(callers);
+  }
+
+  private Map<String, Object> externalReferences(JsonObject args) {
+    List<ExternalMethod> methods = externalMethods(args);
+    if (methods.size() != 1 && !args.has("overload_index"))
+      throw new InputFailure("overload_index", "Select one of " + methods.size() + " observed external prototypes");
+    int index = integer(args, "overload_index", 0);
+    if (index >= methods.size()) throw new InputFailure("overload_index", "External prototype index out of range: " + index);
+    ExternalMethod method = methods.get(index);
+    MethodInfo target = method.info();
+    Map<String, Object> selected = method.summary();
+    InvokeBudget budget = new InvokeBudget(MAX_EXTERNAL_XREF_BYTES
+        - 4096L - escapedJsonBytes(selected));
+    List<ExternalCaller> callers = externalCallers(target, budget);
+    List<Map<String, Object>> items = new ArrayList<>();
+    for (ExternalCaller caller : callers) {
+      DirectInvokes invokes = directInvokes(caller.node(), target, budget);
+      caller.row().put("direct_invokes", invokes.sites());
+      caller.row().put("direct_invokes_exhaustive", invokes.exhaustive());
+      items.add(caller.row());
+    }
+    Map<String, Object> result = new LinkedHashMap<>();
+    result.put("target", string(args, "class_name") + "." + target.getName());
+    result.put("reference_target", "external");
+    result.put("reference_scope", "direct_dex_invokes");
+    result.put("dex_descriptor", selected.get("dex_descriptor"));
+    result.put("reported_signature", selected.get("signature"));
+    result.put("overload_index", index);
+    result.put("total", items.size());
+    result.put("count", items.size());
+    result.put("resolve_line", false);
+    result.put("items", items);
+    return result;
+  }
+
  private CallToolResult handle(String name, kotlinx.serialization.json.JsonObject input) {
    JsonObject args = JsonParser.parseString(input.toString()).getAsJsonObject();
    if (name.equals("rea_jvm_status")) return json(Map.of(
@@ -712,6 +913,12 @@ class ReaJadxBridge {
          "scope", "top_level", "offset", offset, "limit", limit,
          "items", items));
    }
+    indexClasses();
+    if (flag(args, "reference_target") && !classes.containsKey(string(args, "class_name"))) {
+      if (name.equals("get_class_summary")) return json(externalSummary(args));
+      if (name.equals("get_xrefs_to_method")) return json(externalReferences(args));
+      throw new InputFailure("class_name", "External prototypes are only available to method reference queries");
+    }
    ClassSnapshot cls = selected(args);
    if (name.equals("get_class_summary"))
      return json(flag(args, "dex_static_values") ? cls.summaryWithValues() : cls.summary());
@@ -785,6 +992,9 @@ class ReaJadxBridge {
      try { return bridge.handle(name, request.getArguments()); }
      catch (InputFailure error) { return text(JSON.toJson(Map.of(
          "kind", "invalid-input", "field", error.field, "message", error.getMessage())), true); }
+      catch (ReferenceLimit error) { return text(JSON.toJson(Map.of(
+          "kind", "reference-output-limit", "stage", error.stage,
+          "limit_bytes", MAX_EXTERNAL_XREF_BYTES)), true); }
      catch (IllegalArgumentException error) { return text(error.getMessage(), true); }
    });
  }
@@ -797,7 +1007,7 @@ class ReaJadxBridge {
    SessionHolder holder = new SessionHolder(defaults);
    ServerCapabilities capabilities = new ServerCapabilities(
        new ServerCapabilities.Tools(null), null, null, null, null, null, null, Map.of());
-    Server server = new Server(new Implementation("rea-jadx-bridge", "9", null, null, null),
+    Server server = new Server(new Implementation("rea-jadx-bridge", "10", null, null, null),
        new ServerOptions(capabilities), "", ignored -> Unit.INSTANCE);
    SessionToolsKt.registerSessionTools(server, holder);
    ClassToolsKt.registerClassTools(server, holder);
@@ -847,6 +1057,12 @@ class ReaJadxBridge {
      if (name.equals("get_class_summary")) properties.put("dex_static_values",
          new kotlinx.serialization.json.JsonObject(Map.of(
              "type", kotlinx.serialization.json.JsonElementKt.JsonPrimitive("boolean"))));
+      if (name.equals("get_class_summary") || name.equals("get_xrefs_to_method"))
+        properties.put("reference_target", new kotlinx.serialization.json.JsonObject(Map.of(
+            "type", kotlinx.serialization.json.JsonElementKt.JsonPrimitive("boolean"))));
+      if (name.equals("get_class_summary")) properties.put("method_name",
+          new kotlinx.serialization.json.JsonObject(Map.of(
+              "type", kotlinx.serialization.json.JsonElementKt.JsonPrimitive("string"))));
      String description = switch (name) {
        case "list_classes" -> "Pages of case-sensitive matching top-level class names; offset and next_offset are inventory positions, limit bounds matching rows. Omitted or empty query inventories all names.";
        case "get_class_summary" -> "Parsed member metadata for one exact class name; no source generation. Set dex_static_values to include encoded static final field values.";
@@ -40,6 +40,7 @@ import java.util.Locale;
 import java.util.Map;
 import java.util.Set;
 import java.util.TreeMap;
+import java.util.TreeSet;
 import java.util.regex.Pattern;
 import java.util.regex.PatternSyntaxException;

@@ -548,6 +549,11 @@ public final class ReaGhidraBridge extends HeadlessScript {
        String softFloat = currentProgram.getOptions(ghidra.program.model.listing.Program.PROGRAM_INFO)
            .getString("REA MIPS soft-float storage", null);
        if (softFloat != null) result.add("mips_soft_float_storage", JsonParser.parseString(softFloat));
+        // Written by ReaGhidraRiscvCallingConvention after analysis; REA requires it
+        // exactly when the committed profile declares a RISC-V calling-convention policy.
+        String riscvCallingConvention = currentProgram.getOptions(ghidra.program.model.listing.Program.PROGRAM_INFO)
+            .getString("REA RISC-V calling convention", null);
+        if (riscvCallingConvention != null) result.add("riscv_calling_convention", JsonParser.parseString(riscvCallingConvention));
        return result;
    }

@@ -922,17 +928,33 @@ public final class ReaGhidraBridge extends HeadlessScript {
        requireKeys(params, Set.of("document", "address"));
        requireDocument(params);
        Address address = requireAddress(params, "address");
+        String at = canonicalAddress(address);
+        // A well-formed address can still lack one exact source offset. Each
+        // outcome has its own code, so REA reports the reason rather than
+        // schema repair. Initialization, not the loaded flag, decides whether
+        // source bytes can exist: file-backed overlays are not loaded.
        MemoryBlock block = currentProgram.getMemory().getBlock(address);
-        if (block == null || !block.isInitialized())
-            throw new RequestFailure("invalid_request", "Address has no initialized file-backed memory: " + canonicalAddress(address));
+        if (block == null)
+            throw new RequestFailure("address_unmapped",
+                "Address " + at + " is outside every Ghidra memory block");
+        if (!block.isInitialized())
+            throw new RequestFailure("address_uninitialized",
+                "Address " + at + " is in uninitialized Ghidra memory block " + block.getName());
        TargetFileOffset mapping = targetFileOffset(block, address);
-        if (mapping.mappings() != 1)
-            throw new RequestFailure("invalid_request", "Address has " + mapping.mappings() + " authoritative target-file mappings: " + canonicalAddress(address));
+        if (mapping.mappings() == 0)
+            throw new RequestFailure("file_mapping_absent",
+                "Address " + at + " in initialized Ghidra memory block " + block.getName() +
+                " has no authoritative mapping to the admitted target file");
+        if (mapping.mappings() > 1)
+            throw new RequestFailure("file_mapping_ambiguous",
+                "Address " + at + " has " + mapping.mappings() +
+                " authoritative mappings to the admitted target file");
        Long fileOffset = mapping.offset();
        if (fileOffset == null)
-            throw new RequestFailure("invalid_request", "Address lacks a safe file offset: " + canonicalAddress(address));
+            throw new RequestFailure("file_offset_unrepresentable",
+                "Address " + at + " maps to an admitted target-file offset beyond the exact JSON integer range");
        JsonObject result = new JsonObject();
-        result.addProperty("address", canonicalAddress(address));
+        result.addProperty("address", at);
        result.addProperty("file_offset", fileOffset);
        return result;
    }
@@ -1313,7 +1335,7 @@ public final class ReaGhidraBridge extends HeadlessScript {
        flow.addProperty("computed", false);
        if (instruction == null) {
            result.addProperty("status", !currentProgram.getMemory().contains(address) ? "outside-memory" : currentProgram.getListing().getInstructionContaining(address) != null
-                ? "not-instruction-boundary" : currentProgram.getListing().getDefinedDataContaining(address) != null ? "data" : "undecodable");
+                ? "not-instruction-boundary" : currentProgram.getListing().getDefinedDataContaining(address) != null ? "data" : "not-in-listing");
            for (String key : List.of("bytes", "length", "mnemonic", "raw_disassembly")) result.add(key, JsonNull.INSTANCE);
        } else {
            result.addProperty("status", "decoded");
@@ -1385,6 +1407,7 @@ public final class ReaGhidraBridge extends HeadlessScript {
            result.add("incoming_references", incomingReferences);
        }
        List<String> limitations = new ArrayList<>(List.of("Operand components are Ghidra Listing decoder tokens; effective memory base/index/displacement roles and per-instruction context mode are unavailable. The mode field is the program language variant."));
+        if (result.get("status").getAsString().equals("not-in-listing")) limitations.add("No listed instruction or defined data covers this in-memory address. REA did not attempt a decode; the memory may be uninitialized or contain valid instructions.");
        if (flow.get("kind").getAsString().equals("terminal")) limitations.add("No RETURN operation was observed in the provider's instruction p-code; terminal classification remains generic.");
        result.add("limitations", GSON.toJsonTree(limitations));
        return result;
@@ -1930,41 +1953,62 @@ public final class ReaGhidraBridge extends HeadlessScript {
        return symbol == null ? JsonNull.INSTANCE : GSON.toJsonTree(symbol.getName(true));
    }

-    // Analyst naming: a function entry renames the function, other addresses get a primary label.
-    private boolean applyAddressName(Address address, String name) throws Exception {
+    // Analyst naming: a function entry renames the function; another mapped
+    // address renames its non-dynamic primary label or receives a new global
+    // label. Resolve that destination without editing the program.
+    private AddressNameTarget addressNameTarget(Address address, String name)
+        throws ghidra.util.exception.InvalidInputException {
        if (!currentProgram.getMemory().contains(address))
            throw new RequestFailure("invalid_request", "Address is not mapped: " + canonicalAddress(address));
        validateAnnotationText(name, "name");
+        Symbol edited = editedNameSymbol(address);
+        return edited == null
+            ? new AddressNameTarget(address, currentProgram.getGlobalNamespace(), name)
+            : new AddressNameTarget(address, edited.getParentNamespace(), symbolLeafName(edited, name));
+    }
+
+    private Symbol editedNameSymbol(Address address) {
+        Function function = currentProgram.getFunctionManager().getFunctionAt(address);
+        if (function != null) return function.getSymbol();
+        Symbol primary = currentProgram.getSymbolTable().getPrimarySymbol(address);
+        return primary == null || primary.isDynamic() ? null : primary;
+    }
+
+    // Every address whose label or function symbol holds the destination.
+    private List<Address> addressNameHolders(AddressNameTarget target) {
+        Set<Address> holders = new TreeSet<>();
+        for (Symbol symbol : currentProgram.getSymbolTable().getLabelOrFunctionSymbols(target.leaf(), target.namespace()))
+            holders.add(symbol.getAddress());
+        return List.copyOf(holders);
+    }
+
+    // Apply one planned destination in its own transaction. Null means the
+    // edit committed with matching primary-symbol readback.
+    private String applyAddressName(AddressNameTarget target) {
+        Address address = target.address();
        int transaction = currentProgram.startTransaction("REA address name");
        boolean commit = false;
        try {
            Function function = currentProgram.getFunctionManager().getFunctionAt(address);
-            SymbolTable table = currentProgram.getSymbolTable();
-            Symbol primary = function == null ? table.getPrimarySymbol(address) : function.getSymbol();
-            Namespace namespace = primary == null
-                ? currentProgram.getGlobalNamespace()
-                : primary.getParentNamespace();
-            String expected = primary == null ? name : symbolLeafName(primary, name);
-            for (Symbol symbol : table.getLabelOrFunctionSymbols(expected, namespace)) {
-                if (!address.equals(symbol.getAddress())) return false;
-            }
+            Symbol edited = editedNameSymbol(address);
            if (function != null) {
-                function.setName(expected, SourceType.USER_DEFINED);
+                function.setName(target.leaf(), SourceType.USER_DEFINED);
+            } else if (edited != null) {
+                edited.setName(target.leaf(), SourceType.USER_DEFINED);
            } else {
-                if (primary != null && !primary.isDynamic()) {
-                    primary.setName(expected, SourceType.USER_DEFINED);
-                } else {
-                    Symbol created = table.createLabel(address, expected, SourceType.USER_DEFINED);
-                    created.setPrimary();
-                }
+                Symbol created = currentProgram.getSymbolTable().createLabel(address, target.leaf(), SourceType.USER_DEFINED);
+                created.setPrimary();
            }
            invalidateAnalysisCaches();
            Symbol readback = currentProgram.getSymbolTable().getPrimarySymbol(address);
-            commit = readback != null && expected.equals(readback.getName());
-            return commit;
+            commit = readback != null && target.leaf().equals(readback.getName());
+            return commit ? null : "readback_mismatch";
        }
-        catch (ghidra.util.exception.InvalidInputException | ghidra.util.exception.DuplicateNameException exception) {
-            return false;
+        catch (ghidra.util.exception.InvalidInputException exception) {
+            return "invalid_name";
+        }
+        catch (ghidra.util.exception.DuplicateNameException exception) {
+            return "duplicate_name";
        }
        finally {
            currentProgram.endTransaction(transaction, commit);
@@ -1974,7 +2018,17 @@ public final class ReaGhidraBridge extends HeadlessScript {
    private JsonElement setAddressName(JsonObject params) throws Exception {
        requireKeys(params, Set.of("document", "address", "name"));
        requireDocument(params);
-        return GSON.toJsonTree(applyAddressName(requireAddress(params, "address"), requireString(params, "name")));
+        String key = requireString(params, "address");
+        Address address = requireAddress(params, "address");
+        String name = requireString(params, "name");
+        // A single edit keeps request errors for unmapped addresses and
+        // unrepresentable text; other outcomes share the batch representation.
+        if (!currentProgram.getMemory().contains(address))
+            throw new RequestFailure("invalid_request", "Address is not mapped: " + canonicalAddress(address));
+        validateAnnotationText(name, "name");
+        Map<String, String> requested = new LinkedHashMap<>();
+        requested.put(key, name);
+        return applyAddressNames(requested);
    }

    private JsonElement setAddressesNames(JsonObject params) throws Exception {
@@ -1982,34 +2036,129 @@ public final class ReaGhidraBridge extends HeadlessScript {
        requireDocument(params);
        if (!params.has("names") || !params.get("names").isJsonObject())
            throw new RequestFailure("invalid_request", "names must be an object of address -> name");
+        Map<String, String> requested = new LinkedHashMap<>();
+        for (Map.Entry<String, JsonElement> entry : params.getAsJsonObject("names").entrySet())
+            requested.put(entry.getKey(), entry.getValue().getAsString());
+        return applyAddressNames(requested);
+    }
+
+    // Decide every request from the names held before any edit, so object
+    // member order never selects which address receives a name. Reply with
+    // per-key results and reasons; a contested destination is listed once in
+    // conflicts and failures refer to it by index.
+    private JsonObject applyAddressNames(Map<String, String> requested) {
+        Map<String, Address> addressesByKey = new LinkedHashMap<>();
        Map<Address, List<AddressNameRequest>> requestsByAddress = new LinkedHashMap<>();
-        JsonObject result = new JsonObject();
-        for (Map.Entry<String, JsonElement> entry : params.getAsJsonObject("names").entrySet()) {
+        for (Map.Entry<String, String> entry : requested.entrySet()) {
+            Address address = null;
            try {
-                Address address = parseReaAddress(entry.getKey());
+                address = parseReaAddress(entry.getKey());
                requestsByAddress.computeIfAbsent(address, ignored -> new ArrayList<>())
-                    .add(new AddressNameRequest(entry.getKey(), address, entry.getValue().getAsString()));
+                    .add(new AddressNameRequest(entry.getKey(), address, entry.getValue()));
            }
            catch (RequestFailure failure) {
-                result.addProperty(entry.getKey(), false);
+                // The key keeps its own invalid_address outcome below.
+            }
+            addressesByKey.put(entry.getKey(), address);
+        }
+        Map<Address, AddressNameFailure> failures = new HashMap<>();
+        Map<AddressNameDestination, List<AddressNameTarget>> destinations = new LinkedHashMap<>();
+        for (Map.Entry<Address, List<AddressNameRequest>> selected : requestsByAddress.entrySet()) {
+            Address address = selected.getKey();
+            String name = selected.getValue().get(0).name;
+            if (selected.getValue().stream().anyMatch(request -> !request.name.equals(name))) {
+                failures.put(address, new AddressNameFailure("conflicting_alias_names", null));
+                continue;
+            }
+            if (!currentProgram.getMemory().contains(address)) {
+                failures.put(address, new AddressNameFailure("unmapped_address", null));
+                continue;
+            }
+            try {
+                AddressNameTarget target = addressNameTarget(address, name);
+                destinations.computeIfAbsent(target.destination(), ignored -> new ArrayList<>()).add(target);
+            }
+            catch (RequestFailure | ghidra.util.exception.InvalidInputException exception) {
+                failures.put(address, new AddressNameFailure("invalid_name", null));
            }
        }
-        for (List<AddressNameRequest> requests : requestsByAddress.values()) {
-            String name = requests.get(0).name;
-            boolean conflictingAliasNames = requests.stream()
-                .anyMatch(request -> !request.name.equals(name));
-            boolean success = false;
-            if (!conflictingAliasNames) {
-                try {
-                    success = applyAddressName(requests.get(0).address, name);
-                }
-                catch (RequestFailure failure) {
-                    // Keep per-address failures in the existing batch result shape.
-                }
+        // Reject a destination that several selected addresses request, or
+        // that another address holds, instead of letting order pick a winner.
+        List<AddressNameConflict> conflicts = new ArrayList<>();
+        List<AddressNameTarget> independent = new ArrayList<>();
+        for (List<AddressNameTarget> requesters : destinations.values()) {
+            AddressNameTarget first = requesters.get(0);
+            List<Address> holders = addressNameHolders(first);
+            String reason;
+            if (requesters.size() > 1) {
+                reason = "duplicate_requested_name";
+            } else if (holders.stream().allMatch(first.address()::equals)) {
+                independent.add(first);
+                continue;
+            } else if (holders.stream().anyMatch(holder ->
+                !holder.equals(first.address()) && !requestsByAddress.containsKey(holder))) {
+                reason = "name_held_by_unselected_address";
+            } else {
+                reason = "name_held_by_selected_address";
            }
-            for (AddressNameRequest request : requests)
-                result.addProperty(request.inputAddress, success);
+            AddressNameConflict conflict = new AddressNameConflict(
+                first.namespace(),
+                first.leaf(),
+                requesters.stream().map(AddressNameTarget::address).sorted().toList(),
+                holders
+            );
+            conflicts.add(conflict);
+            for (AddressNameTarget target : requesters)
+                failures.put(target.address(), new AddressNameFailure(reason, conflict));
        }
+        // Independent edits have distinct destinations that no other address
+        // holds, so their results do not depend on application order.
+        for (AddressNameTarget target : independent) {
+            String reason = applyAddressName(target);
+            if (reason != null) failures.put(target.address(), new AddressNameFailure(reason, null));
+        }
+        // Requesters belong to exactly one destination, so ordering conflicts
+        // by their first requester gives indexes independent of member order.
+        conflicts.sort(Comparator.comparing((AddressNameConflict conflict) -> conflict.requesters().get(0)));
+        Map<AddressNameConflict, Integer> indexes = new IdentityHashMap<>();
+        JsonArray contested = new JsonArray();
+        for (AddressNameConflict conflict : conflicts) {
+            indexes.put(conflict, contested.size());
+            JsonObject value = new JsonObject();
+            if (conflict.namespace().isGlobal()) value.add("namespace", JsonNull.INSTANCE);
+            else value.addProperty("namespace", conflict.namespace().getName(true));
+            value.addProperty("name", conflict.leaf());
+            value.add("requested_by", canonicalAddresses(conflict.requesters()));
+            value.add("held_by", canonicalAddresses(conflict.holders()));
+            contested.add(value);
+        }
+        JsonObject results = new JsonObject();
+        JsonObject failed = new JsonObject();
+        for (Map.Entry<String, Address> entry : addressesByKey.entrySet()) {
+            Address address = entry.getValue();
+            AddressNameFailure failure = address == null
+                ? new AddressNameFailure("invalid_address", null)
+                : failures.get(address);
+            results.addProperty(entry.getKey(), failure == null);
+            if (failure == null) continue;
+            JsonObject value = new JsonObject();
+            if (address == null) value.add("address", JsonNull.INSTANCE);
+            else value.addProperty("address", canonicalAddress(address));
+            value.addProperty("reason", failure.reason());
+            if (failure.conflict() == null) value.add("conflict", JsonNull.INSTANCE);
+            else value.addProperty("conflict", indexes.get(failure.conflict()));
+            failed.add(entry.getKey(), value);
+        }
+        JsonObject result = new JsonObject();
+        result.add("results", results);
+        result.add("failures", failed);
+        result.add("conflicts", contested);
+        return result;
+    }
+
+    private static JsonArray canonicalAddresses(List<Address> addresses) {
+        JsonArray result = new JsonArray();
+        for (Address address : addresses) result.add(canonicalAddress(address));
        return result;
    }

@@ -2346,6 +2495,7 @@ public final class ReaGhidraBridge extends HeadlessScript {

        JsonArray parameters = new JsonArray();
        result.add("parameters", parameters);
+        result.add("parameter_list", parameterList(function, prototype));

        JsonArray jumpTables = new JsonArray();
        result.add("jump_tables", jumpTables);
@@ -2403,6 +2553,28 @@ public final class ReaGhidraBridge extends HeadlessScript {
        return result;
    }

+    /**
+     * Ghidra fixes prototype inputs from a non-default signature: an empty one
+     * reaches the decompiler as a void-input lock (FunctionPrototype), and each
+     * valid parameter is type-locked (LocalSymbolMap). Any other list was
+     * recovered from observed uses and may omit parameters.
+     */
+    private static JsonObject parameterList(Function function, FunctionPrototype prototype) {
+        int count = prototype.getNumParams();
+        boolean signature = count > 0 || (
+            function.getSignatureSource() != SourceType.DEFAULT &&
+            function.getParameterCount() == 0
+        );
+        for (int index = 0; signature && index < count; index += 1) {
+            HighSymbol parameter = prototype.getParam(index);
+            signature = parameter != null && parameter.isTypeLocked();
+        }
+        JsonObject result = new JsonObject();
+        result.addProperty("basis", signature ? "signature" : "recovered");
+        result.addProperty("variadic", prototype.isVarArg());
+        return result;
+    }
+
    private static JsonObject unavailableNativeValueFlow(String reason) {
        JsonObject unavailable = new JsonObject();
        unavailable.addProperty("available", false);
@@ -4980,6 +5152,14 @@ public final class ReaGhidraBridge extends HeadlessScript {

    private record InventoryItem(Address address, String value, JsonObject facts, JsonObject symbol) {}
    private record AddressNameRequest(String inputAddress, Address address, String name) {}
+    private record AddressNameDestination(long namespace, String leaf) {}
+    private record AddressNameTarget(Address address, Namespace namespace, String leaf) {
+        AddressNameDestination destination() {
+            return new AddressNameDestination(namespace.getID(), leaf);
+        }
+    }
+    private record AddressNameConflict(Namespace namespace, String leaf, List<Address> requesters, List<Address> holders) {}
+    private record AddressNameFailure(String reason, AddressNameConflict conflict) {}
    private record FunctionEntry(Function function, InventoryItem item) {}
    private record FunctionAnalysisObservation(JsonObject dossier, List<String> limitations, JsonObject relationshipCoverage, boolean decompilerFailed) {}
    private record CallBoundaryObservation(List<String> limitations, Integer unrepresentedCalleeCalls, JsonArray unresolvedCalls) {}
@@ -0,0 +1,283 @@
+import ghidra.app.script.GhidraScript;
+import ghidra.program.database.SpecExtension;
+import ghidra.program.model.data.DataType;
+import ghidra.program.model.data.DoubleDataType;
+import ghidra.program.model.data.Float16DataType;
+import ghidra.program.model.data.FloatDataType;
+import ghidra.program.model.data.FunctionDefinition;
+import ghidra.program.model.data.IntegerDataType;
+import ghidra.program.model.data.StructureDataType;
+import ghidra.program.model.lang.CompilerSpec;
+import ghidra.program.model.lang.Language;
+import ghidra.program.model.lang.PrototypeModel;
+import ghidra.program.model.lang.Register;
+import ghidra.program.model.listing.Function;
+import ghidra.program.model.listing.Parameter;
+import ghidra.program.model.listing.Program;
+import ghidra.program.model.listing.VariableStorage;
+import ghidra.program.model.pcode.Varnode;
+import ghidra.program.model.pcode.XmlEncode;
+import java.io.StringReader;
+import java.io.StringWriter;
+import java.util.ArrayList;
+import java.util.Iterator;
+import java.util.List;
+import java.util.regex.Pattern;
+import javax.xml.parsers.DocumentBuilderFactory;
+import javax.xml.transform.OutputKeys;
+import javax.xml.transform.TransformerFactory;
+import javax.xml.transform.dom.DOMSource;
+import javax.xml.transform.stream.StreamResult;
+import org.w3c.dom.Document;
+import org.w3c.dom.Element;
+import org.w3c.dom.Node;
+import org.w3c.dom.NodeList;
+import org.xml.sax.InputSource;
+
+/**
+ * Apply the committed RISC-V calling-convention policy after analysis. Ghidra's generic RV32
+ * compiler specification models ilp32d. Each policy derives a program-specific prototype from the
+ * program's own default prototype, as its {@link Policy} row and docs/ghidra-riscv.md state. The
+ * script installs the prototype as a specification extension and assigns it, with dynamic
+ * storage, to every non-thunk function, external function and function definition.
+ */
+public final class ReaGhidraRiscvCallingConvention extends GhidraScript {
+  static final String REPORT_KEY = "REA RISC-V calling convention";
+  /** RISC-V floating-point registers by ABI name: ft0-ft11, fs0-fs11 and fa0-fa7. */
+  private static final Pattern FLOAT_REGISTER = Pattern.compile("f[ast]\\d+");
+
+  /**
+   * What a policy changes in the default ilp32d prototype. Every policy also passes values of 9
+   * bytes or more, such as {@code long double}, by reference.
+   *
+   * @param floatEntryBytes the largest value a floating-point register may pass or return; 0
+   *     removes those entries and every rule that assigns floating-point storage
+   * @param preservesFloatRegisters whether fs0-fs11 stay preserved across calls
+   */
+  private record Policy(
+      String id, String prototype, int floatEntryBytes, boolean preservesFloatRegisters) {}
+
+  private static final List<Policy> POLICIES =
+      List.of(new Policy("ilp32-prototype-v1", "__rea_ilp32", 0, false));
+
+  @Override
+  public void run() throws Exception {
+    String[] arguments = getScriptArgs();
+    Policy policy =
+        POLICIES.stream()
+            .filter(candidate -> arguments.length == 1 && candidate.id().equals(arguments[0]))
+            .findFirst()
+            .orElseThrow(
+                () ->
+                    new IllegalArgumentException(
+                        "REA RISC-V calling convention requires one of the policies "
+                            + POLICIES.stream().map(Policy::id).toList()));
+    Language language = currentProgram.getLanguage();
+    if (!language.getProcessor().toString().equals("RISCV")
+        || currentProgram.getDefaultPointerSize() != 4)
+      throw new IllegalStateException(
+          "REA " + policy.id() + " requires a 32-bit RISC-V program, not "
+              + language.getLanguageID());
+    CompilerSpec spec = currentProgram.getCompilerSpec();
+    new SpecExtension(currentProgram)
+        .addReplaceCompilerSpecExtension(
+            derive(spec.getDefaultCallingConvention(), spec, language, policy), monitor);
+    PrototypeModel model =
+        currentProgram.getCompilerSpec().getCallingConvention(policy.prototype());
+    if (model == null)
+      throw new IllegalStateException("REA " + policy.prototype() + " was not installed");
+    selfCheck(model, policy, language);
+    int functions = 0;
+    List<Function> callables = new ArrayList<>();
+    currentProgram.getFunctionManager().getFunctions(true).forEach(callables::add);
+    currentProgram.getFunctionManager().getExternalFunctions().forEach(callables::add);
+    for (Function function : callables) {
+      // A thunk's signature is its target's; the target is in this list.
+      if (function.isThunk()) continue;
+      if (function.hasCustomVariableStorage()) function.setCustomVariableStorage(false);
+      function.setCallingConvention(policy.prototype());
+      if (policy.floatEntryBytes() == 0) {
+        List<VariableStorage> storage = new ArrayList<>();
+        storage.add(function.getReturn().getVariableStorage());
+        for (Parameter parameter : function.getParameters())
+          storage.add(parameter.getVariableStorage());
+        // An untyped function has no assigned storage yet; the decompiler applies the
+        // prototype when it recovers one.
+        requireIntegerStorage(
+            storage.toArray(VariableStorage[]::new), function.getName(true), true);
+      }
+      functions += 1;
+    }
+    int definitions = 0;
+    Iterator<DataType> types = currentProgram.getDataTypeManager().getAllDataTypes();
+    while (types.hasNext()) {
+      if (!(types.next() instanceof FunctionDefinition definition)) continue;
+      definition.setCallingConvention(policy.prototype());
+      definitions += 1;
+    }
+    // Written last: any failure above leaves no report, and REA refuses the session.
+    currentProgram.getOptions(Program.PROGRAM_INFO).setString(
+        REPORT_KEY,
+        "{\"policy\":\"" + policy.id() + "\",\"functions\":" + functions
+            + ",\"definitions\":" + definitions + "}");
+    println(
+        "REA RISC-V " + policy.prototype() + ": functions=" + functions
+            + " definitions=" + definitions);
+  }
+
+  /** The default ilp32d prototype changed as the policy states. */
+  private static String derive(
+      PrototypeModel base, CompilerSpec spec, Language language, Policy policy) throws Exception {
+    XmlEncode encoder = new XmlEncode();
+    base.encode(encoder, spec.getPcodeInjectLibrary());
+    DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
+    factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);
+    Document document =
+        factory.newDocumentBuilder().parse(new InputSource(new StringReader(encoder.toString())));
+    Element root = document.getDocumentElement();
+    if (!root.getTagName().equals("prototype"))
+      throw new IllegalStateException("Unexpected default prototype encoding " + root.getTagName());
+    root.setAttribute("name", policy.prototype());
+    List<Element> floatEntries = new ArrayList<>();
+    NodeList entries = root.getElementsByTagName("pentry");
+    for (int index = 0; index < entries.getLength(); index += 1) {
+      Element entry = (Element) entries.item(index);
+      if (entry.getAttribute("storage").equals("float")) floatEntries.add(entry);
+    }
+    if (floatEntries.isEmpty())
+      throw new IllegalStateException("Default prototype has no floating-point entries");
+    if (policy.floatEntryBytes() == 0) {
+      List<Node> removed = new ArrayList<>(floatEntries);
+      NodeList rules = root.getElementsByTagName("rule");
+      for (int index = 0; index < rules.getLength(); index += 1) {
+        Element rule = (Element) rules.item(index);
+        if (usesFloatStorage(rule)) removed.add(rule);
+      }
+      if (removed.size() == floatEntries.size())
+        throw new IllegalStateException("Default prototype has no floating-point rules to remove");
+      for (Node node : removed) node.getParentNode().removeChild(node);
+    } else
+      for (Element entry : floatEntries)
+        entry.setAttribute("maxsize", Integer.toString(policy.floatEntryBytes()));
+    // Values over 2 x XLEN go by reference. Returns need no rule: a value that the return
+    // registers cannot hold already becomes a caller buffer passed in a0.
+    NodeList inputs = root.getElementsByTagName("input");
+    if (inputs.getLength() != 1)
+      throw new IllegalStateException("Default prototype has no single input list");
+    Element input = (Element) inputs.item(0);
+    Element last = null;
+    for (Node child = input.getFirstChild(); child != null; child = child.getNextSibling())
+      if (child instanceof Element element && element.getTagName().equals("rule")) last = element;
+    if (last == null || !joinsAnyValue(last))
+      throw new IllegalStateException("Default prototype's input list does not end with a join");
+    Element byReference = document.createElement("rule");
+    Element datatype = document.createElement("datatype");
+    datatype.setAttribute("name", "any");
+    datatype.setAttribute("minsize", "9");
+    byReference.appendChild(datatype);
+    byReference.appendChild(document.createElement("convert_to_ptr"));
+    input.insertBefore(byReference, last);
+    if (!policy.preservesFloatRegisters()) {
+      NodeList killedLists = root.getElementsByTagName("killedbycall");
+      Element killed = killedLists.getLength() == 0 ? null : (Element) killedLists.item(0);
+      if (killed == null) {
+        killed = document.createElement("killedbycall");
+        root.appendChild(killed);
+      }
+      List<Element> moved = new ArrayList<>();
+      NodeList preservedLists = root.getElementsByTagName("unaffected");
+      for (int list = 0; list < preservedLists.getLength(); list += 1) {
+        NodeList preserved = preservedLists.item(list).getChildNodes();
+        for (int index = 0; index < preserved.getLength(); index += 1) {
+          if (preserved.item(index) instanceof Element varnode
+              && isFloatRegister(varnode, language))
+            moved.add(varnode);
+        }
+      }
+      for (Element varnode : moved) {
+        varnode.getParentNode().removeChild(varnode);
+        killed.appendChild(varnode);
+      }
+    }
+    StringWriter xml = new StringWriter();
+    var transformer = TransformerFactory.newInstance().newTransformer();
+    transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes");
+    transformer.transform(new DOMSource(document), new StreamResult(xml));
+    return xml.toString();
+  }
+
+  /** The installed prototype places each class of value as its policy states. */
+  private void selfCheck(PrototypeModel model, Policy policy, Language language) {
+    StructureDataType pair = new StructureDataType("rea_float_pair", 0);
+    pair.add(FloatDataType.dataType);
+    pair.add(FloatDataType.dataType);
+    VariableStorage[] storage =
+        model.getStorageLocations(
+            currentProgram,
+            new DataType[] {
+              DoubleDataType.dataType, FloatDataType.dataType, DoubleDataType.dataType,
+              IntegerDataType.dataType, pair, Float16DataType.dataType
+            },
+            false);
+    VariableStorage quad = storage[storage.length - 1];
+    if (quad.size() != currentProgram.getDefaultPointerSize() || quad.getRegister() == null)
+      throw new IllegalStateException(
+          "REA " + policy.prototype() + " does not pass a 16-byte value by reference: " + quad);
+    if (policy.floatEntryBytes() == 0)
+      requireIntegerStorage(storage, policy.prototype() + " self-check", false);
+    if (policy.preservesFloatRegisters()) return;
+    for (Varnode preserved : model.getUnaffectedList()) {
+      Register register = language.getRegister(preserved.getAddress(), preserved.getSize());
+      if (register != null && FLOAT_REGISTER.matcher(register.getName()).matches())
+        throw new IllegalStateException(
+            "REA " + policy.prototype() + " still preserves " + register.getName());
+    }
+  }
+
+  private static boolean joinsAnyValue(Element rule) {
+    List<Element> children = new ArrayList<>();
+    for (Node child = rule.getFirstChild(); child != null; child = child.getNextSibling())
+      if (child instanceof Element element) children.add(element);
+    return children.size() == 2
+        && children.get(0).getTagName().equals("datatype")
+        && children.get(0).getAttribute("name").equals("any")
+        && children.get(1).getTagName().equals("join");
+  }
+
+  /** Whether a rule's action, at any depth, assigns floating-point storage. */
+  private static boolean usesFloatStorage(Element element) {
+    NodeList children = element.getChildNodes();
+    for (int index = 0; index < children.getLength(); index += 1) {
+      if (!(children.item(index) instanceof Element child)) continue;
+      if (child.getAttribute("storage").equals("float") || usesFloatStorage(child)) return true;
+    }
+    return false;
+  }
+
+  private static boolean isFloatRegister(Element varnode, Language language) {
+    if (!varnode.getTagName().equals("varnode")
+        || !varnode.getAttribute("space").equals("register"))
+      return false;
+    Register register =
+        language.getRegister(
+            language.getAddressFactory().getRegisterSpace()
+                .getAddress(Long.decode(varnode.getAttribute("offset"))),
+            Integer.parseInt(varnode.getAttribute("size")));
+    return register != null && FLOAT_REGISTER.matcher(register.getName()).matches();
+  }
+
+  private static void requireIntegerStorage(
+      VariableStorage[] storage, String owner, boolean allowUnassigned) {
+    for (VariableStorage item : storage) {
+      if (item.isBadStorage() || (!allowUnassigned && item.isUnassignedStorage()))
+        throw new IllegalStateException("REA RISC-V storage unresolved for " + owner);
+      List<Register> registers = item.getRegisters();
+      if (registers == null) continue; // stack-only storage
+      for (Register register : registers) {
+        if (FLOAT_REGISTER.matcher(register.getName()).matches())
+          throw new IllegalStateException(
+              "REA RISC-V storage still uses " + register.getName() + " for " + owner);
+      }
+    }
+  }
+}
@@ -22,6 +22,9 @@ HOPPER_SYMBOL_NAME_UTF16_UNITS = 1024
 # that does not fit is null, not an older descriptor path.
 # 536870887 is Node's 536870888-character string ceiling minus the framing LF.
 # The ceiling is the encoded payload; JSON expansion is measured before it.
+# Encoded JSON allowance, in bytes, shared by one instruction list, one
+# native-caller list, and one caller-scan page. This release has no runtime override.
+CALLER_SCAN_ALLOWANCE_BYTES = 512 * 1024
 _BRIDGE_MAX_REQUEST_BYTES_SETTING = "REA_BRIDGE_MAX_REQUEST_BYTES"
 DEFAULT_BRIDGE_MAX_REQUEST_BYTES = 16 * 1024 * 1024
 MINIMUM_BRIDGE_MAX_REQUEST_BYTES = 7464
@@ -232,6 +235,9 @@ EXHAUSTIVE_ANALYSIS_METHODS = frozenset(
        "procedure_assembly",
        "procedure_callees",
        "procedure_callers",
+        "rea_caller_scan_page",
+        "rea_caller_scan_target",
+        "rea_caller_base",
        "procedure_info",
        "procedure_pseudo_code",
        "procedure_references",
@@ -485,19 +491,30 @@ def _instruction_addresses(procedure):
    return result


-def _native_calls(procedure, direction):
+def _iter_native_calls(procedure, direction):
    references = procedure.getAllCallees() if direction == "outgoing" else procedure.getAllCallers()
    kinds = {0: "none", 1: "unknown", 2: "direct", 3: "objective_c"}
-    calls = {}
-    unresolved = []
    for reference in references:
        source, target, kind = reference.fromAddress(), reference.toAddress(), reference.type()
        if source in BAD_ADDRESSES:
+            yield None, None, None
            continue
        if target in BAD_ADDRESSES:
-            unresolved.append({"address": _hex(source), "reason": "Native CallReference has no resolved target (type %s)" % kind})
+            yield source, None, {"address": _hex(source), "reason": "Native CallReference has no resolved target (type %s)" % kind}
            continue
-        calls[(source, target)] = {"classification": kinds.get(kind, "unknown"), "provider_type": kind, "provenance": "hopper-public-python-api:CallReference"}
+        yield source, target, {"classification": kinds.get(kind, "unknown"), "provider_type": kind, "provenance": "hopper-public-python-api:CallReference"}
+
+
+def _native_calls(procedure, direction):
+    calls = {}
+    unresolved = []
+    for source, target, detail in _iter_native_calls(procedure, direction):
+        if detail is None:
+            continue
+        if target is None:
+            unresolved.append(detail)
+        else:
+            calls[(source, target)] = detail
    return calls, sorted(unresolved, key=lambda item: int(item["address"], 16))


@@ -547,6 +564,136 @@ def _procedure_map(document):
    return result


+def _caller_target_data(procedure):
+    addresses = []
+    seen = set()
+    size = 0
+    for block in procedure.basicBlockIterator():
+        for address in _block_instruction_addresses(procedure, block):
+            if address in seen:
+                continue
+            encoded = _hex(address)
+            size += len(encoded) + 4
+            if size > CALLER_SCAN_ALLOWANCE_BYTES:
+                return {"target": _procedure_identity(procedure), "instructions": addresses, "instructions_complete": False}
+            addresses.append(encoded)
+            seen.add(address)
+    return {"target": _procedure_identity(procedure), "instructions": addresses, "instructions_complete": True}
+
+
+def _caller_scan_target(document, params):
+    return _caller_target_data(_procedure(document, params.get("procedure")))
+
+
+def _caller_base(document, params):
+    procedure = _procedure(document, params.get("procedure"))
+    callers = []
+    size = 0
+    complete = True
+    for item in procedure.getAllCallerProcedures():
+        address = _hex(item.getEntryPoint())
+        size += len(address) + 4
+        if size > CALLER_SCAN_ALLOWANCE_BYTES:
+            complete = False
+            break
+        callers.append(address)
+    return {
+        **_caller_target_data(procedure),
+        "callers": sorted(callers, key=lambda value: int(value, 16)),
+        "callers_complete": complete,
+    }
+
+
+def _caller_scan_page(document, params):
+    """Observe forward relationships in one bounded, stateless bridge request."""
+    start = params.get("start")
+    if isinstance(start, bool) or not isinstance(start, int) or start < 0:
+        raise InvalidRequestError("Caller scan start must be a non-negative integer")
+    segments = document.getSegmentsList()
+    counts = [segment.getProcedureCount() for segment in segments]
+    total = sum(counts)
+    end = min(start + 64, total)
+    if start > total:
+        raise InvalidRequestError("Caller scan start exceeds the procedure inventory")
+    items = []
+    item_bytes = 0
+    page_limit = CALLER_SCAN_ALLOWANCE_BYTES
+    oversized = False
+    identities = {}
+    containing = {}
+
+    def identity(procedure):
+        entry = procedure.getEntryPoint()
+        if entry not in identities:
+            identities[entry] = _procedure_identity(procedure)
+        return identities[entry]
+
+    def owner(address):
+        if address not in containing:
+            procedure, _ = _containing_procedure(document, address)
+            containing[address] = identity(procedure) if procedure is not None else None
+        return containing[address]
+
+    segment_start = 0
+    for segment, count in zip(segments, counts):
+        begin, stop = max(start - segment_start, 0), min(end - segment_start, count)
+        segment_start += count
+        for index in range(begin, max(begin, stop)):
+            candidate = segment.getProcedureAtIndex(index)
+            item = {"caller": identity(candidate), "callees": [], "references": []}
+            size = len(json.dumps(item, ensure_ascii=True).encode("utf-8")) + 1
+            remaining = page_limit - item_bytes
+            too_large = size > remaining
+            if not too_large:
+                for callee in candidate.getAllCalleeProcedures():
+                    address = _hex(callee.getEntryPoint())
+                    size += len(address) + 4
+                    if size > remaining:
+                        too_large = True
+                        break
+                    item["callees"].append(address)
+            if not too_large:
+                callee_entries = set(item["callees"])
+                for source, destination, call in _iter_native_calls(candidate, "outgoing"):
+                    # Account for every native record, even when its target cannot
+                    # be associated with an observed procedure.
+                    size += 32
+                    if size > remaining:
+                        too_large = True
+                        break
+                    if destination is None:
+                        continue
+                    source_procedure = item["caller"] if _hex(source) == item["caller"]["address"] else owner(source)
+                    target_address = _hex(destination)
+                    if target_address in callee_entries:
+                        target_entry = target_address
+                    else:
+                        target_procedure = owner(destination)
+                        if target_procedure is None:
+                            continue
+                        target_entry = target_procedure["address"]
+                    edge = {
+                        "source_address": _hex(source), "target_address": _hex(destination),
+                        "source_procedure": "caller" if source_procedure is not None and source_procedure["address"] == item["caller"]["address"] else source_procedure,
+                        "target_procedure": target_entry,
+                        "call": call,
+                    }
+                    size += len(json.dumps(edge, ensure_ascii=True).encode("utf-8")) + 1
+                    if size > remaining:
+                        too_large = True
+                        break
+                    item["references"].append(edge)
+            if too_large:
+                oversized = not items
+                break
+            items.append(item)
+            item_bytes += size
+        else:
+            continue
+        break
+    return {"start": start, "next": start + len(items), "total": total, "items": items, "oversized": oversized}
+
+
 def _string_record(segment, address, display):
    """Read one native typed object, retaining its shortened display separately."""
    length = segment.getObjectLength(address)
@@ -887,6 +1034,15 @@ def _dispatch(method, params):
    if method in EXHAUSTIVE_ANALYSIS_METHODS:
        _api().require_analysis_complete(document, method)

+    if method == "rea_caller_scan_target":
+        return _caller_scan_target(document, params)
+
+    if method == "rea_caller_base":
+        return _caller_base(document, params)
+
+    if method == "rea_caller_scan_page":
+        return _caller_scan_page(document, params)
+
    if method == "analyze_function":
        return _analyze_function(document, params)
    if method == "read_function_instructions":
@@ -161,8 +161,20 @@ private func unavailableIdentity(pid: Int32, reason: String) -> ProcessIdentityO
  )
 }

+enum ProcargsMalformedStage: String, CaseIterable {
+  case header
+  case argumentCount = "argument_count"
+  case executablePath = "executable_path"
+  case pointerSize = "pointer_size"
+  case pathPadding = "path_padding"
+  case arguments
+  case terminator
+  case trailingEntries = "trailing_entries"
+}
+
 enum RunTokenReadError: Error {
  case invalidBuffer
+  case invalidBufferAt(ProcargsMalformedStage)
  case duplicateToken
  case invalidTokenEncoding
  case environmentUnavailable
@@ -244,6 +256,8 @@ func processRunTokenObservation(
      return unavailable(pid: pid, reason: "apple_vector_unavailable")
    case .invalidBuffer:
      return unavailable(pid: pid, reason: "malformed_procargs")
+    case .invalidBufferAt(let stage):
+      return unavailable(pid: pid, reason: "malformed_procargs_\(stage.rawValue)")
    }
  }
 }
@@ -302,27 +316,30 @@ func parseProcessEnvironment(
  in bytes: [UInt8],
  pointerSize: Int = MemoryLayout<UnsafeRawPointer>.size
 ) throws -> ParsedRunToken {
-  guard bytes.count >= MemoryLayout<Int32>.size else { throw RunTokenReadError.invalidBuffer }
+  guard bytes.count >= MemoryLayout<Int32>.size else { throw RunTokenReadError.invalidBufferAt(.header) }
  let argc = bytes.withUnsafeBytes { $0.loadUnaligned(as: Int32.self).littleEndian }
-  guard argc >= 0, Int(argc) <= bytes.count else { throw RunTokenReadError.invalidBuffer }
+  guard argc >= 0, Int(argc) <= bytes.count else { throw RunTokenReadError.invalidBufferAt(.argumentCount) }
  var offset = MemoryLayout<Int32>.size
  guard let executablePath = readString(in: bytes, offset: &offset) else {
-    throw RunTokenReadError.invalidBuffer
+    throw RunTokenReadError.invalidBufferAt(.executablePath)
  }
-  guard pointerSize == 4 || pointerSize == 8 else { throw RunTokenReadError.invalidBuffer }
+  guard pointerSize == 4 || pointerSize == 8 else { throw RunTokenReadError.invalidBufferAt(.pointerSize) }
  let pathRecordSize = Array("executable_path=".utf8).count + executablePath.count + 1
  let padding = (pointerSize - pathRecordSize % pointerSize) % pointerSize
  guard offset + padding <= bytes.count,
        bytes[offset..<(offset + padding)].allSatisfy({ $0 == 0 }) else {
-    throw RunTokenReadError.invalidBuffer
+    throw RunTokenReadError.invalidBufferAt(.pathPadding)
  }
  offset += padding
+  let tokenPrefix = Array("REA_PROCESS_RUN_ID=".utf8)
+  var tokenInArgument = false
  for _ in 0..<argc {
-    guard readString(in: bytes, offset: &offset, allowEmpty: true) != nil else {
-      throw RunTokenReadError.invalidBuffer
+    guard let argument = readString(in: bytes, offset: &offset, allowEmpty: true) else {
+      throw RunTokenReadError.invalidBufferAt(.arguments)
    }
+    tokenInArgument = tokenInArgument || argument.starts(with: tokenPrefix)
  }
-  guard bytes.last == 0 else { throw RunTokenReadError.invalidBuffer }
+  guard bytes.last == 0 else { throw RunTokenReadError.invalidBufferAt(.terminator) }
  if offset == bytes.count {
    throw RunTokenReadError.environmentUnavailable
  }
@@ -340,7 +357,7 @@ func parseProcessEnvironment(
      continue
    }
    guard let entry = readString(in: bytes, offset: &offset) else {
-      throw RunTokenReadError.invalidBuffer
+      throw RunTokenReadError.invalidBufferAt(.trailingEntries)
    }
    trailingEntries.append(entry)
  }
@@ -361,22 +378,28 @@ func parseProcessEnvironment(
    throw RunTokenReadError.appleVectorUnavailable
  }
  if trailingEntries[appleVectorStart...].contains(where: {
-    $0.starts(with: Array("REA_PROCESS_RUN_ID=".utf8))
+    $0.starts(with: tokenPrefix)
  }) {
    throw RunTokenReadError.ambiguousEnvironmentBoundary
  }
  let environmentEntries = trailingEntries[..<appleVectorStart]
  var found: String?
  for entry in environmentEntries {
-    if entry.starts(with: Array("REA_PROCESS_RUN_ID=".utf8)) {
+    if entry.starts(with: tokenPrefix) {
      guard found == nil else { throw RunTokenReadError.duplicateToken }
-      let value = entry.dropFirst("REA_PROCESS_RUN_ID=".utf8.count)
+      let value = entry.dropFirst(tokenPrefix.count)
      guard let decoded = String(bytes: value, encoding: .utf8) else {
        throw RunTokenReadError.invalidTokenEncoding
      }
      found = decoded
    }
  }
+  // A changed process title can overwrite the original argument boundaries,
+  // causing a real environment entry to be consumed as an argument. A real
+  // argument can have this form too, so it proves neither ownership nor absence.
+  if tokenInArgument {
+    throw RunTokenReadError.ambiguousEnvironmentBoundary
+  }
  return ParsedRunToken(runId: found, environmentEntryCount: environmentEntries.count)
 }

@@ -70,6 +70,7 @@ export default defineConfig({
          { text: "Apple applications", link: "/apple-application-analysis" },
          { text: "Desktop installations", link: "/desktop-applications" },
          { text: "Firmware", link: "/firmware-analysis" },
+          { text: "iNES containers", link: "/ines-containers" },
          { text: "SQLite databases", link: "/sqlite-databases" },
          { text: "Packet captures", link: "/packet-captures" },
          { text: "Signal recordings", link: "/signal-recordings" },
@@ -103,6 +103,10 @@ existing analysis families directly, for example
 | `start_adb_activity`    | **mutates device** | Starts an intent (`am start -a` with optional URI, component, and up to 16 typed extras); preserves the activity manager's verdict                                                                                                    |
 | `stop_adb_app`          | **mutates device** | Force-stops every process of a package, ending a dynamic-analysis run                                                                                                                                                                 |

+Screen capture validates the PNG signature, IHDR framing, dimensions, and IHDR
+checksum before publishing. It does not validate encoding fields or decode and
+validate image contents; that limitation is retained in Evidence.
+
 When `push_adb_file` receives an existing directory, adb places the local file
 inside it under the local basename; Evidence reports that effective file path
 while retaining the caller's directory path in the input parameters. The
@@ -158,12 +158,12 @@ assigned by the app.

 Use the report's hints to decide what to record next:

-| Reason                          | Next step                                                                                |
-| ------------------------------- | ---------------------------------------------------------------------------------------- |
-| `unconfirmed`                   | Read the item and its list after the change.                                             |
-| `no-state-target`               | Record reads of the collection or item the operation changes.                            |
-| `no-observation`                | Read back a created item. For an edit or delete, also read it before changing it.        |
-| `contradicted` or `side-effect` | Inspect the reported disagreement. The operation may need behavior REA cannot model yet. |
+| Reason                          | Next step                                                                                                                   |
+| ------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| `unconfirmed`                   | Read the item and its list after the change.                                                                                |
+| `no-state-target`               | Check the path template and recorded views; record missing reads. The route form may not be supported as a mutation target. |
+| `no-observation`                | Read back a created item. For an edit or delete, also read it before changing it.                                           |
+| `contradicted` or `side-effect` | Inspect the reported disagreement. The operation may need behavior REA cannot model yet.                                    |

 See the [full reason table](agent-environments.md#build-a-bundle-in-one-step)
 for the other cases. Rebuild from the new recording and check the report
@@ -174,7 +174,7 @@ what to record next; hints never change what is served:

 | Reason                | Hint                                                                                                                                                                                                                                             |
 | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| `no-state-target`     | The write's path names no collection or item the capture reads. Read the collection or item it changes.                                                                                                                                          |
+| `no-state-target`     | The write could not be linked to a modelled target. Check the path template and recorded views; record missing reads. Some route forms may not be supported.                                                                                     |
 | `no-call`             | No recorded call of this tool was modelled, for example because every call failed. Record a successful call.                                                                                                                                     |
 | `body-unusable`       | The retained request or response cannot be modelled. Record a successful call with a complete supported request and reproducible response.                                                                                                       |
 | `no-observation`      | Nothing showed the entity or document this write changed. Read a created entity back by id right after the write; for an update or delete the state must already hold the entity, so read it before the write or record the create that made it. |
@@ -723,6 +723,8 @@ and `POST` tools the capture shows only reading (a lookup answering as a `GET`
 did, an RPC tunnel naming read operations, a session renewal), stay served and
 answer from their recordings with the reason `query-body`; they are not write
 tools.
+`HEAD`, `OPTIONS` and `TRACE` tools also replay their captured responses; their
+state views report `method-replay` and coverage counts them as recorded reads.

 A line establishes whole-collection membership only from the beginning:
 `offset`, `start`, `_start` and `page` must be zero when present. Positive or
@@ -737,14 +739,14 @@ tools are not served, so no call claims a change it does not make; each one's
 plan states why in its `reason`. A served write changes the live state, which
 every MCP session and `data/get` then see:

-| Effect                    | Call                                                                                                                                                                                                                                                                                                                 |
-| ------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `create`                  | Adds an entity to the collection the path names, built from the observed entity with each ruled field taken from the call or generated, at the plan's `insert` position. A plan tied to its exemplar's collection writes only there.                                                                                 |
-| `update`                  | Sets the sent members on the entity the path names, constants for members accepted only with their recorded value, and the clock, nested clock, increment, slug, stamp, derived, composed, reference, unique and renewed changes the plan models.                                                                    |
-| `update` (action)         | A `POST`, `PUT` or `PATCH` to an item path plus an action segment (`/{type}/{id}/archive`) sets, on the entity before the segment, each scalar the recorded calls showed the action set (`set`), with any sent members; it is served only when a recorded call found those fields already set, so a toggle never is. |
-| `delete`                  | Removes the entity the path names.                                                                                                                                                                                                                                                                                   |
-| bulk `update` or `delete` | A `DELETE`, `PUT` or `PATCH` at a collection, or a `POST` to it plus `delete`, `remove` or `destroy`, applies its effect to every entity the body names, as recorded: an array of ids or of objects carrying the id field, at the root or as the body's one array member (`{"IDs": […], "Read": true}`).             |
-| `document`                | Merges the body into the plan's document object, or replaces it for `PUT`.                                                                                                                                                                                                                                           |
+| Effect                    | Call                                                                                                                                                                                                                                                                                                                                                                                                |
+| ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `create`                  | Adds an entity to the collection the path names, built from the observed entity with each ruled field taken from the call or generated, at the plan's `insert` position. A plan tied to its exemplar's collection writes only there.                                                                                                                                                                |
+| `update`                  | Sets the sent members on the entity the path names, constants for members accepted only with their recorded value, and the clock, nested clock, increment, slug, stamp, derived, composed, reference, unique and renewed changes the plan models.                                                                                                                                                   |
+| `update` (action)         | A `POST`, `PUT` or `PATCH` to an item path plus an action segment (`/{type}/{id}/archive`) sets, on the entity before the segment, each scalar the recorded calls showed the action set (`set`), or flips each boolean they showed it flipping both ways (`toggle`), with any sent members; it is served only when a recorded call found what it sets already set, or flipped back what it toggles. |
+| `delete`                  | Removes the entity the path names.                                                                                                                                                                                                                                                                                                                                                                  |
+| bulk `update` or `delete` | A `DELETE`, `PUT` or `PATCH` at a collection, or a `POST` to it plus `delete`, `remove` or `destroy`, applies its effect to every entity the body names, as recorded: an array of ids or of objects carrying the id field, at the root or as the body's one array member (`{"IDs": […], "Read": true}`).                                                                                            |
+| `document`                | Merges the body into the plan's document object, or replaces it for `PUT`.                                                                                                                                                                                                                                                                                                                          |

 An update's unsent changes follow the plan's rules. A `held-clock` is a clock
 the client sends back as it read it and the application stamps anew (Ghost's
@@ -755,7 +757,9 @@ the entity already names under its `created…by` counterpart into a
 `modified…by` or `updated…by` field. A `derived` field takes a value showing
 the one sent member's text that the entity stores nowhere (a field Ghost
 derives from `html`), only with that member's recorded value. An action's
-`set` rule sets a scalar to the value the recorded calls left it at.
+`set` rule sets a scalar to the value the recorded calls left it at, and its
+`toggle` rule flips a boolean, refusing a call on an entity that holds none
+there (Miniflux's `PUT /v1/entries/{id}/bookmark` stars and unstars).

 Its answer has the status and content type of the plan's recorded response,
 with the written entity or its identity rendered in, no body, or the recorded
@@ -39,7 +39,9 @@ unverified.

 `inspect_android_package` also returns a static inventory of declared
 activities, aliases, services, receivers and providers from the decoded
-manifest. `declared_name` preserves the source attribute; `name` resolves a
+manifest. The binary XML decoder preserves component class spelling, including
+`$` in nested classes, without applying JADX class aliases. `declared_name`
+preserves the decoded source attribute; `name` resolves a
 relative name only when the manifest package is known and the resolved copy
 fits the UTF-8 byte budget. An unresolved package or exhausted name budget
 retains the declared name and marks the inventory partial. Empty component
@@ -250,6 +252,35 @@ queries accept the same `overload_index`; the bridge resolves the selected
 method node and the result reports its index and displayed signature. These
 indices are tied to the current artifact and engine, not stable across builds.

+Method reference queries also accept an external class, such as
+`android.app.NotificationManager --method-name notify`, when the APK directly
+invokes that exact DEX class and method name. If multiple prototypes are observed,
+the input error lists their exact DEX descriptors and local overload indices;
+repeat with an explicit `--overload-index`. These are the prototypes observed in
+the APK, not the complete method inventory of an Android framework or library.
+
+Such results report `target_definition: "external"` and
+`reference_scope: "direct_dex_invokes"`. Each using method has `source_selector`
+with `class_name`, `method_name` and `overload_index`; pass those fields with the
+same APK path to `inspect_android_method` to inspect the caller. Repeated direct
+invokes in one method remain one using node with multiple instruction offsets.
+This scans raw invoke instructions in JADX's admitted APK methods without
+generating their source. It does not resolve reflection, JNI, method handles,
+inherited method lookup or possible runtime dispatch. Class-only queries and
+class/method inspection still require an APK definition; an external target has
+no invented body. Unknown class/method names remain input errors.
+
+External prototype and caller metadata use a bridge-frame-derived representation
+allowance that reserves space for retained raw calls and CLI/MCP copies. Exhausting
+it returns a typed `resource_constraint`, rather than a truncated caller list
+reported as complete. Direct instruction offsets have their separate explicit
+`direct_invokes_exhaustive` coverage. Older retained Evidence may omit the new
+definition, scope and caller-selector fields; omission does not establish them.
+The bridge checks prototype expansion before copying descriptors or joining
+displayed signatures. It reuses one bounded prototype inventory for the exact
+class/method selection in the current APK session; replacing the session or
+selection invalidates that retained result.
+
 `inspect_android_class` also reports `dex_static_value` for each `static final`
 field whose class definition encodes a value in its DEX static values, so
 compile-time constants are readable even when the class has no `<clinit>`.
@@ -734,3 +765,7 @@ containing node's unknown `dex_offset`. `direct_invokes_exhaustive: false`
 means instruction rows were bounded by the local bridge frame budget; `null`
 means the producer did not establish instruction coverage. Using-node totals
 and coverage do not imply complete instruction evidence.
+`direct_invokes_coverage` reports counts of using nodes with complete, partial,
+or unknown positions, plus the number of retained instruction sites. This
+aggregate makes position truncation visible without scanning every caller;
+older retained Evidence may omit it, which means the aggregate was unexamined.
@@ -179,26 +179,31 @@ share the application workflow, projection, retention and publication owners.
  - `schemes_agree_on_signer` (observed): every present block scheme presents
    the same _set_ of signer certificates. An extra signer in one scheme is
    disagreement; a signer without a certificate makes it `null` (unknown).
-    Build-tools 33+ rotate through v3.1 by default, so a rotated app usually
-    reads `false` here and `true` below.
+    A single present block scheme with known signers agrees with itself;
+    v1 is compared separately below.
  - `signer_change_declared_by_rotation` (declared): the signers differ, but
-    each appears in a lineage the APK declares. Read the two together: a
-    rotated APK shows `false` / `true`; signers that differ with no declared
-    lineage containing them show `false` / `false`. It is `null` when a
-    signer's identity is unknown, or when the signers differ and a declared
-    lineage could not be decoded.
+    each appears in a lineage the APK declares. Read the two together: block
+    schemes with different signers covered by a declared lineage show `false`
+    / `true`; differing signers without such a lineage show `false` / `false`.
+    A lineage alone does not establish a change between block schemes. It is
+    `null` when a signer's identity is unknown, or when the signers differ and
+    a declared lineage could not be decoded.
  - `v1_signers_match_block_signers` (observed): the v1 signer certificates
    equal what the lowest block scheme that has signers (v2, else v3, else
    v3.1) expects v1 to carry. That is its signer set, except that a v3/v3.1
    signer declaring a rotation lineage expects the lineage's first
    (original) certificate, as apksig requires. `false` is notable: the JAR
-    signature names a different key than the block signature. A key rotation
-    keeps v1 (and v2) on the original key, so it reads `true` while
-    `schemes_agree_on_signer` reads `false`, with or without v2. `null` when
-    v1 or a block scheme is absent, any signer's identity is unknown (a
+    signature names a different key than the block signature. When v1 uses
+    the lineage's original key and v3 its newer key, this comparison reads
+    `true`. If v3 is the only present block scheme, agreement is `true` and
+    declared inter-block signer change is `false` even though rotation is
+    present. If v2 also uses the original key, agreement is `false` and the
+    declared inter-block change is `true`. `null` when
+    v1 or a populated block scheme is absent, any signer's identity is unknown (a
    `decode_error`, a `null` certificate or a `subjectKeyIdentifier`
    `SignerInfo`), or the lineage's original certificate cannot be
-    identified; a limitation then says why.
+    identified. When identities or a lineage origin are unknown, limitations
+    explain why; absence is shown in the scheme records.
  - `strongest_scheme`, `rotation_present`, `source_stamp_present`,
    `self_consistent`.

@@ -101,8 +101,8 @@ limitation reports how many inventoried entries were left out. IPA projection
 still lists every archive component, including `SwiftSupport/`.

 `platforms` lists `macos` for application roots with `Contents/`. It lists `ios`
-for shallow application roots that have an `Info.plist`. An application root
-with neither, such as an empty inventory, has no platform.
+for shallow application roots that have an `Info.plist` at their root. An
+application root with neither, such as an empty inventory, has no platform.

 ## macOS bundle anatomy

@@ -149,6 +149,11 @@ directories rather than `Versions/Current`. A framework's `info_plist_path` is
 because `Versions/Current` decides which one applies) or when its single
 version directory has no `Resources/Info.plist`.

+A `shallow` bundle's `info_plist_path` is its root `Info.plist`. Without one,
+it is `Resources/Info.plist`: a flattened macOS framework keeps its binary,
+`_CodeSignature/`, and `Resources/` directly in the `.framework`, like a single
+`Versions/<version>/` directory without the `Versions/` wrapper.
+
 AppleDouble sidecar files (`._*` and `__MACOSX/`) are inventory facts, but they
 describe neighbouring files. They are excluded from roots, bundle roles, and the
 anatomy components.
@@ -52,7 +52,11 @@ observations may omit the coverage field; treat omission as `unknown` rather
 than inferring completeness from the array.

 Passive DOM comparison checks complete node inventories and complete frame
-parent/child structure independently. Frame IDs and sibling enumeration order
+parent/child structure independently. Node value lengths are comparable only
+when both nonempty snapshots declare the same `node_value_length_unit`.
+Missing or different units leave length comparison unknown; independent node
+or frame structural differences can still prove change. Empty inventories have
+no value lengths to compare. Frame IDs and sibling enumeration order
 are capture-local and do not establish a change; duplicate IDs, missing parents,
 and cyclic ancestry remain unknown. A complete frame difference can still prove
 change when DOM nodes are incomplete, and vice versa. Partial DOM or metadata
@@ -400,7 +404,19 @@ contextual evidence with `timestamp: null`, accompanied by a limitation stating
 that it does not establish activity in the selected window. Main-frame scope
 enforcement still applies to contextual navigation events. Network redirect
 events retain their paired prior-hop response context when the timestamped
-next-request event falls inside the window. The pre-arm timeline buffer is bounded
+next-request event falls inside the window. A redirect row's optional
+`redirect_response` contains the prior response `url`, CDP-reported `status`,
+and `scope`. The URL has transport credentials removed; URL and status are
+withheld unless its origin is approved. Missing or malformed response URLs have
+null scope and add `invalid_protocol_value` timeline coverage; a valid URL with an
+unsupported protocol has `unsupported` scope. Outside-policy and unsupported
+responses mark the timeline as policy-filtered with `disallowed_origin` or
+`unsupported_url`. Missing status remains null rather than zero. A supplied
+non-numeric status is also null and records `invalid_protocol_value` coverage;
+the other valid response facts remain available. Historical rows may omit this
+field; omission does not establish that no prior response existed. Response
+headers and bodies are discarded. The row timestamp belongs to the next request,
+not an exact prior response time. The pre-arm timeline buffer is bounded
 by original CDP message bytes. If clock sampling completes after that budget is
 exhausted, the operation returns `payload_limit` instead of a partial window.
 Cancellation and clock-request failures retain their own outcomes. Session
@@ -449,7 +465,7 @@ not bound the whole process heap.
 REA retains local observation data and removes only URL userinfo credentials, explicitly declared scenario secrets, and values from structured credential/storage fields:

 - URL observations preserve the complete local URL, including query values, fragments, duplicate parameters, and their order. Only username/password userinfo is removed; malformed original URL strings remain available with `origin: null`.
- DOM snapshots retain node types, node names, value lengths, and attribute names, but not text or attribute values.
+- DOM snapshots retain node types, node names, value lengths, and attribute names, but not text or attribute values. `dom.node_value_length_unit` is `utf16-code-units` for web observations and applies to every node's `node_value_length`; it counts JavaScript string code units, not Unicode code points or UTF-8 bytes. Electron observations declare `utf8-bytes` instead. Historical captures without the unit leave it unknown; reading them does not infer a unit or convert their stored lengths.
 - Supported DOM URL attributes are projected separately as resolved destinations. Empty `action` on HTML or XHTML forms and empty `formaction` on HTML or XHTML submit controls resolve to the document URL; other relative URL attributes resolve against the captured document base.
 - Accessibility structure and reported roles are retained by default, while names and descriptions require `include_accessibility_text: true`. The browser protocol may omit an individual role; that role remains unknown for comparison. Other observed accessibility differences can still establish a change.
 - Network observations retain method, status, MIME type, size, type, initiator stack location, and complete URLs with userinfo credentials removed. Redirects reported by CDP are attached as ordered `redirects` on the one request ID, with the prior request URL, CDP response URL, method/type, response status/MIME/encoded length, request timestamp, and the next `requestWillBeSent` event timestamp. CDP delivers `redirectResponse` with that next request event, so the latter is an event boundary rather than an exact response timestamp. Redirect response headers and bodies are discarded; hops outside the selected origins are discarded with the request chain. Headers are discarded after an allowlisted projection of length/encoding, structured CSP/Link/policy fields, and untrusted agent hints. Cookies and authorization headers are never retained.
@@ -411,8 +411,10 @@ data you may change. This scenario creates one item:
 - Request steps follow no redirects: a redirect answer fails the step, and
  nothing is sent to the location it names, though a write the redirect
  answered may already have been applied. `expected_status` cannot name a 3xx
-  status. Give the path the redirect names; with header values selected, the
-  capture records its `Location`.
+  status. Manual redirects can be opaque to the page and may not produce a
+  response event; their status and `Location` can therefore be unavailable even
+  when network events and header values were selected. Such captures report
+  incomplete event coverage.
 - Header values are literals, declared secrets, a cookie the browser holds for
  the request URL (`{"source": "cookie", "name"}`, HttpOnly cookies included,
  whose value the page's scripts can then see while the request runs), or a
@@ -0,0 +1,62 @@
+# Bun standalone executables
+
+`inspect-artifact` inventories embedded Bun module graphs in Mach-O `__BUN,__bun`,
+PE `.bun`, ELF `.bun`, and appended trailers. `extract-artifact` writes their stored
+module contents through the existing safe output tree. Neither operation executes
+the executable or decompiles bytecode.
+
+```sh
+rea inspect-artifact ./hello --json
+rea extract-artifact ./hello --json
+```
+
+In MCP, open the executable with `open_binary`, then call `inspect_artifact`.
+Use `detail: "summary"` for large graphs and `inspect_analysis_view` to page retained
+Evidence. The root metadata's `entry_point_logical_path` is the reader-owned
+location of its entry module. Use it as an inventory `logical_paths` filter,
+then read selected node fields with the returned content identity. This also
+works for names mapped to indexed extraction paths. The complete Evidence stays
+retained; no source-name normalization is needed in the caller.
+
+The root reports the carrier, layout, module count, entry point, raw flags and
+compile exec-argv. Each module retains its source name, loader and encoding values,
+entry-point status, sizes and SHA-256. Sourcemaps, bytecode and module-info regions
+are separate children. Source names such as `/$bunfs/root/main.js` remain in
+metadata; extraction uses a relative path. Unsafe or non-UTF-8 names receive an
+indexed path and retain their source spelling or bytes. Virtual names deeper
+than 256 logical path parts also use an indexed path with an explicit limitation,
+preventing unbounded path-tree work while retaining the source fact. Duplicate names remain
+separate occurrences; ordinary extraction collision rules apply.
+
+The recognized record shapes are the 36-byte Bun 1.3.3 layout and the 52-byte
+Bun 1.3.9 layout. These labels identify structural layouts, not a detected compiler
+version. Bun does not store an explicit revision identifier: unknown table sizes
+and ambiguous known layouts are unsupported. A future layout that is byte-for-byte
+compatible cannot be distinguished. Invalid pointers and truncated claimed sections
+are malformed. An absent trailer without a named section does not establish a Bun
+graph. Unknown enum values remain raw, with a null name.
+
+Sourcemaps are stored Bun regions, not necessarily standalone JSON source maps.
+Extracted contents retain their original encoding. Use JavaScript analysis only on
+compatible source files; bytecode is retained as evidence, not decoded.
+
+Module parsing reads exact metadata ranges rather than loading stored asset
+bodies or whole pages around small pointers. A cache retains at most 256 KiB
+and 1,024 ranges for one reader preparation. Cumulative uncached metadata reads
+are limited to 256 MiB, checked before allocation or I/O. The module table,
+decoded strings and combined logical path tree have separate admission checks;
+at most 250,000 distinct path prefixes are admitted before inventory construction.
+Stored bodies are range-streamed for hashing and extraction. Header/suffix observations are reused
+only for the same admitted file state, with selected-path checks before publication.
+
+See [limits and recovery](design/limits-and-recovery.md) for admission ceilings.
+Synthetic tests cover the carriers and malformed declarations. Run
+`node scripts/verify-bun-standalone.mjs` after `npm run build:cached` for local Bun
+verification, and add `--docker` to compile a Linux fixture with `oven/bun:1.4.0`.
+Bun and Docker are fixture producers only and are not installed by REA.
+
+Layout references: [Bun 1.3.3 serializer](https://github.com/oven-sh/bun/blob/bun-v1.3.3/src/StandaloneModuleGraph.zig)
+and [Bun 1.3.9 serializer](https://github.com/oven-sh/bun/blob/bun-v1.3.9/src/StandaloneModuleGraph.zig).
+
+The current 52-byte record order can also be checked in the
+[Bun 1.4.4 Rust serializer](https://github.com/oven-sh/bun/blob/bun-v1.4.4/src/standalone_graph/StandaloneModuleGraph.rs).
@@ -165,6 +165,15 @@ into the current shell:
 eval "$(rea completions bash)"
 ```

+For zsh, initialize completion before loading the hook. If your shell already
+runs `compinit`, place the hook after that existing initialization:
+
+```zsh
+autoload -Uz compinit
+compinit
+eval "$(rea completions zsh)"
+```
+
 The Bash hook supports macOS system Bash 3.2. It uses optional completion
 features when the shell provides them and falls back to portable registration.
 Completion includes standard global options and the active command's options;
@@ -261,6 +270,29 @@ Format versions 6 through 8 retain header, block and directory facts with
 none/LZ4/LZ4HC block decompression. See [UnityFS](unityfs.md) for encryption
 and LZMA coverage boundaries.

+Inspect an ESP32-family app or bootloader image without esptool:
+
+```sh
+rea inspect-artifact firmware.bin --json
+rea extract-artifact firmware.bin --json
+```
+
+The inventory lists each segment with its ESP-IDF load classification, the
+checksum and SHA-256 results, the descriptor and any Secure Boot v2 signature
+blocks. See [ESP images](esp-image.md) for recognition, coverage and refusals.
+
+Inspect an ESP flash dump, or one read from a flash address other than 0:
+
+```sh
+rea inspect-artifact flash.bin --json
+rea inspect-artifact dump.bin --target-format esp-flash-image --flash-offset 0x1000 --json
+rea extract-artifact flash.bin --json
+```
+
+The inventory lists the bootloader, the partition table and each partition,
+with ESP image facts for app partitions and the OTA records. See
+[ESP flash images](esp-flash-image.md) for table location, inputs and limits.
+
 Inspect a Node.js SEA carrier without running it:

 ```sh
@@ -291,6 +323,32 @@ rea extract-artifact ./firmware.bin --json
 See [U-Boot uImage](uimage.md) for verified CRCs, physical component ranges,
 unknown names, resource limits and retained views. Compressed bytes stay stored.

+`inspect-artifact` and `extract-artifact` also read ZIP members compressed with
+Zstandard (standard method 93). They retain the shared ZIP CRC, declared-size,
+overlap and archive expansion checks. The native streaming decoder keeps the
+existing 128 MiB Zstandard window cap; frames requiring a larger window are
+refused. Deprecated method 20 and other unregistered ZIP codecs remain unsupported.
+
+Inventory and extract UF2 or DfuSe regions:
+
+```sh
+rea inspect-artifact ./firmware.uf2 --json
+rea extract-artifact ./firmware.dfu --json
+```
+
+See [UF2 and DfuSe images](uf2-dfuse.md) for recognition, families, numbering,
+the DfuSe suffix CRC and limits.
+
+Inventory and extract U-Boot FIT images:
+
+```sh
+rea inspect-artifact ./boot.itb --json
+rea extract-artifact ./boot.itb --json
+```
+
+See [U-Boot FIT images](fit-images.md) for recognition, data sources, hashes
+and limits.
+
 Inspect local model declarations without loading weights:

 ```bash
@@ -594,6 +652,11 @@ rea compare left.json right.json --record_pairs '[{"left_evidence_id":"ev_<left-
 Migration: replace `rea compare-bundles` with `rea compare`; the former command
 has been removed. The MCP tool remains `compare_bundles`.

+`rea compare` compares records by Evidence identity and explicit pairs. It does
+not read artifact contents: the inventories of two builds are unresolved
+records, or one opaque change when you pair them. Use `compare-artifacts`,
+described at the end of this section, to compare their contents.
+
 `--record_pairs` supplies an explicit JSON array of observation pairs, matching
 MCP `compare_bundles.record_pairs`. Pair IDs must exist on their named sides and
 be one-to-one. Without pairs, one-sided membership remains unknown; REA does
@@ -610,12 +673,63 @@ with `details.reason: path-limit` and `boundary: filesystem-path`.
 For application traces and version comparisons, see
 [JavaScript application workflows](javascript-application-workflows.md).
 MCP [retained Evidence references](mcp-contracts.md#retained-application-evidence-inputs)
-belong to one connection. Separate CLI calls can consume full saved records.
-`inspect-analysis-view REQUEST.json --evidence-bundle BUNDLE.json` resolves
-the request's `retained-evidence` source ID from that authenticated bundle,
-including bundles exported from an MCP session. The same view JSON works for
-every supported parent kind; no target is reopened and no record is selected
-by file order. Omit `--evidence-bundle` when the request supplies inline Evidence.
+belong to one connection. Separate CLI calls can consume full saved records or
+resolve exact retained IDs from an explicitly selected local bundle:
+
+```bash
+rea trace-application-feature request.json --evidence-bundle /absolute/path/evidence.json --json
+```
+
+Here `request.json` uses the same logical Evidence input as MCP, for example
+`"application": {"kind":"retained-evidence","evidence_id":"ev_<64 lowercase hex characters>"}`.
+Inline records and references may be mixed in the request's declared source
+fields, including arrays and nested inputs. The bundle is read and authenticated
+once for that command; no target is reopened, no producer is rerun, and no
+record is selected by file order. Source identity, provenance, coverage and
+partial or unknown facts agree with the complete inline form. When starting
+from summary or inspection Evidence, select its
+`normalized_result.parent_evidence_id` for a workflow requiring complete source
+facts. Omit `--evidence-bundle` when all sources are inline.
+
+The JSON workflow commands supporting this option are:
+
+- `trace-application-feature`, `trace-javascript-semantics`,
+  `compare-application-versions`, `compare-javascript-export-shapes`,
+  `compare-source-to-bundle`, and `reconcile-javascript-runtime`.
+- `import-managed-reconstruction`, `verify-managed-native-boundaries`, and
+  `project-managed-application-graph`.
+- `project-android-application-graph`, `project-apple-application-graph`, and
+  `project-harmony-application-graph`.
+- `compare-wasm-interfaces` and `inspect-analysis-view`.
+
+For `inspect-analysis-view`, the request's source reference selects a parent
+from the bundle for every supported view kind. Bundles exported from MCP work
+for these commands. Its inline source form cannot also select a bundle.
+A missing ID is refused with `details.reason: "missing"`;
+supplying a bundle does not make incompatible Evidence valid for a workflow.
+`compare-managed-members` keeps its two assembly paths, and
+`compare-process-captures` keeps its two capture Evidence JSON paths. The bundle
+option above selects an input; producer options that write a new bundle, such
+as `inspect-managed-members --evidence-bundle`, retain their existing meaning.
+File selectors remain available only on contracts that explicitly support them.
+
+Compare two artifact inventories with `compare-artifacts`. It takes the same
+`left` and `right` input as MCP `compare_artifacts`: complete Evidence, or an
+`evidence-file` source with an optional `evidence_id` that selects one record
+from a bundle. Relative paths resolve from the working directory:
+
+```bash
+rea inspect-artifact old.zip --json > old.json
+rea inspect-artifact new.zip --json > new.json
+rea compare-artifacts '{"left":{"kind":"evidence-file","path":"old.json"},"right":{"kind":"evidence-file","path":"new.json"}}' --json
+```
+
+A one-shot `compare-artifacts` command keeps no session Evidence, so it refuses a
+`retained-evidence` source with `details.reason: "missing"`. Select the record
+from a saved bundle instead.
+For an artifact summary selected from a bundle, include its complete parent
+inventory in the same bundle. The command resolves that parent from the
+authenticated file records; a summary-only file cannot supply missing facts.

 ## Import historical source

@@ -794,7 +908,13 @@ rea mcp --http --port 8765
 `--host` and `--port` default to `MCP_HOST` and `MCP_PORT` from the environment,
 then to `127.0.0.1` and an ephemeral port. A bind outside loopback requires
 `MCP_ALLOWED_HOSTS` or `--allowed-hosts`, a comma-separated list of client host
-names or IP addresses without URLs or ports. For example:
+names or IP addresses without URLs or ports.
+
+Repeat `--allowed-hosts` to append names, or put multiple names in one
+comma-separated value. All occurrences are validated together and deduplicated
+after hostname normalization; the explicit list replaces `MCP_ALLOWED_HOSTS`.
+
+For example:

 ```sh
 rea mcp --http --host 0.0.0.0 --allowed-hosts 127.0.0.1,rea.lan
@@ -999,8 +1119,8 @@ Malformed format values and token windows fail with `INVALID_OUTPUT_VALUE` in th
 selected structured format. Token limits and offsets must be nonnegative safe
 integers; zero selects an empty window. These checks run before command execution. `--json` is indented on a terminal and compact when piped or
 redirected, which keeps large results smaller for agents and scripts; pipe
-through `jq .` for indented files. Output selection and formatting do not change
-operation status.
+through `jq .` for indented files. A formatting refusal exits nonzero even when
+the underlying operation succeeded.

 `--format md` escapes backslashes, pipes, and inline Markdown syntax in table
 headers and cells so source text is displayed literally, and renders cell line
@@ -1012,6 +1132,12 @@ values instead of replacing them with an object label. Table widths are measured
 iteratively, so an admitted row page is not limited by the JavaScript function
 argument count.

+Markdown refuses selected NUL characters and unpaired UTF-16 surrogates because
+renderers or UTF-8 output would substitute them. TOON refuses selected unpaired
+surrogates for the same UTF-8 reason. Use JSON or YAML to retain those values.
+An authored replacement character and valid supplementary characters are not
+treated as malformed.
+
 `--format csv` and `--format tsv` export one selected row collection. Select an
 exact array path with `--filter-output` and provide comma-separated direct
 scalar columns with `--columns`; column order is the output column order:
@@ -1031,7 +1157,8 @@ delimiter, quotes, or line breaks are quoted and embedded quotes are doubled.
 Values are emitted as UTF-8 without Unicode normalization. Missing and `null`
 cells are empty; booleans and finite numbers use their ordinary text forms.
 String cells and headers that begin with spreadsheet formula syntax are refused
-with a structured error; JSON retains those values unchanged.
+with a structured error; unpaired surrogates in selected cells or headers are
+also refused. JSON retains those values unchanged.

 Delimited output does not flatten nested Evidence or nested field values.
 It returns a structured error and a nonzero status if the filter does not
@@ -1190,3 +1317,8 @@ rea inspect-pe-load-config /absolute/path/to/application.exe --json
 Reports TLS callbacks and size-covered load-config fields without execution.
 Use `--max-callbacks` and `--max-file-bytes` to set read budgets. See
 [PE TLS and load configuration](pe-load-config.md).
+
+Bun standalone executables use the existing `inspect-artifact` and
+`extract-artifact` commands to inventory and materialize embedded source,
+sourcemaps and bytecode without running the executable. See
+[Bun standalone executables](bun-standalone.md) for layout coverage and limits.
@@ -273,7 +273,7 @@ This headroom is a practical default, not a guarantee for every analysis
 duration. Setup preserves positive timeout values already in the `rea` entry.

 Setup also forwards explicitly selected input/output schema profiles,
-`REA_MCP_MAX_RESPONSE_BYTES`, provider paths and supported Ghidra, JADX and Kuna
+`REA_MCP_MAX_RESPONSE_BYTES`, `REA_MCP_MAX_INPUT_ELEMENTS`, provider paths and supported Ghidra, JADX and Kuna
 settings. It also forwards explicit executable and resource selections for ADB,
 apktool, packet capture, GDB/Rizin/objdump, Cutter, WABT, Wakaru, firmware and
 signal tools, browser inspection, and pwntools/pwndbg. This includes their
@@ -283,8 +283,9 @@ patterns. A provider being unavailable does not discard its selected paths;
 doctor reports its readiness separately. Explicit selections override discovered
 defaults, including when setup runs again with a changed selection. Unrelated
 environment variables, process ownership tokens and one-shot target paths are not
-copied. Existing client environment overrides remain intact unless setup supplies
-the same key.
+copied. For an explicitly configured startup target, see the
+[initial-target settings](mcp-contracts.md#initial-target-at-startup). Existing
+client environment overrides remain intact unless setup supplies the same key.
 You can edit `startupTimeoutMs` and `toolTimeoutMs` there; doctor keeps positive
 caller-selected values aligned and reports a non-blocking advisory when a tool
 timeout is shorter than the known provider allowance.
@@ -616,9 +617,10 @@ the fallback file untouched. Existing REA environment overrides are preserved
 when refreshing its command. A malformed or unreadable fallback file fails setup instead of
 being silently suppressed; repair or remove it and rerun. Uninstall removes an
 REA-owned `rea` entry from both the native table and the fallback, backing up
-each changed file, so an emptied native table cannot load a leftover fallback
-registration; other fallback servers, settings and a foreign `rea` entry are
-kept. ZCode disables a
+each changed file. If removing the last native server would activate a retained
+fallback server, uninstall refuses before changing either file; review the
+fallback configuration before retrying. Other fallback servers, settings and a
+foreign `rea` entry are kept. ZCode disables a
 server with `enable: false` on its entry; doctor reports such a registration
 as stale, and rerunning setup removes the flag to repair it. Native configuration
 uses strict JSON; setup refuses comments, trailing commas and a BOM rather than
@@ -378,3 +378,17 @@ The [verification report](../verification/runtime-analysis-settings.md) separate
 public MCP checks, simulated provider coverage, real Ghidra execution, and
 measured task costs. It does not establish real-provider behavior for every
 editable setting or active worker telemetry.
+
+## Bun standalone module graphs
+
+`MAX_BUN_MODULE_COUNT` admits at most 100,000 module records.
+`MAX_BUN_RETAINED_BYTES` admits at most 256 MiB of serialized graph payload and
+separately bounds retained entry metadata. Physical metadata read work is also
+limited to 256 MiB per preparation, including repeated uncached ranges. A
+256 KiB / 1,024-entry exact-range cache avoids full-page amplification. The
+combined logical path tree admits at most 250,000 distinct prefixes; this is
+checked before adding nodes, with shared prefixes counted once. The shared
+artifact expansion budget also bounds the sum of referenced member lengths. Refusals name the boundary.
+There is no runtime override; additional host memory or `NODE_OPTIONS` does not
+raise these ceilings. Use a smaller producer fixture or a separately reviewed
+reader for larger graphs. No partial extraction is claimed on admission failure.
@@ -135,11 +135,13 @@ observations, not an atomic directory snapshot. Unread bytes remain unknown.
 ## Resource bounds and reuse

 Defaults are 20,000 examined entries and 8 MiB of total probe reads. Callers may
-select up to 100,000 entries and 64 MiB. A separate 32 MiB conservative
-representation budget bounds retained paths and facts before growth. Limits
-and failed probes produce partial coverage. Traversal and reads are serial.
-Each reader admits one inspection at a time; overlapping requests receive a
-retryable capacity refusal without cancelling the admitted caller.
+select up to 100,000 entries and 64 MiB. A separate 32 MiB representation
+budget bounds retained rows, paths and facts before growth. Each retained path
+is charged at the larger of its UTF-16 heap size and its escaped JSON size, so
+typical macOS bundle paths fit about 20,000 rows, and control-character paths
+fewer. Limits and failed probes produce partial coverage. Traversal and reads
+are serial. Each reader admits one inspection at a time; overlapping requests
+receive a retryable capacity refusal without cancelling the admitted caller.

 Unity reference decoding stops after a witness in each `Data/Managed` directory;
 other assemblies' references remain unexamined, while their headers are still
@@ -0,0 +1,110 @@
+# .NET single-file bundles
+
+Use `rea inspect-artifact /absolute/path/host --json` to inventory an ordinary
+.NET single-file host and `rea extract-artifact /absolute/path/host --json` to
+materialize its members into a fresh, REA-owned output directory. With a host
+selected through `open_binary`, the corresponding MCP tools are
+`inspect_artifact` and `extract_artifact`. No .NET installation is needed for
+inspection or extraction.
+
+For a compact inventory, call `inspect_artifact` with `detail: "summary"`,
+then use `inspect_analysis_view` with the returned `parent_evidence_id`.
+Inventory occurrence pages accept `logical_paths`, `occurrence_ids`, selected
+`fields`, `offset`, and `limit`; node pages accept batches of `artifact_ids`
+to retrieve expanded-byte digests. Include `format_metadata` and
+`source_location` when member declarations and stored extents matter. Identity
+fields survive projection, and the complete inspection Evidence stays retained.
+
+REA detects the apphost marker and its preceding header offset from PE, ELF,
+and thin Mach-O bytes, regardless of filename. An unbundled apphost's zero
+offset remains an ordinary native artifact. Universal Mach-O slice inventory
+keeps its existing behavior; bundled contents inside slices are not expanded.
+When a native file has a recognized PyInstaller CArchive, apphost-marker
+scanning stops before its payload. A .NET helper stored inside that archive
+does not replace the outer container's format; an outer .NET host can still
+contain a PyInstaller helper as a member.
+
+## Supported layout
+
+| Header | Producer generation                | Member encoding             |
+| ------ | ---------------------------------- | --------------------------- |
+| 1.0    | .NET Core 3.x                      | Uncompressed                |
+| 2.0    | .NET 5                             | Uncompressed                |
+| 6.0    | .NET 6 and later using this layout | Uncompressed or raw DEFLATE |
+
+Versions, minor versions, and flags outside this set are refused explicitly;
+they do not silently become an ordinary PE or a successful empty inventory.
+Flags 0 and the v2+ compatibility flag 1 are admitted. Unknown file-type bytes
+are retained with a limitation, rather than treated as executable authority.
+Encrypted/protected wrappers and recovering their payloads are outside this
+reader's scope.
+
+The host keeps its whole-file SHA-256. Each embedded file gets its expanded-byte
+SHA-256, path, declared size, compressed size, and `format_metadata` declaration
+(`major_version`, `minor_version`, `file_type`). Its `source_location` describes
+the stored host extent, including the compressed length when applicable.
+The root manifest's `root_format` is `dotnet-bundle`; the root content node
+still records its native PE/ELF/Mach-O format. A file-type declaration or `.dll`
+suffix does not establish a valid assembly. Inspect an extracted component
+explicitly with the managed tools to establish PE/CLI facts.
+
+## Admission and containment
+
+Metadata is range-read with a 64 KiB cache. Policy budgets are 16 MiB of
+manifest metadata, 100,000 files, 64 KiB per UTF-8 string, 512 MiB of stored or
+expanded bytes per file, 256 path parts per member, 250,000 distinct in-memory
+path-tree nodes, and 2 GiB of aggregate expanded bytes. The node budget counts
+shared directory prefixes only once. These are REA
+resource policies, not limits imposed by Microsoft's format. Marker scanning
+streams 64 KiB chunks and reuses completed probe facts during extraction;
+ordinary native files without a marker incur one extra
+read pass before host hashing.
+
+Extraction hashes the whole host again through the same descriptor used to read
+members and compares it with the inventory's root digest before creating an
+output directory. This adds a full-host read pass to extraction, including when
+the embedded members themselves are small.
+
+Malformed/truncated headers, unsafe or conflicting paths, overlapping member
+ranges, members crossing the manifest, contradictory configuration extents,
+invalid UTF-8, corrupt/trailing compressed data, and incorrect expanded sizes
+fail before output publication. Source descriptor/path identity is checked
+during reading; extraction verifies the host digest and member bytes against
+the inventory. Existing output roots are never overwritten. Cancellation and
+failures release owned streams/descriptors through the shared extraction
+rollback scope.
+
+## Reproduce producer fixtures
+
+The source-owned generator uses the installed .NET 8 SDK's **Microsoft
+HostModel** producer to emit x64 v1, v2, plain v6, and compressed v6 bundles
+for Windows, Linux, or macOS. It does not run generated hosts or download runtime packs. Supply an
+SDK apphost template from
+`packs/Microsoft.NETCore.App.Host.<rid>/<version>/runtimes/<rid>/native/apphost`
+(`apphost.exe` on Windows). Pass `windows` (the default), `linux`, or `osx`
+as the optional third generator argument to match that template.
+
+```bash
+dotnet build scripts/fixtures/dotnet-bundle/BundleFixture.csproj -c Release --configfile scripts/fixtures/dotnet-bundle/NuGet.Config -o /absolute/path/producer -p:BaseIntermediateOutputPath=/absolute/path/producer-obj/
+dotnet /absolute/path/producer/BundleFixture.dll /absolute/path/apphost.exe /absolute/path/absent-bundles-directory
+rea inspect-artifact /absolute/path/absent-bundles-directory/net8-compressed/Probe.exe --json
+rea extract-artifact /absolute/path/absent-bundles-directory/net8-compressed/Probe.exe --json
+```
+
+The generator writes `oracle.json` beside each host. An independent C#
+`BinaryReader`/`DeflateStream` pass records version, member types and stored
+extents, then compares every expanded member digest with its source file.
+Compare those records with inspection Evidence and the extracted bytes.
+This verifies Microsoft's compression writer separately from synthetic parser
+fixtures; it is not evidence that the bundled host executes on a target runtime.
+
+Deterministic boundary and public-entrypoint coverage:
+
+```bash
+npm run test:focused -- tests/boundary/filesystem/dotnetBundleArtifacts.test.ts tests/acceptance/dotnetBundleJourney.test.ts
+```
+
+Layout references: Microsoft's [manifest writer](https://github.com/dotnet/runtime/blob/v8.0.22/src/installer/managed/Microsoft.NET.HostModel/Bundle/Manifest.cs),
+[file entry writer](https://github.com/dotnet/runtime/blob/v8.0.22/src/installer/managed/Microsoft.NET.HostModel/Bundle/FileEntry.cs),
+[apphost marker handling](https://github.com/dotnet/runtime/blob/v8.0.22/src/installer/managed/Microsoft.NET.HostModel/AppHost/HostWriter.cs),
+and [compression producer](https://github.com/dotnet/runtime/blob/v8.0.22/src/installer/managed/Microsoft.NET.HostModel/Bundle/Bundler.cs).
@@ -75,6 +75,13 @@ DOM node indices retain their snapshot positions. Invalid rows are omitted with
 completeness diagnostics, so `total_nodes` can exceed the retained node count
 and a parent index can refer to an omitted source node.

+`dom.node_value_length_unit` is `utf8-bytes`: each node's `node_value_length`
+counts the bytes needed to encode its value as UTF-8, not characters. Web
+observations instead declare `utf16-code-units`. These existing measurements
+are preserved; the unit is reported once for the whole DOM, without retaining
+text values. Historical captures without the unit leave it unknown; reading
+them does not infer a unit or convert their stored lengths.
+
 Script metadata retains its execution-context frame ID when CDP supplies one and
 records admission separately in `frame_scope`. An `authorized` scope refers to
 the observed document generation; `unknown` retains the known frame ID without
@@ -701,7 +701,7 @@
                "calculated_sha256",
                "unpacked"
              ],
-              "additionalProperties": false
+              "additionalProperties": {}
            },
            {
              "type": "object",
@@ -727,7 +727,33 @@
                "calculated_md5",
                "unpacked"
              ],
-              "additionalProperties": false
+              "additionalProperties": {}
+            },
+            {
+              "type": "object",
+              "properties": {
+                "logical_path": { "type": "string" },
+                "algorithm": { "type": "string", "const": "dfu-crc32" },
+                "declared_crc32": {
+                  "type": "string",
+                  "pattern": "^[a-f0-9]{8}$"
+                },
+                "calculated_crc32": {
+                  "anyOf": [
+                    { "type": "string", "pattern": "^[a-f0-9]{8}$" },
+                    { "type": "null" }
+                  ]
+                },
+                "unpacked": { "type": "boolean" }
+              },
+              "required": [
+                "logical_path",
+                "algorithm",
+                "declared_crc32",
+                "calculated_crc32",
+                "unpacked"
+              ],
+              "additionalProperties": {}
            }
          ]
        }
@@ -0,0 +1,348 @@
+# ESP flash images
+
+REA reads a dump of an ESP32-family SPI flash, such as the output of
+`esptool read-flash 0 ALL dump.bin` or `esptool merge-bin`, through
+`inspect_artifact` and `extract_artifact`. The reader is static: no device,
+esptool or ESP-IDF is needed, and no code is run.
+
+The container format is `esp-flash-image`. Entries are the bootloader region,
+the partition table sector and one file per partition. The bootloader and
+each app partition are also decoded as [ESP images](esp-image.md), so their
+headers, segments, integrity and descriptors appear in the root
+`format_metadata`. Layout facts are cited to ESP-IDF v6.1
+(`esp_flash_partitions.h`, `flash_partitions.c`, `gen_esp32part.py`,
+`bootloader_common_loader.c`, `bootloader_utility.c` and each chip's
+`esp_rom_caps.h`).
+
+## Recognition
+
+A file is a flash image when REA finds a partition table in the entry
+structure ESP-IDF's bootloader verifies (`esp_partition_table_verify`):
+32-byte `0x50AA` entries, at most one `0xEBEB` MD5 entry over the entries
+before it, and a terminating entry within `0xC00` bytes. ESP-IDF accepts a
+table with no partition entries, but REA requires one, so that neither
+erased flash nor a lone MD5 entry is read as a table. A table whose MD5 does not match, or that has a second MD5 entry, is
+still read, with `md5.status` `invalid` and a limitation, because the
+bootloader would refuse it. The table is located in this order:
+
+1. at the caller's `partition_table_offset`, when given; no scan follows;
+2. at the default `0x8000`;
+3. by scanning every `0x1000`-aligned flash sector for a table whose MD5
+   verifies. This location is derived, and the inventory says so.
+
+A table never lies inside the located bootloader image, so the default
+offset and the scan are tried only after the image's last segment. Without
+a caller selection, the scan runs only when an ESP image sits at a ROM
+bootloader offset, and a single app or bootloader image ends at its last
+segment, so neither ordinary files nor single images are scanned. A C3 or
+S3 dump begins with its bootloader, so flash layouts are detected before a
+file is read as one ESP image.
+
+Unless the caller names the table with `partition_table_offset`, REA
+refuses two kinds of dump before looking for a table:
+
+- an image of a known chip at another chip's ROM offset, such as an ESP32
+  bootloader at the start of a dump read from `0x1000`. The dump's origin
+  is not the flash address REA assumed, given or default, and a table found
+  there would place every partition at the wrong file offset; pass the
+  `flash_offset` where the dump starts. When a partition table sits where
+  the image's own ROM offset puts `0x8000`, after the image's segments, the
+  refusal names that offset.
+  Without a selected format such a dump opens as its bootloader image, whose
+  [ESP image](esp-image.md) facts say how to reopen it.
+- an ESP8266 image at a ROM offset. ESP8266 dumps can hold the same table
+  format, and they keep the [ESP image](esp-image.md) reader's ESP8266
+  refusal.
+
+When no table is found the layout is not recognized. This is an unknown
+outcome, not a malformed file: flash encryption, which encrypts the
+bootloader and the table, is one cause. When a table is found without a
+located bootloader and `flash_offset` is omitted, a limitation says that
+each partition's file offset assumes the dump starts at flash `0x0`.
+
+## Caller inputs
+
+| Input                     | Meaning                                                                       |
+| ------------------------- | ----------------------------------------------------------------------------- |
+| `format: esp-flash-image` | Read the file as a flash dump; with no table found, refuse it                 |
+| `flash_offset`            | Flash address (`0x…`) of the dump's first byte; default 0                     |
+| `partition_table_offset`  | Flash address (`0x…`, a multiple of `0x1000`) of the table; disables the scan |
+
+MCP takes these on `open_binary`; the CLI takes `--target-format
+esp-flash-image`, `--flash-offset` and `--partition-table-offset` on
+`inspect-artifact` and `extract-artifact`. The offsets require the format, and
+the format takes no `architecture` or `entry_point`. The inputs are part of
+the target's identity, so reopening the same bytes with other inputs reads
+them again instead of reusing the earlier reading. The `open_binary` summary
+reports them as `flash_offset` and `partition_table_offset`, null when
+omitted.
+
+## Layout facts
+
+The root `format_metadata` (`esp-flash-image`) records:
+
+- `flash_offset`: its `value` and whether the `caller` gave it or it is the
+  `default`;
+- `chip`: from the bootloader's `chip_id`, or null without a located
+  bootloader;
+- `bootloader`: the region from the chip's ROM bootloader offset to the
+  table, with its ESP image facts;
+- `partition_table`: its flash address, the `method` that found it
+  (`default`, `caller` or `scan`), the partition count and the MD5 `status`
+  (`valid`, `invalid` or `absent`) with the stored and computed digests;
+- `apps`: ESP image facts for each app partition the dump holds; app
+  partitions declared over the same bytes share one decode;
+- `otadata`: the otadata partition's records, or null without one;
+- `boot_selection`: the app the bootloader would select, for every table;
+- `partitions_outside_dump`: declared partitions that begin before the
+  dump's first byte, which have no entry;
+- `undescribed`: ranges outside every region, each from a byte that is not
+  erased flash to the end of its gap.
+
+The ROM loads the bootloader from `ESP_ROM_BOOTLOADER_OFFSET_FLASH`:
+`0x1000` for ESP32 and ESP32-S2; `0x0` for ESP32-S3, C2, C3, C6, C61, H2 and
+H21; and `0x2000` for ESP32-C5, H4, P4 and S31. A bootloader is located only
+where its own `chip_id` says the ROM loads it.
+
+### Partitions
+
+Each partition entry is `partitions/<label>.bin` when the label is a safe
+name of up to 16 letters, digits, `.`, `_` and `-` that starts with a
+letter, digit or underscore and has at least one letter or underscore, is
+not a Windows device name such as `NUL` or `COM1`, alone or before a dot,
+and no other label repeats it, ignoring case as some file systems do; it is
+`partitions/<index>.bin` otherwise. `source_path` keeps the label, the
+table's own name for the partition. Its `format_metadata`
+(`esp-flash-partition`) records the table `index`, `label` (null when not
+UTF-8), `label_hex` (the label's bytes when it is not UTF-8, else null),
+`type`, `subtype`, ESP-IDF's `type_name` and `subtype_name`,
+`flash_address`, `size`, the `encrypted` and `readonly` flags and any
+`unknown_flags`. The `encrypted` flag says how a device with flash
+encryption stores the partition; it does not establish that the dump's
+bytes are ciphertext.
+
+Each partition entry also records where the bytes the dump holds are
+written, relative to the partition's start: `written_offset`, the first
+byte that is not erased flash (`0xFF`), `written_end`, just past the last
+such byte, and `written_bytes`, how many bytes are not `0xFF`. A partition
+erased throughout has null offsets and `written_bytes` `0`; a partition the
+file holds none of has all three null. The range bounds the written
+bytes and does not say whether erased flash lies between them; extract the
+partition to read them. REA reads the bytes the partitions cover once, so
+overlapping partitions share that read however many the table declares.
+
+ESP-IDF 5.3 and later may declare primary `bootloader` and `partition_table`
+entries over the bootloader region and the table sector. They are
+partitions like any other, whose bytes are also `bootloader.bin` and
+`partition-table.bin`, and they are exempt from the rule that partitions
+follow the table, as in `gen_esp32part.py`.
+
+Every partition from the dump's first byte on is an entry holding the bytes
+the file has. One that the file holds only in part, as when an `esptool
+merge-bin` dump ends inside its last partition, has an entry limitation that
+gives the size the table declares; one that lies past the end of the file is
+an entry with no bytes and a limitation, and has no image facts. A partition
+that begins before the dump's first byte has no entry and is listed in
+`partitions_outside_dump`. One unreadable partition does not hide the
+others: partitions outside the dump or overlapping another are each reported
+while the rest stay readable.
+
+### App partitions and the bootloader
+
+Each app partition and the bootloader region carry their entry's `path`
+and ESP image `facts`:
+`status` is `esp-image`, `erased` (the image header bytes are erased flash,
+as in an empty OTA slot) or `unrecognized` (ciphertext or other data). For an
+image they hold the [ESP image](esp-image.md) root facts, `segments`,
+`signature_blocks`, `coverage` and `limitations`, with offsets relative to
+the region. Extract a partition and inspect it as an ESP image for its
+segments as entries.
+
+The summary view (`inspect_artifact` with `detail: "summary"`, or the
+inventory summary of `inspect_analysis_view`) reports the root facts under
+their own kind, `esp-flash-image-summary`, and gives each of these images a
+`summary` instead of its `facts`: `status`, `chip`, `entry_addr`,
+`segment_count`, `load_ranges` (the load address, declared length and
+classification of each segment that is mapped, loaded or unclassified),
+`signature_block_count`, the `descriptor` kind with the fields that tell
+builds apart (an app's `project_name`, `version`, `idf_ver`,
+`secure_version` and `app_elf_sha256`; a bootloader's `version`, `idf_ver`
+and `secure_version`), the `checksum` and `appended_sha256` statuses,
+`coverage` and `limitations`. The default complete detail keeps the full
+facts, every segment included, and the summary's `inventory_evidence_ids`
+name the Evidence that holds them.
+
+`erased` is the bootloader's view: with no image header at the start of the
+slot, it finds no app there. An erased slot can still hold data further in,
+even a complete app image. When it does, its entry's `written_offset` and
+`written_end` say where, and a limitation says that the slot holds bytes the
+bootloader does not read; REA does not look for images in them.
+
+### OTA data
+
+The otadata partition holds two `esp_ota_select_entry_t` records, one at the
+start of each 4 KiB sector. Like the bootloader, REA reads the last otadata
+partition the table declares, and the last factory app and OTA app of each
+subtype; a limitation names any repeated declaration. REA reports each
+record the partition and the dump hold: its `ota_seq`, `seq_label`,
+`ota_state` and its name, `crc`, whether the CRC matches (CRC-32 of
+`ota_seq` seeded with `0xFFFFFFFF`) and whether the bootloader would treat
+it as valid.
+
+### Boot selection
+
+`boot_selection` is present for every table. It is derived as
+`bootloader_utility_get_selected_boot_partition` does without app rollback
+or anti-rollback, and `basis` names its branch:
+
+- `otadata`: the valid record with the higher `ota_seq` (record 0 on a tie)
+  selects slot `(ota_seq - 1) % ota_app_count`, indexed by OTA subtype;
+- `factory-fallback`: no record is usable, or the table has no OTA app, and
+  a factory app is declared; or records are set but none is valid, as after
+  a CRC mismatch, which selects the factory index whether or not a factory
+  app is declared;
+- `ota_0-fallback`: no record is usable, or the table has no OTA app, and no
+  factory app is declared, so the bootloader selects boot index 0;
+- `no-otadata`: the table declares no otadata partition, or one at offset 0,
+  which the bootloader takes for none, so it selects the factory index, as in
+  the common factory-only layout;
+- `none`: the bootloader rejects the table, for an MD5 mismatch or a second
+  MD5 entry, or cannot read an otadata partition smaller than two 4 KiB
+  sectors, and resets without selecting an app;
+- `unknown`: the dump lacks an otadata record the bootloader reads.
+
+Without an OTA app the records do not matter, so a dump that lacks them
+still selects a fallback. REA does not compare the partitions with the
+flash size in the bootloader header, which the bootloader also checks.
+
+`active_record` and `slot` are set for `otadata` and `slot` for
+`ota_0-fallback`. `partition_index` is null when the table declares no
+partition for the selected slot or fallback; the bootloader then tries the
+other apps. `assumptions` list what the derivation leaves out: records used
+as written (for the branches that read them), anti-rollback, load fallback,
+and factory-reset and test-app GPIO holds and a wake from deep sleep; they
+are empty for `none` and `unknown`. `running_partition` is always
+`unknown`: at boot the bootloader may first mark a pending-verify record
+aborted, check the app's secure version against eFuse, and fall back to
+another partition when an app fails to load.
+
+## Coverage and extraction
+
+Erased flash (`0xFF`) between regions is described. In a gap between
+regions, the first byte that is not erased starts an `undescribed` range to
+the end of the gap, and makes coverage `unknown`; the rest of that range is
+not examined. Coverage is also `unknown` when no bootloader is located, or
+when a declared partition begins before the dump's first byte, since it has
+no entry. A partition cut short or left out by the end of the file does not
+make it `unknown`: its entry holds the bytes the file has, none for one past
+the end, and its limitation says what the file lacks. Coverage describes the
+inventory of the file, not the observation of every declared flash byte.
+
+So artifact comparison classifies every partition entry of two dumps. Where
+both lack the same bytes, as two `merge-bin` dumps of the same layout do,
+the entries are equal; a dump against a longer one reports each partition
+it cuts short or lacks as `changed`, and that entry's limitation says the
+file did not hold the bytes.
+
+`extract_artifact` writes every entry as an ordinary file, `nvs_keys`
+partitions included. On a device without flash encryption an `nvs_keys`
+partition holds the NVS encryption keys in plain text, and a dump of it
+contains them. REA decrypts nothing, recovers no keys and does not interpret
+NVS.
+
+## Comparison
+
+Artifact comparison uses each partition's `label`, `label_hex`, `type`,
+`subtype`, `flash_address`, `size` and flags as its declaration, so a
+partition that moves, changes type or flags, or is renamed with unchanged
+bytes is `changed` in `metadata`. Partitions pair by path. The root facts
+are not compared as a declaration: they derive from the dump's bytes, which
+content comparison covers, and from the caller's `flash_offset` and
+`partition_table_offset`, which are part of the target's identity and
+decide each partition's byte range.
+
+## Limits
+
+- A flash dump inside another container, such as a ZIP, is classified from
+  its first bytes and so reads as an ESP image, not as a flash layout; extract
+  it first.
+- ESP8266 dumps are refused; Secure Boot v1 bootloader digests and
+  flash-encrypted layouts are not read.
+- Partitions are not checked against the flash chip size, which the
+  bootloader also verifies.
+- NVS, FAT, SPIFFS and other data partitions are extracted, not decoded.
+- An image nested in a partition is decoded for its facts; its segments are
+  not inventory entries.
+
+## Verification
+
+Synthetic fixtures with computed MD5s and CRCs, and one CRC otatool wrote,
+cover the table rules, every way the table is located, the scan's chunk and
+sector edges, the misplaced-origin guard with the origin omitted or given,
+the ESP8266 refusal, the `0x0`, `0x1000` and `0x2000` ROM bootloader
+offsets, single images that are not scanned, overlaps, primary entries,
+truncation and partitions outside the dump, index names for unsafe labels,
+repeated declarations, the otadata states and records, and each branch of
+the bootloader's selection. CLI and stdio MCP tests exercise the inputs and
+their identity and extraction. MCP `compare_artifacts` tests compare
+partition declarations, labels that are not UTF-8 included, two dumps that
+end inside their last partition, and such a dump against a full one.
+
+The optional real lane builds its dumps with esptool and ESP-IDF's own tools:
+
+```sh
+REA_RISCV_CLANG=/path/to/clang REA_RISCV_LLD=/path/to/ld.lld \
+REA_ESPTOOL_PYTHON=/path/to/python-with-esptool \
+REA_ESP_IDF_PATH=/path/to/esp-idf \
+  npm run verify:esp-flash
+```
+
+It converts the conformance ELFs with esptool, builds a default, a
+relocated and a primary-entry partition table with `gen_esp32part.py`,
+assembles dumps with `esptool merge-bin`, one of them written from flash
+`0x1000` with `--target-offset`, and writes OTA records with `otatool`
+through `tests/conformance/esp/flash_file_tool.py`. That script replaces
+parttool's esptool calls with reads and writes of the dump file, so
+otatool's own OTA logic runs unchanged. The lane then checks:
+
+- the bootloader and app facts against `esptool image-info`;
+- every partition against `gen_esp32part.py`'s decoding of the table REA
+  extracted;
+- both OTA records against `otatool read_otadata` after switching to slot 0,
+  then to slot 1, then erasing the otadata, and the derived selection after
+  each: slot 0, slot 1, then the factory fallback;
+- that each extracted file is the dump's bytes at its range and that the
+  source is unchanged;
+- a table with the primary `bootloader` and `partition_table` entries that
+  `--primary-bootloader-offset` fills, read with complete coverage and no
+  overlap or misplacement limitation; it has no otadata, so its boot
+  selection is `no-otadata` with the factory app;
+- the relocated table, found by scanning and named with
+  `partition_table_offset`, and the dump written from `0x1000`, read with
+  `flash_offset` and, without it, left an ESP image whose `flash_dump`
+  names `flash_offset` `0x1000`;
+- an app with a flipped byte beside valid partitions, and a truncated dump,
+  read with complete coverage and its missing partitions as entries with no
+  bytes.
+
+The lane ran on macOS arm64 with Node 24.22.1, Homebrew Clang and LLD 21.1.8
+and ESP-IDF v5.5.2's `gen_esp32part.py`, `otatool.py` and `parttool.py`,
+once with esptool v5.6.0 and once with 4.12.0. Its `gen_esp32part.py` is
+identical to v6.1's, and its otatool and parttool differ only in import style
+and esptool command spelling. All checks passed in both runs. With v5.6.0 and
+the build already cached, the run took 24.1 s elapsed, 16.9 s user CPU and
+6.3 s system CPU under `/usr/bin/time -l`; the largest single process peaked
+at a 278 MiB resident set, and the combined peak of all processes was not
+measured.
+
+The lane does not establish:
+
+- dumps read from a device: its dumps come from `merge-bin`;
+- chips other than ESP32-C3 and ESP32;
+- `ota_state` and record validity, which `read_otadata` does not print, or
+  OTA states the bootloader writes itself, app rollback or anti-rollback;
+- selection with gaps or repeated OTA subtypes, which otatool does not
+  write;
+- flash-encrypted dumps, which are not recognized by design.
+
+It does not run in CI.
@@ -0,0 +1,333 @@
+# ESP images
+
+REA reads ESP32-family firmware images through `inspect-artifact` /
+`inspect_artifact` and `extract-artifact` / `extract_artifact`. OTA downloads,
+app partitions and second-stage bootloaders are all ESP images. Reading is
+static: no esptool, device or flash access is needed, and no code is run or
+disassembled.
+
+```sh
+rea inspect-artifact ./firmware.bin --json
+rea inspect-artifact ./ota.bin --detail summary --evidence_output evidence.json --json
+rea extract-artifact ./firmware.bin --json
+```
+
+For MCP, open the file with `open_binary`, then call `inspect_artifact`. The
+summary's `root_format_metadata` holds the image facts. Use its
+`parent_evidence_id` with `inspect_analysis_view` to select segment rows.
+`extract_artifact` writes one file per segment and per signature block.
+
+For agent sessions, advertise the `session,artifact,application` tool families
+and consider setting both `REA_MCP_INPUT_SCHEMA_PROFILE` and
+`REA_MCP_OUTPUT_SCHEMA_PROFILE` to `compact`. The output profile bounds each
+advertised output schema to 4,096 bytes by relaxing nested client validation;
+REA still validates complete results against the canonical contracts. Pair
+this with retained summaries and selected inventory views to limit the context
+needed for one question. See [MCP contracts](mcp-contracts.md) for the profiles
+and their client compatibility tradeoffs.
+
+The layout facts follow ESP-IDF v6.1 (`esp_app_format.h`, `esp_app_desc.h`,
+`esp_bootloader_desc.h`, `esp_image_format.c`, the ROM `secure_boot.h`
+headers and `docs/en/security/secure-boot-v2.rst`) and esptool v5.6.0
+(`bin_image.py`, `cmds.py`, `loader.py`, espsecure).
+
+## Recognition
+
+The container format is `esp-image`. A file is an ESP image when its bytes
+show all of these; the file name does not matter:
+
+- magic `0xE9` at offset 0 and 1 to 16 segments. A count of 0 is valid but
+  loads nothing, and accepting it would admit x86 programs that begin
+  `E9 00`;
+- a flash mode and flash speed code that ESP-IDF's enums define;
+- a `hash_appended` byte of 0 or 1, as esptool requires;
+- when the file holds the first segment header, a segment length that is a
+  multiple of 4.
+
+Later segments, the checksum and the digest are integrity facts. A truncated
+download is still an ESP image, with its integrity reported as unavailable.
+
+| Input                                               | Outcome                                                          |
+| --------------------------------------------------- | ---------------------------------------------------------------- |
+| ESP8266 image (v1 or v3): same magic, 8-byte header | Refused: "ESP8266 firmware images are not supported…"            |
+| Flash-encrypted image (ciphertext)                  | Not recognized: the bytes carry no magic. Unknown, not malformed |
+| ESP8266 v2 image (magic `0xEA`)                     | Not recognized                                                   |
+
+An ESP8266 image has its first segment header at offset 8, and that segment
+loads into ESP8266 DRAM, IRAM (Arduino's eboot links at `0x4010F000`) or the
+IROM flash window, where v3 and Arduino app images begin. In an ESP32-family
+header the same bytes hold `wp_pin` and the drive settings, which esptool and
+ESP-IDF write as `0xEE` and zeros. Inside another container, an ESP8266 image
+is classified as a plain file.
+
+Recognition cannot exclude every file that starts with an x86 near jump
+(`0xE9`), such as a DOS `.com` program. An explicit `--target-format dos-com`
+or `raw-binary` selection skips ESP recognition.
+
+## Image facts
+
+Root `format_metadata` has `kind: "esp-image"`:
+
+| Field                     | Label    | Meaning                                                                                                          |
+| ------------------------- | -------- | ---------------------------------------------------------------------------------------------------------------- |
+| `header`                  | observed | Every `esp_image_header_t` field, with ESP-IDF's names, for example `entry_addr`, `chip_id`, `min_chip_rev_full` |
+| `chip`                    | derived  | `target`, `isa` and the table's `source` (`ESP-IDF v6.1`) from `chip_id`; `null` for an ID the table lacks       |
+| `checksum`                | derived  | `offset`, `stored`, `computed` and `status`: `valid`, `invalid` or `unavailable`                                 |
+| `appended_sha256`         | derived  | The digest `hash_appended` adds: `offset`, `stored`, `computed` and `status`, including `not-appended`           |
+| `image_end`               | derived  | End of the checksum block and any appended digest; `null` when the file ends before it                           |
+| `signature_sector_offset` | derived  | The Secure Boot v2 signature sector, when it holds at least one valid block                                      |
+| `undescribed_trailing`    | derived  | Byte ranges after the image that nothing describes; empty when every byte is described                           |
+| `descriptor`              | observed | `esp_app_desc_t` or `esp_bootloader_desc_t` fields, with ESP-IDF's names, and the descriptor's file `offset`     |
+
+The descriptor's `kind`, derived from its magic, classifies the image as an
+`app` or a `bootloader`. Without a descriptor the role is unknown.
+
+The ISA comes from `chip_id`, never from the series letter: ESP32-S31 is
+RISC-V. The chip table covers every `esp_chip_id_t` in ESP-IDF v6.1:
+
+| `chip_id` | Target    | ISA    | `chip_id` | Target     | ISA   |
+| --------- | --------- | ------ | --------- | ---------- | ----- |
+| `0x0000`  | `esp32`   | xtensa | `0x0012`  | `esp32p4`  | riscv |
+| `0x0002`  | `esp32s2` | xtensa | `0x0014`  | `esp32c61` | riscv |
+| `0x0005`  | `esp32c3` | riscv  | `0x0017`  | `esp32c5`  | riscv |
+| `0x0009`  | `esp32s3` | xtensa | `0x0019`  | `esp32h21` | riscv |
+| `0x000C`  | `esp32c2` | riscv  | `0x001C`  | `esp32h4`  | riscv |
+| `0x000D`  | `esp32c6` | riscv  | `0x0020`  | `esp32s31` | riscv |
+| `0x0010`  | `esp32h2` | riscv  |           |            |       |
+
+Other IDs, for example esptool v5.6.0's ESP32-E22 (`0x1F`), have `chip: null`
+and unclassified segments.
+
+**Integrity.** The checksum is the XOR of every segment data byte, seeded with
+`0xEF`, in the last byte of the next 16-byte block. The appended SHA-256 covers
+every byte through the checksum. Both are facts, not admission rules: a
+mismatch is reported with a limitation and the segments stay readable.
+
+**Descriptors.** Both descriptors begin segment 0: ESP-IDF's bootloader reads
+the app descriptor there, and esptool places the bootloader descriptor there.
+Strings stop at the first NUL and are omitted, with a limitation, when they
+are not valid UTF-8. The bootloader descriptor's magic is a single byte
+(`0x50`), so its reserved bytes, which ESP-IDF zero-fills, must also be zero.
+A `--ram-only-header` image puts RAM segments first, so its app descriptor is
+not in segment 0 and its role is unknown. `mmu_page_size` keeps ESP-IDF's
+name and value: the MMU page size as a base-2 logarithm, as
+`esp_app_desc_t` declares it, so `16` means 64 KiB. It is `0` in images built
+before ESP-IDF v5.4. `spi_flash_mode` is the next byte, which ESP-IDF v6.1
+names, kept as stored and not interpreted; releases that reserve it leave it
+`0`. A file can end inside the app descriptor: every field it holds in full
+is kept, a field it cuts off is `null`, and `observed_length` gives the
+descriptor bytes the file holds. The segment's truncation is reported as usual.
+
+## Segments
+
+Each header-declared segment is one entry named `segment-<index>.bin`, for
+example `segment-00.bin`, so two builds pair segments by position. Its
+`source_location` is the segment data in the image file. `format_metadata`
+(`esp-image-segment`) records `index`, `load_addr`, `data_len`,
+`header_offset` and `classification`.
+
+`classification` follows ESP-IDF's bootloader (`should_map` and
+`should_load` in `esp_image_format.c`) on a cold boot:
+
+| Value        | Meaning                                                                                           |
+| ------------ | ------------------------------------------------------------------------------------------------- |
+| `mapped`     | Inside the chip's IROM, DROM or, where the MMU is per memory type, PSRAM range (`soc.h`)          |
+| `loaded`     | `should_load` selects it: not mapped, at or above `0x10000000`. RAM ranges are not checked        |
+| `not-loaded` | Below `0x10000000`: the padding segments esptool writes at address 0, including `--secure-pad-v2` |
+| `unknown`    | The chip is unknown, or the mapping depends on the bootloader's MMU page size                     |
+
+`loaded` does not mean the bootloader accepts the segment. Before loading,
+ESP-IDF's `verify_load_addresses` rejects the image when a loaded segment is
+not entirely in the chip's DRAM, IRAM, RTC memory or SPM, or overlaps the
+bootloader's own stack, data or loader code. For example, an ESP32-C6
+segment at `0x43000000` is `loaded` here and rejected there. REA models no
+RAM ranges.
+
+Padding segments are inventoried and extractable, but are never load regions.
+When waking from deep sleep, ESP-IDF also skips RTC-memory segments; that
+runtime case is not modelled. ESP32-C6 and ESP32-H2 map flash from
+`0x42000000` through 256 pages of the bootloader's configured MMU page size,
+which no image records. The app descriptor's page size describes the app's
+build, not the bootloader's. With page sizes from 8 KiB (which the hardware
+supports and esptool builds for) to 64 KiB, segments from `0x42200000` to
+`0x43000000` are `unknown`. Ranges follow ESP-IDF's `should_map`, not esptool's
+wider placement ranges.
+
+A segment cut short by the end of the file is the bytes the file holds, with
+an entry limitation that gives the declared length.
+
+Artifact comparison uses each segment's `load_addr` and `data_len` as its
+declaration, so a segment that moves with unchanged bytes is `changed` in
+`metadata`. Segments pair by index: inserting or removing one shifts the
+paths of the segments after it. Header offsets and `classification` are not
+compared; the image's own change covers the header and chip. The image's and
+the signature blocks' `format_metadata` carry no declaration: their fields
+come from their own bytes, which content comparison covers, and a block's
+`image_digest_matches` follows the image's content.
+
+## Secure Boot v2 signatures
+
+A signature sector starts at the next 4 KiB boundary after the image and
+holds up to three 1216-byte slots. A slot holds a block when it has the `0xE7`
+magic and a matching CRC32 at offset 1196, the rule ESP-IDF and espsecure
+apply. Each slot is examined independently, so an erased or damaged slot does
+not hide a later block. Each block is an entry, `signature-block-<slot>.bin`,
+with `esp-image-signature-block` metadata:
+
+| Field                              | Meaning                                                                   |
+| ---------------------------------- | ------------------------------------------------------------------------- |
+| `index`, `version`, `scheme`       | Slot 0 to 2, version byte, and `rsa` (`0x02`) or `ecdsa` (`0x03`)         |
+| `sha_version`, `curve_id`          | For ECDSA, the third byte (0 is SHA-256, 1 SHA-384) and the curve ID byte |
+| `digest_algorithm`, `image_digest` | The digest the block records                                              |
+| `image_digest_matches`             | Whether it equals the digest of every byte before the sector              |
+| `public_key_sha256`                | SHA-256 of the block's public key, the value eFuse key digests hold       |
+| `signature_status`                 | Always `unverified`                                                       |
+
+Signatures are observed, not verified: REA checks no public key, signature or
+eFuse. `public_key_sha256` is the digest espsecure `signature-info-v2`
+prints, so it can be compared with `espefuse summary`. An unknown version or
+`sha_version` leaves the layout-dependent fields `null`. A slot with the magic
+but no matching CRC32 is not a block: it is reported in a limitation, whether
+or not another slot holds a block, and its bytes are undescribed. Secure Boot
+v1 signatures are not decoded.
+
+## Coverage and limitations
+
+Bytes after the image are described when they are erased flash (`0xFF`) or a
+signature sector's blocks; erased slots and slack in that sector count as
+erased flash. Every other byte is in `undescribed_trailing`.
+
+| Situation                                                              | Outcome                                                                                                    |
+| ---------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
+| Segment data or a segment header beyond the end of the file            | Truncation limitation; checksum and SHA-256 `unavailable`; coverage `unknown`                              |
+| File ends before the checksum or the appended digest                   | That status is `unavailable`, with a limitation; coverage `unknown`, since a signature sector could follow |
+| Checksum or SHA-256 mismatch                                           | `invalid`, with a limitation; coverage is unchanged                                                        |
+| Erased flash after the image that runs past the three slots            | Described; no limitation                                                                                   |
+| Erased flash that ends before the three slots are complete             | Limitation; coverage `unknown`, since a signed image cut there would have lost its sector                  |
+| A signature sector the file cuts short                                 | Limitation; coverage `unknown`                                                                             |
+| Any other bytes after the image                                        | Ranges in `undescribed_trailing`, a limitation, and coverage `unknown`                                     |
+| Segment length that is not a multiple of 4                             | Limitation: ESP-IDF rejects such an image                                                                  |
+| Segment of 16 MiB or more, except on chips with 32-bit cache addresses | Limitation: ESP-IDF rejects such an image                                                                  |
+
+ESP32-S3, ESP32-P4, ESP32-C5, ESP32-C61, ESP32-H4 and ESP32-S31 map flash
+through 32-bit cache addresses (`SOC_SPI_MEM_SUPPORT_CACHE_32BIT_ADDR_MAP`), so
+ESP-IDF sets no 16 MiB segment limit for them. For an unknown chip the limit
+is not applied.
+
+Undescribed bytes include other flash contents such as an app partition's
+stale data, a Secure Boot v1 signature, and the flash segments that esptool
+`--ram-only-header` writes after the checksum without counting them. REA
+reports their ranges and does not guess their structure. In the padding, in a
+sector without a valid block, in the sector's slack and after the sector, the
+first byte that is not erased starts a range to the end of that region. A
+slot that is neither a block nor erased is reported whole. Adjacent ranges
+are merged.
+
+A whole-flash dump whose partition table REA finds is read as an
+[ESP flash image](esp-flash-image.md). Without one, a dump of a chip whose
+bootloader is at offset 0, such as ESP32-C3 or ESP32-S3, is recognized as that
+bootloader image, and the partition table, apps and data follow as
+undescribed bytes.
+
+A dump read from a later flash address, such as an ESP32 dump read from
+`0x1000` with `read-flash 0x1000 …` or `merge-bin --target-offset 0x1000`,
+opens as its bootloader image. REA says so when the file shows it: the image
+at file offset 0 is not an app, its chip's ROM loads the bootloader from a
+later address (`0x1000` for ESP32 and S2, `0x2000` for C5, H4, P4 and S31),
+and a partition table sits where that origin puts `0x8000` (file offset
+`0x7000` for `0x1000`), after the image ends. Then `flash_dump` records
+`flash_offset` and
+`table_file_offset`, a limitation says to reopen the file with
+`format: "esp-flash-image"` and that `flash_offset`, and `inspect_artifact`
+lists the same `open_binary` call as a next probe. `flash_dump` is null for
+every other image. Evidence that REA recorded before it reported the field
+omits it; REA still reads and compares such Evidence, and the omission says
+nothing about where the file was read from.
+
+## Limits
+
+An image has at most 16 segments and 3 signature blocks. Decoding reads each
+byte once and retains only fixed-size fields. It reads through erased flash to
+find the first byte that is not erased, and stops there. There is no
+file-size limit.
+
+## Analyzing a segment
+
+Inventory does not disassemble code or build a memory map. `open_binary`
+admits neither RISC-V nor Xtensa as a raw-binary architecture, so a segment
+cannot yet be opened as a raw image. Each segment's `source_location` and
+`load_addr` give the file offset and address to map it at by hand, for
+example with the Rizin tool's `om` command.
+
+## Verification
+
+Synthetic fixtures with computed checksums, digests and CRCs cover
+recognition, ESP8266 layouts, the ESP32, ESP32-C3, ESP32-C6 and ESP32-P4
+memory maps, truncation at each structure, integrity mismatches, erased and
+undescribed trailing bytes, signature slots including damaged and unknown
+layouts, and the refusals. CLI and stdio MCP tests exercise the same artifact
+provider and advertised schemas.
+
+The optional real lane builds ELF files from source, converts them with
+esptool and compares REA's facts with `esptool image-info`:
+
+```sh
+REA_RISCV_CLANG=/path/to/clang REA_RISCV_LLD=/path/to/ld.lld \
+REA_ESPTOOL_PYTHON=/path/to/python-with-esptool \
+  npm run verify:esp-images
+```
+
+It needs a Clang with the RISC-V target, `ld.lld` and a Python that can run
+`esptool` and `espsecure`. It checks each tool before building anything and
+names the variable to set when one is missing, and it warns when esptool is
+not v5.6.0, the version whose sources the layout facts cite. It builds an
+ESP32-C3 app, the same app with `--dont-append-digest`, `--secure-pad-v2`,
+`--ram-only-header` and `--pad-to-size`, a bootloader, and ESP8266 v1 and v3
+images. It then checks:
+
+- entry point, chip ID, each segment's length, address and header offset,
+  checksum, digest and descriptor fields against `image-info`;
+- each segment's classification in the app, its variants and the
+  bootloader, whose linker scripts fix every section's region, including the
+  `not-loaded` padding that `--secure-pad-v2` adds;
+- after signing with RSA-3072 and appending ECDSA P-256 and P-384 blocks,
+  each block's `public_key_sha256` against espsecure `signature-info-v2`,
+  and that its recorded digest matches;
+- extraction of the app and the signed image: each segment file equals the
+  bytes after esptool's segment header offset, each signature block equals
+  its slot in the sector espsecure appended, and the source's SHA-256 is
+  unchanged and equals the reported `root_sha256`;
+- the `--pad-to-size` erased tail is described; the `--ram-only-header`
+  flash segments are undescribed;
+- a flipped checksum, a flipped digest byte, a truncated segment (where
+  `image-info` stops with "End of file reading segment"), and both ESP8266
+  refusals.
+
+`REA_XTENSA_ESP32_GCC` adds an ESP32 (Xtensa) app built with Espressif's
+`xtensa-esp32-elf-gcc`. Without it the report marks that image as skipped.
+
+Each command runs as a process tree owned by the shared verifier command
+owner, so a timeout also stops the linker or assembler a compiler driver
+starts. The lane removes its workspace only after every tree has stopped and
+keeps it when that cleanup cannot be confirmed.
+
+The lane ran on macOS arm64 with Node 24.22.1, Homebrew Clang and LLD 21.1.8,
+and `xtensa-esp32-elf-gcc` 14.2.0 (crosstool-NG esp-14.2.0_20251107), once
+with esptool and espsecure v5.6.0 and once with 4.12.0. All checks passed for
+all 13 images in both runs. With v5.6.0 the complete run, including the builds
+and every esptool call, took 21.7 s elapsed, 16.9 s user CPU and 6.1 s system
+CPU under `/usr/bin/time -l` with warm caches. The largest single process
+peaked at a 253 MiB resident set; the combined peak of all processes was not
+measured.
+
+The lane does not establish:
+
+- the other chips: only ESP32-C3 (RISC-V) and ESP32 (Xtensa) images come
+  from a real producer; the other rows of the chip table are checked against
+  the ESP-IDF v6.1 headers by reading them;
+- images from a real ESP-IDF project build, an OTA download or a device's
+  flash, none of which it inspects;
+- that a signature is valid: it compares digests, and nothing verifies a
+  signature.
+
+It does not run in CI.
@@ -80,8 +80,10 @@ without bytecode text or duplicated raw stdout:
 }
 ```

-The result is distinct derived Evidence linked to its complete parent. Its
-`normalized_result.summary` preserves every producer-returned selector, decoded
+The result is distinct view Evidence linked to its complete parent. Like the
+parent, it has `confidence: inferred`; projection never strengthens inferred
+candidates. Its `normalized_result.summary` preserves every producer-returned
+selector, decoded
 byte offset, dispatch, argument/mutability string including null, carrier/decoded
 identities, original limitations and explicit unknowns. Payload `evidence_kind`
 remains `inferred`. It preserves stderr/truncation and records stdout text length.
@@ -82,6 +82,11 @@ Published file `relative_path` preserves producer spelling for lineage; `path`
 uses the writer's actual normalized filename. An extracted filename that cannot
 be represented losslessly as UTF-8 fails publication explicitly with its raw
 name bytes in hexadecimal instead of silently omitting the entry.
+Unpublished symlinks retain the extracted tree's target bytes in lowercase
+`link_target_hex`; `link_target` is null when those bytes are not valid UTF-8.
+Older retained Evidence may omit the hexadecimal field. Unblob may have rewritten
+the target before REA observed it, so these bytes are not necessarily those stored
+in the firmware image.

 ## CLI and MCP

@@ -286,6 +291,26 @@ REA_FIRMWARE_VERIFY_GHIDRA=1 npm run verify:firmware
 generated gzip/USTAR/ext4 with a Linux x64 ELF child; SquashFS, UBIFS, proprietary
 firmware, other hosts and architectures remain unverified.

+## Inspect ESP images
+
+Use `inspect-artifact` / `inspect_artifact` on an ESP32-family app or
+bootloader image, such as an OTA download or app partition, for its chip,
+classified segments, checksum and SHA-256 results, descriptor and Secure Boot
+v2 signature blocks. `extract-artifact` / `extract_artifact` writes one file
+per segment and signature block. Reading is portable and needs no external
+tool. See [ESP images](esp-image.md).
+
+## Inspect ESP flash dumps
+
+Use the same tools on a whole-flash dump, such as `esptool read-flash 0 ALL`
+output. The inventory reports the bootloader, the partition table and how it
+was found, each partition with its declared type, flags and digest, ESP image
+facts for the bootloader and each app partition, and the OTA records with a
+derived selection; the running partition stays unknown. Extraction writes
+each partition, `nvs_keys` included, as an ordinary file. For a dump that
+does not start at flash address 0, select `esp-flash-image` with
+`flash_offset`. See [ESP flash images](esp-flash-image.md).
+
 ## Inspect extracted devicetrees

 Use [`inspect_devicetree`](devicetree.md) / `rea inspect-devicetree` on an
@@ -308,9 +333,26 @@ portable and requires no external tool. See
 The root facts record the 64-byte header (architecture, OS, type, and
 compression as raw values and names, load and entry addresses, image name,
 and timestamp) with the header and data CRC32 verified; the stored payload
-is extractable as `payload.bin`, and multi-file images additionally expose
-each sub-image as `image-<n>.bin` from the stored size table. Declared
+is extractable as `payload.bin`, and multi-file and script images additionally
+expose each sub-image as `image-<n>.bin` from the stored size table. Declared
 addresses are facts from the header, not proven entry points, and compressed
 payloads stay as stored. Intel HEX/S-record and FIT images are separate
 readers and are not covered here. See [U-Boot legacy uImage](uimage.md) for
 component padding, preserved names, resource policies and verification scope.
+
+## Inspect UF2 and DfuSe images
+
+Use `inspect-artifact` / `inspect_artifact` on a UF2 file for each familyID's
+address regions and its block numbering, or on a DfuSe file for its targets,
+elements and DFU suffix, then `extract-artifact` / `extract_artifact` for one
+raw file per region or element. A DfuSe suffix CRC mismatch follows
+`integrity_policy`. Decoding is portable and requires no external tool. See
+[UF2 and DfuSe images](uf2-dfuse.md).
+
+## Inspect U-Boot FIT images
+
+Use `inspect-artifact` / `inspect_artifact` on a U-Boot FIT (`.itb`) for its
+images, declared load and entry addresses, configurations and verified hashes,
+then `extract-artifact` / `extract_artifact` for one raw file per image.
+Decoding is portable and requires no external tool. See
+[U-Boot FIT images](fit-images.md).
@@ -0,0 +1,172 @@
+# U-Boot FIT images
+
+REA inventories U-Boot Flattened Image Tree (FIT, `.itb`) files through
+`inspect-artifact` / `inspect_artifact`, and materializes the stored bytes of
+each image through `extract-artifact` / `extract_artifact`. Decoding is static
+and needs no external tool.
+
+```sh
+rea inspect-artifact ./boot.itb --json
+rea inspect-artifact ./boot.itb --detail summary --evidence_output evidence.json --json
+rea extract-artifact ./boot.itb --json
+```
+
+For MCP, open the file with `open_binary`, then call `inspect_artifact`. Summary
+delivery retains the complete Evidence; use `parent_evidence_id` with
+`inspect_analysis_view` to read selected images and fields. `extract_artifact`
+returns a fresh `output_root` containing one raw file per image. FIT summaries
+use the current projection identity; there is no pre-coverage FIT summary variant.
+
+## Recognition
+
+A FIT is a flattened devicetree (FDT v16 or v17) with a top-level `/images`
+node. Recognition walks the structure block within the first 4 KiB of the file
+only; the file name does not matter. A devicetree whose `/images` node begins
+after 4 KiB, a devicetree without `/images`, and any other FDT version stay on
+the plain devicetree route: `open_binary` refuses them and
+[`inspect_devicetree`](devicetree.md) still parses them. A U-Boot control DTB
+that contains `/images` is treated as a FIT. The container format is `fit`.
+
+Recognition is a probe. The complete devicetree parse decides, so a file whose
+prefix declares `/images` but whose structure is malformed fails as a
+malformed FIT rather than falling back to plain classification.
+
+## Images and metadata
+
+Each child of `/images` is one inventory entry named `images/<unit-name>.bin`,
+listed in devicetree order. Its bytes come from exactly one data source:
+
+| Source          | Stored bytes                                                                            |
+| --------------- | --------------------------------------------------------------------------------------- |
+| `data`          | The embedded property value                                                             |
+| `data-offset`   | `data-size` bytes at `data-offset` past the devicetree end, aligned to 4 (`mkimage -E`) |
+| `data-position` | `data-size` bytes at `data-position` from the start of the file (`mkimage -p`)          |
+
+`data-position` is read as U-Boot reads it: an offset from the start of the
+FIT, not a machine address.
+
+Image `format_metadata` (`fit-image`) records `index`, `name`, `description`,
+`type`, `arch`, `os`, `compression`, `load` and `entry`, the `data_source`,
+the raw `declared_offset` for external data, `image_data` (the shared-data
+link), `cipher_present`, `cipher_algo`, `hash_algorithms`, `hashes_verified`,
+`hashes_unverified`, `signature_count`, `signatures_unreadable` and
+`signature_algorithms`. Algorithm lists are arrays. Nullable declaration fields
+are absent unless named in `unreadable_fields`, which records parsing failures
+per field. Hash or signature warnings do not make unrelated declarations unknown.
+`load` and `entry` fold one or two 32-bit cells into a lowercase
+`0x…` value, as U-Boot does, independent of `#address-cells`.
+
+Root `format_metadata` (`fit`) records `fdt_version`, `fdt_totalsize`,
+`external_data_base` (the aligned devicetree end), the root `description`,
+`timestamp` (seconds since 1970) and `address_cells`, plus
+`default_configuration` and `configurations`. A missing description or
+timestamp is `null`.
+
+Image bytes are reported as stored. Compressed images are not decompressed and
+ciphered images are not decrypted: entries report `encrypted: false` and the
+cipher declaration in `cipher_present` and algorithm in `cipher_algo`. A missing
+or malformed algorithm stays `null`; it does not establish unciphered bytes.
+Embedded `image-data` links require byte-identical stored properties; external
+links require matching physical ranges.
+
+The extracted file holds the stored bytes. Direct-analysis suggestions require
+`compression: "none"` and `cipher_present: false`.
+
+## Hashes and signatures
+
+Hash subnodes are children whose name starts with `hash`. Inventory verifies
+`crc32` (4 bytes, big-endian), `md5`, `sha1`, `sha256`, `sha384` and `sha512`
+over the stored bytes, the same bytes mkimage hashed after any ciphering. All
+hashes of an image are computed in one streamed pass while the inventory is
+prepared, so a mismatch fails the whole inventory, naming the image, hash
+node, algorithm, and the declared and computed values. A supported algorithm
+whose value has the wrong length also fails.
+
+Other algorithms such as `crc16-ccitt`, `crc8` or `sm3_256`, a hash without a
+readable `algo`, and a hash without a `value` are not verified; each is
+counted in `hashes_unverified` and reported as an image limitation.
+
+Signature subnodes (names starting with `signature`) on images and
+configurations retain the total declaration count, readable algorithms and
+`signatures_unreadable`. Missing or malformed algorithms carry source limitations
+so unknown declarations remain distinguishable from absence. Signatures are never
+verified.
+
+## Configurations
+
+`/configurations` is optional. Each child records its `name`, `description`,
+and the image references `kernel`, `firmware`, `fdt` (base plus overlays),
+`ramdisk` and `loadables`, always as lists, plus its signature algorithms.
+`compatible`, `fpga`, `script`, `cmdline` and `load-only` are not reported. A
+reference to a name that is not an `/images` child, and a `default` that names
+no configuration, are reported as limitations and kept as declared. Each
+configuration carries `unresolved_reference_count`; dangling references share one
+configuration-level diagnostic while every original reference remains available.
+
+## Facts, limitations and failures
+
+| Situation                                                                                      | Outcome                              |
+| ---------------------------------------------------------------------------------------------- | ------------------------------------ |
+| Malformed devicetree, truncated header, `totalsize` past the end of the file                   | Fails as malformed                   |
+| No data source, more than one data source, external data without `data-size`                   | Fails as malformed                   |
+| `data-offset`, `data-position` or `data-size` not one 32-bit cell, `image-data` not one string | Fails as malformed                   |
+| External data outside the file, overlapping the devicetree or another image                    | Fails as malformed                   |
+| Two images with an identical external range linked by `image-data`                             | Accepted as shared data              |
+| A dangling, chained or mismatched `image-data` link                                            | Fails as malformed                   |
+| Hash mismatch, or a supported hash value with the wrong length                                 | Fails integrity                      |
+| Unsupported, algorithm-less or value-less hashes                                               | Unverified, reported as a limitation |
+| Malformed `description`, `type`, `arch`, `os`, `compression`, `load`, `entry` or `timestamp`   | `null`, reported as a limitation     |
+| Dangling configuration reference, missing default configuration                                | Reported as a limitation             |
+
+Failures apply to the whole file and return no partial inventory.
+
+## Limits
+
+The devicetree, including any embedded image data, must be at most 16 MiB; a
+larger `totalsize` fails as a memory limit. Store large images externally
+(`mkimage -E`): external data of any size is streamed from the file and never
+loaded into memory. A FIT may declare at most 1,024 images and 1,024
+configurations, and an image at most 8 hash nodes; the devicetree parser's
+node, property and depth bounds also apply. The sum of declared image sizes
+is bounded by the shared archive expansion budget. These are fixed resource
+bounds with no runtime override. Configurable ceilings are tracked in
+[#6176](https://github.com/morluto/rea/issues/6176).
+
+## Analyzing an image
+
+Inventory does not execute anything, and `load` and `entry` are declarations.
+After extraction:
+
+- inspect `flat_dt` images with [`inspect_devicetree`](devicetree.md);
+- open an uncompressed image with `open_binary` using format `raw-binary`, an
+  architecture matching its declared `arch`, and `entry_point` set to its
+  declared `load` address; raw-binary maps file offset 0 and seeds analysis at
+  `entry_point`. Automatic suggestions require nonempty bytes, an admitted
+  architecture/address/extent, and a declared entry that is absent or equal to
+  load. Distinct or unreadable entry declarations remain in Evidence without
+  a raw-loader suggestion, since this loader cannot represent separate mapping
+  and analysis entry addresses.
+
+## Comparison
+
+Artifact comparison reports changes to an image's payload interpretation,
+including load and entry declarations. Equivalent external offset forms and
+inventory positions leave those declarations unchanged. Unavailable
+interpretations remain unknown, while independently known changes survive.
+
+## Verification
+
+Synthetic fixtures with computed hashes cover embedded, `data-offset` and
+`data-position` layouts, shared data, overlap and bounds failures, every
+verified hash algorithm, configurations, resource limits, inventory,
+extraction and reader lifecycle. CLI and stdio MCP tests exercise the same
+artifact provider and advertised schemas. Real U-Boot `mkimage` 2023.01 output
+has also been verified for embedded, `-E -B 0x200`, and
+`-E -p 0x2000 -B 0x200` layouts, with byte-exact extraction checked against
+`dumpimage`. The OpenWrt 24.10.3 ABT ASR3000 recovery FIT was checked against
+`mkimage`, `fdtget` and `dumpimage`, including its kernel, initrd and devicetree.
+No image was executed.
+
+For small containers, complete delivery avoids an additional view request.
+Choose summary and selected views when the omitted facts justify that extra
+request; summary delivery does not reduce the underlying inventory work.
@@ -119,7 +119,7 @@ installation's language catalog, the same catalog REA uses to admit
 and still succeeds on the stock checks.

 The ELF lane (`npm run verify:ghidra:ppc`) is separate. See
-[PowerPC ELF analysis through Ghidra](/ghidra-ppc).
+[PowerPC ELF analysis through Ghidra](ghidra-ppc.md).

 ## Not supported yet

@@ -39,9 +39,9 @@ bridge-reported `language_id` after import. A caller-selected
 pin; combining the pinned profile with an environment override is a typed
 refusal. A header that declares an ABI field but carries no record is still
 refused. Two further boundaries apply: an inspection that could not examine
-every ABI declaration source (for example a carved ELF whose section table
-extends past the captured bytes without a program-header record) does not
-establish the recordless admission, and an `EF_MIPS_ARCH_1` or
+every ABI declaration source does not establish the recordless admission
+(target opening already refuses a carved ELF whose section table extends past
+the captured bytes, as described below), and an `EF_MIPS_ARCH_1` or
 `EF_MIPS_ARCH_32` header that _declares_ an ABI is refused rather than
 relabeled, because the declared-ABI lane is verified for
 `EF_MIPS_ARCH_32R2` headers only. The recordless MIPS-I lane pins the same
@@ -77,13 +77,16 @@ argument ABI and unknown nonzero MSA values remain unsupported. Without a
 separate ABI flags record, FP attribute values are admitted only when absent,
 `ANY` (0), double precision (1), or FPXX (5), the values covered by the
 recordless profile. Parsed values are retained in the MIPS analysis profile.
-For carved ELFs whose section table extends
-beyond the captured file, REA examines every complete captured section header
-and records the unavailable headers as a limitation. The provider refuses an
-incomplete ABI declaration inspection even when a program-header ABI record is
-valid, because an unavailable section header could carry an unsupported or
-conflicting declaration. A missing program-header record does not make ABI
-declarations in uncaptured sections absent or supply a default ABI.
+A carved ELF whose section header table extends beyond the captured file is
+refused when the target is opened, before provider selection, as is every ELF
+declaration beyond EOF ([installation](installation.md#ghidra)). The refusal
+names the declared range and the file size. It applies even when a
+program-header ABI record was captured: an uncaptured section header could
+carry an unsupported or conflicting declaration, so the captured bytes are not
+analyzed as a complete smaller program. The provider also refuses any ABI
+declaration inspection that reports unexamined headers. A missing
+program-header record does not make ABI declarations in uncaptured sections
+absent or supply a default ABI.
 The field layout follows
 [`Elf_MIPS_ABIFlags_v0`](https://github.com/bminor/glibc/blob/master/elf/elf.h).

@@ -257,11 +260,13 @@ observations and does not relabel the upstream result as verified.

 CLI/MCP discovery and decompilation, direct calls, target/profile/Evidence
 identity, snapshot round-trip and final process cleanup remain covered.
-For both byte orders, the lane also carves away the section table while retaining
-all program-header payloads. It checks the actual Ghidra language, entry-address
-decompilation, distinct artifact digest and missing-section limitations through
-CLI Evidence and an MCP-produced snapshot. Caller-selected Ghidra heap limits
-are passed to these child workflows.
+For both byte orders, the lane also cuts the image one byte before its section
+header table, after checking that every program header and payload stays
+captured. `open_binary` and the CLI must both refuse that copy before provider
+selection as `target_unavailable` with constraint `file_format_rejected`,
+naming the declared section-table range and the captured size, and leave it
+unchanged. Caller-selected Ghidra heap limits are passed to the lane's CLI and
+MCP child workflows.
 For soft-float fixtures the lane also checks, through `inspect_native_api`, the
 exact parameter and return types and storage of float, double, mixed (pair
 alignment and stack spill) and struct-returning functions; that a caller's
@@ -31,7 +31,8 @@ operation-scoped JVM `OutOfMemoryError` observations retain their separate resou
 classification. Automatic kernel or cgroup OOM attribution is not implemented.

 After the authenticated startup handshake, rejected inputs (`invalid_request`,
-`not_found`, `ambiguous`, or an invalid function name) use
+`not_found`, `ambiguous`, an invalid function name, or an address without one
+exact file offset) use
 `diagnostics.diagnostic_scope: "request"` when their active output checkpoint is
 available. They preserve the active request's
 `failure_output`, target/profile identity and runtime/log coordinates, while
@@ -244,6 +245,7 @@ profile stages before retrying their retained descriptors.
 | CFG                     | Dossiers use `BasicBlockModel` and retain only non-call successors inside the function body. CFG topology is address-normalized for comparison; provider-specific block construction remains a declared difference.                                                                                                                                                                                                                                                                                                                                                                                                        |
 | P-code value flow       | Function dossiers include up to 3,000 high-p-code operations, at most 64 inputs per operation, and 12,000 def-use edges. Results identify memory reads/writes, branches, and calls by p-code opcode, and mark decompiler-dead operations. Large results report truncation, an omitted-operation lower bound, and known omitted-input/edge counts. The dossier is an intra-function graph; `trace_native_values` composes derived parameter/argument and return/output dependencies across resolved calls. It does not resolve memory aliasing, call side effects, runtime behavior, persistent state, or business meaning. |
 | Result extent           | Function instruction scans and native API boundary observations remain complete. P-code flow is the explicit bounded exception; its count fields distinguish exact retained counts from lower-bound or known-omitted counts. Caller cancellation and provider failures remain distinct.                                                                                                                                                                                                                                                                                                                                    |
+| Parameter lists         | `native_api.parameter_list.basis` is `signature` when Ghidra fixes HighFunction inputs from a non-default signature: an empty one as a void-input lock, or every valid parameter type-locked. Otherwise it is `recovered` and the decompiler may have omitted parameters. `variadic` is the HighFunction prototype's varargs flag. `signature_source` names the signature's origin, which may be analysis or an import; a signature basis is not source-level proof. Ghidra snapshots recorded without this fact are not replayed.                                                                                         |

 Runtime updates apply to newly accepted operations on the existing Program.
 They preserve accepted budgets and do not clear cleanup blockers or change the
@@ -299,7 +301,7 @@ host/provider acceptance run with only the host compiler.
 `--dll`. These static fixtures contain source-owned encoded instructions; they
 are not compiler-produced programs. See the [Windows verification scope](windows-ghidra-p0.md#native-authority-and-target-identity)
 for real-provider coverage and exclusions.
-These lanes check all 26 read-only operations, target/snapshot/import SHA-256 linkage,
+These lanes check all 27 read-only operations, target/snapshot/import SHA-256 linkage,
 and project, endpoint, process, and runtime cleanup. The independent native
 lane checks DACLs, handle admission, cancellation, and Job Object lifecycle.
 `npm run verify:ghidra:windows:package` packs and installs REA into an isolated
@@ -85,9 +85,9 @@ node scripts/verify-real-ghidra-mips.mjs --psp-missing-extension
 npm run verify:ghidra:mips
 ```

-The generic verifier also exercises a section-truncated firmware fixture. That
-check uses generic MIPS symbols and language expectations and runs only in generic
-mode; the PSP report explicitly records carved-PSP coverage as not run.
+The generic verifier also checks that a section-truncated firmware copy is
+refused when the target is opened. That check runs only in generic mode; the
+PSP report explicitly records carved-PSP coverage as not run.

 The maintained PSP fixture builds from `tests/conformance/psp/`, never executes,
 and is independent of commercial game data. PSP GNU tools supply ELF/ABI,
@@ -9,29 +9,43 @@ lane shape as [generic MIPS support](ghidra-mips.md).

 ELF `EM_RISCV` (243) is retained as the provider-neutral `riscv` family. The
 target also retains the raw ELF declarations that decide a lane: class, byte
-order, `e_type`, and `e_flags`. Recognition does not mean every provider or
-RISC-V variant is supported. Existing PE, managed and Mach-O architecture sets
-are unchanged. Headerless inputs use the separate [raw-binary admission
+order, `e_type`, `e_flags`, and the ISA string that `.riscv.attributes`
+declares. Recognition does not mean every provider or RISC-V variant is
+supported. Existing PE, managed and Mach-O architecture sets are unchanged.
+Headerless inputs use the separate [raw-binary admission
 boundary](raw-binary.md); raw RISC-V images are not supported.

-The Ghidra lane admits little-endian ELF32 and ELF64 `ET_EXEC` images that
-declare `EF_RISCV_FLOAT_ABI_DOUBLE` in `e_flags`, with no `EF_RISCV_RVE`,
-`EF_RISCV_TSO`, or any bit outside `EF_RISCV_RVC | EF_RISCV_FLOAT_ABI`. These are
-header declarations, not proof that every instruction conforms to that ISA.
+The Ghidra lane admits little-endian `ET_EXEC` images with no `EF_RISCV_RVE`,
+`EF_RISCV_TSO`, or any bit outside `EF_RISCV_RVC | EF_RISCV_FLOAT_ABI`, in one
+of three lanes:
+
+- ELF64 or ELF32 images that declare `EF_RISCV_FLOAT_ABI_DOUBLE` use Ghidra's
+  stock double-float model unchanged. Their `.riscv.attributes` is not read for
+  admission.
+- ELF32 images that declare the soft-float ABI (`e_flags` float-ABI bits `0`,
+  ilp32) use REA's [ilp32 calling-convention policy](#ilp32). They must also
+  declare an RV32I base and only [decoded extensions](#isa-declarations) in
+  `Tag_RISCV_arch`.
+
+These are header declarations, not proof that every instruction conforms to
+that ISA.

 Provider selection returns the specific unsupported constraint rather than
 guessing a compatible profile:

-| Declaration                                     | Outcome                                                                                  |
-| ----------------------------------------------- | ---------------------------------------------------------------------------------------- |
-| Little-endian ELF64 `ET_EXEC`, double-float ABI | admitted, `RISCV:LE:64:default` + `gcc`                                                  |
-| Little-endian ELF32 `ET_EXEC`, double-float ABI | admitted, `RISCV:LE:32:default` + `gcc`                                                  |
-| Big-endian                                      | refused; Ghidra 12.1.4 ships no big-endian RISC-V language                               |
-| `ET_REL`, `ET_DYN`, other `e_type`              | refused with the declared value                                                          |
-| `EF_RISCV_RVE`                                  | refused; the embedded 16-register profile (x0–x15) needs its own processor specification |
-| `EF_RISCV_TSO`                                  | refused; the total-store-order memory model is unverified here                           |
-| Soft, single, or quad float ABI                 | refused; the pinned generic compiler specification models double-float                   |
-| Reserved or newer `e_flags` bits                | refused with the offending bits named                                                    |
+| Declaration                                                                | Outcome                                                                                                              |
+| -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
+| Little-endian ELF64 `ET_EXEC`, double-float ABI                            | admitted, `RISCV:LE:64:default` + `gcc`, lane `elf64-exec-le-double-float-generic-v1`                                |
+| Little-endian ELF32 `ET_EXEC`, double-float ABI                            | admitted, `RISCV:LE:32:default` + `gcc`, lane `elf32-exec-le-double-float-generic-v1`                                |
+| Little-endian ELF32 `ET_EXEC`, soft-float ABI, decoded extensions only     | admitted, `RISCV:LE:32:default` + `gcc` with the `__rea_ilp32` prototype, lane `elf32-exec-le-soft-float-generic-v1` |
+| ELF32 soft-float ABI without `Tag_RISCV_arch`, or with any other extension | refused; the reason names the extensions outside the decoded set                                                     |
+| ELF32 single-float ABI (ilp32f)                                            | refused until its [written policy](#ilp32f) is implemented and verified                                              |
+| ELF64 soft- or single-float ABI (lp64, lp64f), or the quad-float ABI       | refused; no verified calling-convention policy                                                                       |
+| Big-endian                                                                 | refused; Ghidra 12.1.4 ships no big-endian RISC-V language                                                           |
+| `ET_REL`, `ET_DYN`, other `e_type`                                         | refused with the declared value                                                                                      |
+| `EF_RISCV_RVE`                                                             | refused; the embedded 16-register profile (x0–x15) needs its own processor specification                             |
+| `EF_RISCV_TSO`                                                             | refused; the total-store-order memory model is unverified here                                                       |
+| Reserved or newer `e_flags` bits                                           | refused with the offending bits named                                                                                |

 `e_type` is the only load-shape declaration this lane reads. A fixed-address
 `ET_EXEC` declaration does **not** establish static linkage: `PT_INTERP` and
@@ -58,15 +72,193 @@ with the `gcc` compiler specification per class, records
 pin without changing the requested override. An override that matches the pin is
 accepted and recorded as `configured-v1`.

+The soft-float lane pins the same `RISCV:LE:32:default` language. Every RV32
+language in Ghidra 12.1.4, including the deprecated soft-float `RV32I`, `RV32IC`
+and `RV32IMC` variants in `old/riscv_deprecated.ldefs`, uses the same
+`riscv.ilp32d.sla` decoder; only the compiler specification differs. REA keeps
+the generic language and corrects the calling convention instead.
+
+## Calling conventions
+
+Ghidra's generic RV32 compiler specification, `riscv32-fp.cspec`, models the
+ilp32d ABI. Its default prototype passes `float` and `double` values in
+`fa0`–`fa7` and returns them in `fa0`, and it passes a structure of one or two
+floating-point members in floating-point registers. An ilp32 image passes all
+of these in integer registers. Measured on Ghidra 12.1.4 with an ilp32 build of
+the fixture in `tests/conformance/c/riscv-float-abi.c`, the stock model
+decompiles `rea_riscv_abi_pick(1.5f, 2.5f, sel)` as
+`rea_riscv_abi_pick(in_fa0,in_fa1,0x3fc00000)`.
+
+### Decision record: D3, RISC-V float ABIs
+
+Decided in [#7477](https://github.com/morluto/rea/issues/7477).
+
+- **Choice.**
+  - Admit little-endian ELF32 `ET_EXEC` images that declare the soft-float ABI
+    (ilp32) through a new lane, `elf32-exec-le-soft-float-generic-v1`. Lane ids
+    are built from their fields: `elf<class>-exec-le-<float ABI>-float-generic-v1`.
+  - Keep the pinned `RISCV:LE:32:default` language and `gcc` compiler
+    specification. After analysis, `ReaGhidraRiscvCallingConvention.java`
+    derives the program-specific `__rea_ilp32` prototype from the program's
+    default prototype as the [ilp32 policy](#ilp32) states. It installs the
+    prototype through a Ghidra specification extension and assigns it, with
+    dynamic storage, to every non-thunk function, every external function and
+    every function definition. Thunks follow their targets. The script fails,
+    and writes no report, if the derived prototype or any function still
+    places a value in a floating-point register, or if the prototype does not
+    pass a 16-byte value by reference.
+  - One derivation serves every policy. A policy row says how it changes the
+    default prototype's floating-point entries and preserved registers; every
+    policy passes values of 9 bytes or more by reference.
+  - The profile commits `riscv_calling_convention: ilp32-prototype-v1`. The
+    bridge reports the policy and its function and definition counts, and REA
+    requires that report exactly when the profile commits the policy.
+  - Admission requires a `Tag_RISCV_arch` declaration with an RV32I base and
+    only extensions that Ghidra 12.1.4's generic RV32 language implements with
+    p-code ([ISA declarations](#isa-declarations)).
+  - Soft-float profiles add `float_abi` and `arch` to `riscv_elf`. Double-float
+    profiles keep their exact parameters, so their digests, sessions and
+    snapshots are unchanged.
+  - ilp32f keeps its [written policy](#ilp32f) and stays refused until its
+    prototype is implemented and verified. Quad-float, RVE, TSO, and ELF64
+    soft- or single-float images stay refused.
+- **Alternatives** (and what switching to each would take):
+  - Pin the deprecated soft-float languages (`RISCV:LE:32:RV32IMC` and others,
+    `riscv32.cspec`): REA's language catalog would have to read `old/`, the
+    variants cover only I, IC and IMC, Ghidra marks them deprecated, and no
+    stock specification models ilp32f.
+  - Assign `__rea_ilp32` only to callables whose types use floating-point
+    values, as the MIPS soft-float lane does: typed storage is the same, but
+    prototypes Ghidra infers for untyped code would keep the ilp32d model. In
+    an ilp32 image that contains F or D instructions, that model can still
+    claim `fa0`. Switching is one predicate in the Java script and a new
+    policy id.
+  - Admit with a limitation and no correction: a reduced-capability contract
+    that needs its own review, because arguments, returns and aggregates
+    become unverified.
+  - Keep refusing: the lane rows become refusals again.
+  - Admit images without `Tag_RISCV_arch`, or refuse a list of known
+    extensions instead of admitting a list: a declaration that REA cannot
+    check would be treated as compatible. Widening the decoded set later is
+    additive.
+  - Add `float_abi` and `arch` to double-float profiles as well: one shape for
+    every lane, but every existing RISC-V session and snapshot would be
+    invalidated.
+  - Ship ilp32 and ilp32f together (the question in #7477): ilp32f needs a
+    float-and-integer structure rule that Ghidra's model lacks, so it ships
+    separately with its own fixtures.
+- **Semantic owner and consumers.**
+  - Owners:
+    - `src/domain/riscvIsaDeclaration.ts` owns the float-ABI vocabulary of
+      `e_flags` and the parsing of `.riscv.attributes` and `Tag_RISCV_arch`.
+    - `GHIDRA_RISCV_LANES`, `GHIDRA_RISCV_CALLING_CONVENTIONS` and
+      `GHIDRA_RISCV32_DECODED_EXTENSIONS` (`src/ghidra/GhidraRiscvProfile.ts`)
+      own admission, lane ids and the policy table.
+    - `bridge/ghidra/ReaGhidraRiscvCallingConvention.java` owns how each policy
+      becomes a Ghidra prototype.
+  - Consumers: target resolution, Ghidra provider admission, the analysis
+    profile, the provider client and launcher, the session handshake, project
+    history, the real-Ghidra lane and this page. Later work reuses the table:
+    ilp32f adds a row, and RISC-V ESP images (F6) select a row through D5.
+- **Costs of changing it.**
+  - **Code:** S. A policy or lane is one table row plus the Java derivation.
+  - **Compatibility:** the soft-float lane id, `riscv_elf.float_abi`,
+    `riscv_elf.arch` and `riscv_calling_convention` are persisted in sessions,
+    snapshots and Evidence once released. A changed derivation ships as a new
+    policy id, such as `ilp32-prototype-v2`, which invalidates soft-float
+    snapshots only.
+  - **Migration:** none for admitted targets; double-float profiles are pinned
+    by tests. Previously refused soft-float targets become admitted.
+  - **Verification:** rerun `npm run verify:ghidra:riscv`.
+
+### ilp32
+
+Policy `ilp32-prototype-v1`, prototype `__rea_ilp32`. XLEN is 32 bits and no
+floating-point register passes a value.
+
+| Topic                      | psABI rule                                                                                                                                                                                        | `__rea_ilp32`                                                                                                                       |
+| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
+| Integer and pointer values | `a0`–`a7`, then the stack in 4-byte-aligned slots                                                                                                                                                 | The default integer and stack entries, unchanged                                                                                    |
+| `float`                    | One integer register, or a stack slot                                                                                                                                                             | The `fa0`–`fa7` entries and the `float` rule are removed, so a `float` takes the next integer register                              |
+| `double` and 8-byte values | A register pair with the low word in the lower register. Named arguments need no aligned pair. With one register left, the low word goes in `a7` and the high word on the stack                   | The default `join` rule with stack spill: Ghidra writes `a2:4,a1:4` for a pair and `Stack[0x0]:4,a7:4` for the split                |
+| Aggregates up to 8 bytes   | One or two integer registers, laid out as in memory, also when every member is floating-point                                                                                                     | The homogeneous-float-aggregate rule is removed; the `join` rule applies                                                            |
+| Aggregates over 8 bytes    | By reference: the caller passes the address of a copy                                                                                                                                             | The default rule that converts structures and unions of 9 bytes or more to pointers                                                 |
+| Return values              | As the first argument of the same type: `a0`, or `a0` and `a1`. Larger values go to a caller buffer whose address is an implicit first argument in `a0`                                           | The `fa0`/`fa1` return entries and floating-point rules are removed; Ghidra's hidden-return fallback supplies the pointer in `a0`   |
+| Variadic arguments         | The integer convention. A variadic argument with 8-byte alignment and size takes an aligned (even-numbered) register pair, or the stack; after the first stack argument, the rest go on the stack | The default variadic rule (`join` with alignment), unchanged                                                                        |
+| Preserved registers        | `s0`–`s11` and `sp`; `gp` and `tp` are not allocated. No floating-point register is preserved                                                                                                     | The default preserved list without `fs0`–`fs11`, which join the killed-by-call list                                                 |
+| Scalars over 8 bytes       | By reference (`long double` is 16 bytes), and returned through a caller buffer                                                                                                                    | A rule before the final join converts any value of 9 bytes or more to a pointer; a return that size already goes to a caller buffer |
+
+Ghidra recovers the arguments of a variadic call from the registers the caller
+writes, not from their types. A padding register that still holds an earlier
+value can appear as an argument, and arguments after an unwritten register are
+omitted.
+
+### ilp32f
+
+Written policy for `EF_RISCV_FLOAT_ABI_SINGLE` on ELF32. REA does not admit it
+yet. ABI_FLEN is 32 bits.
+
+| Topic                                                   | psABI rule                                                                                       |
+| ------------------------------------------------------- | ------------------------------------------------------------------------------------------------ |
+| `float`                                                 | `fa0`–`fa7` while one is free, then the integer convention                                       |
+| `double` and other values wider than 32 bits            | The integer convention, as in ilp32                                                              |
+| Structure of one or two floats (after flattening)       | One floating-point register per member when enough are free, otherwise the integer convention    |
+| Structure of one float and one integer, in either order | One floating-point and one integer register when both are free, otherwise the integer convention |
+| Unions                                                  | Never flattened; the integer convention                                                          |
+| Return values                                           | As the first argument: `fa0`, `fa0` and `fa1`, or `fa0` and `a0`                                 |
+| Variadic arguments                                      | The integer convention, as in ilp32                                                              |
+| Preserved registers                                     | `s0`–`s11`, `sp`, and `fs0`–`fs11` for values of 32 bits or fewer                                |
+
+The planned prototype limits the default floating-point entries to 4 bytes and
+keeps the shared rule that passes values of 9 bytes or more by reference.
+Observed on Ghidra 12.1.4, a `double` then takes an integer pair and a structure
+of two floats takes `fa0` and `fa1`. Ghidra's model has no rule for a structure
+of one float and one integer: it joins `struct { float; int; }` into `a1:a0`
+instead of `fa0` and `a0`. The ilp32f policy needs that rule and its own
+fixtures before it is admitted.
+
+### ilp32d and lp64d
+
+The double-float lanes use Ghidra's stock `riscv32-fp.cspec` and
+`riscv64-fp.cspec` models unchanged. This page does not verify them. They share
+the float-and-integer structure gap above.
+
+## ISA declarations
+
+The target reader finds the one `SHT_RISCV_ATTRIBUTES` section and reads
+`Tag_RISCV_arch`, such as `rv32i2p1_m2p0_c2p0_zicsr2p0_zifencei2p0`. It
+retains the string, the base and the extension names, or an unavailable reason
+when the section is malformed, declares other vendors or scopes, or uses a
+non-canonical string. A missing section or tag is recorded as absent.
+
+Calling-convention lanes admit an image only when it declares an RV32I base
+and only extensions that Ghidra 12.1.4's generic RV32 language implements with
+p-code: `m`, `a`, `f`, `d`, `c`, `zicsr`, `zifencei`, and the subset names
+toolchains record, `zmmul`, `zaamo`, `zalrsc`, `zca`, `zcf` and `zcd`. Any
+other extension is refused. In particular:
+
+- Ghidra 12.1.4 decodes no Zcb, Zcmp or Zcmt instruction.
+- Its bit-manipulation, cryptography and packed-SIMD files follow draft
+  encodings and mark nearly every instruction unimplemented.
+- Vendor extensions, such as Espressif's `xesploop`, `xespv` and `xespdsp`,
+  decode only as custom-opcode placeholders.
+
+ESP-IDF builds ESP32-C2 and C3 images as `rv32imc_zicsr_zifencei` and ESP32-C5,
+C6, C61, H2 and H21 images as `rv32imac_zicsr_zifencei_zaamo_zalrsc`, all ilp32.
+Those base strings are admitted. Builds that add `_zba_zbb_zbs`,
+`_zcb_zcmp_zcmt` or an `xesp` extension are refused.
+
 ## Evidence

-The lane identity is `elf32-exec-le-double-float-generic-v1` or
-`elf64-exec-le-double-float-generic-v1`, and `riscv_elf` retains `elf_class`,
-`byte_order`, `type`, and the raw `flags` alongside the read-only booleans
-`float_abi_double`, `rvc_declared`, `rve_declared`, and `tso_declared`. Those
-fields report declarations the header makes; none of them is evidence of the
-original compiler, of instruction conformance, or of a floating-point calling
-convention beyond the ABI the pinned language models.
+The lane identity is one of the lane ids above, and `riscv_elf` retains
+`elf_class`, `byte_order`, `type`, and the raw `flags` alongside the read-only
+booleans `float_abi_double`, `rvc_declared`, `rve_declared`, and
+`tso_declared`. Soft-float profiles also retain `float_abi: soft`, the declared
+`arch` string, and `riscv_calling_convention: ilp32-prototype-v1`. Those fields
+report declarations the header and attributes make, and the policy REA applied;
+none of them is evidence of the original compiler or of instruction
+conformance. Session Evidence states the prototype and how many functions and
+definitions use it.

 ## Verification and limits

@@ -76,9 +268,9 @@ tree ships no host decompiler binary, so `Decompiler/os/<platform>/decompile` an
 [installation](installation.md#ghidra).

 Run `npm run verify:ghidra:riscv` with an existing Ghidra 12.1.4 installation,
-JDK 21+, and a RISC-V-capable Clang, LLD and LLVM readelf. The verifier acquires
-no tools and never executes target code. Select installed tools explicitly when
-they are not on `PATH`:
+JDK 21+, and a RISC-V-capable Clang, LLD, LLVM readelf and LLVM objdump. The
+verifier acquires no tools and never executes target code. Select installed
+tools explicitly when they are not on `PATH`:

 ```sh
 GHIDRA_INSTALL_DIR=/path/to/ghidra_12.1.4_PUBLIC \
@@ -86,20 +278,52 @@ JAVA_HOME=/path/to/jdk-21 \
 REA_RISCV_CLANG=/path/to/llvm/bin/clang \
 REA_RISCV_LLD=/path/to/lld/bin/ld.lld \
 REA_RISCV_READELF=/path/to/llvm/bin/llvm-readelf \
+REA_RISCV_OBJDUMP=/path/to/llvm/bin/llvm-objdump \
 npm run verify:ghidra:riscv
 ```

-The lane builds the committed freestanding C and assembly sources into RV32 and
-RV64 `ET_EXEC` fixtures. Independent LLVM readelf observations establish ELF
-declarations and symbol addresses. Public CLI and stdio MCP workflows verify
-function enumeration, decompilation, pinned language/compiler identity, decoded
-probe bytes, global data, and direct calls. It validates advertised MCP output
-schemas and both JSON representations, saves and reopens snapshots, rejects
-header-mutated soft-float and unsupported high-bit declarations, and checks
-unchanged source bytes and owned cleanup. Failures retain the diagnostic
-workspace; successful runs remove it and report the observed process lineage.
+The lane builds four `ET_EXEC` fixtures from committed freestanding C and
+assembly sources:

-Module tests cover admission and malformed headers. Call-graph completeness,
-string inventories, dynamic linkage, Andes or RVE/TSO images, and big-endian
-targets are **not** established by this lane. `.riscv.attributes` ISA extensions
-are not inspected; the generic language pin remains an analysis convention.
+- RV32 and RV64 double-float builds (`rv{32,64}imafdc`) of `riscv.c`.
+- An RV32 soft-float build of `riscv-float-abi.c` with ESP32-C3's
+  `-march=rv32imc_zicsr_zifencei -mabi=ilp32`, typed with DWARF.
+- The same objects linked with `--strip-all`. Every allocated section keeps
+  its address and bytes, so the typed build's symbols locate its functions.
+
+Independent LLVM readelf observations establish ELF declarations,
+`Tag_RISCV_arch` and symbol addresses. Public CLI and stdio MCP workflows verify
+function enumeration, decompilation, pinned language/compiler identity, the
+committed lane and policy, decoded probe bytes, global data, and direct calls.
+They validate advertised MCP output schemas and both JSON representations, save
+and reopen snapshots, and check unchanged source bytes and owned cleanup.
+
+For the soft-float builds the lane also checks:
+
+- `fence.i` and `csrr` decode, as ESP32-C3's Zifencei and Zicsr declare.
+- An LLVM objdump reading of `rea_riscv_abi_caller` finds each call-site word
+  where the [ilp32 policy](#ilp32) puts it: an unaligned `double` in `a1`/`a2`,
+  the `a7`/stack split, two floats in an integer pair, a large structure and a
+  `long double` passed by reference (the pointed-to copies hold the source
+  values), aligned variadic pairs, and an indirect call.
+- `inspect_native_api` reports `__rea_ilp32` with exactly that storage for the
+  typed build. The stripped build has one integer word per parameter location
+  and returns in the typed build's registers, or in none when the result goes
+  through caller memory.
+- The caller's pseudocode passes the source constants through that storage and
+  names no floating-point register.
+- Retained Evidence states the prototype outcome; the stripped build has no
+  function definitions.
+
+Header-mutated copies check admission. The RV32 double-float image relabelled as
+soft-float (`e_flags` `0x1`), refused before this lane, is admitted through the
+soft-float lane over CLI and MCP. The soft-float image relabelled as
+single-float, RV64 soft-float, and unsupported high bits are refused with their
+reasons. Failures retain the diagnostic workspace; successful runs remove it and
+report the observed process lineage.
+
+Module tests cover admission, malformed headers and attribute sections, the
+handshake, and the conformance checks against recorded LLVM and Ghidra output.
+Call-graph completeness, string inventories, dynamic linkage, Andes or RVE/TSO
+images, big-endian targets, ilp32f images, and decoding beyond the probes are
+**not** established by this lane.
@@ -220,6 +220,12 @@ For guided registration, set `REA_IDA_MCP_CONFIG` before `rea setup --client <cl

 ## Coverage and evidence

+REA admits x86, x86_64, arm and arm64 executables through IDA. Every other CPU
+family, including families that REA recognizes later, is refused until REA
+admits it explicitly. Raw-binary and GameCube DOL targets are refused; open
+them with Ghidra. Admission is not verification: the real workflows under
+[Verification](#verification) cover x86_64 and arm64 only.
+
 All profiles support procedure/string inventory and literal or regex search, procedure resolution, pseudocode, assembly, raw function instructions, resolved callees, incoming address references, and a function dossier. Inventories and modern pseudocode/assembly follow upstream pagination. Upstream limits on modern xrefs and callees are retained as explicit truncation limitations. In the modern headless profile, targets that are not proven x86-only use processor-neutral `callgraph` edges instead of the x86 instruction checks in upstream `callees` (mrexodia/ida-pro-mcp#549). REA requests depth zero: the pinned upstream emits the root's outgoing edges without scanning child functions, then REA batches function-name lookup for those addresses. The graph covers recognized function destinations only; imports and other non-function targets remain unknown. A server without `callgraph` returns an empty relationship list with an explicit coverage limitation. Graph and path workflows retain those limitations alongside observed edges. A failed or inconsistent graph reply remains an error. A transport-level truncated preview is rejected rather than reported as complete evidence; the error preserves upstream retrieval guidance.

 All profiles expose `list_documents` as the single target admitted for the session. Attached mode verifies its digest against IDA metadata before returning it; headless mode binds the digest-checked private input. `inspect_address_context`, `trace_feature`, and `binary_overview` can therefore resolve that identity without upstream document-listing tools. Segment enumeration is optional: when the selected profile cannot provide it, `binary_overview` still returns document and procedure/string counts and omits `segments` and `segment_count`; omission means unobserved, not empty. The modern headless profile also supports `resolve_containing_procedure`. An address resolves through upstream `lookup_funcs` to the canonical entry of the function that contains it; the body stays unavailable like other IDA identities. When no function contains it, REA reads the database-scoped minimal `survey_binary` and reports `not_in_procedure` for an address inside one of its segments (ends are exclusive) and `outside_segments` otherwise. A missing, truncated or inconsistent survey fails the read instead of guessing a reason. `trace_feature` marks a trace truncated, with a residual unknown for that address, when upstream caps the references it returned. Attached profiles do not declare address containment resolution.
@@ -528,6 +528,12 @@ message names one reason:
 | `image-range-overlap`     | Two images claim the same type definitions.                                                                      |
 | `invalid-string`          | A name index is outside the strings section, its string is unterminated, or it is not valid UTF-8.               |

+Record extents are checked for the decoded images, types, methods, fields,
+properties, events, parameters, string literals, nested types, generic
+containers, generic parameters and interface offsets. Other header sections
+are checked for file bounds and overlap; their internal record layouts are not
+decoded or validated by this inventory.
+
 A version field that disagrees with the file's layout, for example a version
 39 file relabeled as 29, usually surfaces as `unexpected-header-size` or
 `record-size-mismatch`.
@@ -47,20 +47,20 @@ For runtime instrumentation, see the [Frida guide](./frida-instrumentation.md).

 ## Choose a guide

-| Task                                                | Guides                                                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
-| --------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Identify a desktop installation                     | [Runtime candidates, evidence and follow-up files](desktop-applications.md)                                                                                                                                                                                                                                                                                                                                                                                                                       |
-| Inspect native functions, references, or types      | [Native binaries](native-investigation.md), [Go metadata](go-binaries.md), [Rust dependencies](rust-binaries.md), [CPython pyc files](python-pyc.md), [PE certificates](pe-certificates.md), [PE imports](pe-imports.md), [PE TLS/load config](pe-load-config.md), [ELF notes](elf-notes.md), [Linux kernel modules](kernel-modules.md), [Apple IPS](apple-ips.md), [Erlang BEAM](erlang-beam.md), [offline ELF layout](binary-diagnostics.md), [recorded crashes](recorded-crashes.md)           |
-| Inspect native functions, references, or types      | [Native binaries](native-investigation.md), [Go metadata](go-binaries.md), [Rust dependencies](rust-binaries.md), [CPython pyc files](python-pyc.md), [PE certificates](pe-certificates.md), [PE imports](pe-imports.md), [PE TLS/load config](pe-load-config.md), [ELF notes](elf-notes.md), [Apple IPS](apple-ips.md), [Erlang BEAM](erlang-beam.md), [offline ELF layout](binary-diagnostics.md), [recorded crashes](recorded-crashes.md)                                                      |
-| Select a native provider or import format           | [Ghidra semantics](ghidra-provider.md), [Windows](windows-ghidra-p0.md), [DOS](ghidra-dos.md), [raw bytes](raw-binary.md), [GameCube DOL](ghidra-dol.md), [MIPS](ghidra-mips.md), [PSP](ghidra-psp.md), [NativeAOT](ghidra-nativeaot.md), [IDA](ida-provider.md), [Kuna](kuna-provider.md), [JEB](jeb-analysis.md)                                                                                                                                                                                |
-| Analyze JavaScript or Electron artifacts            | [Static analysis](javascript-artifact-reconstruction.md), [tracing and comparisons](javascript-application-workflows.md), [application graph](javascript-application-graph.md), [source recovery](javascript-recovery.md)                                                                                                                                                                                                                                                                         |
-| Compare static JavaScript with runtime observations | [Runtime attribution](javascript-runtime-observation.md), [reconciliation](javascript-runtime-reconciliation.md), [Electron observation](electron-observation.md), [Electron fuses](electron-fuses.md)                                                                                                                                                                                                                                                                                            |
-| Inspect assemblies, packages, or firmware           | [Godot PCK](godot-pck.md), [UnityFS](unityfs.md), [U-Boot uImage](uimage.md), [.NET](managed-code-analysis.md), [Python packages](python-packaged-applications.md), [Android](android-analysis.md), [APK signatures](apk-signature.md), [Apktool resources](apktool-resource-analysis.md), [ADB acquisition](adb-device-analysis.md), [Apple](apple-application-analysis.md), [Harmony](harmony-analysis.md), [firmware](firmware-analysis.md), [WASM](wasm-artifacts.md), [EVM](evm-bytecode.md) |
-| Observe or compare a browser scenario               | [CDP observation](browser-observation.md), [scenarios](browser-scenario-contract.md), [runtime evidence](web-runtime.md), [historical captures](web-network-captures.md)                                                                                                                                                                                                                                                                                                                          |
-| Serve recorded behavior as an agent environment     | [Agent environments](agent-environments.md)                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
-| Trace captured website source                       | [Source locations](web-source-location.md), [module traces](website-module-trace.md), [script export](website-script-export.md)                                                                                                                                                                                                                                                                                                                                                                   |
-| Capture and compare a command                       | [Process capture](process-capture.md)                                                                                                                                                                                                                                                                                                                                                                                                                                                             |
-| Use CLI/MCP and retain evidence                     | [CLI](cli.md), [MCP contracts](mcp-contracts.md), [agent prompts](mcp-prompts.md), [obligation ledgers](reconstruction-obligation-ledgers.md)                                                                                                                                                                                                                                                                                                                                                     |
+| Task                                                | Guides                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
+| --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Identify a desktop installation                     | [Runtime candidates, evidence and follow-up files](desktop-applications.md)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| Inspect native functions, references, or types      | [Native binaries](native-investigation.md), [Go metadata](go-binaries.md), [Rust dependencies](rust-binaries.md), [CPython pyc files](python-pyc.md), [PE certificates](pe-certificates.md), [PE imports](pe-imports.md), [PE TLS/load config](pe-load-config.md), [ELF notes](elf-notes.md), [Linux kernel modules](kernel-modules.md), [Apple IPS](apple-ips.md), [Erlang BEAM](erlang-beam.md), [offline ELF layout](binary-diagnostics.md), [recorded crashes](recorded-crashes.md)                                                                               |
+| Inspect native functions, references, or types      | [Native binaries](native-investigation.md), [Go metadata](go-binaries.md), [Rust dependencies](rust-binaries.md), [CPython pyc files](python-pyc.md), [PE certificates](pe-certificates.md), [PE imports](pe-imports.md), [PE TLS/load config](pe-load-config.md), [ELF notes](elf-notes.md), [Apple IPS](apple-ips.md), [Erlang BEAM](erlang-beam.md), [offline ELF layout](binary-diagnostics.md), [recorded crashes](recorded-crashes.md)                                                                                                                          |
+| Select a native provider or import format           | [Ghidra semantics](ghidra-provider.md), [Windows](windows-ghidra-p0.md), [DOS](ghidra-dos.md), [raw bytes](raw-binary.md), [GameCube DOL](ghidra-dol.md), [MIPS](ghidra-mips.md), [PSP](ghidra-psp.md), [NativeAOT](ghidra-nativeaot.md), [IDA](ida-provider.md), [Kuna](kuna-provider.md), [JEB](jeb-analysis.md)                                                                                                                                                                                                                                                    |
+| Analyze JavaScript or Electron artifacts            | [Static analysis](javascript-artifact-reconstruction.md), [tracing and comparisons](javascript-application-workflows.md), [application graph](javascript-application-graph.md), [source recovery](javascript-recovery.md)                                                                                                                                                                                                                                                                                                                                             |
+| Compare static JavaScript with runtime observations | [Runtime attribution](javascript-runtime-observation.md), [reconciliation](javascript-runtime-reconciliation.md), [Electron observation](electron-observation.md), [Electron fuses](electron-fuses.md)                                                                                                                                                                                                                                                                                                                                                                |
+| Inspect assemblies, packages, or firmware           | [Godot PCK](godot-pck.md), [UnityFS](unityfs.md), [U-Boot uImage](uimage.md), [.NET](managed-code-analysis.md), [Python packages](python-packaged-applications.md), [Android](android-analysis.md), [APK signatures](apk-signature.md), [Apktool resources](apktool-resource-analysis.md), [ADB acquisition](adb-device-analysis.md), [Apple](apple-application-analysis.md), [Harmony](harmony-analysis.md), [firmware](firmware-analysis.md), [ESP images](esp-image.md), [ESP flash images](esp-flash-image.md), [WASM](wasm-artifacts.md), [EVM](evm-bytecode.md) |
+| Observe or compare a browser scenario               | [CDP observation](browser-observation.md), [scenarios](browser-scenario-contract.md), [runtime evidence](web-runtime.md), [historical captures](web-network-captures.md)                                                                                                                                                                                                                                                                                                                                                                                              |
+| Serve recorded behavior as an agent environment     | [Agent environments](agent-environments.md)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| Trace captured website source                       | [Source locations](web-source-location.md), [module traces](website-module-trace.md), [script export](website-script-export.md)                                                                                                                                                                                                                                                                                                                                                                                                                                       |
+| Capture and compare a command                       | [Process capture](process-capture.md)                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
+| Use CLI/MCP and retain evidence                     | [CLI](cli.md), [MCP contracts](mcp-contracts.md), [agent prompts](mcp-prompts.md), [obligation ledgers](reconstruction-obligation-ledgers.md)                                                                                                                                                                                                                                                                                                                                                                                                                         |

 For development, use [testing](testing.md), [client verification](client-verification.md),
 [tool design](tool-design.md), [admission limits and recovery](design/limits-and-recovery.md),
@@ -0,0 +1,72 @@
+# Classic iNES container inspection
+
+REA recognizes classic iNES from the `NES` + `0x1a` byte signature, independently
+of the file extension. This read-only container inspection uses portable
+Node.js file reads; it needs neither Ghidra nor an emulator.
+
+```bash
+rea inspect-artifact ./cartridge.nes --json
+rea extract-artifact ./cartridge.nes --json
+```
+
+Through MCP, call `open_binary` with the local path, then `inspect_artifact`.
+Use `extract_artifact` to materialize the regions in the fresh directory named
+by its result. The caller owns that successful extraction directory.
+
+## Header and file regions
+
+Inspection returns `container-header` and `reconstruction` observations inline.
+The single inventory Evidence under `substeps[].evidence.normalized_result`
+contains the complete graph and an `ines` object:
+
+- `ines.header`: original 16-byte `header_hex`, PRG/CHR file-unit counts, mapper,
+  raw flags 6/7, trainer and battery flags, and the declared mirroring mode.
+- `occurrences[]`: each region's path, `source_location.offset` and
+  `source_location.length` in the original container. Follow `artifact_id` to
+  the node's observed SHA-256 and byte count.
+- `ines.reconstruction`: ordered region paths, concatenated byte count,
+  SHA-256 and `verified: true`. REA accumulates the concatenation digest during
+  the same physical-order region scan that produces node hashes, then compares
+  it with the original whole-file digest. Final source freshness is also checked.
+  No reconstructed file is written during inspection.
+
+Regions are `header.bin`, optional `trainer.bin` (512 bytes),
+`prg/000.bin` onward (16 KiB each), `chr/000.bin` onward (8 KiB each), and
+optional `trailing.bin`. Every input byte is retained, including unused header
+fields and uninterpreted trailing data. Zero CHR-ROM units create no CHR region;
+REA does not fabricate CHR-RAM contents.
+
+After extraction, concatenate the materialized files in
+`ines.reconstruction.region_order` from the inspection inventory. Their bytes
+reproduce the input exactly. Graph path order is lexical and is not physical
+file order; use the explicit region order or source offsets.
+
+## Supported boundary
+
+This increment supports classic iNES with a complete 16-byte header, nonzero
+PRG count, complete declared trainer/PRG/CHR payload, and zero reserved bytes
+12–15. Dirty legacy headers are refused because their upper mapper bits are
+ambiguous; REA does not silently repair them. NES 2.0 and UNIF signatures,
+unsupported header variants and truncated payloads are explicitly refused.
+An arbitrary file named `.nes` is not admitted as iNES.
+
+The PRG/CHR units describe file storage, not mapper bank sizes or CPU windows.
+The mapper number and flags are header declarations, not proof of cartridge
+hardware or runtime behavior. Bank switching, 6502/65816 disassembly, emulator
+sessions and interpretation of console-specific trailing data remain outside
+this lane. Raw-binary Ghidra analysis is a separate workflow. This container
+increment addresses the first milestone of [#2072](https://github.com/morluto/rea/issues/2072);
+the related [#1641](https://github.com/morluto/rea/issues/1641) tracks 6502/65816
+native analysis with explicit load addresses and provider limitations. Extracted
+PRG units still need caller-selected CPU windows before static code analysis;
+their physical file offsets do not establish those addresses.
+
+Source-owned byte fixtures verify original offsets and hashes, extraction and
+byte-exact reconstruction, CLI/stdio MCP parity, malformed/unsupported inputs,
+failed target-switch recovery, cancellation and source identity. These checks
+do not establish emulator behavior or compatibility with every historical ROM.
+The portable CLI/stdio MCP acceptance and source-identity checks run in Linux
+and macOS CI. The same workflows have also been executed on native Windows x64.
+
+Format references: [iNES](https://www.nesdev.org/wiki/INES) and
+[NES 2.0](https://www.nesdev.org/wiki/NES_2.0).
@@ -381,7 +381,7 @@ Select the part you want to check:
 | Task                                | Readiness check                                                          |
 | ----------------------------------- | ------------------------------------------------------------------------ |
 | Static JavaScript/Electron analysis | Run `rea analyze-javascript-application PATH --json` directly.           |
-| One analysis engine                 | `rea doctor --provider ghidra --json` (or `hopper`, `ida`)               |
+| One analysis engine                 | `rea doctor --provider ghidra --json` (or `hopper`, `ida`, `kuna`)       |
 | One agent registration              | `rea doctor --client codex --json` (see [client IDs](#supported-agents)) |
 | Installed workflow instructions     | `rea doctor --skill --json`                                              |

@@ -928,7 +928,12 @@ selected only when it is the arm64 family's only candidate. REA checks the
 entire source's SHA-256 while copying the slice; source identity and reported
 offsets still refer to the original container. Any other ambiguous architecture
 subtype requires an explicitly extracted thin image; REA does not guess.
-Configured loader arguments remain explicit overrides.
+Set `HOPPER_LOADER_ARGS_JSON` in REA's launch environment to a JSON array of
+strings to override the derived Hopper loader arguments, for example
+`["-l","Mach-O"]`. Empty string elements are preserved; NUL bytes are not
+accepted. An omitted setting or empty array uses the derived arguments. `rea
+setup` forwards an explicitly selected setting to supported registrations;
+restart the MCP server to apply a change. These arguments are Hopper-specific.
 FAT64 is distinct from the CPU architecture: FAT32 containers can contain 64-bit
 executable images. This preparation avoids the Raw Binary loader dialog observed
 with native FAT64 loading on Hopper 6.1.0-demo.
@@ -988,6 +993,14 @@ When Hopper cannot start in CI, run
 `rea doctor --provider hopper --json` in the failing runner.
 Structured failures distinguish private-display dependencies, an unsupported
 demo dialog or build, process-ownership conflicts, and an early lifecycle exit.
+Once launcher authentication succeeds, an absent first-run dialog is reported as
+`demo_dialog_absent` rather than a build or publisher rejection. The watcher
+waits 10 seconds by default. Set `REA_HOPPER_DEMO_DIALOG_TIMEOUT_MS` in the
+environment that starts REA to a positive decimal integer of milliseconds from
+1 to 2147483647 when a slower host needs a longer window. An invalid value is
+`invalid_dialog_timeout`: the error names that setting, shows the rejected
+value and its source, lists the allowed range, and asks you to correct the
+setting and restart REA.
 If a private-display probe times out or is cancelled and its process cleanup
 fails, REA retains that exact probe owner and reports `cleanup_incomplete`.
 Session close retries the probe before releasing its cleanup marker; doctor
@@ -1020,7 +1033,7 @@ reported as incompatible instead of being admitted from its directory name, and
 a header that cannot be read or recognized is reported as unknown. REA does not
 build or install native tools, or change Gatekeeper quarantine settings.

-The adapter exposes 26 read-only operations: fourteen inventory/name/search
+The adapter exposes 27 read-only operations: fifteen inventory/name/search
 operations and twelve function-analysis operations. These cover metadata,
 decompilation, assembly, resolved calls, typed references, xrefs, function
 dossiers, instructions, recovered data types, measured load mappings, loaded
@@ -1212,8 +1225,10 @@ bridge, and health readiness. Large binaries can need more: set
 milliseconds in the server environment. An absent setting uses the default;
 empty, invalid or out-of-range supplied values fail configuration validation.
 When the deadline elapses, the `provider_timeout` error names
-`REA_GHIDRA_STARTUP_TIMEOUT_MS` with the deadline that was applied and suggests
-`REA_GHIDRA_DISABLED_ANALYZERS` for analyzers that dominate the time.
+`REA_GHIDRA_STARTUP_TIMEOUT_MS` with the deadline that was applied. In
+fresh-import mode it also suggests `REA_GHIDRA_DISABLED_ANALYZERS` for analyzers
+that dominate the time and `REA_GHIDRA_PROJECT_PATH` for reusing a completed
+analysis; in existing-project mode it omits that import and analyzer advice.
 REA parses the supplied configuration environment and
 passes the deadline to each provider client; a startup failure is returned by the query that triggered it,
 without exposing partial analysis. This deadline is separate from MCP transport
@@ -1404,6 +1419,33 @@ REA passes `-processor`/`-cspec`, checks both against the installation's `.ldefs

 Language definitions must be well-formed XML encoded as UTF-8 or BOM-marked UTF-16, with any encoding declaration matching the bytes. Literal Unicode replacement characters (U+FFFD) are accepted; malformed source bytes are rejected.

+Ghidra imports little-endian ARM ELF files, including Cortex-M
+(`arm-none-eabi`) firmware, as `ARM:LE:32:v8`. That language defaults to ARM
+state, and its ELF loader marks code as Thumb only where `$t` mapping symbols
+or odd function-symbol addresses say so. Cortex-M cores run only Thumb code, so
+the gap matters mainly for code without those markers, such as stripped images
+and handlers reached only through the vector table. REA has no M-profile ARM
+lane. As an unverified interim, select an M-profile language, which decodes in
+Thumb state by default. For ARMv6-M, ARMv7-M and ARMv7E-M cores:
+
+```bash
+export REA_GHIDRA_LANGUAGE_ID="ARM:LE:32:Cortex"
+```
+
+For ARMv8-M cores, use `ARM:LE:32:v8-m` instead. REA has not verified either
+language for Cortex-M analysis. While the variable is set, it applies to every
+Ghidra import in the REA server:
+
+- raw-binary, DOS, GameCube DOL and PSP opens are refused, as are opens in
+  lanes that reject a different language, such as RISC-V;
+- REA asks Ghidra to import everything else in the selected ARM language,
+  including x86, x86-64, arm64, PowerPC and Hexagon ELF files and PE and
+  Mach-O files, because it does not check that the override's processor
+  matches the target.
+
+Restart REA without the variable before you analyze other targets. A future
+M-profile lane may refuse it; remove the setting then.
+
 To seed code that auto-analysis cannot reach (computed jumps, pointers in data):

 ```bash
@@ -1555,7 +1597,7 @@ On a controlled Windows x64 runner, use
 `npm run verify:ghidra:windows`. The verifier generates a deterministic native
 PE fixture from source bytes and requires the Windows native authority before
 opening the provider. The controls are implemented on main; see the
-[release boundary](#released-package-and-main). The lane verifies all 26 admitted
+[release boundary](#released-package-and-main). The lane verifies all 27 admitted
 read-only operations, digest identity, and runtime cleanup. The separate
 `verify:ghidra:windows:package` lane checks the packed CLI/MCP boundary with an
 ordinary user. It requires the built Windows native bundle and an existing
@@ -161,6 +161,17 @@ reached through `contains` from one of its children only leads further up its
 containment chain, so a shared asset or artifact root does not pull in its
 other children.

+When a string seed has no application match and the supplied Evidence has a
+semantic graph, `semantic_discovery` lists matching retained semantic node
+labels and direct string call arguments using the same matching mode and case
+rules. These are candidate starting
+points, not application trace matches. Its graph coverage and total describe the
+retained graph; missing or partial source coverage cannot establish absence.
+Results follow retained node order and default to offset 0 and limit 64. Supply
+`semantic_page` and follow `next_offset` for further matches. Use a returned
+`trace_seed` with the same application Evidence and `trace_javascript_semantics`
+to examine relationships from that node. Other typed seeds do not search labels.
+
 The result contains the matching basis, complete reachable subgraph, terminal
 paths, authority summaries, and native handoffs. A handoff binds
 the exact native artifact digest and requested exports from the application
@@ -187,6 +198,10 @@ rereading mutable files. A seed may identify a semantic or application node,
 literal, function fingerprint, property, endpoint, event, or boundary field.
 For a recovered parse, coercion, or validation boundary, its field value is the
 static operation's method name (for example, `Number`).
+When a recovered boundary call directly supplies a scalar binding, the graph
+connects the boundary to that binding; unresolved boundary calls remain
+candidates. A boundary nested inside another expression or compound assignment
+does not establish a direct result binding.
 The query declares backward provenance, forward influence, callers, or
 ownership and can restrict admitted relation kinds. REA returns every matching
 seed and the complete reachable subgraph; callers do not choose node, relation,
@@ -209,6 +224,25 @@ resulting value. Deferred callback bodies do not become inputs to the enclosing
 assignment. Computed method keys belong to the enclosing callable; parameter
 defaults and method bodies belong to the method. Uncertain later property reads
 remain opt-in through `include_ambiguous_dynamic_edges`.
+
+Binary, logical, unary, template, conditional, and sequence expressions retain
+`influences` edges from supported immediate inputs to the result, then to a
+direct declaration, assignment, call argument, or return. These are static
+dependencies, not aliases or proof that the expression executed; conditional
+operands and logical-assignment writes carry `conditional: true`. Unsupported
+operand dependencies, unmodeled receiving containers, dynamic call results,
+and sequence side effects remain unknown. An applicable
+unknown makes the trace status `partial` even when a seed was found. Literal
+operator operands, direct call arguments and directly returned scalar literals
+can also be seeds. Older graphs that only recorded a call-site literal remain
+searchable. The offered per-file node capacity also bounds the producer's
+expression and operand collections before graph projection.
+Expression nodes and unknowns share the existing per-file graph admission
+budgets; omitted facts make graph coverage truncated and the trace partial.
+Consumers that previously treated `found` as compatible with a relevant
+unknown should handle `partial` and inspect the returned unknowns. Retained
+graphs without `influences` edges remain readable but do not gain edges until
+the application is analyzed again.
 Global timer, `fetch`, `WebSocket`, `JSON.parse`, and coercion calls receive
 these built-in effects only when the file has no visible possible write to that
 global, including a computed write through a global object. The check does not
@@ -273,7 +307,14 @@ mapped candidate, but structural reachability, semantic influence, runtime
 observation, and causal proof remain separate claims.

 Semantic literal nodes keep their complete value in `properties.value`; literal
-queries match that field. String labels use `string literal` when that is
+queries match that field. Call-site nodes also retain direct scalar arguments in
+`properties.arguments`, with source argument indexes; literal queries can start
+at those call sites. These are syntactic facts, not runtime values, and an index
+after a spread is not necessarily the runtime argument position. Nonliteral
+arguments and values not representable in JSON are omitted. The primitive byte
+bound and the worker transfer record ceiling can also omit direct values; the
+call-site unknown reports the applicable limit. String labels use
+`string literal` when that is
 shorter than the complete JSON value. A literal's `identity.role_key` commits
 its canonical JSON value as `value-sha256:<digest>` when the digest key is
 shorter; smaller values keep their existing JSON key. This keeps large values
@@ -581,8 +622,10 @@ or process workflows.
 ## CLI and verification

 All six CLI commands accept inline JSON or a path to a JSON file. The CLI
-returns an Evidence record directly. Put the full records in a later CLI input;
-a separate CLI process has no retained MCP connection state.
+returns an Evidence record directly. Later workflow inputs can contain full
+records, or exact retained references when `--evidence-bundle PATH` selects an
+authenticated exported bundle. A separate CLI process has no retained MCP
+connection state. See [CLI Evidence reuse](cli.md#import-export-and-compare-evidence).

 File inputs must be regular files; symlinks to regular files are accepted.
 Directories, named pipes and device files produce an input error before JSON
@@ -605,8 +648,12 @@ rea trace-application-feature ./trace-input.json --json
 MCP analysis returns the complete Evidence record, with the operation result
 in `normalized_result` and its identity in `evidence_id`. If the connected server advertises retained references, reuse its
 exact returned ID as `{"kind":"retained-evidence","evidence_id":"RETURNED_ID"}`
-in `application`, or `left`/`right` for comparisons. `RETURNED_ID` is a template,
-not a literal valid ID. Native Evidence arrays still use complete records.
+in `application`, or `left`/`right` for comparisons. For summary or inspection
+replies, use `normalized_result.parent_evidence_id` to select the complete source.
+`RETURNED_ID` is a template, not a literal valid ID. Native-observation arrays
+and `reconcile_javascript_runtime`'s nested static layers and runtime-observation
+array also accept references where advertised, independently mixed with inline
+records. Exact identity, coverage and partial or unknown facts are preserved.
 References are scoped to one connection; `close_binary` clears them. Export a
 bundle before closing and import it on another connection, or supply the full
 inline Evidence there. Versions before 4.1.0 accept full inline Evidence only; installing
@@ -560,6 +560,8 @@ alternative object. A traced invocation whose key, API object or world stays
 unresolved or guarded keeps the call's own unresolved observation.
 Unknown spreads, reassigned bindings, accessors,
 dynamic channels and unsupported syntax do not become exact implementations.
+Literal switch cases retain their selection conditions. Possible fallthrough
+remains partial; dynamic case expressions remain unknown.
 This pass neither executes the bundle nor proves that runtime guards pass.
 An ambiguous or unresolved handler retains its channel registration but does
 not acquire a path to one arbitrarily selected callback. Unknown factory
@@ -642,7 +644,13 @@ identity. This static check does
 not evaluate arbitrary call side effects or runtime registration. Missing findings
 do not establish that an application has no Electron boundary usage.

-IPC pairing is an inference, not an observation. A renderer `invoke` pairs only
+IPC pairing is an inference, not an observation. A main handler registered on an
+unresolved channel may receive any literal channel, so a compatible renderer send
+or `invoke` beside it is ambiguous, not unpaired. A wrapper's registration is
+exempt only when every invocation is a traced direct call supplying a literal
+channel, each recorded as its own finding. A guarded invocation keeps its
+predicate on a call path instead, so its channel still competes without pairing.
+A renderer `invoke` pairs only
 with one unique `ipcMain.handle`/`handleOnce` candidate on the same exact literal
 channel; a renderer send pairs only with one unique `ipcMain.on`/`once`/`addListener`
 candidate. Dynamic channels are never paired, and multiple compatible handlers
@@ -99,7 +99,9 @@ nodes. REA evaluates compatible static candidates conservatively:
   content digest can match. Whole-asset digests and reconstructed module-factory source
   digests remain distinguishable in the reported basis.
 3. Without captured bytes, one unique mapped artifact path can produce a
-   medium-confidence location match.
+   medium-confidence location match. A proven factory module contained within
+   the located asset is not a competing whole-file location; separate assets
+   and independently plausible modules remain candidates.
 4. Multiple candidates remain `ambiguous`; no `observed_as` edge is emitted.
   With captured source and mapped candidates, only mapped content matches
   qualify; unrelated content matches elsewhere are excluded.
@@ -1,6 +1,6 @@
 # Kuna provider

-[Kuna](https://github.com/Noelo-Lab/kuna) is an Apache-2.0 decompiler distributed as one `kuna` executable. REA uses a `kuna` you supply. It does not download, install, update or bundle Kuna. REA verified this provider with Kuna 1.833; it accepts other releases and reports them as unverified in `rea doctor` and in each analysis profile.
+[Kuna](https://github.com/Noelo-Lab/kuna) is an Apache-2.0 decompiler distributed as one `kuna` executable. For a new installation, use Kuna 1.986, REA's recommended verified release. REA uses a `kuna` you supply; it does not download, install, update or bundle Kuna. REA accepts other releases, which it reports as unverified in `rea doctor` and in each analysis profile. The 1.986 real-provider checks ran on macOS arm64; Linux and other hosts have not been verified with that release.

 Kuna is static: it reads the selected image and never executes it.

@@ -40,6 +40,38 @@ inspection is needed; see [selected member inspection](#selected-member-inspecti
 Compare separate builds with [member comparison](#member-comparison), preserving
 their paths, digests, and selection scope.

+### Field constant defaults
+
+`inspect_managed_members` reads field-owned values from the ECMA-335 `Constant`
+table without loading the assembly. Each selected field's `constant` contains
+the declaration's row offset, element-type code, blob index and exact `raw_hex`,
+plus its decoded `element_type` and `value`. For example, an `i4` declaration
+with bytes `865d0000` returns `23942`.
+
+Boolean, character, signed/unsigned integers, floating-point, UTF-16 strings
+and class-null declarations are supported. `i8` and `u8` values are decimal
+strings to avoid JSON integer precision loss. Floating-point negative zero,
+NaN and infinities are the strings `-0`, `NaN`, `Infinity` or `-Infinity`;
+`raw_hex` preserves their original bits. UTF-16 code units, including embedded
+NULs and unpaired surrogates, are preserved.
+
+`constant: null` means neither a Constant declaration nor `HasDefault` was
+observed. Historical Evidence can omit the field entirely; omission does not
+prove that the artifact has no default. Missing or duplicate declarations,
+inconsistent flags, malformed values and unsupported element types return
+`state: "unavailable"`, a limitation and partial coverage while retaining other
+member facts. This decoding shares the existing metadata representation budget
+and only decodes blobs for the selected fields.
+
+Retained `managed-members` field pages can select `fields: ["constant"]` while
+keeping original field identity and source offsets. These values are metadata
+declarations, including enum members' encoded underlying constants, not observed
+runtime state or inferred enum-name mappings. Parameter/property defaults are
+not exposed by this field-focused reader. Member comparison still covers field
+names, flags and signatures; it does not compare constant defaults.
+
+The encoding follows [ECMA-335, Partition II, sections 22.9 and 23.1.16](https://ecma-international.org/publications-and-standards/standards/ecma-335/).
+
 ### Metadata overview and retained rows

 The existing CLI and omitted/complete MCP detail return complete metadata
@@ -120,6 +152,50 @@ literal pool's own coverage. Older Evidence that never examined exported types
 or user strings reports a null count and refuses those pages rather than
 returning an empty one.

+To find specific retained members without returning their IL anchors, select
+exact names and defining types, then project columns:
+
+```json
+{
+  "source": {
+    "kind": "retained-evidence",
+    "evidence_id": "<parent_evidence_id>"
+  },
+  "view": {
+    "kind": "managed-members",
+    "collection": "methods",
+    "names": ["ParseNumber", "ParseReadNumber"],
+    "declaring_types": ["Newtonsoft.Json.JsonTextReader"],
+    "fields": ["name", "declaring_type", "signature"],
+    "offset": 0,
+    "limit": 64
+  }
+}
+```
+
+Filters are exact and case-sensitive; lists are alternatives and filters
+intersect. An empty list matches nothing. Names select `name` in types,
+exported types, fields, methods and member references; in call edges they select
+`target_name`, and in field accesses `field_name`. Declaring-type filters select
+`declaring_type` in fields/methods, `parent_name` in member references,
+`target_declaring_type` in call edges and `field_declaring_type` in field accesses.
+Types, exported types and user strings do not accept a declaring-type filter;
+user strings do not accept a name filter. No display strings are reparsed.
+
+`fields` accepts only columns of that collection. Omitting it preserves full
+rows, including method bodies. Selecting `body` explicitly returns the full
+recorded body and anchors; selecting no columns (`[]`) returns identity fields.
+Projected or filtered rows add their original `source_index`; tokens and source
+byte offsets remain, with defining/parent tokens or IL-site endpoints where
+applicable. The page retains module/MVID, artifact digest, parent Evidence,
+producer selection and source coverage. Full facts remain in the parent.
+
+Paging offsets and totals count known matches in original order. `source_count`
+counts the producer-returned collection; `unresolved_filter_rows` counts rows
+that could match but lack a requested name/type. Those candidates remain unknown
+and are excluded from the matched total. Exhausting the known matches does not
+prove absence among unresolved or unexamined source rows.
+
 #### CLI summary and saved member rows

 The CLI accepts the same `complete` and `summary` detail choices. Omitted or
@@ -167,13 +243,17 @@ authenticates the saved bundle; the full source is retained on disk.

 The canonical parser admits PE/CLI bytes and their metadata/CIL without loading
 an assembly. It reports observed implementation markers and unavailable facts;
-it does not unpack .NET single-file hosts or infer a NativeAOT identity from an
-ordinary native PE. It does not decode IL2CPP; use
+it does not itself unpack .NET single-file hosts or infer a NativeAOT identity
+from an ordinary native PE. It does not decode IL2CPP; use
 [IL2CPP metadata](il2cpp-metadata.md) for the image, type and method names in a
 Unity `global-metadata.dat`. Inputs without admitted CLI metadata do not
 become managed assemblies through naming or routing guesses.
 Inspect separately obtained components explicitly and preserve their identities.

+For ordinary .NET single-file hosts, use the existing artifact tools to
+[inventory and extract bundle members](dotnet-bundles.md), then inspect the
+extracted assembly explicitly with the managed tools.
+
 A valid implementation marker establishes a candidate native boundary, not
 recovered native semantics or runtime behavior.

@@ -432,8 +512,18 @@ raw digest stands in. Missing or unreadable TypeDef and TypeRef operands are
 reported as coverage issues. Invalid NestedClass rows retain their failure
 reasons and withhold TypeDef signature identities; type names and nesting are
 parsed once by their shared owner. Each current inspection records
-`signature_resolution: "type-names-v1"`, even when none of its operands can be
-resolved. Historical Evidence defaults this attestation to `null`. When either
+`signature_resolution: "type-names-v2"`, even when none of its operands can be
+resolved. Version 2 also appends readable names to signature operands, for
+example `class:7772 (AnalysisJob)`. Coded indexes remain build-local references;
+names are display text and do not change raw or resolved signature digests.
+Nested names use `Outer/Inner`. Generic instantiations keep their decoded
+arguments, for example ``class:9 (System.Collections.Generic.List`1)<string>``;
+custom modifiers are named too. Valid but unresolved TypeSpecs, invalid scopes,
+unreadable type names, cycles and nesting beyond the cap keep their raw operand
+spelling. Invalid or missing metadata coordinates retain the existing malformed
+signature result and source issue; rendering does not bypass validation.
+Version 1 Evidence remains readable and compares using the same digest policy.
+Historical Evidence defaults this attestation to `null`. When either
 observation predates resolution, both sides compare raw digests, which pair only where type rows agree,
 and the comparison reports that limitation. The signature is exact whether or
 not REA decoded it, so undecoded signatures pair by that tuple too, but they
@@ -26,8 +26,21 @@ can be passed directly to `compare_functions`, and `inspect_artifact` Evidence
 to `compare_artifacts`. Use `get_evidence_bundle` when the task needs broader
 retained session history or an explicit bundle for transfer.

+`compare_artifacts` does not need that Evidence sent back. Name each side once
+with a source that `inspect_analysis_view` also accepts:
+`{"kind": "retained-evidence", "evidence_id": "<id>"}` for a record retained in
+this session, or `{"kind": "evidence-file", "path": "/absolute/evidence.json"}`
+for a saved record or bundle. Add `evidence_id` to select one record from a
+bundle that holds more than one. Complete inline Evidence is still accepted as
+the third form. The comparison cites the records that the sources resolve to,
+so all three forms give the same comparison Evidence. A retained reference that
+the session cannot resolve is refused with `evidence_integrity_mismatch` and
+`details.reason: "missing"`.
+
 `compare_artifacts` can also resolve an artifact summary to its exact retained
-parent in the session. Supported historical summaries keep their original
+parent in the session, or from the authenticated bundle containing a file-selected
+summary. File-local records take precedence over the session lookup. Unrelated
+records are not retained by the file resolver. Supported historical summaries keep their original
 Evidence identity and omissions; a missing or mismatched parent is rejected.

 `analyze_function` does not deliver its complete record by default. Without
@@ -40,8 +53,9 @@ reject the summary record. Give `compare_functions` the retained dossier as
 `{"kind": "retained-evidence", "evidence_id": "<parent_evidence_id>"}`; give
 `match_native_functions` the same reference inside `left_observations` or
 `right_observations`, since its `left` and `right` take `list_procedures`
-Evidence. Request `detail: "complete"` for `build_call_path`, which accepts
-only inline complete dossiers.
+Evidence. `build_call_path.functions` also accepts retained references to the
+complete dossiers. Request `detail: "complete"` only when the record must travel
+inline.

 Saved records from the pre-6.6 identity projection that omitted
 `relationship_coverage: null` from its digest remain incompatible, even when
@@ -56,13 +70,16 @@ the same Evidence authentication failures: an admitted source that fails
 authentication is `evidence_integrity_mismatch`, while an authenticated source with an unsupported
 workflow role or invalid selector is `invalid_request`.

-Ghidra inventories and function replies use `raw_result: null` when their facts
-are already preserved in `normalized_result`, limitations, locations and
-relationship coverage. Distinct overview details, measured load-image
-observations, file-offset selection roles and database types supplemented with
-derived metadata keep their upstream representation. Read function results from
-`normalized_result`; older retained Evidence keeps its original representation
-and identity.
+Ghidra inventories, measured load-image observations and function replies use
+`raw_result: null` when their useful facts are already preserved in
+`normalized_result`, limitations, locations and relationship coverage. Distinct
+overview details, file-offset selection roles and database types supplemented
+with derived metadata keep their upstream representation. When a Ghidra naming
+edit is not applied, `raw_result` keeps the bridge's `failures` and shared
+`conflicts` table without a second copy of the result booleans. Native load-image
+attestation continues to use the bridge reply locally before Evidence
+projection. Read function results from `normalized_result`; older retained
+Evidence keeps its original representation and identity.

 Artifact source-map filename relationships require a unique, identified regular
 file at the sibling path. A known directory cannot be the mapped file; the map
@@ -144,7 +161,9 @@ for the error code, target details, partial observations, remediation, and the
 optional bounded `recovery` next step. `recovery.kind=inspect_input_contract`
 names the rejected operation: re-read that operation's advertised input schema
 (call `tools/list` if the catalog may be stale), correct the listed fields, and
-do not repeat the unchanged call. `recovery.kind=inspect_timeout_state` names
+do not repeat the unchanged call. A well-formed request the selected target
+cannot answer, such as an address without one exact file offset, omits this
+hint; follow its `remediation.action`. `recovery.kind=inspect_timeout_state` names
 the operation and the REA server/provider deadline. Inspect partial Evidence
 and reported cleanup state, then follow the returned remediation. Change a
 request field or REA_* setting only when the returned remediation explicitly
@@ -163,8 +182,13 @@ if retention is unavailable or fails, the diagnostic reports that reason.
 SDK-generated input validation failures are normalized into the same canonical
 `invalid_request` text when the bounded diagnostic fits the response budget.
 The complete field/type diagnostic is preserved when normalization fits the
-response budget, including request-specific rejected fields and reasons. Oversized
-SDK diagnostics keep the existing retained-Evidence recovery path. An unknown
+response budget, including request-specific rejected fields and reasons. Zod
+input issues retain their field paths and available type and range constraints.
+SDK diagnostic parts may be distributed between field issues and the main
+message so each retained explanation appears once.
+If their conservative projection allowance is exhausted, the response states
+that field-level detail was omitted and retains the original SDK diagnostic.
+Oversized SDK diagnostics keep the existing retained-Evidence recovery path. An unknown
 tool remains an MCP JSON-RPC `-32602` error, but its message directs the caller
 to `tools/list` and an advertised operation instead of repeating the unknown
 name.
@@ -329,8 +353,11 @@ When `record_unknown` or `update_unknown` commits but its complete reply exceeds
 the response budget, `details.reported_limits.committed_unknown` identifies the
 exact unknown ID, committed revision and mutation Evidence IDs. Its retained
 Evidence reference remains available on the same connection. Export the bundle
-or page `list_unknowns` to recover the result; do not repeat the committed
-mutation. A delivery failure does not undo that revision.
+to recover the result; do not repeat the committed mutation. A single unknown
+may be too large for a `list_unknowns` page. A delivery failure does not undo
+that revision. If a list response overflows, retry on the same connection with
+the same filters and offset and a smaller limit; export if one head still cannot
+fit.

 For a portable exported bundle, the CLI shares this projection:
 `rea inspect-evidence-bundle '{"path":"/tmp/evidence.json","detail":"summary","filters":{"operation":"analyze_function"}}' --format json`.
@@ -351,6 +378,38 @@ that buffer. It does not raise REA's reserved single-string limit, which is
 raise that Node ceiling. It does not change analysis coverage or retained
 content. Ordinary responses keep their existing complete result contract.

+### Input validation resource allowance
+
+Both HTTP and stdio admit at most 1,024 combined array elements and object
+members in one tool's arguments by default. The pinned SDK counts them before
+canonical schema validation or lazy runtime materialization. Oversized calls
+return a bounded, nonretryable `resource_constraint` with resource `transport`
+and `reported_limits.max_input_elements`; the full element count is not claimed.
+No provider or tool handler starts for a refused call. Subsequent calls remain
+usable.
+
+Set `REA_MCP_MAX_INPUT_ELEMENTS` to a positive decimal safe integer and restart
+REA to select another allowance for a larger complete observation or batch.
+Where a tool supports retained-Evidence or Evidence-file selectors, prefer
+those selectors to resending large inline records. Admission never truncates
+the caller's selected input or removes retained Evidence.
+This is a configurable transport admission policy, not a per-array `maxItems`
+contract or an exact heap guarantee. Missing required fields can amplify one
+input element into many issues: on the pinned Evidence array schema,
+1,024 empty objects produced 16,384 issues and about 26 MiB heapUsed delta
+before SDK formatting. The default therefore admits at most 1,023 such objects
+plus the root member, rather than extrapolating the scalar case to larger batches;
+actual memory also depends on schema branches, runtime state and concurrent
+work. HTTP's separate request-byte limit and the client's receive limit still
+apply.
+
+Canonical schemas and CLI/application analysis semantics remain shared and
+unchanged. Admitted arguments retain the same values and ordinary validation
+diagnostics. SDK embedders can select `maxToolInputElements` in the server
+options; the common REA MCP server supplies the finite default to eager and
+deferred registrations alike. This does not impose the separate semantic
+batch-workload limit tracked in issue #5930.
+
 ### Error recovery and deadline ownership

 Initialization instructions and the static JavaScript tool description teach
@@ -386,10 +445,12 @@ result's `_meta`, whether the call succeeded or failed:
 ```

 The marker is declared once per tool contract (`returnsTargetContent`) and is
-on by default: only `export_evidence_bundle` and `record_unknown`, whose
-results and errors contain only REA session state or caller-supplied values,
-omit it. Tools whose results or errors can include provider, launcher, or
-device output stay marked, including `binary_session` (provider failure
+on by default: `export_evidence_bundle`, `record_unknown`, `search_guidance`,
+and `read_guidance_section` omit it. The first two contain only REA session
+state or caller-supplied values; the guidance tools return REA's own installed
+documentation, not text from an analysis target. Tools whose results or errors
+can include provider, launcher, or device output stay marked, including
+`binary_session` (provider failure
 reasons and availability diagnostics), `close_binary` (provider cleanup
 diagnostics with captured launcher output), `inspect_adb_client` and
 `inspect_apktool_client` (version output and stderr excerpts), and
@@ -426,6 +487,9 @@ session retention refuses summary detail with `capability_unavailable`;
 For `inspect_artifact`, omission also keeps the original request parameters and
 complete output shape. Delivery selection never reaches the inventory engine;
 the complete inspection and its atomic inventory Evidence remain retained.
+A view is never more certain than its parent: a summary or other view of
+`inferred` Evidence is `inferred`. Other views are `derived`, unless the
+view kind itself infers, as described below.

 `inspect_analysis_view` also accepts `api-surface` for retained HAR capture Evidence,
 grouping request lines by method, origin and format-rule path template. Templated
@@ -541,10 +605,12 @@ reach WABT or change the original source Evidence ID.
 Completed `inspect_macho` Evidence supports a summary and
 `view: {kind: "macho", facet: "exports", offset: 0, limit: 64}`. Facets are
 `entrypoints`, `architectures`, `build_metadata`, `load_commands`,
-`dependencies`, `imports`, `exports`, `segments`, and `provenance`; pages return
-the original rows. The summary keeps the selected slice, header fields and UUID,
-and replaces each collection with its returned count, reported total and
-`exhaustive` flag. Each page repeats the paged collection's `source_total` and
+`dependencies`, `imports`, `exports`, `segments`, `encryption`, and
+`provenance`; pages return the original rows. Evidence retained before
+`encryption` was reported pages no encryption rows and reports that collection
+as non-exhaustive with an unknown status. The summary keeps the selected
+slice, header fields and UUID, and replaces each collection with its returned
+count, reported total and `exhaustive` flag. Each page repeats the paged collection's `source_total` and
 `source_exhaustive`; exhausting a non-exhaustive collection does not establish
 that unreturned symbols are absent. Large frameworks return megabytes of
 symbols (Electron Framework: 2.5 MB of imports and exports, 3.3 KB as a
@@ -562,10 +628,24 @@ counts, and whether the decoded graph is incomplete. Each page repeats
 budget (XLD.app: 6.7 MB), so select `detail: "summary"` on the first call.
 Delivery detail never reaches the decoder or changes the source Evidence ID.

-`trace_application_feature`, `trace_javascript_semantics`,
-`compare_application_versions`, `compare_source_to_bundle`, and
-`compare_javascript_export_shapes` accept complete inline application Evidence
-or an exact reference to a record already retained by the current connection:
+Logical Evidence source fields share one input contract across domains:
+complete inline Evidence or an exact reference to a record already retained by
+the current connection. This applies to individual sources, optional sources,
+arrays and nested sources declared by the tool's input schema:
+
+| Workflows                                                                                                   | Retained-reference inputs                                                                                             |
+| ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- |
+| `compare_functions`, `compare_process_captures`, `compare_wasm_interfaces`                                  | `left`, `right`                                                                                                       |
+| `match_native_functions`                                                                                    | `left`, `right`, `left_observations[]`, `right_observations[]`                                                        |
+| `trace_application_feature`, `trace_javascript_semantics`, `compare_source_to_bundle`                       | `application`; feature tracing also accepts `native_observations[]`                                                   |
+| `compare_application_versions`, `compare_javascript_export_shapes`                                          | `left`, `right`; version comparison also accepts both native-observation arrays                                       |
+| `reconcile_javascript_runtime`                                                                              | `static_layers[].analysis`, `runtime_observations[]`                                                                  |
+| `compare_managed_members`, `verify_managed_native_boundaries`, `import_managed_reconstruction`              | Comparison `left`/`right`; verification `managed_boundaries`/`native_observations[]`; reconstruction `static_members` |
+| `project_managed_application_graph`                                                                         | `managed_artifact`, `managed_members`, `managed_native_boundaries`                                                    |
+| `project_android_application_graph`, `project_apple_application_graph`, `project_harmony_application_graph` | `inventory_evidence[]`                                                                                                |
+| `build_call_path`, `find_changed_behavior`, `correlate_static_and_runtime`                                  | `functions[]`, `comparisons[]`, or `static_comparisons[]`/`runtime_comparisons[]`, respectively                       |
+
+For example:

 ```json
 {
@@ -581,11 +661,16 @@ or an exact reference to a record already retained by the current connection:
 ```

 Use the `evidence_id` returned by `analyze_javascript_application` (or another
-compatible application-graph producer). Comparisons accept this form in `left`
-and `right`; each side can independently be inline or retained. Native
-observation arrays continue to take complete inline Evidence. Results and their
-Evidence remain complete inline, and both input forms pass the same semantic,
-identity, authority, and provenance checks without running the producer again.
+compatible application-graph producer). When the producer returned a summary
+or inspection page, use its `normalized_result.parent_evidence_id` to select
+the complete source, rather than the view's own `evidence_id`. Each source can
+independently be inline or retained, including within one array. Both forms use
+the same application workflow and owner validation, preserve exact source
+identity, provenance, authority, coverage and partial or unknown facts, and do
+not run the producer again. A reference cannot supply facts absent from that
+record. Workflows that follow source links also require those linked records
+in the ledger. File references are accepted only where the tool explicitly
+advertises a file selector; a retained ID does not authorize a file read.

 References belong to the current connection's Evidence ledger. Opening another
 target or restarting the current target preserves retained records, including
@@ -598,10 +683,13 @@ Supply complete inline Evidence, repeat its producer, or import an exported
 Evidence bundle before referencing that imported record. Export a bundle before
 closing if the investigation needs it later.

-CLI application workflows continue to read portable inline Evidence from files
-and run the same analysis workflows; a standalone CLI invocation cannot resolve
-another MCP connection's retained records. No additional lookup call, provider
-selection, or approval step is required for a same-session follow-up.
+CLI workflows that advertise `--evidence-bundle` can resolve the same reference
+JSON from one explicitly selected local bundle, including an MCP export. They
+also accept portable inline Evidence and use the same application workflows.
+A standalone CLI invocation cannot resolve another MCP connection's ledger
+without that exported bundle. See [CLI Evidence reuse](cli.md#import-export-and-compare-evidence)
+for the supported commands. No additional lookup call, provider selection, or
+approval step is required for a same-session follow-up.
 CLI `inspect-artifact` continues to return complete portable Evidence. Save that
 JSON to a file and use `inspect-analysis-view` with inline source Evidence for
 later inventory summaries or pages; a one-shot CLI session cannot retain a
@@ -700,6 +788,37 @@ concrete version, selection source, and complete analysis profile through
 choices return typed selection details. A selected provider is never replaced
 automatically after a runtime failure.

+`open_binary` resolves an Apple bundle directory (`.app`, `.appex`,
+`.framework`, `.xpc`, `.systemextension`, `.bundle` or `.plugin`, compared
+case-insensitively) to the program file its `Info.plist` names in
+`CFBundleExecutable`; the Evidence subject is that program file. It reads the
+macOS `Contents/` layout or the flat root layout. A framework with `Versions/`
+may instead keep `Info.plist` in `Versions/Current/Resources/` with its program
+file in `Versions/Current/`; a flattened framework without `Versions/`, as
+Electron and Gecko apps ship it, keeps `Resources/Info.plist` beside its
+program file. An app keeps its iOS-on-Mac `Wrapper` resolution. For the
+other types, exactly one layout may declare the bundle, and its `Info.plist`,
+program directory and program file must stay inside the bundle. Resolution
+never guesses a program file. Each refusal reports one `details.constraint`:
+
+- `bundle_info_plist_missing`, with `probed_paths` listing every layout's
+  `Info.plist`.
+- `bundle_layout_ambiguous`, with `probed_paths` listing the `Info.plist`
+  files found.
+- `bundle_current_version_missing`, with `probed_paths` naming
+  `Versions/Current`.
+- `bundle_path_escapes`, with `probed_paths` naming the path that resolved
+  outside the bundle.
+- `bundle_executable_undeclared`, with `info_plist`.
+- `bundle_program_missing`, with `info_plist` and `probed_paths` naming the
+  declared program file.
+
+An unreadable or malformed `Info.plist` keeps its reason without a bundle
+constraint, and `details.path` names that file. A `.dext`, `.kext`,
+`.qlgenerator` or `.mdimporter` directory reports `bundle_type_unsupported`. A
+resource root reports its `layout` as `contents`, `root`,
+`versioned-framework` or `flattened-framework`.
+
 `open_bundle_resources` selects a separate read-only app resource session
 without resolving `CFBundleExecutable`, including when it is absent or
 unresolvable. `binary_session` reports `session_kind: "bundle_resources"` and the
@@ -742,6 +861,22 @@ inspection fails or is cancelled before a provider client exists. If no client
 remains, no provider run or health observation is available; follow the cleanup
 error's reported resources.

+## Initial target at startup
+
+MCP normally starts without a target; use `open_binary` to select one during the
+session. To open a target before serving MCP, set `HOPPER_TARGET_PATH` to the
+selected path in REA's launch environment. `HOPPER_TARGET_KIND` accepts
+`executable` (the default) or `database`. Despite the names, these are initial
+session settings; the configured provider still determines how the target is
+opened. If the initial open fails, REA reports the failure and exits with code 1
+without serving MCP. Shutdown during startup cancels and cleans up the open as
+described below.
+
+The source-checkout helper `node scripts/print-mcp-config.mjs /path/to/target`
+prints a registration containing these settings; `--kind database` selects the
+database kind. The helper is not part of the installed npm package. `rea setup`
+does not copy these one-shot target settings into generated registrations.
+
 ## Transports

 The eager stdio runtime owns SIGINT, SIGTERM and stdin EOF before opening an
@@ -986,6 +1121,15 @@ mapping. A successful start-address mapping does not establish that an entire
 range is contiguous in the original file, or that its bytes equal analysis
 memory after loader fixups. Uninitialized, missing, and ambiguous mappings fail
 explicitly; preserve the reported failure rather than guessing an offset.
+For Ghidra, such a well-formed address returns `invalid_request` whose message
+states the bridge's reason and whose remediation points to
+`inspect_native_load_image`. It carries no `inspect_input_contract` recovery.
+`details.issues[0].observed` keeps the caller's exact `address` and a
+`file_mapping` outcome: `unmapped` (outside every memory block),
+`uninitialized`, `absent` (no authoritative target-file source), `ambiguous`,
+or `unrepresentable` (beyond the exact JSON integer range). Initialization, not
+the loaded flag, decides whether source bytes can exist, so an initialized
+file-backed overlay still maps.

 For constructor-populated pointer or resource slots, a static zero is not proof
 of a later null value. Inspect the slot's `xrefs` and the writer's assembly or
@@ -1209,12 +1353,20 @@ bytes and returns the `integrity_contradictions` records for the extracted
 files. An active ASAR unpacked entry whose companion file is absent cannot be
 materialized; extraction fails as `unavailable` with that logical path.

+A container can also declare a checksum over its own bytes; today that is the
+DFU suffix CRC of a DfuSe file. A mismatch is a contradiction of the root
+occurrence (logical path `.`), recorded as a `dfu-crc32` pair. Under
+`record-and-continue` the root becomes `mismatched` while its elements stay
+listed and extractable as observed-untrusted bytes, and `extract_artifact`
+returns the root record with the extracted files' records.
+
 If native DMG child traversal is unavailable after carrier identification,
 the typed failure retains a revalidated root-only inventory under
 `details.partial_observation.inventory`, with unknown child coverage and the
 producer's diagnostics/provenance. It does not borrow or detach an existing
 attachment. Native checksum verification failures still refuse traversal;
-`record-and-continue` recovery applies to structured entry contradictions.
+`record-and-continue` recovery applies to structured entry and container
+contradictions.

 Occurrences use normalized logical paths for identity and lookup. Optional
 `source_path` retains the original path within the owning reader when Unicode
@@ -18,6 +18,26 @@ non-string values are rejected with field paths. `action: "list"` accepts no
 workflow identifier or arguments. The MCP adapter respects the same
 `REA_MCP_TOOL_FAMILIES` scope as native prompts, including render requests.

+To find a section in the installed guidance bundle by analyst question, use
+`search_guidance` and pass a returned locator to `read_guidance_section`. The
+CLI equivalent is `rea guidance --query "exact JavaScript module"`, followed
+by `rea guidance --action read --locator LOCATOR`. Search is limited to the
+packaged managed skill files, works without providers or a target, and returns
+deterministically paged matches. Every non-generic query word must occur in the
+section; generic-only queries return no matches. Results are documentation; locators
+are bound to the installed bundle and report stale or unavailable guidance without
+returning cached section content. A no-match result says nothing about analysis
+capability availability.
+
+Search returns at most 20 matches per page with 500-code-unit context excerpts.
+Read retrieves the complete selected section. Admission permits 1 MiB per file,
+4 MiB per bundle, 4,096 sections, and 25,165,824 expanded UTF-16 code units before
+section text is materialized. Unreadable or oversized bundles return
+`bundle_unavailable`, with no partial index or inferred absence. Cleanup failures
+remain errors with their retained retry owner. The bundle and complete section
+are bound by fixed-size hashes in locators, so a long heading does not make its own
+locator unreadable.
+
 ## Prompt inventory

 | Prompt                            | Purpose                                                                              |
@@ -51,9 +71,11 @@ directly to `analyze_javascript_application` with `input_path`; it does not
 require `open_binary`. When that Evidence, or `inspect_binary_layout` Evidence,
 is already retained, it suggests `inspect_analysis_view` before tracing a
 feature seed. The CLI equivalent is `rea analyze <directory>`.
-`open_binary` and the doctor target check admit files and macOS app bundles.
-A directory outside that opening route is reported with an available analysis
-action; this does not establish support for every directory format.
+`open_binary` and the doctor target check admit files and Apple bundle
+directories (`.app`, `.appex`, `.framework`, `.xpc`, `.systemextension`,
+`.bundle` and `.plugin`). Another Apple bundle type is refused as unsupported,
+and another directory is reported with an available analysis action; this does
+not establish support for every directory format.

 For target paths in `compare_application_versions`, the prompt suggests
 opening each target before calling `inspect_artifact`; inspection operates on
@@ -127,7 +127,11 @@ rea inspect-native-data-type <binary> --address <typed-data-address> --provider

 Instruction facts include bytes, length, decoder text, ordered register/scalar/
 address tokens, typed references and flow destinations. Mid-instruction, data,
-outside-memory and undecodable addresses have separate outcomes. Effective
+outside-memory and unlisted addresses have separate outcomes. For Ghidra,
+`not-in-listing` means the address is in memory without a listed instruction or
+defined data. REA does not attempt a decode there: the memory may be uninitialized
+or contain valid instructions. Older Evidence may report `undecodable` for this
+same ambiguous case; it does not establish that a decode failed. Effective
 memory base/index/displacement roles remain unavailable. Ghidra reports its program
 language variant in `mode`; other providers retain their own mode label. Ghidra
 MIPS results additionally expose `decoder_context`
@@ -138,7 +142,7 @@ that do not expose this facet. The context is an analysis observation, not proof
 of a runtime processor state.

 `inspect_native_instruction` also returns `incoming_references` to the exact
-queried address, including data, interior-instruction and undecodable addresses.
+queried address, including data, interior-instruction and unlisted addresses.
 Ghidra enumerates its ReferenceManager, excludes synthetic entry-point
 references, and returns deterministic source-address ordering while retaining
 distinct operand references from the same source. `[]` means that enumeration
@@ -181,6 +185,13 @@ observed entry label. An interior address therefore remains visible without
 being mistaken for the function entry. Identity failures are reported as
 `procedure.status: "unknown"`; label failures leave a null name and `name_error`.
 Neither failure discards usable pseudocode, and names are not parsed from it.
+A provider answer without pseudocode is an error item that keeps that
+observation's own `limitations`, so a reason the provider reported for that
+entry, such as a Kuna export failure or a missing body, stays with the item.
+Null pseudocode is `capability_unavailable`; empty or non-text pseudocode is
+`unreadable_output`. Provider failures keep their typed error. Successful items
+do not repeat limitations; the batch Evidence aggregates every observation's
+limitations by provider and operation.
 Resolved entries also appear in the composed Evidence locations. New batch
 Evidence commits the revised workflow profile; retained historical Evidence
 remains valid. This tool
@@ -339,6 +350,27 @@ Hopper regex mode.

 ## Bounded static traces

+Hopper caller queries, incoming procedure references and function dossiers
+reconcile reported reverse relationships with forward call observations. Each
+standalone query or composed workflow scans the current document in pages of at
+most 64 procedures and retains at most 4 MiB of encoded scan results. A composed
+workflow reuses its own index and clears it when the workflow finishes. The
+default cooperative scan budget is
+2,000 ms; set `REA_HOPPER_CALLER_SCAN_BUDGET_MS` to a positive integer number of
+milliseconds before starting REA to change it. The default limits additional
+work on the serial Hopper bridge; larger documents may need a higher setting.
+Results report the examined procedure count and any budget interruption.
+An individual page, native caller list, and target instruction list each have
+a 512 KiB encoded allowance. Hitting one reports the incomplete observation.
+Cancellation is checked between pages, but cannot interrupt a Hopper API call
+already executing; Hopper's native API itself materializes its reference arrays
+before REA can bound their copies. Hopper exposes no document revision token, so scans are not
+reused across workflows and coverage and consistency during a live scan remain
+unknown even when every procedure was examined.
+Hopper observations are re-observed rather than replayed from snapshots because
+the provider has no document revision token. Safe observations may still be
+retained as Evidence.
+
 `trace_native_ui_action` / `rea trace-native-ui-action <target> <seed>` accepts
 one authored selector/object ID, native symbol or exact function address. It
 joins UI wiring to uniquely matched class/selector implementations and follows
@@ -389,6 +421,15 @@ nodes and edges. Node payloads are bounded to 8 MiB and serialized results to
 32 MiB. Pagination returns edges whose source is on the node page and preserves
 stable IDs for endpoints outside that page.

+A call to an analyzed callee with no recovered parameter nodes gets the unknown
+`Parameter bindings for <callee> are unavailable or omitted`, unless the
+callee's `native_api` reports no parameters and a `parameter_list` with
+`basis: "signature"` and `variadic: false`. That provider fact means the
+callee's signature fixes zero parameters, so the call has nothing to bind.
+Recovered, variadic or unreported parameter lists, and callees that were not
+analyzed, keep the unknown. Evidence recorded before `parameter_list` existed
+omits it, and its arity remains unknown.
+
 Within one value trace, each exact procedure selector is attempted at most once,
 including failed analyses. A failed seed returns the provider's original typed
 failure and corrective guidance; it cannot establish a trace or target identity.
@@ -397,6 +438,21 @@ establish canonical function identity. A successful seed without a native def-us
 model still returns its procedure and an explicit coverage unknown. A new trace
 can retry failed selectors.

+Paging and traversal completeness are separate facts. `page_truncated` means the
+page omits retained nodes, and the edges they source, before `offset` or after
+`next_offset`. Every page repeats `traversal`: `complete`, or `truncated` with
+`reasons` naming each observed cause: the `max_depth`, `max_functions`,
+`max_call_sites`, `max_nodes` or `max_edges` budget, the fixed
+`node_payload_bytes` allowance, `provider_pcode_truncated`, or
+`ambiguous_call_candidates`. Each cause also has a located unknown. A budget is
+reported only after it rejects work, so an exactly filled budget is not
+truncation; a depth or candidate limit is reported only when no other path
+analyzes or queues that destination. `total_nodes` and `total_edges` count
+retained rows. `truncated` remains true for either kind of omission. Failed
+analyses and unresolved calls stay in `unknowns` and do not truncate the
+traversal. Each page reruns analysis; pages are not pinned to one snapshot
+across session edits.
+
 The raw Java `is_dead` flag can remain set after Ghidra decodes a live block;
 `block_membership` reports actual syntax-tree membership separately.

@@ -487,8 +543,10 @@ output-budget omissions remain omissions.

 Source input is limited to 64 MiB. Binary and direct XML decoding reserve an
 estimated 64 MiB decode budget before parsing; this is not a hard process-memory
-bound. JSON decode memory has not been measured and has no equivalent decode
-estimate. A refused input reports non-retryable `resource_constraint` with
+bound. The XML estimate charges every element and every text, comment or CDATA
+node of the decoder's DOM at a measured upper bound, so a plist made of many
+small elements reaches it at a few MiB of source. JSON decode memory has not
+been measured and has no equivalent decode estimate. A refused input reports non-retryable `resource_constraint` with
 `reported_limits.maximum_input_bytes` or `maximum_decoded_bytes` as applicable.
 Ordinary direct-source decoding has a ceiling of 998 source nesting levels,
 derived from the existing 1000-level JSON result capacity by reserving one level
@@ -533,7 +591,21 @@ support for core-dump analysis, historical FVMLIB layouts, or unobserved native
 diagnostic spellings. Unknown or contradictory header values and signalled
 commands remain failures.

-`inspect_macho.selected_architecture` identifies the exact selected lipo slice
+`inspect_macho` reads load-command framing and fields from the selected Mach-O
+bytes. It does not use line-delimited tool output to decide where a command,
+section, or embedded string begins. Names whose bytes are not valid UTF-8 have
+a null text value and retain their original bytes as lowercase hexadecimal in
+`name_bytes_hex`, `segment_bytes_hex`, or `path_bytes_hex`; fixed-width names
+stop at the first NUL, and command paths exclude their NUL terminator. Older
+retained Evidence may omit the byte fields. Large binary sizes and offsets that
+cannot be represented as safe JSON integers retain an exact hexadecimal field;
+the corresponding numeric field is null. A section alignment too large to
+represent in bytes retains `alignment_exponent` instead.
+
+Unknown or partially decoded commands retain their selected-slice-relative
+offset and size. Their unexamined fields are described in load-command coverage
+limitations; an exhaustive command inventory does not by itself establish that
+every payload field was decoded. `inspect_macho.selected_architecture` identifies the exact selected lipo slice
 and its `container_file_offset` in the input file. A thin Mach-O has a known
 offset of zero; an unknown universal-slice offset stays null. The Evidence
 subject format describes the input container: `mach-o-universal` for FAT files,
@@ -541,15 +613,49 @@ including those with one slice. The normalized result also reports the container
 in `format`; `selected_architecture` identifies the selected Mach-O image.
 Architecture `file_offset` values are container-relative. Entrypoint, segment
 and section `file_offset` values retain their source meaning and are relative
-to the selected Mach-O slice. Raw load-command fields retain their original values.
-A field otool prints more than once, such as each `LC_BUILD_VERSION` tool, is
-keyed `name #n` in print order. Each `LC_LINKER_OPTION` string is keyed
-`string #n` and checked against the declared `count`. Evidence locations map the LC_MAIN entrypoint and nonempty file-backed segment
+to the selected Mach-O slice. Decoded load-command fields retain their original
+values. Repeated fields, such as each `LC_BUILD_VERSION` tool, are keyed
+`name #n` in order. Each decoded `LC_LINKER_OPTION` string is keyed `string #n`
+and checked against the declared `count`. Evidence locations map the LC_MAIN entrypoint and nonempty file-backed segment
 ranges to container offsets by adding the observed slice offset. Zero-fill
 segments do not produce file ranges. When the selected slice's container offset
 is unknown, those mapped locations are omitted with an explicit limitation;
 architecture inventory locations remain available.

+`inspect_macho.encryption` reports the `LC_ENCRYPTION_INFO(_64)` state of every
+slice, not only the selected one. It decodes only the FAT table, slice headers
+and load commands. Like every Mach-O container read, a `0xcafebabe` input of at
+most 16 MiB is first read whole to rule out a JVM class file, so that read
+includes code bytes; larger inputs and thin images read only the structures
+above. A slice is `encrypted` when its single encryption command has a nonzero
+`cryptid`, `not-encrypted` when `cryptid` is zero, and `absent` only when every
+load command was read and none was an encryption command. A command whose width
+or `cmdsize` contradicts the image, more than one such command, or a range past
+the slice is `malformed`; a slice whose commands could not be fully read is
+`malformed` or `unknown` with a reason, keeping any commands seen before the
+failure. A slice with more than two encryption commands keeps the first two
+and states the count in its reason. Range mapping in all slices shares one
+budget of segment and section records (16,384, a sixteenth of the native
+output budget); a slice past it keeps its status and reports its mapping as
+`unknown` with that reason. Framing caps retained segment commands before decoding.
+Only a successful mapping consumes the shared allowance; failed mappings leave
+it available to later slices. Each slice's `range` is end-exclusive in slice and input-file
+coordinates and maps to file-backed segment fragments, VM addresses and the
+overlapping nonempty sections; bytes outside every segment remain unmapped
+fragments. A segment with no VM size keeps its file bytes as fragments with
+null VM addresses, and a segment whose file size exceeds its VM size or whose
+VM range leaves the address space makes the mapping `unknown` with a reason
+while the slice keeps its encryption status. `architecture` is the lipo name of the record at the same offset,
+size and CPU identity, and is null when no single record matches. A ciphertext
+range adds a limitation naming its input-file bytes, because disassembly,
+decompilation, strings and references derived from them do not describe
+program code. Encryption is read through the same regular-file descriptor
+that `inspect_macho` binds for its load-command reads, whose SHA-256 must match
+the session target before and after the native tools run, or the call reports
+`artifact_changed`. A target that cannot be opened, or a symlinked, non-regular
+or changing target, fails the call instead of reporting tool facts without an
+encryption status.
+
 Hopper's `address_to_file_offset` combines the native image-relative mapping with
 original-file coordinates only after checking the source against the session's
 SHA-256. FAT tables and embedded Mach-O headers come from that same hashing pass.
@@ -586,6 +692,9 @@ complete observation.
  undecodable filenames and skipped symlinks, as partial coverage. Known
  executable roots remain available; unexamined names and symlink targets
  cannot establish an empty root set or the absence of other roots.
+  A dependency symlink whose target is not valid UTF-8 is undetermined, with
+  its stored target bytes in the limitation and partial coverage; a selected
+  root crossing such a symlink is refused with the same bytes in its diagnostic.
 - `inspect_asset_catalog` / `rea inspect-asset-catalog <app>` reads compiled
  `Assets.car` metadata through macOS `assetutil --info`. Catalog digests, raw
  rendition fields, pagination and exact UI resource-name matches are returned.
@@ -739,6 +848,11 @@ complete observation.
  files and universal slices before metadata decoding. CPU subtypes and
  capability bits remain source facts; an `arm64` request may select an
  `arm64e` image under the existing slice preference policy.
+  Objective-C class, protocol and category lists require eight-byte entries;
+  Swift type and conformance sections require four-byte entries. Misaligned
+  section lengths and unsupported non-PowerPC big-endian CPU declarations return
+  `unsupported_target` with the selected path and precise reason. Recovery
+  selects a well-formed or supported artifact and reopens that target.
  The byte reader holds the whole selected file in memory, so it admits files up
  to 64 MiB / 67108864 bytes by default. Select a larger budget with
  `max_input_bytes` (CLI `--max-input-bytes`), at most 1 GiB / 1073741824
@@ -833,7 +947,11 @@ complete observation.
  and `__objc_catlist` categories are also decoded. Categories record the
  extended class, local or external, plus
  their methods, protocols and properties; category methods appear as
-  implementations with a `category`. Swift field-offset globals that are only
+  implementations with a `category`. A category whose class reference is null,
+  or is bound to a symbol other than `_OBJC_CLASS_$_`, such as the `_$s…CN`
+  metadata symbol of another module's Swift class, keeps a null class, and
+  `objc_properties_categories` coverage names that reference. Swift
+  field-offset globals that are only
  initialized at runtime stay unresolved. Generic, resilient, async and
  coroutine tables, and inherited overrides, have explicit unsupported or
  partial coverage. Other providers retain the
@@ -1030,11 +1148,55 @@ unpaired Unicode surrogate; a rejection identifies the field and UTF-16 index
 and leaves every annotation unchanged. CRLF, supplementary Unicode characters,
 and combining characters are preserved. Windows P0 remains read-only. Ghidra has no
 GUI authority, and REA never falls back automatically to Hopper.
+For a before-and-after `compare_functions` in MCP, call `analyze_function`
+before and after the edit while the session remains open; the annotation Evidence
+itself is not an `analyze_function` input. If comparing after close, export the
+needed Evidence before closing and import it into the later session. A one-shot
+CLI annotation returns its edited dossier before its temporary session is
+discarded; a later CLI invocation with the same fresh-import settings starts from
+the original executable. Comparison preserves correspondence across renames
+when authenticated artifact identity, architecture and provider-owned mapping
+and slice commitments establish the same canonical entry. The result reports
+`matched`, `method: "same-entry"` and `entry_address`; name and exact-text changes
+remain separate dimensions. Equal numeric addresses without applicable coordinate
+commitments do not establish same-entry correspondence. Inspect the retained
+source Evidence and coverage when correspondence remains ambiguous.
+To aggregate already-retained comparison results, pass their exact IDs to
+`find_changed_behavior`, for example:
+
+```javascript
+await call("find_changed_behavior", {
+  comparisons: comparisons.map(({ evidence_id }) => ({
+    kind: "retained-evidence",
+    evidence_id,
+  })),
+});
+```
+
+These IDs select comparison Evidence, not function dossiers or summary views.
+Complete inline comparisons remain accepted and can be mixed with references.
+The current server must retain the comparisons and their original source closure;
+import the complete source bundle after a session handoff. Missing or damaged
+records are explicit failures. A missing required retained record reports its exact
+`evidence_id` with `details.reference_scope: "retained-closure"`. Import the
+originating bundle with its linked sources, or re-create those observations in the
+current investigation, before retrying; resending the inline comparison alone
+does not restore its closure. Aggregating static differences does not establish
+observed runtime change.
+
 `set_address_name` and `set_addresses_names` give Ghidra sessions the same
 compact naming results as Hopper: a local function entry renames that function,
 and any other mapped address, such as a global, receives a new or renamed primary
-label. A batch applies each address separately and reports one success boolean
-per address. Use them to name many globals and helpers cheaply; use
+label. A batch decides every address from the names held before it: addresses
+that request the same name in one namespace, or a name another selected address
+holds, are rejected without applying them, so JSON member order never selects a
+winner. Every other address applies separately, and each address reports one
+success boolean. `raw_result.failures` gives each failed address's canonical
+address and reason. A contested name appears once in `raw_result.conflicts`,
+with its namespace, requesting addresses and holding addresses, and conflict
+failures refer to it by index. To move a label between
+addresses, rename its holder first and assign the name in a later call. Use
+them to name many globals and helpers cheaply; use
 `annotate_native_function` when you also want comments and a refreshed dossier.
 Ghidra name edits preserve the existing namespace. Supply either a leaf name
 such as `renamed` or a fully qualified name in that namespace, such as
@@ -106,6 +106,17 @@ URI leaves coverage partial. The HTTP URI profile covers HTTP/1 and HTTP/2;
 HTTP/3 URI semantics are unexamined. All admitted URI fields share the same
 credential exclusion and source-value retention rules.
 Counts preserve distinct observed source URIs before omission or coalescing.
+
+Failed capture-summary TShark commands apply the same HTTP URI policy to
+retained JSON diagnostics, including cancellation, output-limit and cleanup
+failures. JSON spelling outside the excluded credential spans is preserved.
+An unfinished or malformed JSON token and its following suffix are withheld,
+with `captured_output.truncated: true`; complete preceding fields remain
+available. Diagnostic byte counts and output allowances describe original
+producer input, before credential exclusion. Caller-selected packet-field tools
+continue to return their selected recorded values.
+Origin-form request targets and HTTP/2 `:path` values retain path semantics,
+including leading double slashes and userinfo-like text within the path.
 `coverage: "partial"` records unresolved DNS attribution or URI item loss;
 component credential exclusion is also counted explicitly. Diagnostics retain
 both tool stderr streams. Recorded fields do not establish decrypted payloads,
@@ -40,6 +40,12 @@ signer identifier facts. A signer identified by subject key identifier reports
 that value as `subject_key_identifier_hex`. Other certificate types keep
 `pkcs7` null.

+Each signer reports `unsigned_attribute_oids`: null means the field was absent,
+and an array lists the types when present. Older retained Evidence may omit the
+field. Unsigned attribute contents, including nested signatures and timestamp
+tokens, are not decoded; their presence makes coverage partial and adds a
+limitation. Certificate and signer counts refer to the outer SignedData.
+
 A missing table is observed absence of that directory. It is not proof the
 image is unsigned in every catalog or overlay sense.

@@ -54,7 +60,11 @@ fails the same way. SignedData must contain at least one `SignerInfo`, and
 each `SignerInfo` must carry a non-empty signature value. Each embedded X.509
 certificate must include `subjectPublicKeyInfo` and `signatureValue`. Decoded
 certificate name text, serials, validity spellings, and subject key identifiers
-share a 64 KiB budget per PKCS#7 payload. Unsupported certificate name
+share a 64 KiB budget per PKCS#7 payload, and each payload decodes at most
+16,384 ASN.1 values. Exhausting either fixed allowance returns a nonretryable
+`resource_constraint` error naming it, not an invalid-input error; this release
+has no runtime override, and `max_file_bytes` and `max_entries` do not raise
+it. Unsupported certificate name
 encodings, including GeneralString, fail explicitly. TeletexString (T.61)
 values are rendered with the ISO-8859-1 compatibility mapping used by OpenSSL;
 this is not a full T.61 decoder, so the result includes a limitation whenever
@@ -257,7 +257,9 @@ A bare executable name uses the scenario's `PATH` override, then the inherited
 An explicitly empty `PATH` searches only the working directory. Executable,
 working-directory, and observation paths preserve native `symlink/..` traversal.

-Terminal dimensions must satisfy `columns × (rows + scrollback) ≤ 1,000,000`.
+Terminal width must be at least two columns: the pinned xterm renderer cannot
+represent a one-column screen. This applies to the initial size and every resize.
+Terminal dimensions must also satisfy `columns × (rows + scrollback) ≤ 1,000,000`.
 Every scheduled resize uses the same selected scrollback and must fit this
 working-buffer budget. REA rejects oversized scenarios before launching the
 command; it never clamps the requested dimensions. This limit is independent
@@ -353,9 +355,12 @@ recapture both sides with the same observation version before comparison.
 When path normalization is enabled, aliases apply to selected path identities
 at clear text delimiters. A selected executable path does not alias a longer
 sibling filename such as `tool-helper`; selected parent directories still
-normalize within descendant paths. The comparison contract records these rules as
-`path-component-boundaries-v2`, so captures made with the earlier prefix rules
-cannot be compared as if the text had the same meaning.
+normalize within descendant paths, including when the working directory or an
+observation path is spelled with a trailing `/` or `/.`. A selected filesystem
+root `/` also aliases descendant paths, without rewriting URL separators or
+HTML closing tags. The comparison contract
+records these rules as `path-component-boundaries-v3`, so captures made with the
+earlier rules cannot be compared as if the text had the same meaning.

 Rendered frame `lines` hold the visible rows after normalization, with trailing
 U+0020 spaces removed. Blank rows and internal spaces remain. `columns` records
@@ -10,24 +10,28 @@ inferred from a `.bin` suffix or from unrecognized bytes.
 ## Open and inspect

 ```bash
-rea inspect /absolute/path/to/ecu.bin --target-format raw-binary --architecture arm --entry-point 0x8000000 --provider ghidra --json
-rea function /absolute/path/to/ecu.bin 0x8000000 --target-format raw-binary --architecture arm --entry-point 0x8000000 --provider ghidra --json
-rea inspect-native-load-image /absolute/path/to/ecu.bin --target-format raw-binary --architecture arm --entry-point 0x8000000 --provider ghidra --json
+rea inspect /absolute/path/to/kernel.img --target-format raw-binary --architecture arm --entry-point 0x8000 --provider ghidra --json
+rea function /absolute/path/to/kernel.img 0x8000 --target-format raw-binary --architecture arm --entry-point 0x8000 --provider ghidra --json
+rea inspect-native-load-image /absolute/path/to/kernel.img --target-format raw-binary --architecture arm --entry-point 0x8000 --provider ghidra --json
 ```

 ```json
 {
  "name": "open_binary",
  "arguments": {
-    "path": "/absolute/path/to/ecu.bin",
+    "path": "/absolute/path/to/kernel.img",
    "format": "raw-binary",
    "architecture": "arm",
-    "entry_point": "0x8000000",
+    "entry_point": "0x8000",
    "provider_id": "ghidra"
  }
 }
 ```

+The example maps a 32-bit ARM-state image at `0x8000`. For `arm`, decoding
+starts at the entry in ARM (A32) state, so Thumb-only images, including Cortex-M
+firmware, are not supported. See [Limitations](#limitations).
+
 `architecture` is one of `x86`, `x86_64`, `arm`, `arm64`, `6502`, or `m68k`. `entry_point` is a
 hexadecimal address of the form `0x…`. The complete file is mapped starting at
 that address, and Ghidra seeds an `entry` function there before auto-analysis.
@@ -60,7 +60,7 @@

 يربط REA وكيلك بأدوات لفحص الملفات الثنائية للشيفرة الأصلية، وتطبيقات JavaScript وElectron، وتجميعات .NET، والمواقع. يمكنك أيضًا استخدام الأدوات نفسها من الطرفية. يجري التحليل محليًا، وتتضمن النتائج الأدلة والقيود التي تستند إليها كل خلاصة.

-يسجّل الإعداد REA لدى وكيلك ويثبّت تعليمات العمل المطابقة. يمكن للتحليل الأصلي استخدام Hopper أو Ghidra أو IDA المثبّت مسبقًا؛ ويمكن تثبيت Hopper بعد موافقتك. لا يحتاج التحليل الثابت لـ JavaScript إلى محرك تحليل أصلي.
+يسجّل الإعداد REA لدى وكيلك ويثبّت تعليمات العمل المطابقة. يمكن للتحليل الأصلي استخدام Hopper أو Ghidra أو IDA أو Kuna المثبّت مسبقًا؛ ويمكن تثبيت Hopper بعد موافقتك. لا يحتاج التحليل الثابت لـ JavaScript إلى محرك تحليل أصلي.

 > **[زر موقع REA](https://rea.tools/ar/)** للاطلاع على تعليمات الإعداد والأدلة المصوّرة ودراسات الحالة الفعلية.

@@ -151,7 +151,7 @@ npx rea-agents@latest setup

 | الهدف                           | ما يعيده REA                                                                                               | المتطلبات والدليل                                                                                                                    |
 | ------------------------------- | ---------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
-| الملفات الثنائية للشيفرة الأصلية | شيفرة شبه برمجية، وتعليمات تجميع، وسلاسل نصية، ورموز، واستدعاءات، ومراجع                                    | Hopper أو Ghidra أو IDA؛ [تحليل الشيفرة الأصلية](../native-investigation.md)                                                          |
+| الملفات الثنائية للشيفرة الأصلية | شيفرة شبه برمجية، وتعليمات تجميع، وسلاسل نصية، ورموز، واستدعاءات، ومراجع                                    | Hopper أو Ghidra أو IDA أو Kuna؛ [تحليل الشيفرة الأصلية](../native-investigation.md)                                                  |
 | بنية ELF دون تشغيل              | الأقسام والمقاطع والرموز ومعلومات إعادة التموضع الأصلية، وآليات الحماية المحتملة المستدلّ عليها بالفحص الثابت | pwntools يوفّره المستدعي على Linux x64؛ [تشخيص الملفات الثنائية](../binary-diagnostics.md)                                            |
 | PE certificates                 | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields                               | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                              |
 | PE imports                      | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash                                 | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                        |
@@ -280,9 +280,9 @@ agent-env run ./my-env
 </details>

 <details>
-<summary><strong>هل أحتاج إلى Hopper أو Ghidra أو IDA؟</strong></summary>
+<summary><strong>هل أحتاج إلى Hopper أو Ghidra أو IDA أو Kuna؟</strong></summary>

-يستخدم تحليل الشيفرة الأصلية المتعمق أحدها. يعمل الفحص الثابت لـ JavaScript و.NET دون محرك لتحليل الشيفرة الأصلية. يستطيع الإعداد تثبيت Hopper بعد الموافقة؛ أما Ghidra وIDA فيستخدمان تثبيتاتك الموجودة. راجع [إعداد الموفّرين](../installation.md#hopper).
+يستخدم تحليل الشيفرة الأصلية المتعمق أحدها. يعمل الفحص الثابت لـ JavaScript و.NET دون محرك لتحليل الشيفرة الأصلية. يستطيع الإعداد تثبيت Hopper بعد الموافقة؛ أما Ghidra وIDA وKuna فتستخدم تثبيتاتك الموجودة. راجع [إعداد الموفّرين](../installation.md#hopper).

 </details>

@@ -20,7 +20,7 @@

 **[Website](https://rea.tools/de/) · [Anleitungen](https://rea.tools/de/guides/) · [Fallstudien](https://rea.tools/de/showcase/)**

-[Schnellstart](#schnellstart) · [So funktioniert REA](#so-funktioniert-rea) · [Was du analysieren kannst](#was-du-analysieren-kannst) · [Fallstudien](#fallstudien) · [RL-Umgebungen erstellen](#build-rl-environments) · [Häufige Fragen](#häufige-fragen) · [GNU-objdump- und Rizin-Tools](../reverse-engineering-tools.md) · [Dokumentation](#dokumentation)
+[Schnellstart](#schnellstart) · [So funktioniert REA](#so-funktioniert-rea) · [Was du analysieren kannst](#was-du-analysieren-kannst) · [Fallstudien](#fallstudien) · [RL-Umgebungen erstellen](#build-rl-environments) · [Häufige Fragen](#häufige-fragen) · [Dokumentation](#dokumentation)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@ Du hast in einer App eine Funktion entdeckt, die du in dein eigenes Produkt übe

 REA verbindet deinen Agenten mit Werkzeugen zum Untersuchen nativer Binärdateien, von JavaScript- und Electron-Apps, .NET-Assemblies und Websites. Dieselben Werkzeuge kannst du auch im Terminal nutzen. Die Analyse läuft lokal; die Ergebnisse enthalten die Belege und Einschränkungen hinter jeder Schlussfolgerung.

-Die Einrichtung registriert REA bei deinem Agenten und installiert passende Workflow-Anweisungen. Native Analysen nutzen eine vorhandene Installation von Hopper, Ghidra oder IDA; nach Zustimmung kann die Einrichtung Hopper installieren. Statische JavaScript-Analysen benötigen keine native Analyse-Engine.
+Die Einrichtung registriert REA bei deinem Agenten und installiert passende Workflow-Anweisungen. Native Analysen nutzen eine vorhandene Installation von Hopper, Ghidra, IDA oder Kuna; nach Zustimmung kann die Einrichtung Hopper installieren. Statische JavaScript-Analysen benötigen keine native Analyse-Engine.

 > **[Besuche die REA-Website](https://rea.tools/de/)** für Einrichtungshinweise, bebilderte Anleitungen und echte Fallstudien.

@@ -151,7 +151,7 @@ REA benötigt Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) oder 26+ (>=26.12.1) so

 | Ziel                                | Was REA zurückgibt                                                                                              | Voraussetzungen und Anleitung                                                                                                                                        |
 | ----------------------------------- | --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Native Binärdateien                 | Pseudocode, Assemblercode, Zeichenketten, Symbole, Aufrufe und Verweise                                         | Hopper, Ghidra oder IDA; [native Analyse](../native-investigation.md)                                                                                                |
+| Native Binärdateien                 | Pseudocode, Assemblercode, Zeichenketten, Symbole, Aufrufe und Verweise                                         | Hopper, Ghidra, IDA oder Kuna; [native Analyse](../native-investigation.md)                                                                                          |
 | Offline-ELF-Struktur                | Sektionen, Segmente, ursprüngliche Symbole/Relokationen und mögliche Schutzmaßnahmen aus statischer Analyse     | Vom Aufrufer bereitgestelltes pwntools unter Linux x64; [Binärdiagnostik](../binary-diagnostics.md)                                                                  |
 | PE certificates                     | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields                                    | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                                                              |
 | PE imports                          | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash                                      | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                                                        |
@@ -190,6 +190,8 @@ REA benötigt Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) oder 26+ (>=26.12.1) so

 Statische JavaScript- und .NET-Untersuchungen lesen die bereitgestellten Dateien, ohne die Anwendung auszuführen. Laufzeitaufzeichnungen führen das gewählte Ziel mit deinen Benutzerrechten aus oder interagieren damit; die jeweiligen Anleitungen beschreiben die Auswirkungen.

+Für die Offline-Untersuchung nativer Binärdateien unterstützt REA auch GNU objdump und Rizin, die du selbst bereitstellst. Der [Leitfaden zu Reverse-Engineering-Tools](../reverse-engineering-tools.md) beschreibt die Einrichtung der Provider, CLI-Befehle und Einschränkungen der Evidence. REA installiert oder aktualisiert keinen der beiden Provider.
+
 <a id="choosing-a-deep-analysis-provider"></a>

 Bei großen Binärdateien kannst du die Startfrist mit `REA_GHIDRA_STARTUP_TIMEOUT_MS` oder `REA_HOPPER_STARTUP_TIMEOUT_MS` erhöhen.
@@ -278,9 +280,9 @@ Jeder Agent, der lokale MCP-Server unterstützt. Die Einrichtung konfiguriert di
 </details>

 <details>
-<summary><strong>Brauche ich Hopper, Ghidra oder IDA?</strong></summary>
+<summary><strong>Brauche ich Hopper, Ghidra, IDA oder Kuna?</strong></summary>

-Für tiefgehende native Analysen wird eines dieser Programme verwendet. Statische JavaScript- und .NET-Untersuchungen funktionieren ohne native Analyse-Engine. Die Einrichtung kann Hopper nach Zustimmung installieren; Ghidra und IDA nutzen deine vorhandenen Installationen. Siehe [Provider-Einrichtung](../installation.md#hopper).
+Für tiefgehende native Analysen wird eines dieser Programme verwendet. Statische JavaScript- und .NET-Untersuchungen funktionieren ohne native Analyse-Engine. Die Einrichtung kann Hopper nach Zustimmung installieren; Ghidra, IDA und Kuna nutzen deine vorhandenen Installationen. Siehe [Provider-Einrichtung](../installation.md#hopper).

 </details>

@@ -62,7 +62,7 @@

 Το REA συνδέει τον πράκτορά σου με εργαλεία εξέτασης δυαδικών αρχείων με κώδικα μηχανής, εφαρμογών JavaScript και Electron, assemblies .NET και ιστοτόπων. Μπορείς να χρησιμοποιήσεις τα ίδια εργαλεία και από το τερματικό. Η ανάλυση εκτελείται τοπικά και τα αποτελέσματα περιλαμβάνουν τα τεκμήρια και τους περιορισμούς στους οποίους βασίζεται κάθε συμπέρασμα.

-Η διαδικασία εγκατάστασης καταχωρίζει το REA στον agent σου και εγκαθιστά τις αντίστοιχες οδηγίες εργασίας. Για ανάλυση κώδικα μηχανής μπορείς να χρησιμοποιήσεις μια υπάρχουσα εγκατάσταση του Hopper, του Ghidra ή του IDA. Η διαδικασία εγκατάστασης μπορεί επίσης να εγκαταστήσει το Hopper, εφόσον το εγκρίνεις. Η στατική ανάλυση JavaScript δεν χρειάζεται μηχανή ανάλυσης κώδικα μηχανής.
+Η διαδικασία εγκατάστασης καταχωρίζει το REA στον agent σου και εγκαθιστά τις αντίστοιχες οδηγίες εργασίας. Για ανάλυση κώδικα μηχανής μπορείς να χρησιμοποιήσεις μια υπάρχουσα εγκατάσταση του Hopper, του Ghidra, του IDA ή του Kuna. Η διαδικασία εγκατάστασης μπορεί επίσης να εγκαταστήσει το Hopper, εφόσον το εγκρίνεις. Η στατική ανάλυση JavaScript δεν χρειάζεται μηχανή ανάλυσης κώδικα μηχανής.

 > **[Επισκέψου τον ιστότοπο του REA](https://rea.tools/)** για οδηγίες εγκατάστασης, εικονογραφημένους οδηγούς και πραγματικές μελέτες περίπτωσης.

@@ -151,7 +151,7 @@ npx rea-agents@latest setup

 | Στόχος                                 | Τι επιστρέφει το REA                                                                                                        | Απαιτήσεις και οδηγός                                                                                                               |
 | -------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------- |
-| Δυαδικά αρχεία με κώδικα μηχανής       | Ψευδοκώδικα, κώδικα assembly, συμβολοσειρές, σύμβολα, κλήσεις και αναφορές                                                  | Hopper, Ghidra ή IDA· [ανάλυση κώδικα μηχανής](../native-investigation.md)                                                          |
+| Δυαδικά αρχεία με κώδικα μηχανής       | Ψευδοκώδικα, κώδικα assembly, συμβολοσειρές, σύμβολα, κλήσεις και αναφορές                                                  | Hopper, Ghidra, IDA ή Kuna· [ανάλυση κώδικα μηχανής](../native-investigation.md)                                                    |
 | Δομή ELF χωρίς εκτέλεση                | Ενότητες, τμήματα, αρχικά σύμβολα/εγγραφές μετεγκατάστασης και ενδείξεις πιθανών μέτρων προστασίας από στατική ανάλυση      | pwntools που παρέχει ο χρήστης σε Linux x64· [διαγνωστικά δυαδικών αρχείων](../binary-diagnostics.md)                               |
 | Δυαδικά αρχεία Go                      | Ενσωματωμένη έκδοση μεταγλωττιστή, modules, αντικαταστάσεις και ρυθμίσεις μεταγλώττισης                                     | Ενσωματωμένη στατική εξέταση ELF/PE/thin Mach-O· δεν απαιτείται εγκατάσταση του Go                                                  |
 | Δυαδικά αρχεία Rust                    | Ενσωματωμένα ονόματα, εκδόσεις, πηγές και σχέσεις εξάρτησης των crates από το cargo-auditable                               | Ενσωματωμένη στατική εξέταση ELF/PE/thin Mach-O· [δυαδικά αρχεία Rust](../rust-binaries.md)                                         |
@@ -282,9 +282,9 @@ agent-env run ./my-env
 </details>

 <details>
-<summary><strong>Χρειάζομαι Hopper, Ghidra ή IDA;</strong></summary>
+<summary><strong>Χρειάζομαι Hopper, Ghidra, IDA ή Kuna;</strong></summary>

-Η εις βάθος ανάλυση κώδικα μηχανής χρησιμοποιεί ένα από αυτά. Η στατική εξέταση JavaScript και .NET λειτουργεί χωρίς μηχανή ανάλυσης κώδικα μηχανής. Η διαδικασία εγκατάστασης μπορεί να εγκαταστήσει το Hopper μετά την έγκρισή σου· το Ghidra και το IDA χρησιμοποιούν τις υπάρχουσες εγκαταστάσεις σου. Δες τη [ρύθμιση παρόχων ανάλυσης](../installation.md#hopper).
+Η εις βάθος ανάλυση κώδικα μηχανής χρησιμοποιεί ένα από αυτά. Η στατική εξέταση JavaScript και .NET λειτουργεί χωρίς μηχανή ανάλυσης κώδικα μηχανής. Η διαδικασία εγκατάστασης μπορεί να εγκαταστήσει το Hopper μετά την έγκρισή σου· το Ghidra, το IDA και το Kuna χρησιμοποιούν τις υπάρχουσες εγκαταστάσεις σου. Δες τη [ρύθμιση παρόχων ανάλυσης](../installation.md#hopper).

 </details>

@@ -20,7 +20,7 @@

 **[Sitio web](https://rea.tools/es/) · [Guías](https://rea.tools/es/guides/) · [Casos prácticos](https://rea.tools/es/showcase/)**

-[Inicio rápido](#inicio-rápido) · [Cómo funciona REA](#cómo-funciona-rea) · [Qué puedes analizar](#qué-puedes-analizar) · [Casos prácticos](#casos-prácticos) · [Crear entornos de RL](#build-rl-environments) · [Preguntas frecuentes](#preguntas-frecuentes) · [Herramientas GNU objdump y Rizin](../reverse-engineering-tools.md) · [Documentación](#documentación)
+[Inicio rápido](#inicio-rápido) · [Cómo funciona REA](#cómo-funciona-rea) · [Qué puedes analizar](#qué-puedes-analizar) · [Casos prácticos](#casos-prácticos) · [Crear entornos de RL](#build-rl-environments) · [Preguntas frecuentes](#preguntas-frecuentes) · [Documentación](#documentación)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@

 REA conecta tu agente con herramientas para inspeccionar binarios nativos, aplicaciones JavaScript y Electron, ensamblados .NET y sitios web. También puedes usar las mismas herramientas desde la terminal. El análisis se ejecuta localmente y los resultados incluyen las pruebas y limitaciones que sustentan cada conclusión.

-La configuración registra REA con tu agente e instala las instrucciones de trabajo correspondientes. El análisis nativo puede usar Hopper, Ghidra o IDA ya instalados; la configuración puede instalar Hopper con tu aprobación. El análisis estático de JavaScript no requiere un motor de análisis nativo.
+La configuración registra REA con tu agente e instala las instrucciones de trabajo correspondientes. El análisis nativo puede usar Hopper, Ghidra, IDA o Kuna ya instalados; la configuración puede instalar Hopper con tu aprobación. El análisis estático de JavaScript no requiere un motor de análisis nativo.

 > **[Visita el sitio web de REA](https://rea.tools/es/)** para encontrar instrucciones de configuración, guías ilustradas y casos reales.

@@ -151,7 +151,7 @@ REA requiere Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) o 26+ (>=26.12.1), adem

 | Objetivo                    | Qué devuelve REA                                                                                                               | Requisitos y guía                                                                                                                            |
 | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------- |
-| Binarios nativos            | Pseudocódigo, ensamblador, cadenas, símbolos, llamadas y referencias                                                           | Hopper, Ghidra o IDA; [análisis nativo](../native-investigation.md)                                                                          |
+| Binarios nativos            | Pseudocódigo, ensamblador, cadenas, símbolos, llamadas y referencias                                                           | Hopper, Ghidra, IDA o Kuna; [análisis nativo](../native-investigation.md)                                                                    |
 | Estructura ELF sin ejecutar | Secciones, segmentos, símbolos/reubicaciones originales y posibles medidas de mitigación detectadas mediante análisis estático | pwntools proporcionado por quien llama, en Linux x64; [diagnóstico de binarios](../binary-diagnostics.md)                                    |
 | PE certificates             | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields                                                   | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                                      |
 | PE imports                  | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash                                                     | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                                |
@@ -190,6 +190,8 @@ REA requiere Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) o 26+ (>=26.12.1), adem

 La inspección estática de JavaScript y .NET lee los archivos suministrados sin ejecutar la aplicación. La captura en ejecución inicia el objetivo seleccionado o interactúa con él con los permisos de tu usuario; cada guía describe sus efectos.

+Para inspeccionar binarios nativos sin conexión, REA también admite GNU objdump y Rizin, que debes proporcionar por tu cuenta. La [guía de herramientas de ingeniería inversa](../reverse-engineering-tools.md) explica la configuración de los proveedores, los comandos de la CLI y las limitaciones de Evidence. REA no instala ni actualiza ninguno de estos proveedores.
+
 <a id="choosing-a-deep-analysis-provider"></a>

 Para binarios grandes, aumenta el plazo de inicio mediante `REA_GHIDRA_STARTUP_TIMEOUT_MS` o `REA_HOPPER_STARTUP_TIMEOUT_MS`.
@@ -278,9 +280,9 @@ Cualquier agente que admita servidores MCP locales. La configuración prepara lo
 </details>

 <details>
-<summary><strong>¿Necesito Hopper, Ghidra o IDA?</strong></summary>
+<summary><strong>¿Necesito Hopper, Ghidra, IDA o Kuna?</strong></summary>

-El análisis nativo en profundidad utiliza uno de ellos. La inspección estática de JavaScript y .NET funciona sin un motor de análisis nativo. La configuración puede instalar Hopper después de tu aprobación; Ghidra e IDA usan las instalaciones que ya tienes. Consulta [configuración de proveedores](../installation.md#hopper).
+El análisis nativo en profundidad utiliza uno de ellos. La inspección estática de JavaScript y .NET funciona sin un motor de análisis nativo. La configuración puede instalar Hopper después de tu aprobación; Ghidra, IDA y Kuna usan las instalaciones que ya tienes. Consulta [configuración de proveedores](../installation.md#hopper).

 </details>

@@ -20,7 +20,7 @@

 **[وب‌سایت](https://rea.tools/fa/) · [راهنماها](https://rea.tools/fa/guides/) · [نمونه‌های عملی](https://rea.tools/fa/showcase/)**

-[شروع سریع](#شروع-سریع) · [REA چگونه کار می‌کند؟](#rea-چگونه-کار-می‌کند) · [چه چیزهایی را میتوان تحلیل کرد؟](#چه-چیزهایی-را-می‌توان-تحلیل-کرد) · [نمونه‌های عملی](#نمونه‌های-عملی) · [ساخت محیط‌های RL](#build-rl-environments) · [پرسش‌های متداول](#پرسش‌های-متداول) · [ابزارهای GNU objdump و Rizin](../reverse-engineering-tools.md) · [مستندات](#مستندات)
+[شروع سریع](#شروع-سریع) · [REA چگونه کار می‌کند؟](#rea-چگونه-کار-می‌کند) · [چه چیزهایی را میتوان تحلیل کرد؟](#چه-چیزهایی-را-می‌توان-تحلیل-کرد) · [نمونه‌های عملی](#نمونه‌های-عملی) · [ساخت محیط‌های RL](#build-rl-environments) · [پرسش‌های متداول](#پرسش‌های-متداول) · [مستندات](#مستندات)

 <code>npx rea-agents setup</code>

@@ -52,7 +52,7 @@

 REA ایجنت شما را به ابزارهایی برای بررسی باینری‌های بومی، برنامه‌های JavaScript و Electron، اسمبلی‌های .NET و وب‌سایت‌ها متصل می‌کند. همین ابزارها از ترمینال نیز قابل استفاده‌اند. تحلیل به‌صورت محلی انجام می‌شود و نتایج شامل شواهد و محدودیت‌های پشت هر نتیجه‌گیری هستند.

-راه‌اندازی، REA را در ایجنت ثبت و دستورالعمل‌های متناظر را نصب می‌کند. تحلیل بومی می‌تواند از Hopper، Ghidra یا IDA موجود استفاده کند؛ نصب Hopper پس از تأیید شما ممکن است. تحلیل ایستای JavaScript به موتور تحلیل بومی نیاز ندارد.
+راه‌اندازی، REA را در ایجنت ثبت و دستورالعمل‌های متناظر را نصب می‌کند. تحلیل بومی می‌تواند از Hopper، Ghidra، IDA یا Kuna موجود استفاده کند؛ نصب Hopper پس از تأیید شما ممکن است. تحلیل ایستای JavaScript به موتور تحلیل بومی نیاز ندارد.

 > برای دستورالعمل‌های راه‌اندازی، راهنماهای تصویری و مطالعات موردی واقعی، **[به وب‌سایت REA مراجعه کنید](https://rea.tools/fa/)**.

@@ -143,7 +143,7 @@ REA به Node.js 22.x (>=22.23.4)، 24.x (>=24.22.1) یا 26+ (>=26.12.1)، به

 | هدف                    | خروجی REA                                                                           | پیش‌نیازها و راهنما                                                                                                                |
 | ---------------------- | ----------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
-| باینری‌های بومی         | شبه‌کد، اسمبلی، رشته‌ها، نمادها، فراخوانی‌ها و ارجاعات                                 | Hopper، Ghidra یا IDA؛ [تحلیل بومی](../native-investigation.md)                                                                   |
+| باینری‌های بومی         | شبه‌کد، اسمبلی، رشته‌ها، نمادها، فراخوانی‌ها و ارجاعات                                 | Hopper، Ghidra، IDA یا Kuna؛ [تحلیل بومی](../native-investigation.md)                                                             |
 | ساختار ELF آفلاین       | بخش‌ها، سگمنت‌ها، نمادها و relocationهای اصلی و گزینه‌های احتمالی کاهش آسیب‌پذیری ایستا | pwntools تأمین‌شده توسط فراخواننده روی Linux x64؛ [تشخیص باینری](../binary-diagnostics.md)                                         |
 | PE certificates        | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields        | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                           |
 | PE imports             | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash          | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                     |
@@ -182,6 +182,8 @@ REA به Node.js 22.x (>=22.23.4)، 24.x (>=24.22.1) یا 26+ (>=26.12.1)، به

 بررسی ایستای JavaScript و .NET فایل‌های ارائه‌شده را بدون اجرای برنامه می‌خواند. ضبط زمان اجرا، هدف انتخاب‌شده را با مجوزهای کاربری شما اجرا می‌کند یا با آن تعامل دارد؛ آثار این عملیات در راهنمای مربوط به هر نوع ضبط توضیح داده شده‌اند.

+برای بررسی آفلاین فایل‌های باینری بومی، REA از GNU objdump و Rizin نیز پشتیبانی می‌کند؛ این ابزارها را باید خودتان فراهم کنید. [راهنمای ابزارهای مهندسی معکوس](../reverse-engineering-tools.md) تنظیم ارائه‌دهندگان، فرمان‌های CLI و محدودیت‌های Evidence را توضیح می‌دهد. REA هیچ‌یک از این دو ارائه‌دهنده را نصب یا به‌روزرسانی نمی‌کند.
+
 <a id="choosing-a-deep-analysis-provider"></a>

 برای باینری‌های بزرگ، مهلت شروع را با `REA_GHIDRA_STARTUP_TIMEOUT_MS` یا `REA_HOPPER_STARTUP_TIMEOUT_MS` افزایش دهید.
@@ -268,9 +270,9 @@ REA محیطی آمادهٔ اجرا همراه با یک آزمون ساده ب

 </details>

-<details><summary><strong>آیا به Hopper، Ghidra یا IDA نیاز دارم؟</strong></summary>
+<details><summary><strong>آیا به Hopper، Ghidra، IDA یا Kuna نیاز دارم؟</strong></summary>

-تحلیل عمیق بومی به یکی از آن‌ها نیاز دارد. بررسی ایستای JavaScript و .NET بدون موتور تحلیل بومی کار می‌کند. setup می‌تواند با تأیید شما Hopper را نصب کند؛ Ghidra و IDA از نصب‌های موجود شما استفاده می‌کنند. [راه‌اندازی ارائه‌دهنده](../installation.md#hopper) را ببینید.
+تحلیل عمیق بومی به یکی از آن‌ها نیاز دارد. بررسی ایستای JavaScript و .NET بدون موتور تحلیل بومی کار می‌کند. setup می‌تواند با تأیید شما Hopper را نصب کند؛ Ghidra، IDA و Kuna از نصب‌های موجود شما استفاده می‌کنند. [راه‌اندازی ارائه‌دهنده](../installation.md#hopper) را ببینید.

 </details>

@@ -20,7 +20,7 @@

 **[Site web](https://rea.tools/fr/) · [Guides](https://rea.tools/fr/guides/) · [Études de cas](https://rea.tools/fr/showcase/)**

-[Démarrage rapide](#démarrage-rapide) · [Comment fonctionne REA](#comment-fonctionne-rea) · [Ce que vous pouvez analyser](#ce-que-vous-pouvez-analyser) · [Études de cas](#études-de-cas) · [Créer des environnements RL](#build-rl-environments) · [Questions fréquentes](#questions-fréquentes) · [Outils GNU objdump et Rizin](../reverse-engineering-tools.md) · [Documentation](#documentation)
+[Démarrage rapide](#démarrage-rapide) · [Comment fonctionne REA](#comment-fonctionne-rea) · [Ce que vous pouvez analyser](#ce-que-vous-pouvez-analyser) · [Études de cas](#études-de-cas) · [Créer des environnements RL](#build-rl-environments) · [Questions fréquentes](#questions-fréquentes) · [Documentation](#documentation)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@ Vous avez repéré dans une application une fonctionnalité que vous aimeriez av

 REA connecte votre agent à des outils d'inspection de binaires natifs, d'applications JavaScript et Electron, d'assemblys .NET et de sites web. Les mêmes outils sont aussi disponibles depuis votre terminal. L'analyse s'exécute localement, et chaque conclusion s'accompagne des preuves et des limites sur lesquelles elle repose.

-Setup enregistre REA auprès de votre agent et installe les instructions de workflow correspondantes. L'analyse native peut utiliser une installation existante de Hopper, de Ghidra ou d'IDA ; Setup peut aussi installer Hopper après votre accord. L'analyse statique JavaScript ne nécessite aucun moteur d'analyse natif.
+Setup enregistre REA auprès de votre agent et installe les instructions de workflow correspondantes. L'analyse native peut utiliser une installation existante de Hopper, de Ghidra, d'IDA ou de Kuna ; Setup peut aussi installer Hopper après votre accord. L'analyse statique JavaScript ne nécessite aucun moteur d'analyse natif.

 > **[Visitez le site web de REA](https://rea.tools/fr/)** pour les instructions d'installation, des guides illustrés et des études de cas réelles.

@@ -150,7 +150,7 @@ REA nécessite Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) ou 26+ (>=26.12.1), ai

 | Cible                        | Ce que REA renvoie                                                                                          | Prérequis et guide                                                                                                                        |
 | ---------------------------- | ----------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
-| Binaires natifs              | Pseudo-code, assembleur, chaînes, symboles, appels et références                                            | Hopper, Ghidra ou IDA ; [analyse native](../native-investigation.md)                                                                      |
+| Binaires natifs              | Pseudo-code, assembleur, chaînes, symboles, appels et références                                            | Hopper, Ghidra, IDA ou Kuna ; [analyse native](../native-investigation.md)                                                                |
 | Structure ELF hors ligne     | Sections, segments, symboles et relocations d'origine, et protections statiques candidates                  | pwntools fourni par l'utilisateur sous Linux x64 ; [diagnostics binaires](../binary-diagnostics.md)                                       |
 | PE certificates              | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields                                | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                                   |
 | PE imports                   | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash                                  | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                             |
@@ -189,6 +189,8 @@ REA nécessite Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) ou 26+ (>=26.12.1), ai

 L'inspection statique JavaScript et .NET lit les fichiers fournis sans exécuter l'application. La capture à l'exécution lance la cible choisie ou interagit avec elle avec vos permissions utilisateur ; chaque guide d'exécution décrit ses effets.

+Pour inspecter les binaires natifs hors ligne, REA prend aussi en charge GNU objdump et Rizin, que vous devez fournir vous-même. Le [guide des outils de rétro-ingénierie](../reverse-engineering-tools.md) décrit la configuration des fournisseurs, les commandes CLI et les limites des Evidence. REA n’installe ni ne met à jour ces deux fournisseurs.
+
 <a id="choosing-a-deep-analysis-provider"></a>

 Les formats natifs et les hôtes pris en charge varient selon le fournisseur. Consultez [la configuration de Hopper et Ghidra](../installation.md#hopper), le [guide IDA](../ida-provider.md), [Kuna](../kuna-provider.md) et [la prise en charge expérimentale de Ghidra sous Windows](../windows-ghidra-p0.md). Ghidra prend aussi en charge [l'analyse DOS 16 bits](../ghidra-dos.md). Pour les gros binaires, augmentez son délai de démarrage avec `REA_GHIDRA_STARTUP_TIMEOUT_MS` / `REA_HOPPER_STARTUP_TIMEOUT_MS`. Pour le choix du fournisseur, consultez le [guide CLI](../cli.md#choose-a-provider). Vérifiez la [disponibilité dans les versions publiées](../installation.md#released-package-and-main) pour les fonctionnalités ajoutées depuis la dernière version npm.
@@ -275,9 +277,9 @@ Tout agent compatible avec les serveurs MCP locaux. Setup configure les [agents
 </details>

 <details>
-<summary><strong>Ai-je besoin de Hopper, Ghidra ou IDA ?</strong></summary>
+<summary><strong>Ai-je besoin de Hopper, Ghidra, IDA ou Kuna ?</strong></summary>

-L'analyse native approfondie utilise l'un d'eux. L'inspection statique JavaScript et .NET fonctionne sans moteur d'analyse native. Setup peut installer Hopper après votre accord ; Ghidra et IDA utilisent vos installations existantes. Consultez [la configuration des fournisseurs](../installation.md#hopper).
+L'analyse native approfondie utilise l'un d'eux. L'inspection statique JavaScript et .NET fonctionne sans moteur d'analyse native. Setup peut installer Hopper après votre accord ; Ghidra, IDA et Kuna utilisent vos installations existantes. Consultez [la configuration des fournisseurs](../installation.md#hopper).

 </details>

@@ -20,7 +20,7 @@

 **[Situs Web](https://rea.tools/id/) · [Panduan](https://rea.tools/id/guides/) · [Contoh Penggunaan](https://rea.tools/id/showcase/)**

-[Mulai Cepat](#mulai-cepat) · [Cara Kerja REA](#cara-kerja-rea) · [Hal yang Dapat Anda Analisis](#hal-yang-dapat-anda-analisis) · [Contoh Penggunaan](#contoh-penggunaan) · [Membangun lingkungan RL](#build-rl-environments) · [FAQ](#faq) · [Alat GNU objdump dan Rizin](../reverse-engineering-tools.md) · [Dokumentasi](#dokumentasi)
+[Mulai Cepat](#mulai-cepat) · [Cara Kerja REA](#cara-kerja-rea) · [Hal yang Dapat Anda Analisis](#hal-yang-dapat-anda-analisis) · [Contoh Penggunaan](#contoh-penggunaan) · [Membangun lingkungan RL](#build-rl-environments) · [FAQ](#faq) · [Dokumentasi](#dokumentasi)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@ Melihat fitur dalam suatu aplikasi yang ingin Anda hadirkan di produk sendiri? M

 REA menghubungkan agen Anda dengan berbagai alat untuk memeriksa biner native, aplikasi JavaScript dan Electron, assembly .NET, serta situs web. Anda juga dapat menggunakan alat yang sama dari terminal. Analisis dijalankan secara lokal, dan hasilnya mencakup bukti serta keterbatasan yang mendasari setiap kesimpulan.

-Proses penyiapan mendaftarkan REA ke agen Anda dan memasang instruksi alur kerja yang sesuai. Analisis native dapat menggunakan instalasi Hopper, Ghidra, atau IDA yang sudah ada. Proses penyiapan juga dapat memasang Hopper secara opsional setelah mendapatkan persetujuan. Analisis JavaScript statis tidak memerlukan mesin analisis native.
+Proses penyiapan mendaftarkan REA ke agen Anda dan memasang instruksi alur kerja yang sesuai. Analisis native dapat menggunakan instalasi Hopper, Ghidra, IDA, atau Kuna yang sudah ada. Proses penyiapan juga dapat memasang Hopper secara opsional setelah mendapatkan persetujuan. Analisis JavaScript statis tidak memerlukan mesin analisis native.

 > **[Kunjungi situs web REA](https://rea.tools/id/)** untuk mendapatkan petunjuk penyiapan, panduan bergambar, dan studi kasus nyata.

@@ -153,18 +153,18 @@ Alat tambahan dan dukungan sistem host bergantung pada target yang dianalisis:

 | Target                     | Hasil yang diberikan REA                                                                              | Persyaratan dan panduan                                                                                                        |
 | -------------------------- | ----------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ |
-| Biner native               | Pseudocode, assembly, string, simbol, pemanggilan, dan referensi                                      | Hopper, Ghidra, atau IDA; [analisis native](../native-investigation.md)                                                        |
+| Biner native               | Pseudocode, assembly, string, simbol, pemanggilan, dan referensi                                      | Hopper, Ghidra, IDA, atau Kuna; [analisis native](../native-investigation.md)                                                  |
 | Tata letak ELF offline     | Bagian, segmen, simbol/relokasi asli, dan kandidat mitigasi statis                                    | pwntools yang disediakan pemanggil pada Linux x64; [diagnostik biner](../binary-diagnostics.md)                                |
 | PE certificates            | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields                          | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                        |
 | PE imports                 | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash                            | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                  |
 | Artefak WASM               | Validasi, bagian, bentuk WAT import/ekspor yang tepat, dan WAT yang didekode                          | WABT 1.0.42 yang disediakan pemanggil; `inspect_wasm_artifact`                                                                 |
-| Bytecode EVM               | Selector dispatch, offset byte, argumen yang disimpulkan, dan sifat mutabilitas                       | Pembawa data raw/hex lokal; [panduan EVM offline](../evm-bytecode.md)                                                          |
+| Bytecode EVM               | Selector dispatch, offset byte, argumen yang disimpulkan, dan sifat mutabilitas                       | Pembawa data raw/hex lokal di Linux x64; [panduan EVM offline](../evm-bytecode.md)                                             |
 | Rust binaries              | Embedded cargo-auditable dependency list                                                              | [Rust binaries](../rust-binaries.md)                                                                                           |
 | ELF notes                  | PT_NOTE/SHT_NOTE owners, types, GNU build-id and ABI-tag fields                                       | Built-in static ELF inspection; [ELF notes](../elf-notes.md)                                                                   |
 | Apple IPS crashes          | .ips metadata, threads, images, registers and crash classes                                           | Built-in static JSON inspection; [Apple IPS](../apple-ips.md)                                                                  |
 | Linux kernel modules       | .modinfo keys, __versions CRCs, this_module presence, and signature trailer                           | Built-in static ELF inspection; [kernel modules](../kernel-modules.md)                                                         |
 | Erlang BEAM                | IFF chunks, atoms, exports, and tables                                                                | Built-in static BEAM inspection; [Erlang BEAM](../erlang-beam.md)                                                              |
-| Crash Linux yang direkam   | Catatan mentah, register/sinyal setiap thread yang direkam, dan kandidat pemetaan opsional            | pwntools yang disediakan pemanggil; GDB/pwndbg opsional; [crash yang direkam](../recorded-crashes.md)                          |
+| Crash Linux yang direkam   | Catatan mentah, register/sinyal setiap thread yang direkam, dan kandidat pemetaan opsional            | pwntools yang disediakan pemanggil di Linux x64; GDB/pwndbg opsional; [crash yang direkam](../recorded-crashes.md)             |
 | Instalasi desktop          | Kandidat runtime, berkas pendukung, penanda komponen, dan langkah berikutnya                          | Pemeriksaan direktori dan header terbatas；[Aplikasi desktop](../desktop-applications.md)                                      |
 | JavaScript / Electron      | Modul, impor, source map, rute, IPC, dan hubungan add-on native                                       | Node.js dan npm; [analisis aplikasi](../javascript-application-workflows.md); Linux: procps `ps`                               |
 | Situs web                  | Struktur halaman, skrip, pengamatan jaringan, dan tangkapan layar yang diminta                        | Peramban berbasis Chrome; [analisis peramban](../browser-observation.md)                                                       |
@@ -192,6 +192,8 @@ Alat tambahan dan dukungan sistem host bergantung pada target yang dianalisis:

 Pemeriksaan JavaScript dan .NET statis membaca berkas yang disediakan tanpa menjalankan aplikasinya. Perekaman runtime menjalankan atau berinteraksi dengan target yang dipilih menggunakan izin pengguna Anda. Setiap panduan runtime menjelaskan dampaknya.

+Untuk pemeriksaan biner native secara offline, REA juga mendukung GNU objdump dan Rizin yang Anda sediakan sendiri. [Panduan alat rekayasa balik](../reverse-engineering-tools.md) menjelaskan penyiapan penyedia, perintah CLI, dan keterbatasan Evidence. REA tidak menginstal atau memperbarui kedua penyedia tersebut.
+
 <a id="choosing-a-deep-analysis-provider"></a>

 Format native dan dukungan sistem host berbeda-beda menurut penyedia. Lihat [penyiapan Hopper dan Ghidra](../installation.md#hopper), [panduan IDA](../ida-provider.md), [Kuna](../kuna-provider.md), dan [dukungan eksperimental Ghidra di Windows](../windows-ghidra-p0.md).
@@ -286,11 +288,11 @@ Agen apa pun yang mendukung server MCP lokal dapat menggunakan REA. Proses penyi
 </details>

 <details>
-<summary><strong>Apakah saya memerlukan Hopper, Ghidra, atau IDA?</strong></summary>
+<summary><strong>Apakah saya memerlukan Hopper, Ghidra, IDA, atau Kuna?</strong></summary>

-Analisis native mendalam menggunakan salah satu dari ketiganya. Pemeriksaan JavaScript dan .NET statis dapat dilakukan tanpa mesin analisis native.
+Analisis native mendalam menggunakan salah satu dari keempatnya. Pemeriksaan JavaScript dan .NET statis dapat dilakukan tanpa mesin analisis native.

-Proses penyiapan dapat memasang Hopper setelah memperoleh persetujuan. Ghidra dan IDA menggunakan instalasi yang sudah tersedia. Lihat [penyiapan penyedia](../installation.md#hopper).
+Proses penyiapan dapat memasang Hopper setelah memperoleh persetujuan. Ghidra, IDA, dan Kuna menggunakan instalasi yang sudah tersedia. Lihat [penyiapan penyedia](../installation.md#hopper).

 </details>

@@ -20,7 +20,7 @@

 **[Sito web](https://rea.tools/it/) · [Guide](https://rea.tools/it/guides/) · [Showcase](https://rea.tools/it/showcase/)**

-[Avvio rapido](#avvio-rapido) · [Come funziona REA](#come-funziona-rea) · [Cosa puoi analizzare](#cosa-puoi-analizzare) · [Showcase](#showcase) · [Creare ambienti RL](#build-rl-environments) · [FAQ](#faq) · [Strumenti GNU objdump e Rizin](../reverse-engineering-tools.md) · [Documentazione](#documentazione)
+[Avvio rapido](#avvio-rapido) · [Come funziona REA](#come-funziona-rea) · [Cosa puoi analizzare](#cosa-puoi-analizzare) · [Showcase](#showcase) · [Creare ambienti RL](#build-rl-environments) · [FAQ](#faq) · [Documentazione](#documentazione)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@ Hai visto una funzionalità in un'app che vorresti nel tuo prodotto? Chiedi al t

 REA collega il tuo agente a strumenti per ispezionare binari nativi, app JavaScript ed Electron, assembly .NET e siti web. Puoi usare gli stessi strumenti anche dal terminale. L'analisi viene eseguita localmente e i risultati includono le prove e i limiti dietro ogni conclusione.

-La configurazione registra REA con il tuo agente e installa le istruzioni di workflow corrispondenti. L'analisi nativa può usare un'installazione esistente di Hopper, Ghidra o IDA; la configurazione può installare opzionalmente Hopper previa approvazione. L'analisi statica JavaScript non richiede alcun motore di analisi nativo.
+La configurazione registra REA con il tuo agente e installa le istruzioni di workflow corrispondenti. L'analisi nativa può usare un'installazione esistente di Hopper, Ghidra, IDA o Kuna; la configurazione può installare opzionalmente Hopper previa approvazione. L'analisi statica JavaScript non richiede alcun motore di analisi nativo.

 > **[Visita il sito web di REA](https://rea.tools/it/)** per istruzioni di configurazione, guide illustrate e veri casi studio.

@@ -150,18 +150,18 @@ REA richiede Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) o 26+ (>=26.12.1), oltre

 | Obiettivo                    | Cosa restituisce REA                                                                                    | Requisiti e guida                                                                                                                        |
 | ---------------------------- | ------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------- |
-| Binari nativi                | Pseudocodice, assembly, stringhe, simboli, chiamate e riferimenti                                       | Hopper, Ghidra o IDA; [analisi nativa](../native-investigation.md)                                                                       |
+| Binari nativi                | Pseudocodice, assembly, stringhe, simboli, chiamate e riferimenti                                       | Hopper, Ghidra, IDA o Kuna; [analisi nativa](../native-investigation.md)                                                                 |
 | Layout ELF offline           | Sezioni, segmenti, simboli/relocazioni originali e candidati mitigazioni statiche                       | pwntools fornito dal chiamante su Linux x64; [diagnostica binaria](../binary-diagnostics.md)                                             |
 | PE certificates              | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields                            | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                                  |
 | PE imports                   | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash                              | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                            |
 | Artefatto WASM               | Convalida, sezioni, forme WAT di import/export esatte e WAT decodificato                                | WABT 1.0.42 fornito dal chiamante; `inspect_wasm_artifact`                                                                               |
-| Bytecode EVM                 | Selettori di dispatch, offset dei byte, argomenti inferiti e mutabilità                                 | Carrier raw/hex locale; [guida EVM offline](../evm-bytecode.md)                                                                          |
+| Bytecode EVM                 | Selettori di dispatch, offset dei byte, argomenti inferiti e mutabilità                                 | Carrier raw/hex locale su Linux x64; [guida EVM offline](../evm-bytecode.md)                                                             |
 | Rust binaries                | Embedded cargo-auditable dependency list                                                                | [Rust binaries](../rust-binaries.md)                                                                                                     |
 | ELF notes                    | PT_NOTE/SHT_NOTE owners, types, GNU build-id and ABI-tag fields                                         | Built-in static ELF inspection; [ELF notes](../elf-notes.md)                                                                             |
 | Linux kernel modules         | .modinfo keys, __versions CRCs, this_module presence, and signature trailer                             | Built-in static ELF inspection; [kernel modules](../kernel-modules.md)                                                                   |
 | Erlang BEAM                  | IFF chunks, atoms, exports, and tables                                                                  | Built-in static BEAM inspection; [Erlang BEAM](../erlang-beam.md)                                                                        |
 | Apple IPS crashes            | .ips metadata, threads, images, registers and crash classes                                             | Built-in static JSON inspection; [Apple IPS](../apple-ips.md)                                                                            |
-| Crash Linux registrati       | Note grezze, registri/segnai di ogni thread registrato e candidati mapping opzionali                    | pwntools fornito dal chiamante; GDB/pwndbg opzionale; [crash registrati](../recorded-crashes.md)                                         |
+| Crash Linux registrati       | Note grezze, registri/segnai di ogni thread registrato e candidati mapping opzionali                    | pwntools fornito dal chiamante su Linux x64; GDB/pwndbg opzionale; [crash registrati](../recorded-crashes.md)                            |
 | Installazioni desktop        | Runtime candidati, file di supporto, componenti e passi successivi                                      | Ispezione limitata di directory e intestazioni；[Applicazioni desktop](../desktop-applications.md)                                       |
 | JavaScript / Electron        | Moduli, import, source map, route, IPC e relazioni con add-on nativi                                    | Node.js e npm; [analisi delle applicazioni](../javascript-application-workflows.md); Linux: procps `ps`                                  |
 | Siti web                     | Struttura della pagina, script, osservazioni di rete e screenshot richiesti                             | Un browser della famiglia Chrome; [analisi browser](../browser-observation.md)                                                           |
@@ -189,6 +189,8 @@ REA richiede Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) o 26+ (>=26.12.1), oltre

 L'ispezione statica di JavaScript e .NET legge i file forniti senza eseguire l'applicazione. La cattura a runtime esegue o interagisce con il bersaglio selezionato usando i tuoi permessi utente; ogni guida runtime descrive i suoi effetti.

+Per ispezionare offline i binari nativi, REA supporta anche GNU objdump e Rizin, che devi fornire autonomamente. La [guida agli strumenti di reverse engineering](../reverse-engineering-tools.md) descrive la configurazione dei provider, i comandi CLI e i limiti di Evidence. REA non installa né aggiorna questi due provider.
+
 <a id="choosing-a-deep-analysis-provider"></a>

 I formati nativi e il supporto host variano in base al provider. Vedi la [configurazione di Hopper e Ghidra](../installation.md#hopper), la [guida IDA](../ida-provider.md), [Kuna](../kuna-provider.md) e il [supporto sperimentale Windows Ghidra](../windows-ghidra-p0.md). Ghidra supporta anche l'[analisi DOS a 16 bit](../ghidra-dos.md). Per binari di grandi dimensioni, aumenta il timeout di avvio con `REA_GHIDRA_STARTUP_TIMEOUT_MS` / `REA_HOPPER_STARTUP_TIMEOUT_MS`. Per la selezione del provider, vedi la [guida CLI](../cli.md#choose-a-provider). Controlla la [disponibilità delle release](../installation.md#released-package-and-main) per le funzionalità aggiunte dall'ultima release npm.
@@ -275,9 +277,9 @@ Qualsiasi agente che supporti server MCP locali. La configurazione configura gli
 </details>

 <details>
-<summary><strong>Ho bisogno di Hopper, Ghidra o IDA?</strong></summary>
+<summary><strong>Ho bisogno di Hopper, Ghidra, IDA o Kuna?</strong></summary>

-L'analisi nativa profonda ne usa uno. L'ispezione statica di JavaScript e .NET funziona senza un motore di analisi nativo. La configurazione può installare Hopper previa approvazione; Ghidra e IDA usano le tue installazioni esistenti. Vedi [configurazione provider](../installation.md#hopper).
+L'analisi nativa profonda ne usa uno. L'ispezione statica di JavaScript e .NET funziona senza un motore di analisi nativo. La configurazione può installare Hopper previa approvazione; Ghidra, IDA e Kuna usano le tue installazioni esistenti. Vedi [configurazione provider](../installation.md#hopper).

 </details>

@@ -20,7 +20,7 @@

 **[ウェブサイト](https://rea.tools/ja/) · [ガイド](https://rea.tools/ja/guides/) · [事例](https://rea.tools/ja/showcase/)**

-[クイックスタート](#クイックスタート) · [REA の仕組み](#rea-の仕組み) · [分析できる対象](#分析できる対象) · [事例](#事例) · [RL 環境を構築する](#build-rl-environments) · [よくある質問](#よくある質問) · [GNU objdump・Rizin ツール](../reverse-engineering-tools.md) · [ドキュメント](#ドキュメント)
+[クイックスタート](#クイックスタート) · [REA の仕組み](#rea-の仕組み) · [分析できる対象](#分析できる対象) · [事例](#事例) · [RL 環境を構築する](#build-rl-environments) · [よくある質問](#よくある質問) · [ドキュメント](#ドキュメント)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@

 REA はエージェントを分析ツールにつなぎ、ネイティブバイナリ、JavaScript や Electron のアプリ、.NET アセンブリ、ウェブサイトを調べられるようにします。同じツールをターミナルからも使えます。分析はローカルで実行され、結果には各結論を裏付ける根拠と制限事項が含まれます。

-セットアップはエージェントに REA を登録し、対応するワークフロー指示をインストールします。ネイティブ解析には既存の Hopper、Ghidra、IDA を使用でき、承認すれば Hopper をインストールできます。静的 JavaScript 解析にネイティブ解析エンジンは不要です。
+セットアップはエージェントに REA を登録し、対応するワークフロー指示をインストールします。ネイティブ解析には既存の Hopper、Ghidra、IDA、Kuna を使用でき、承認すれば Hopper をインストールできます。静的 JavaScript 解析にネイティブ解析エンジンは不要です。

 > **[REA のウェブサイト](https://rea.tools/ja/)**で、セットアップ手順、図解ガイド、実際の事例を確認できます。

@@ -151,7 +151,7 @@ REA には Node.js 22.x（>=22.23.4）、24.x（>=24.22.1）、または 26+ (>=

 | 対象                             | REA が返すもの                                                                              | 要件とガイド                                                                                                                                   |
 | -------------------------------- | ------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
-| ネイティブバイナリ               | 疑似コード、アセンブリ、文字列、シンボル、呼び出し、参照                                    | Hopper、Ghidra、または IDA；[ネイティブ分析](../native-investigation.md)                                                                       |
+| ネイティブバイナリ               | 疑似コード、アセンブリ、文字列、シンボル、呼び出し、参照                                    | Hopper、Ghidra、IDA、または Kuna；[ネイティブ分析](../native-investigation.md)                                                                 |
 | オフライン ELF レイアウト        | セクション、セグメント、元のシンボル／再配置情報、静的解析によるセキュリティ対策の候補      | Linux x64 で利用者が用意する pwntools；[バイナリ診断](../binary-diagnostics.md)                                                                |
 | PE certificates                  | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields                | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                                        |
 | PE imports                       | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash                  | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                                  |
@@ -190,6 +190,8 @@ REA には Node.js 22.x（>=22.23.4）、24.x（>=24.22.1）、または 26+ (>=

 静的な JavaScript と .NET の検査は、指定されたファイルを読み取り、アプリケーションを実行しません。実行時キャプチャは、あなたのユーザー権限で対象を実行したり、対象とやり取りしたりします。それぞれの実行時ガイドに、どのような操作が行われるかを記載しています。

+ネイティブバイナリのオフライン検査では、利用者が用意した GNU objdump と Rizin も使用できます。[リバースエンジニアリングツールのガイド](../reverse-engineering-tools.md)では、プロバイダーのセットアップ、CLI コマンド、Evidence の制約を説明しています。REA はどちらのプロバイダーもインストールや更新を行いません。
+
 <a id="choosing-a-deep-analysis-provider"></a>

 大きなバイナリでは `REA_GHIDRA_STARTUP_TIMEOUT_MS` または `REA_HOPPER_STARTUP_TIMEOUT_MS` でプロバイダーの起動期限を延長できます。
@@ -280,9 +282,9 @@ REA は実行可能な環境と、起動して応答することを確認する
 </details>

 <details>
-<summary><strong>Hopper、Ghidra、IDA は必要ですか？</strong></summary>
+<summary><strong>Hopper、Ghidra、IDA、Kuna は必要ですか？</strong></summary>

-深いネイティブ分析には、そのいずれかを使います。静的な JavaScript と .NET の検査には、ネイティブ分析エンジンは必要ありません。セットアップは承認後に Hopper をインストールできます。Ghidra と IDA は既存のインストールを使います。[プロバイダーのセットアップ](../installation.md#hopper)を参照してください。
+深いネイティブ分析には、そのいずれかを使います。静的な JavaScript と .NET の検査には、ネイティブ分析エンジンは必要ありません。セットアップは承認後に Hopper をインストールできます。Ghidra、IDA、Kuna は既存のインストールを使います。[プロバイダーのセットアップ](../installation.md#hopper)を参照してください。

 </details>

@@ -60,7 +60,7 @@

 REA는 에이전트를 분석 도구에 연결해 네이티브 바이너리, JavaScript와 Electron 앱, .NET 어셈블리, 웹사이트를 검사할 수 있게 합니다. 터미널에서도 같은 도구를 사용할 수 있습니다. 분석은 로컬에서 실행되며, 결과에는 각 결론의 근거와 한계가 포함됩니다.

-설정 과정은 에이전트에 REA를 등록하고 해당 버전에 맞는 워크플로 지침을 설치합니다. 네이티브 분석에는 기존 Hopper, Ghidra 또는 IDA 설치를 사용할 수 있습니다. 승인하면 설정 과정에서 Hopper를 설치할 수도 있습니다. 정적 JavaScript 분석에는 네이티브 분석 엔진이 필요하지 않습니다.
+설정 과정은 에이전트에 REA를 등록하고 해당 버전에 맞는 워크플로 지침을 설치합니다. 네이티브 분석에는 기존 Hopper, Ghidra, IDA 또는 Kuna 설치를 사용할 수 있습니다. 승인하면 설정 과정에서 Hopper를 설치할 수도 있습니다. 정적 JavaScript 분석에는 네이티브 분석 엔진이 필요하지 않습니다.

 > <strong>[REA 웹사이트](https://rea.tools/ko/)</strong>에서 설정 방법, 그림으로 설명한 가이드, 실제 사례를 확인하세요.

@@ -151,7 +151,7 @@ REA에는 Node.js 22.x(>=22.23.4), 24.x(>=24.22.1) 또는 26+ (>=26.12.1)와 npm

 | 대상                   | REA가 반환하는 내용                                                           | 요구 사항 및 가이드                                                                                                               |
 | ---------------------- | ----------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
-| 네이티브 바이너리      | 의사 코드, 어셈블리, 문자열, 심볼, 호출, 참조                                 | Hopper, Ghidra 또는 IDA; [네이티브 분석](../native-investigation.md)                                                              |
+| 네이티브 바이너리      | 의사 코드, 어셈블리, 문자열, 심볼, 호출, 참조                                 | Hopper, Ghidra, IDA 또는 Kuna; [네이티브 분석](../native-investigation.md)                                                        |
 | 오프라인 ELF 레이아웃  | 섹션, 세그먼트, 원본 심볼/재배치 정보, 정적 분석으로 얻은 보안 완화 기법 후보 | Linux x64에서 호출자가 제공하는 pwntools; [바이너리 진단](../binary-diagnostics.md)                                               |
 | Go 바이너리            | 내장된 컴파일러 버전, 모듈, `replace` 지시어, 빌드 설정                       | REA 내장 ELF/PE/thin Mach-O 정적 검사; Go 설치 불필요                                                                             |
 | Rust 바이너리          | cargo-auditable이 내장한 크레이트 이름, 버전, 소스, 의존성 관계               | REA 내장 ELF/PE/thin Mach-O 정적 검사; [Rust 바이너리](../rust-binaries.md)                                                       |
@@ -280,9 +280,9 @@ REA는 실행 가능한 환경과 시작 및 응답 여부를 확인하는 기
 </details>

 <details>
-<summary><strong>Hopper, Ghidra 또는 IDA가 필요한가요?</strong></summary>
+<summary><strong>Hopper, Ghidra, IDA 또는 Kuna가 필요한가요?</strong></summary>

-심층 네이티브 분석에는 이 중 하나를 사용합니다. 정적 JavaScript 및 .NET 검사에는 네이티브 분석 엔진이 필요하지 않습니다. 설정 과정에서 승인 후 Hopper를 설치할 수 있으며, Ghidra와 IDA는 기존 설치를 사용합니다. [제공자 설정](../installation.md#hopper)을 참고하세요.
+심층 네이티브 분석에는 이 중 하나를 사용합니다. 정적 JavaScript 및 .NET 검사에는 네이티브 분석 엔진이 필요하지 않습니다. 설정 과정에서 승인 후 Hopper를 설치할 수 있으며, Ghidra, IDA, Kuna는 기존 설치를 사용합니다. [제공자 설정](../installation.md#hopper)을 참고하세요.

 </details>

@@ -62,7 +62,7 @@

 Native binaries, JavaScript, Electron apps, .NET assemblies, websites എന്നിവ പരിശോധിക്കുന്നതിനുള്ള tools-ലേക്ക് REA നിങ്ങളുടെ agent-നെ ബന്ധിപ്പിക്കുന്നു. ഇതേ tools നിങ്ങളുടെ terminal-ൽ നിന്നും ഉപയോഗിക്കാം. വിശകലനം local ആയി നടക്കുന്നു; ഓരോ നിഗമനത്തിനും പിന്നിലെ തെളിവുകളും പരിമിതികളും ഫലങ്ങളിൽ ഉൾപ്പെടുന്നു.

-Setup നിങ്ങളുടെ agent-ിൽ REA രജിസ്റ്റർ ചെയ്യുകയും അനുയോജ്യമായ workflow നിർദ്ദേശങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുകയും ചെയ്യുന്നു. Native analysis-നായി നിലവിലുള്ള Hopper, Ghidra, അല്ലെങ്കിൽ IDA installation ഉപയോഗിക്കാം; അനുമതി നൽകിയാൽ setup-ന് Hopper ഇൻസ്റ്റാൾ ചെയ്യാനും കഴിയും. Static JavaScript analysis-ന് native analysis engine ആവശ്യമില്ല.
+Setup നിങ്ങളുടെ agent-ിൽ REA രജിസ്റ്റർ ചെയ്യുകയും അനുയോജ്യമായ workflow നിർദ്ദേശങ്ങൾ ഇൻസ്റ്റാൾ ചെയ്യുകയും ചെയ്യുന്നു. Native analysis-നായി നിലവിലുള്ള Hopper, Ghidra, IDA, അല്ലെങ്കിൽ Kuna installation ഉപയോഗിക്കാം; അനുമതി നൽകിയാൽ setup-ന് Hopper ഇൻസ്റ്റാൾ ചെയ്യാനും കഴിയും. Static JavaScript analysis-ന് native analysis engine ആവശ്യമില്ല.

 > **[REA വെബ്സൈറ്റ് സന്ദർശിക്കുക](https://rea.tools/)** — setup നിർദ്ദേശങ്ങൾക്കും ചിത്രങ്ങളോടുകൂടിയ ഗൈഡുകൾക്കും യഥാർത്ഥ case study-കൾക്കും.

@@ -151,7 +151,7 @@ REA-യ്ക്ക് Node.js 22.x (>=22.23.4), 24.x (>=24.22.1), അല്ല

 | Target                 | REA നൽകുന്ന ഫലങ്ങൾ                                                                             | ആവശ്യകതകളും ഗൈഡും                                                                                                                    |
 | ---------------------- | ------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
-| Native binaries        | Pseudocode, assembly, strings, symbols, calls, references                                   | Hopper, Ghidra അല്ലെങ്കിൽ IDA; [native analysis](../native-investigation.md)                                                        |
+| Native binaries        | Pseudocode, assembly, strings, symbols, calls, references                                   | Hopper, Ghidra, IDA അല്ലെങ്കിൽ Kuna; [native analysis](../native-investigation.md)                                                  |
 | Offline ELF layout     | Sections, segments, യഥാർത്ഥ symbols/relocations, static mitigation candidates                 | Linux x64-ൽ caller നൽകുന്ന pwntools; [binary diagnostics](../binary-diagnostics.md)                                                 |
 | Go binaries            | ഉൾച്ചേർത്ത compiler version, modules, replacements, build settings                            | Built-in static ELF/PE/thin Mach-O പരിശോധന; Go installation ആവശ്യമില്ല                                                              |
 | Rust binaries          | ഉൾച്ചേർത്ത cargo-auditable crate പേരുകൾ, versions, sources, dependency edges                   | Built-in static ELF/PE/thin Mach-O പരിശോധന; [Rust binaries](../rust-binaries.md)                                                  |
@@ -284,9 +284,9 @@ Local MCP servers പിന്തുണയ്ക്കുന്ന ഏത് age
 </details>

 <details>
-<summary><strong>Hopper, Ghidra അല്ലെങ്കിൽ IDA ആവശ്യമാണോ?</strong></summary>
+<summary><strong>Hopper, Ghidra, IDA അല്ലെങ്കിൽ Kuna ആവശ്യമാണോ?</strong></summary>

-ആഴത്തിലുള്ള native analysis-ന് ഇവയിൽ ഒന്ന് ആവശ്യമാണ്. Static JavaScript, .NET പരിശോധനകൾ native analysis engine ഇല്ലാതെയും പ്രവർത്തിക്കും. അനുമതി ലഭിച്ചാൽ setup-ന് Hopper ഇൻസ്റ്റാൾ ചെയ്യാം; Ghidra, IDA എന്നിവയ്ക്കായി നിങ്ങളുടെ നിലവിലുള്ള installations ഉപയോഗിക്കുന്നു. [Provider setup](../installation.md#hopper) കാണുക.
+ആഴത്തിലുള്ള native analysis-ന് ഇവയിൽ ഒന്ന് ആവശ്യമാണ്. Static JavaScript, .NET പരിശോധനകൾ native analysis engine ഇല്ലാതെയും പ്രവർത്തിക്കും. അനുമതി ലഭിച്ചാൽ setup-ന് Hopper ഇൻസ്റ്റാൾ ചെയ്യാം; Ghidra, IDA, Kuna എന്നിവയ്ക്കായി നിങ്ങളുടെ നിലവിലുള്ള installations ഉപയോഗിക്കുന്നു. [Provider setup](../installation.md#hopper) കാണുക.

 </details>

@@ -20,7 +20,7 @@

 **[Strona internetowa](https://rea.tools/pl/) · [Przewodniki](https://rea.tools/pl/guides/) · [Przykłady zastosowań](https://rea.tools/pl/showcase/)**

-[Szybki start](#szybki-start) · [Jak działa REA](#jak-działa-rea) · [Co możesz analizować](#co-możesz-analizować) · [Przykłady zastosowań](#przykłady-zastosowań) · [Tworzenie środowisk RL](#build-rl-environments) · [FAQ](#faq) · [Narzędzia GNU objdump i Rizin](../reverse-engineering-tools.md) · [Dokumentacja](#dokumentacja)
+[Szybki start](#szybki-start) · [Jak działa REA](#jak-działa-rea) · [Co możesz analizować](#co-możesz-analizować) · [Przykłady zastosowań](#przykłady-zastosowań) · [Tworzenie środowisk RL](#build-rl-environments) · [FAQ](#faq) · [Dokumentacja](#dokumentacja)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@ Widzisz w aplikacji funkcję, którą chcesz mieć we własnym produkcie? Popro

 REA łączy Twojego agenta z narzędziami do analizy natywnych plików binarnych, aplikacji JavaScript i Electron, zestawów .NET oraz stron internetowych. Z tych samych narzędzi możesz korzystać w terminalu. Analiza odbywa się lokalnie, a wyniki zawierają dowody i ograniczenia stojące za każdym wnioskiem.

-Konfigurator rejestruje REA w Twoim agencie i instaluje pasujące instrukcje pracy. Analiza kodu natywnego może korzystać z istniejącej instalacji Hoppera lub Ghidry; konfigurator może też zainstalować Hoppera po uzyskaniu zgody. Statyczna analiza JavaScript nie wymaga żadnego z tych silników.
+Konfigurator rejestruje REA w Twoim agencie i instaluje pasujące instrukcje pracy. Analiza kodu natywnego może korzystać z istniejącej instalacji Hoppera, Ghidry, IDA lub Kuna; konfigurator może też zainstalować Hoppera po uzyskaniu zgody. Statyczna analiza JavaScript nie wymaga żadnego z tych silników.

 > **[Odwiedź stronę REA](https://rea.tools/pl/)**, aby znaleźć instrukcje konfiguracji, ilustrowane przewodniki i rzeczywiste studia przypadków.

@@ -151,7 +151,7 @@ REA wymaga Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) lub 26+ (>=26.12.1) oraz n

 | Cel                                     | Co zwraca REA                                                                                                         | Wymagania i przewodnik                                                                                                                                |
 | --------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Natywne pliki binarne                   | Pseudokod, kod asemblera, ciągi znaków, symbole, wywołania i odwołania                                                | Hopper, Ghidra lub IDA; [analiza kodu natywnego](../native-investigation.md)                                                                          |
+| Natywne pliki binarne                   | Pseudokod, kod asemblera, ciągi znaków, symbole, wywołania i odwołania                                                | Hopper, Ghidra, IDA lub Kuna; [analiza kodu natywnego](../native-investigation.md)                                                                    |
 | Układ pliku ELF w trybie offline        | Sekcje, segmenty, oryginalne symbole/relokacje i potencjalne mechanizmy zabezpieczeń wskazane przez analizę statyczną | pwntools dostarczone przez użytkownika w systemie Linux x64; [diagnostyka plików binarnych](../binary-diagnostics.md)                                 |
 | PE certificates                         | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields                                          | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                                               |
 | PE imports                              | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash                                            | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                                         |
@@ -190,6 +190,8 @@ REA wymaga Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) lub 26+ (>=26.12.1) oraz n

 Statyczna analiza JavaScript i .NET odczytuje dostarczone pliki bez uruchamiania aplikacji. Przechwytywanie w czasie wykonywania uruchamia wybrany cel lub wchodzi z nim w interakcje z uprawnieniami Twojego użytkownika; skutki opisano w odpowiednich przewodnikach.

+Do analizy offline natywnych plików binarnych REA obsługuje również GNU objdump i Rizin, które musisz dostarczyć samodzielnie. [Przewodnik po narzędziach inżynierii wstecznej](../reverse-engineering-tools.md) opisuje konfigurację dostawców, polecenia CLI i ograniczenia Evidence. REA nie instaluje ani nie aktualizuje żadnego z tych dostawców.
+
 <a id="choosing-a-deep-analysis-provider"></a>

 Dla dużych plików zwiększ czas uruchomienia przez `REA_GHIDRA_STARTUP_TIMEOUT_MS` lub `REA_HOPPER_STARTUP_TIMEOUT_MS`.
@@ -278,9 +280,9 @@ Każdy agent obsługujący lokalne serwery MCP. Konfigurator konfiguruje [obsłu
 </details>

 <details>
-<summary><strong>Czy potrzebuję Hoppera, Ghidry lub IDA?</strong></summary>
+<summary><strong>Czy potrzebuję Hoppera, Ghidry, IDA lub Kuna?</strong></summary>

-Dogłębna analiza kodu natywnego używa jednego z nich. Statyczna analiza JavaScript i .NET działa bez silnika analizy natywnej. Konfigurator może zainstalować Hoppera po uzyskaniu zgody; Ghidra i IDA korzystają z istniejących instalacji. Zobacz [konfigurację dostawców analizy](../installation.md#hopper).
+Dogłębna analiza kodu natywnego używa jednego z nich. Statyczna analiza JavaScript i .NET działa bez silnika analizy natywnej. Konfigurator może zainstalować Hoppera po uzyskaniu zgody; Ghidra, IDA i Kuna korzystają z istniejących instalacji. Zobacz [konfigurację dostawców analizy](../installation.md#hopper).

 </details>

@@ -20,7 +20,7 @@

 **[Site](https://rea.tools/pt-BR/) · [Guias](https://rea.tools/pt-BR/guides/) · [Casos de uso](https://rea.tools/pt-BR/showcase/)**

-[Início rápido](#início-rápido) · [Como o REA funciona](#como-o-rea-funciona) · [O que você pode analisar](#o-que-você-pode-analisar) · [Casos de uso](#casos-de-uso) · [Criar ambientes de RL](#build-rl-environments) · [Perguntas frequentes](#perguntas-frequentes) · [Ferramentas GNU objdump e Rizin](../reverse-engineering-tools.md) · [Documentação](#documentação)
+[Início rápido](#início-rápido) · [Como o REA funciona](#como-o-rea-funciona) · [O que você pode analisar](#o-que-você-pode-analisar) · [Casos de uso](#casos-de-uso) · [Criar ambientes de RL](#build-rl-environments) · [Perguntas frequentes](#perguntas-frequentes) · [Documentação](#documentação)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@ Viu uma funcionalidade em um aplicativo que gostaria de ter no seu próprio prod

 O REA conecta seu agente a ferramentas para inspecionar binários nativos, aplicativos JavaScript e Electron, assemblies .NET e sites. Você também pode usar as mesmas ferramentas pelo terminal. A análise acontece localmente, e os resultados incluem as evidências e limitações por trás de cada conclusão.

-A configuração registra o REA no seu agente e instala as instruções de trabalho correspondentes. A análise nativa pode usar Hopper, Ghidra ou IDA já instalados; o Hopper pode ser instalado após sua aprovação. A análise estática de JavaScript não precisa de um mecanismo de análise nativa.
+A configuração registra o REA no seu agente e instala as instruções de trabalho correspondentes. A análise nativa pode usar Hopper, Ghidra, IDA ou Kuna já instalados; o Hopper pode ser instalado após sua aprovação. A análise estática de JavaScript não precisa de um mecanismo de análise nativa.

 > **[Visite o site do REA](https://rea.tools/pt-BR/)** para instruções de configuração, guias ilustrados e estudos de caso reais.

@@ -151,7 +151,7 @@ O REA requer Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) ou 26+ (>=26.12.1), alé

 | Alvo                        | O que o REA retorna                                                                                                     | Requisitos e guia                                                                                                                            |
 | --------------------------- | ----------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- |
-| Binários nativos            | Pseudocódigo, assembly, strings, símbolos, chamadas e referências                                                       | Hopper, Ghidra ou IDA; [análise nativa](../native-investigation.md)                                                                          |
+| Binários nativos            | Pseudocódigo, assembly, strings, símbolos, chamadas e referências                                                       | Hopper, Ghidra, IDA ou Kuna; [análise nativa](../native-investigation.md)                                                                    |
 | Estrutura ELF sem execução  | Seções, segmentos, símbolos/relocações originais e possíveis mecanismos de mitigação identificados por análise estática | pwntools fornecido pelo chamador no Linux x64; [diagnóstico de binários](../binary-diagnostics.md)                                           |
 | PE certificates             | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields                                            | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                                      |
 | PE imports                  | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash                                              | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                                |
@@ -190,6 +190,8 @@ O REA requer Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) ou 26+ (>=26.12.1), alé

 A inspeção estática de JavaScript e .NET lê os arquivos fornecidos sem executar o aplicativo. A captura em execução inicia o alvo selecionado ou interage com ele usando as permissões do seu usuário; cada guia descreve seus efeitos.

+Para inspecionar binários nativos offline, o REA também oferece suporte ao GNU objdump e ao Rizin, que você deve fornecer por conta própria. O [guia de ferramentas de engenharia reversa](../reverse-engineering-tools.md) descreve a configuração dos provedores, os comandos da CLI e as limitações de Evidence. O REA não instala nem atualiza nenhum desses provedores.
+
 <a id="choosing-a-deep-analysis-provider"></a>

 Para binários grandes, aumente o prazo de inicialização com `REA_GHIDRA_STARTUP_TIMEOUT_MS` ou `REA_HOPPER_STARTUP_TIMEOUT_MS`.
@@ -278,9 +280,9 @@ Qualquer agente que ofereça suporte a servidores MCP locais. A configuração p
 </details>

 <details>
-<summary><strong>Preciso do Hopper, Ghidra ou IDA?</strong></summary>
+<summary><strong>Preciso do Hopper, Ghidra, IDA ou Kuna?</strong></summary>

-A análise nativa aprofundada usa um desses motores. A inspeção estática de JavaScript e .NET funciona sem um motor de análise nativa. A configuração pode instalar o Hopper após aprovação; Ghidra e IDA usam as instalações existentes. Consulte [configuração dos provedores](../installation.md#hopper).
+A análise nativa aprofundada usa um desses motores. A inspeção estática de JavaScript e .NET funciona sem um motor de análise nativa. A configuração pode instalar o Hopper após aprovação; Ghidra, IDA e Kuna usam as instalações existentes. Consulte [configuração dos provedores](../installation.md#hopper).

 </details>

@@ -62,7 +62,7 @@ Ai văzut într-o aplicație o funcționalitate pe care ai vrea să o incluzi î

 REA conectează agentul tău la unelte pentru inspectarea fișierelor binare native, a aplicațiilor JavaScript și Electron, a ansamblurilor .NET și a site-urilor web. Poți folosi aceleași unelte și din terminal. Analiza rulează local, iar rezultatele includ dovezile și limitările care stau la baza fiecărei concluzii.

-Programul de configurare înregistrează REA în agentul tău și instalează instrucțiunile corespunzătoare pentru fluxul de lucru. Analiza nativă poate folosi o instalare existentă de Hopper, Ghidra sau IDA; programul de configurare poate instala opțional Hopper, cu aprobarea ta. Analiza statică JavaScript nu necesită un motor de analiză nativă.
+Programul de configurare înregistrează REA în agentul tău și instalează instrucțiunile corespunzătoare pentru fluxul de lucru. Analiza nativă poate folosi o instalare existentă de Hopper, Ghidra, IDA sau Kuna; programul de configurare poate instala opțional Hopper, cu aprobarea ta. Analiza statică JavaScript nu necesită un motor de analiză nativă.

 > **[Vizitează site-ul REA](https://rea.tools/)** pentru instrucțiuni de configurare, ghiduri ilustrate și studii de caz reale.

@@ -187,7 +187,7 @@ Uneltele suplimentare și platformele acceptate depind de ținta analizată:
 | Țintă                               | Ce returnează REA                                                                                                             | Cerințe și ghid                                                                                                                        |
 | ----------------------------------- | ----------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- |
 | Aplicații desktop instalate         | Componente de execuție candidate, fișiere auxiliare, indicii despre componente și următoarele verificări                      | Inspectare integrată a directoarelor și antetelor, cu limite de resurse; [aplicații desktop](../desktop-applications.md)               |
-| Fișiere binare native               | Pseudocod, cod de asamblare, șiruri de caractere, simboluri, apeluri și referințe                                             | Hopper, Ghidra sau IDA; [analiză nativă](../native-investigation.md)                                                                   |
+| Fișiere binare native               | Pseudocod, cod de asamblare, șiruri de caractere, simboluri, apeluri și referințe                                             | Hopper, Ghidra, IDA sau Kuna; [analiză nativă](../native-investigation.md)                                                             |
 | Structura ELF, offline              | Secțiuni, segmente, simboluri și relocări originale, precum și indicii statice despre mecanismele de protecție                | pwntools furnizat de utilizator, pe Linux x64; [diagnosticarea binarelor](../binary-diagnostics.md)                                    |
 | Fișiere binare Go                   | Versiunea compilatorului încorporată în fișier, modulele, înlocuirile și setările de compilare                                | Inspectare statică integrată a fișierelor ELF/PE/Mach-O cu o singură arhitectură; nu necesită instalarea Go                            |
 | Obiecte de cod GPU                  | Ținte CUDA/HIP, parametri și resurse selectate ale kernelurilor GPU, textul PTX păstrat                                       | Inspectare statică integrată a fișierelor ELF/PE/fatbin/CUBIN/PTX; [obiecte de cod GPU](../gpu-code-objects.md)                        |
@@ -342,11 +342,11 @@ poți folosi [înregistrarea manuală MCP](../installation.md#mcp-registry).
 </details>

 <details>
-<summary><strong>Am nevoie de Hopper, Ghidra sau IDA?</strong></summary>
+<summary><strong>Am nevoie de Hopper, Ghidra, IDA sau Kuna?</strong></summary>

 Analiza nativă aprofundată folosește unul dintre aceste instrumente. Inspectarea
 statică JavaScript și .NET funcționează fără un motor de analiză nativă.
-Programul de configurare poate instala Hopper după aprobare; pentru Ghidra și IDA
+Programul de configurare poate instala Hopper după aprobare; pentru Ghidra, IDA și Kuna
 folosește instalările existente. Consultă [configurarea motoarelor de analiză](../installation.md#hopper).

 </details>
@@ -20,7 +20,7 @@

 **[Сайт](https://rea.tools/ru/) · [Руководства](https://rea.tools/ru/guides/) · [Примеры](https://rea.tools/ru/showcase/)**

-[Быстрый старт](#быстрый-старт) · [Как работает REA](#как-работает-rea) · [Что можно анализировать](#что-можно-анализировать) · [Примеры](#примеры) · [Создание RL-окружений](#build-rl-environments) · [Частые вопросы](#частые-вопросы) · [Инструменты GNU objdump и Rizin](../reverse-engineering-tools.md) · [Документация](#документация)
+[Быстрый старт](#быстрый-старт) · [Как работает REA](#как-работает-rea) · [Что можно анализировать](#что-можно-анализировать) · [Примеры](#примеры) · [Создание RL-окружений](#build-rl-environments) · [Частые вопросы](#частые-вопросы) · [Документация](#документация)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@

 REA подключает вашего агента к инструментам для исследования нативных бинарных файлов, приложений JavaScript и Electron, сборок .NET и сайтов. Те же инструменты доступны в терминале. Анализ выполняется локально, а результаты содержат данные и ограничения, на которых основан каждый вывод.

-Настройка регистрирует REA у агента и устанавливает соответствующие инструкции. Нативный анализ использует установленный Hopper, Ghidra или IDA; Hopper можно установить после одобрения. Статическому анализу JavaScript нативный движок не нужен.
+Настройка регистрирует REA у агента и устанавливает соответствующие инструкции. Нативный анализ использует установленный Hopper, Ghidra, IDA или Kuna; Hopper можно установить после одобрения. Статическому анализу JavaScript нативный движок не нужен.

 > **[Посетите сайт REA](https://rea.tools/ru/)**: там есть инструкции по настройке, иллюстрированные руководства и реальные исследования.

@@ -151,7 +151,7 @@ REA требует Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) или 26+ (>=26.1

 | Цель                                | Что возвращает REA                                                                                                         | Требования и руководство                                                                                                                                   |
 | ----------------------------------- | -------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Нативные бинарные файлы             | Псевдокод, ассемблер, строки, символы, вызовы и ссылки                                                                     | Hopper, Ghidra или IDA; [нативный анализ](../native-investigation.md)                                                                                      |
+| Нативные бинарные файлы             | Псевдокод, ассемблер, строки, символы, вызовы и ссылки                                                                     | Hopper, Ghidra, IDA или Kuna; [нативный анализ](../native-investigation.md)                                                                                |
 | Структура ELF без запуска           | Секции, сегменты, исходные символы/релокации и возможные механизмы защиты по данным статического анализа                   | pwntools, предоставленный вызывающей стороной, в Linux x64; [диагностика бинарных файлов](../binary-diagnostics.md)                                        |
 | Байт-код EVM                        | Селекторы диспетчеризации, смещения байтов, предполагаемые аргументы и изменяемость состояния                              | Локальные необработанные байты или шестнадцатеричное представление в Linux x64; [руководство по EVM без запуска](../evm-bytecode.md)                       |
 | Rust binaries                       | Embedded cargo-auditable dependency list                                                                                   | [Rust binaries](../rust-binaries.md)                                                                                                                       |
@@ -190,6 +190,8 @@ REA требует Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) или 26+ (>=26.1

 Статическое исследование JavaScript и .NET читает предоставленные файлы, не запуская приложение. Захват во время выполнения запускает выбранную цель или взаимодействует с ней с правами вашего пользователя; соответствующие руководства описывают последствия.

+Для автономного анализа нативных бинарных файлов REA также поддерживает GNU objdump и Rizin, которые пользователь предоставляет самостоятельно. В [руководстве по инструментам обратной разработки](../reverse-engineering-tools.md) описаны настройка провайдеров, команды CLI и ограничения Evidence. REA не устанавливает и не обновляет ни один из этих провайдеров.
+
 <a id="choosing-a-deep-analysis-provider"></a>

 Для больших файлов увеличьте срок запуска через `REA_GHIDRA_STARTUP_TIMEOUT_MS` или `REA_HOPPER_STARTUP_TIMEOUT_MS`.
@@ -278,9 +280,9 @@ REA экспортирует готовое к запуску окружение
 </details>

 <details>
-<summary><strong>Нужны ли мне Hopper, Ghidra или IDA?</strong></summary>
+<summary><strong>Нужны ли мне Hopper, Ghidra, IDA или Kuna?</strong></summary>

-Углублённый нативный анализ использует один из этих инструментов. Статическое исследование JavaScript и .NET работает без движка нативного анализа. Настройка может установить Hopper после подтверждения; Ghidra и IDA используют существующие установки. См. [настройку провайдеров](../installation.md#hopper).
+Углублённый нативный анализ использует один из этих инструментов. Статическое исследование JavaScript и .NET работает без движка нативного анализа. Настройка может установить Hopper после подтверждения; Ghidra, IDA и Kuna используют существующие установки. См. [настройку провайдеров](../installation.md#hopper).

 </details>

@@ -20,7 +20,7 @@

 **[เว็บไซต์](https://rea.tools/th/) · [คู่มือ](https://rea.tools/th/guides/) · [ตัวอย่างการใช้งาน](https://rea.tools/th/showcase/)**

-[เริ่มต้นอย่างรวดเร็ว](#เริ่มต้นอย่างรวดเร็ว) · [REA ทำงานอย่างไร](#rea-ทำงานอย่างไร) · [สิ่งที่วิเคราะห์ได้](#สิ่งที่วิเคราะห์ได้) · [ตัวอย่างการใช้งาน](#ตัวอย่างการใช้งาน) · [สร้างสภาพแวดล้อม RL](#build-rl-environments) · [คำถามที่พบบ่อย](#คำถามที่พบบ่อย) · [เครื่องมือ GNU objdump และ Rizin](../reverse-engineering-tools.md) · [เอกสาร](#เอกสาร)
+[เริ่มต้นอย่างรวดเร็ว](#เริ่มต้นอย่างรวดเร็ว) · [REA ทำงานอย่างไร](#rea-ทำงานอย่างไร) · [สิ่งที่วิเคราะห์ได้](#สิ่งที่วิเคราะห์ได้) · [ตัวอย่างการใช้งาน](#ตัวอย่างการใช้งาน) · [สร้างสภาพแวดล้อม RL](#build-rl-environments) · [คำถามที่พบบ่อย](#คำถามที่พบบ่อย) · [เอกสาร](#เอกสาร)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@

 REA เชื่อมเอเจนต์ของคุณกับเครื่องมือสำหรับตรวจสอบไบนารีเนทีฟ แอป JavaScript และ Electron แอสเซมบลี .NET และเว็บไซต์ คุณใช้เครื่องมือเดียวกันจากเทอร์มินัลได้ การวิเคราะห์ทำงานบนเครื่องของคุณ และผลลัพธ์มีทั้งหลักฐานและข้อจำกัดที่ประกอบแต่ละข้อสรุป

-การตั้งค่าลงทะเบียน REA กับเอเจนต์และติดตั้งคำแนะนำการทำงานที่ตรงกัน การวิเคราะห์เนทีฟใช้ Hopper, Ghidra หรือ IDA ที่มีอยู่ได้ และติดตั้ง Hopper ได้เมื่อคุณอนุมัติ การวิเคราะห์ JavaScript แบบสแตติกไม่ต้องใช้เอนจินวิเคราะห์เนทีฟ
+การตั้งค่าลงทะเบียน REA กับเอเจนต์และติดตั้งคำแนะนำการทำงานที่ตรงกัน การวิเคราะห์เนทีฟใช้ Hopper, Ghidra, IDA หรือ Kuna ที่มีอยู่ได้ และติดตั้ง Hopper ได้เมื่อคุณอนุมัติ การวิเคราะห์ JavaScript แบบสแตติกไม่ต้องใช้เอนจินวิเคราะห์เนทีฟ

 > **[เยี่ยมชมเว็บไซต์ REA](https://rea.tools/th/)** เพื่อดูคำแนะนำการตั้งค่า คู่มือพร้อมภาพประกอบ และกรณีศึกษาจริง

@@ -151,7 +151,7 @@ REA ต้องใช้ Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) หรื

 | เป้าหมาย                      | สิ่งที่ REA ส่งกลับ                                                                   | ข้อกำหนดและคู่มือ                                                                                                                        |
 | ---------------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------ |
-| ไบนารีเนทีฟ                    | โค้ดเทียม แอสเซมบลี สตริง สัญลักษณ์ การเรียก และการอ้างอิง                                | Hopper, Ghidra หรือ IDA; [การวิเคราะห์เนทีฟ](../native-investigation.md)                                                                 |
+| ไบนารีเนทีฟ                    | โค้ดเทียม แอสเซมบลี สตริง สัญลักษณ์ การเรียก และการอ้างอิง                                | Hopper, Ghidra, IDA หรือ Kuna; [การวิเคราะห์เนทีฟ](../native-investigation.md)                                                           |
 | โครงสร้าง ELF แบบออฟไลน์       | เซกชัน เซกเมนต์ สัญลักษณ์/รีโลเคชันต้นฉบับ และตัวเลือกกลไกป้องกันที่พบจากการวิเคราะห์แบบสถิต      | pwntools ที่ผู้ใช้จัดเตรียมบน Linux x64; [การวินิจฉัยไบนารี](../binary-diagnostics.md)                                                          |
 | PE certificates              | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields    | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                              |
 | PE imports                   | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash      | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                        |
@@ -190,6 +190,8 @@ REA ต้องใช้ Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) หรื

 การตรวจสอบ JavaScript และ .NET แบบสถิตอ่านไฟล์ที่ให้มาโดยไม่รันแอปพลิเคชัน การบันทึกขณะทำงานจะรันหรือโต้ตอบกับเป้าหมายที่เลือกโดยใช้สิทธิ์ของผู้ใช้คุณ คู่มือการทำงานแต่ละฉบับอธิบายผลที่เกิดขึ้นไว้

+สำหรับการตรวจสอบไบนารีเนทีฟแบบออฟไลน์ REA ยังรองรับ GNU objdump และ Rizin ที่ผู้ใช้ต้องจัดหาเอง [คู่มือเครื่องมือวิศวกรรมย้อนกลับ](../reverse-engineering-tools.md) อธิบายการตั้งค่าผู้ให้บริการ คำสั่ง CLI และข้อจำกัดของ Evidence โดย REA จะไม่ติดตั้งหรืออัปเดตผู้ให้บริการทั้งสองนี้
+
 <a id="choosing-a-deep-analysis-provider"></a>

 สำหรับไบนารีขนาดใหญ่ เพิ่มเวลารอเริ่มต้นด้วย `REA_GHIDRA_STARTUP_TIMEOUT_MS` หรือ `REA_HOPPER_STARTUP_TIMEOUT_MS`
@@ -278,9 +280,9 @@ REA ส่งออกสภาพแวดล้อมที่รันได
 </details>

 <details>
-<summary><strong>จำเป็นต้องมี Hopper, Ghidra หรือ IDA หรือไม่?</strong></summary>
+<summary><strong>จำเป็นต้องมี Hopper, Ghidra, IDA หรือ Kuna หรือไม่?</strong></summary>

-การวิเคราะห์เนทีฟเชิงลึกต้องใช้หนึ่งในเครื่องมือเหล่านี้ การตรวจสอบ JavaScript และ .NET แบบสถิตทำงานได้โดยไม่มีเอนจินวิเคราะห์เนทีฟ ขั้นตอนตั้งค่าสามารถติดตั้ง Hopper หลังได้รับอนุมัติ ส่วน Ghidra และ IDA ใช้การติดตั้งที่คุณมีอยู่แล้ว ดู[การตั้งค่าผู้ให้บริการวิเคราะห์](../installation.md#hopper)
+การวิเคราะห์เนทีฟเชิงลึกต้องใช้หนึ่งในเครื่องมือเหล่านี้ การตรวจสอบ JavaScript และ .NET แบบสถิตทำงานได้โดยไม่มีเอนจินวิเคราะห์เนทีฟ ขั้นตอนตั้งค่าสามารถติดตั้ง Hopper หลังได้รับอนุมัติ ส่วน Ghidra, IDA และ Kuna ใช้การติดตั้งที่คุณมีอยู่แล้ว ดู[การตั้งค่าผู้ให้บริการวิเคราะห์](../installation.md#hopper)

 </details>

@@ -60,7 +60,7 @@ Bir uygulamada kendi ürününüze eklemek istediğiniz bir özellik mi gördün

 REA, ajanınızı yerel makine kodu içeren ikili dosyaları, JavaScript ve Electron uygulamalarını, .NET derlemelerini ve web sitelerini inceleyen araçlara bağlar. Aynı araçları terminalden de kullanabilirsiniz. Analiz yerel olarak çalışır; sonuçlar her çıkarımın dayandığı kanıtları ve sınırlamaları içerir.

-Kurulum, REA'yı ajanınıza kaydeder ve uyumlu iş akışı talimatlarını yükler. Yerel makine kodu analizi mevcut bir Hopper, Ghidra veya IDA kurulumunu kullanabilir; kurulum işlemi, onayınızla isteğe bağlı olarak Hopper da yükleyebilir. Statik JavaScript analizi bu yerel analiz motorlarından hiçbirine ihtiyaç duymaz.
+Kurulum, REA'yı ajanınıza kaydeder ve uyumlu iş akışı talimatlarını yükler. Yerel makine kodu analizi mevcut bir Hopper, Ghidra, IDA veya Kuna kurulumunu kullanabilir; kurulum işlemi, onayınızla isteğe bağlı olarak Hopper da yükleyebilir. Statik JavaScript analizi bu yerel analiz motorlarından hiçbirine ihtiyaç duymaz.

 > Kurulum talimatları, görselli rehberler ve gerçek örnek çalışmalar için **[REA web sitesini ziyaret edin](https://rea.tools/tr/)**.

@@ -149,7 +149,7 @@ REA; Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) veya 26+ (>=26.12.1) ve npm gere

 | Hedef                                   | REA'nın döndürdükleri                                                                                       | Gereksinimler ve rehber                                                                                                            |
 | --------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- |
-| Yerel makine kodu içeren ikili dosyalar | Sözde kod, assembly kodu, dizeler, semboller, çağrılar ve referanslar                                       | Hopper, Ghidra veya IDA; [yerel kod analizi](../native-investigation.md)                                                           |
+| Yerel makine kodu içeren ikili dosyalar | Sözde kod, assembly kodu, dizeler, semboller, çağrılar ve referanslar                                       | Hopper, Ghidra, IDA veya Kuna; [yerel kod analizi](../native-investigation.md)                                                     |
 | Çevrimdışı ELF yapısı                   | Bölümler, segmentler, özgün semboller/yeniden konumlandırmalar ve statik analizden olası güvenlik önlemleri | Linux x64 üzerinde çağıranın sağladığı pwntools; [ikili dosya tanılama](../binary-diagnostics.md)                                  |
 | Go ikili dosyaları                      | Gömülü compiler sürümü, modüller, replacement'lar ve build ayarları                                         | Yerleşik statik ELF/PE/thin Mach-O incelemesi; Go kurulumu gerekmez                                                                |
 | Rust ikili dosyaları                    | Gömülü cargo-auditable crate adları, sürümleri, kaynakları ve bağımlılık ilişkileri                         | Yerleşik statik ELF/PE/thin Mach-O incelemesi; [Rust ikili dosyaları](../rust-binaries.md)                                         |
@@ -274,9 +274,9 @@ Yerel MCP sunucularını destekleyen her ajan REA'yı kullanabilir. Kurulum, [de
 </details>

 <details>
-<summary><strong>Hopper, Ghidra veya IDA gerekiyor mu?</strong></summary>
+<summary><strong>Hopper, Ghidra, IDA veya Kuna gerekiyor mu?</strong></summary>

-Derin yerel kod analizi bunlardan birini kullanır. Statik JavaScript ve .NET incelemesi yerel analiz motoru olmadan çalışır. Kurulum onaydan sonra Hopper yükleyebilir; Ghidra ve IDA mevcut kurulumlarınızı kullanır. [Sağlayıcı kurulumuna](../installation.md#hopper) bakın.
+Derin yerel kod analizi bunlardan birini kullanır. Statik JavaScript ve .NET incelemesi yerel analiz motoru olmadan çalışır. Kurulum onaydan sonra Hopper yükleyebilir; Ghidra, IDA ve Kuna mevcut kurulumlarınızı kullanır. [Sağlayıcı kurulumuna](../installation.md#hopper) bakın.

 </details>

@@ -20,7 +20,7 @@

 **[Сайт](https://rea.tools/uk/) · [Посібники](https://rea.tools/uk/guides/) · [Приклади](https://rea.tools/uk/showcase/)**

-[Швидкий старт](#швидкий-старт) · [Як працює REA](#як-працює-rea) · [Що можна аналізувати](#що-можна-аналізувати) · [Приклади](#приклади) · [Створення RL-середовищ](#build-rl-environments) · [Поширені запитання](#поширені-запитання) · [Інструменти GNU objdump і Rizin](../reverse-engineering-tools.md) · [Документація](#документація)
+[Швидкий старт](#швидкий-старт) · [Як працює REA](#як-працює-rea) · [Що можна аналізувати](#що-можна-аналізувати) · [Приклади](#приклади) · [Створення RL-середовищ](#build-rl-environments) · [Поширені запитання](#поширені-запитання) · [Документація](#документація)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@

 REA підключає вашого агента до інструментів дослідження нативних бінарних файлів, застосунків JavaScript і Electron, збірок .NET та сайтів. Ті самі інструменти можна використовувати з термінала. Аналіз виконується локально, а результати містять підтвердження й обмеження, на яких ґрунтується кожен висновок.

-Налаштування реєструє REA в агенті та встановлює відповідні інструкції. Нативний аналіз використовує наявний Hopper, Ghidra або IDA; Hopper можна встановити після схвалення. Статичний аналіз JavaScript не потребує нативного рушія.
+Налаштування реєструє REA в агенті та встановлює відповідні інструкції. Нативний аналіз використовує наявний Hopper, Ghidra, IDA або Kuna; Hopper можна встановити після схвалення. Статичний аналіз JavaScript не потребує нативного рушія.

 > **[Відвідайте сайт REA](https://rea.tools/uk/)**, щоб знайти інструкції налаштування, ілюстровані посібники та реальні дослідження.

@@ -151,7 +151,7 @@ REA потребує Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) або 26+ (>=26

 | Ціль                                 | Що повертає REA                                                                                                   | Вимоги й посібник                                                                                                                                     |
 | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Нативні бінарні файли                | Псевдокод, асемблерний код, рядки, символи, виклики й посилання                                                   | Hopper, Ghidra або IDA; [нативний аналіз](../native-investigation.md)                                                                                 |
+| Нативні бінарні файли                | Псевдокод, асемблерний код, рядки, символи, виклики й посилання                                                   | Hopper, Ghidra, IDA або Kuna; [нативний аналіз](../native-investigation.md)                                                                           |
 | Структура ELF без запуску            | Секції, сегменти, початкові символи/релокації та можливі захисні механізми за даними статичного аналізу           | pwntools, наданий стороною, що викликає інструмент, у Linux x64; [діагностика бінарних файлів](../binary-diagnostics.md)                              |
 | PE certificates                      | Authenticode WIN_CERTIFICATE entries and PKCS#7 signer/X.509 identity fields                                      | Built-in static PE inspection; [PE certificates](../pe-certificates.md)                                                                               |
 | PE imports                           | Import and delay-load DLL names, ordinals, IAT RVAs and pefile import hash                                        | Built-in static PE inspection; [PE imports](../pe-imports.md)                                                                                         |
@@ -190,6 +190,8 @@ REA потребує Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) або 26+ (>=26

 Статична перевірка JavaScript і .NET читає надані файли, не запускаючи застосунок. Захоплення під час виконання запускає вибрану ціль або взаємодіє з нею з правами вашого користувача; відповідні посібники описують його вплив.

+Для автономного аналізу нативних бінарних файлів REA також підтримує GNU objdump і Rizin, які користувач надає самостійно. [Посібник з інструментів зворотної розробки](../reverse-engineering-tools.md) описує налаштування провайдерів, команди CLI та обмеження Evidence. REA не встановлює й не оновлює жодного з цих провайдерів.
+
 <a id="choosing-a-deep-analysis-provider"></a>

 Для великих файлів збільште час запуску через `REA_GHIDRA_STARTUP_TIMEOUT_MS` або `REA_HOPPER_STARTUP_TIMEOUT_MS`.
@@ -278,9 +280,9 @@ REA експортує готове до запуску середовище з
 </details>

 <details>
-<summary><strong>Чи потрібні мені Hopper, Ghidra або IDA?</strong></summary>
+<summary><strong>Чи потрібні мені Hopper, Ghidra, IDA або Kuna?</strong></summary>

-Поглиблений нативний аналіз використовує один із цих інструментів. Статична перевірка JavaScript і .NET працює без рушія нативного аналізу. Налаштування може встановити Hopper після схвалення; Ghidra й IDA використовують наявні встановлення. Дивіться [налаштування провайдерів](../installation.md#hopper).
+Поглиблений нативний аналіз використовує один із цих інструментів. Статична перевірка JavaScript і .NET працює без рушія нативного аналізу. Налаштування може встановити Hopper після схвалення; Ghidra, IDA й Kuna використовують наявні встановлення. Дивіться [налаштування провайдерів](../installation.md#hopper).

 </details>

@@ -62,7 +62,7 @@ Kisi app mein aisa feature dekha jo aap apne product mein chahte hain? Apne agen

 REA aapke agent ko native binaries, JavaScript aur Electron apps, .NET assemblies aur websites inspect karne wale tools se jorta hai. Yehi tools terminal se bhi use kar sakte hain. Analysis local machine par hota hai, aur har natije ke saath uske saboot aur limitations bhi milti hain.

-Setup REA ko aapke agent ke saath register karta hai aur uske mutabiq workflow instructions install karta hai. Native analysis ke liye pehle se installed Hopper, Ghidra ya IDA use ho sakta hai; aapki approval par setup Hopper bhi install kar sakta hai. Static JavaScript analysis ke liye native analysis engine ki zaroorat nahi.
+Setup REA ko aapke agent ke saath register karta hai aur uske mutabiq workflow instructions install karta hai. Native analysis ke liye pehle se installed Hopper, Ghidra, IDA ya Kuna use ho sakta hai; aapki approval par setup Hopper bhi install kar sakta hai. Static JavaScript analysis ke liye native analysis engine ki zaroorat nahi.

 > Setup instructions, tasveeron ke saath guides aur asli case studies ke liye **[REA ki website dekhein](https://rea.tools/)**.

@@ -187,7 +187,7 @@ Mazeed tools aur host support target par depend karte hain:
 | Target                  | REA kya wapas deta hai                                                                            | Zarooriyat aur guide                                                                                                              |
 | ----------------------- | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
 | Desktop installations   | Runtime candidates, supporting files, component markers aur agle probes                           | Built-in bounded directory/header inspection; [desktop applications](../desktop-applications.md)                                  |
-| Native binaries         | Pseudocode, assembly, strings, symbols, calls aur references                                      | Hopper, Ghidra ya IDA; [native analysis](../native-investigation.md)                                                              |
+| Native binaries         | Pseudocode, assembly, strings, symbols, calls aur references                                      | Hopper, Ghidra, IDA ya Kuna; [native analysis](../native-investigation.md)                                                        |
 | Offline ELF layout      | Sections, segments, original symbols/relocations aur static mitigation candidates                 | Linux x64 par aapka diya hua pwntools; [binary diagnostics](../binary-diagnostics.md)                                             |
 | Go binaries             | Embedded compiler version, modules, replacements aur build settings                               | Built-in static ELF/PE/thin Mach-O inspection; Go install karna zaroori nahi                                                      |
 | GPU code objects        | CUDA/HIP targets, selected kernel parameters aur resources, retained PTX text                     | Built-in static ELF/PE/fatbin/CUBIN/PTX inspection; [GPU code objects](../gpu-code-objects.md)                                    |
@@ -342,11 +342,11 @@ use kar sakte hain.
 </details>

 <details>
-<summary><strong>Kya mujhe Hopper, Ghidra ya IDA chahiye?</strong></summary>
+<summary><strong>Kya mujhe Hopper, Ghidra, IDA ya Kuna chahiye?</strong></summary>

 Deep native analysis in mein se ek use karta hai. Static JavaScript aur .NET
 inspection native analysis engine ke baghair kaam karti hai. Approval ke baad
-setup Hopper install kar sakta hai; Ghidra aur IDA ke liye aapki existing
+setup Hopper install kar sakta hai; Ghidra, IDA aur Kuna ke liye aapki existing
 installations use hoti hain. [Provider setup](../installation.md#hopper) dekhein.

 </details>
@@ -20,7 +20,7 @@

 **[Trang web](https://rea.tools/vi/) · [Hướng dẫn](https://rea.tools/vi/guides/) · [Các nghiên cứu điển hình](https://rea.tools/vi/showcase/)**

-[Bắt đầu nhanh](#bắt-đầu-nhanh) · [Cách REA hoạt động](#cách-rea-hoạt-động) · [Những gì bạn có thể phân tích](#những-gì-bạn-có-thể-phân-tích) · [Các nghiên cứu điển hình](#các-nghiên-cứu-điển-hình) · [Xây dựng môi trường RL](#build-rl-environments) · [Câu hỏi thường gặp](#câu-hỏi-thường-gặp) · [Công cụ GNU objdump và Rizin](../reverse-engineering-tools.md) · [Tài liệu](#tài-liệu)
+[Bắt đầu nhanh](#bắt-đầu-nhanh) · [Cách REA hoạt động](#cách-rea-hoạt-động) · [Những gì bạn có thể phân tích](#những-gì-bạn-có-thể-phân-tích) · [Các nghiên cứu điển hình](#các-nghiên-cứu-điển-hình) · [Xây dựng môi trường RL](#build-rl-environments) · [Câu hỏi thường gặp](#câu-hỏi-thường-gặp) · [Tài liệu](#tài-liệu)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@ Bạn thấy một tính năng trong ứng dụng và muốn đưa nó vào sả

 REA kết nối tác nhân của bạn với các công cụ kiểm tra tệp nhị phân mã máy, ứng dụng JavaScript và Electron, assembly .NET và trang web. Bạn cũng có thể dùng các công cụ đó từ terminal. Việc phân tích chạy cục bộ; kết quả bao gồm bằng chứng và giới hạn làm cơ sở cho từng kết luận.

-Thiết lập đăng ký REA với tác nhân và cài hướng dẫn công việc tương ứng. Phân tích native dùng Hopper, Ghidra hoặc IDA có sẵn; có thể cài Hopper sau khi bạn chấp thuận. Phân tích tĩnh JavaScript không cần công cụ phân tích native.
+Thiết lập đăng ký REA với tác nhân và cài hướng dẫn công việc tương ứng. Phân tích native dùng Hopper, Ghidra, IDA hoặc Kuna có sẵn; có thể cài Hopper sau khi bạn chấp thuận. Phân tích tĩnh JavaScript không cần công cụ phân tích native.

 > **[Truy cập trang web REA](https://rea.tools/vi/)** để xem cách thiết lập, hướng dẫn có hình minh họa và các nghiên cứu điển hình thực tế.

@@ -151,7 +151,7 @@ REA yêu cầu Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) hoặc 26+ (>=26.12.1)

 | Mục tiêu                          | REA trả về gì                                                                                                   | Yêu cầu và hướng dẫn                                                                                                                            |
 | --------------------------------- | --------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------- |
-| Tệp nhị phân mã máy               | Mã giả, hợp ngữ, chuỗi, ký hiệu, lời gọi và tham chiếu                                                          | Hopper, Ghidra hoặc IDA; [phân tích mã máy](../native-investigation.md)                                                                         |
+| Tệp nhị phân mã máy               | Mã giả, hợp ngữ, chuỗi, ký hiệu, lời gọi và tham chiếu                                                          | Hopper, Ghidra, IDA hoặc Kuna; [phân tích mã máy](../native-investigation.md)                                                                   |
 | Bố cục ELF ngoại tuyến            | Các section, segment, ký hiệu/thông tin tái định vị gốc và các biện pháp giảm thiểu có thể có từ phân tích tĩnh | pwntools do bên gọi cung cấp trên Linux x64; [chẩn đoán tệp nhị phân](../binary-diagnostics.md)                                                 |
 | Bytecode EVM                      | Bộ chọn điều phối, độ lệch byte, tham số suy luận và khả năng thay đổi trạng thái                               | Đầu vào cục bộ chứa byte thô hoặc dạng thập lục phân trên Linux x64; [hướng dẫn EVM ngoại tuyến](../evm-bytecode.md)                            |
 | Rust binaries                     | Embedded cargo-auditable dependency list                                                                        | [Rust binaries](../rust-binaries.md)                                                                                                            |
@@ -190,6 +190,8 @@ REA yêu cầu Node.js 22.x (>=22.23.4), 24.x (>=24.22.1) hoặc 26+ (>=26.12.1)

 Kiểm tra tĩnh JavaScript và .NET đọc các tệp được cung cấp mà không chạy ứng dụng. Ghi lại khi chạy sẽ khởi chạy hoặc tương tác với mục tiêu đã chọn bằng quyền người dùng của bạn; từng hướng dẫn mô tả tác động của nó.

+Để kiểm tra tệp nhị phân native ngoại tuyến, REA cũng hỗ trợ GNU objdump và Rizin do bạn tự cung cấp. [Hướng dẫn công cụ dịch ngược](../reverse-engineering-tools.md) trình bày cách thiết lập nhà cung cấp, các lệnh CLI và giới hạn của Evidence. REA không cài đặt hoặc cập nhật hai nhà cung cấp này.
+
 <a id="choosing-a-deep-analysis-provider"></a>

 Với tệp nhị phân lớn, tăng hạn khởi động bằng `REA_GHIDRA_STARTUP_TIMEOUT_MS` hoặc `REA_HOPPER_STARTUP_TIMEOUT_MS`.
@@ -278,9 +280,9 @@ Bất kỳ tác nhân nào hỗ trợ máy chủ MCP cục bộ. Quá trình thi
 </details>

 <details>
-<summary><strong>Tôi có cần Hopper, Ghidra hoặc IDA không?</strong></summary>
+<summary><strong>Tôi có cần Hopper, Ghidra, IDA hoặc Kuna không?</strong></summary>

-Phân tích mã máy chuyên sâu sử dụng một trong những công cụ đó. Kiểm tra tĩnh JavaScript và .NET hoạt động mà không cần bộ máy phân tích mã máy. Quá trình thiết lập có thể cài Hopper sau khi được chấp thuận; Ghidra và IDA dùng bản cài đặt sẵn có. Xem [thiết lập trình phân tích](../installation.md#hopper).
+Phân tích mã máy chuyên sâu sử dụng một trong những công cụ đó. Kiểm tra tĩnh JavaScript và .NET hoạt động mà không cần bộ máy phân tích mã máy. Quá trình thiết lập có thể cài Hopper sau khi được chấp thuận; Ghidra, IDA và Kuna dùng bản cài đặt sẵn có. Xem [thiết lập trình phân tích](../installation.md#hopper).

 </details>

@@ -20,7 +20,7 @@

 **[網站](https://rea.tools/zh-TW/) · [指南](https://rea.tools/zh-TW/guides/) · [案例](https://rea.tools/zh-TW/showcase/)**

-[快速開始](#快速開始) · [REA 的工作原理](#rea-的工作原理) · [可以分析什麼](#可以分析什麼) · [案例](#案例) · [建立 RL 環境](#build-rl-environments) · [常見問題](#常見問題) · [GNU objdump 與 Rizin 工具](../reverse-engineering-tools.md) · [文件](#文件)
+[快速開始](#快速開始) · [REA 的工作原理](#rea-的工作原理) · [可以分析什麼](#可以分析什麼) · [案例](#案例) · [建立 RL 環境](#build-rl-environments) · [常見問題](#常見問題) · [文件](#文件)

 <code>npx rea-agents setup</code>

@@ -60,7 +60,7 @@

 REA 將 AI 代理連接到分析工具，用於檢查原生二進位檔案、JavaScript 和 Electron 應用、.NET 程式集以及網站。你也可以在終端中使用同樣的工具。分析在本機執行，結果包含支撐各項結論的證據和相關限制。

-設定流程會向 AI 代理註冊 REA，並安裝對應的工作流程指引。原生分析可以使用已有的 Hopper、Ghidra 或 IDA；設定流程也可以在你核准後安裝 Hopper。靜態 JavaScript 分析不需要原生分析引擎。
+設定流程會向 AI 代理註冊 REA，並安裝對應的工作流程指引。原生分析可以使用已有的 Hopper、Ghidra、IDA 或 Kuna；設定流程也可以在你核准後安裝 Hopper。靜態 JavaScript 分析不需要原生分析引擎。

 > **[訪問 REA 網站](https://rea.tools/zh-TW/)**，查看設定說明、圖解指南和真實案例。

@@ -149,7 +149,7 @@ REA 需要 Node.js 22.x（>=22.23.4）、24.x（>=24.22.1）或 26+ (>=26.12.1)

 | 目標                  | REA 返回的內容                                                               | 要求與指南                                                                                                         |
 | --------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
-| 原生二進位檔案        | 偽程式碼、組合語言、字串、符號、呼叫和引用                                   | Hopper、Ghidra 或 IDA；[原生分析](../native-investigation.md)                                                      |
+| 原生二進位檔案        | 偽程式碼、組合語言、字串、符號、呼叫和引用                                   | Hopper、Ghidra、IDA 或 Kuna；[原生分析](../native-investigation.md)                                                |
 | 離線 ELF 佈局         | 節、段、原始符號/重定位資訊及靜態防護機制候選項                              | Linux x64 上由呼叫方提供的 pwntools；[二進位診斷](../binary-diagnostics.md)                                        |
 | Go 二進位檔案         | 內嵌編譯器版本、模組、替換項和建置設定                                       | 內建靜態 ELF/PE/thin Mach-O 檢查；無需安裝 Go                                                                      |
 | WASM 工件             | 驗證、節、精確的匯入/匯出 WAT 形式及解碼後的 WAT                             | 呼叫方提供的 WABT 1.0.42；`inspect_wasm_artifact`                                                                  |
@@ -188,6 +188,8 @@ REA 需要 Node.js 22.x（>=22.23.4）、24.x（>=24.22.1）或 26+ (>=26.12.1)

 靜態 JavaScript 和 .NET 檢查讀取提供的檔案，不執行應用。執行階段擷取會以你的使用者權限執行目標或與之互動；各執行階段指南說明瞭具體影響。

+若要離線檢查原生二進位檔，REA 也支援由呼叫端自行提供的 GNU objdump 和 Rizin。[逆向工程工具指南](../reverse-engineering-tools.md)說明了分析提供者的設定、CLI 指令及 Evidence 的限制。REA 不會安裝或更新這兩個分析提供者。
+
 <a id="choosing-a-deep-analysis-provider"></a>

 大型二進位檔可透過 `REA_GHIDRA_STARTUP_TIMEOUT_MS` 或 `REA_HOPPER_STARTUP_TIMEOUT_MS` 延長提供者啟動期限。
@@ -278,9 +280,9 @@ REA 匯出可直接執行的環境，並附帶基本測試，檢查環境能否
 </details>

 <details>
-<summary><strong>需要 Hopper、Ghidra 或 IDA 嗎？</strong></summary>
+<summary><strong>需要 Hopper、Ghidra、IDA 或 Kuna 嗎？</strong></summary>

-深入的原生分析需要其中一個引擎。靜態 JavaScript 和 .NET 檢查不需要原生分析引擎。設定流程可以在你核准後安裝 Hopper；Ghidra 和 IDA 則使用已有安裝。見[提供者設定](../installation.md#hopper)。
+深入的原生分析需要其中一個引擎。靜態 JavaScript 和 .NET 檢查不需要原生分析引擎。設定流程可以在你核准後安裝 Hopper；Ghidra、IDA 和 Kuna 則使用已有安裝。見[提供者設定](../installation.md#hopper)。

 </details>

@@ -60,7 +60,7 @@

 REA 将智能体连接到分析工具，用于检查原生二进制文件、JavaScript 和 Electron 应用、.NET 程序集以及网站。你也可以在终端中使用同样的工具。分析在本机运行，结果包含支撑各项结论的证据和相关限制。

-设置流程会向智能体注册 REA，并安装匹配的工作流指引。原生分析可以使用已有的 Hopper、Ghidra 或 IDA；设置流程也可以在你批准后安装 Hopper。静态 JavaScript 分析不需要原生分析引擎。
+设置流程会向智能体注册 REA，并安装匹配的工作流指引。原生分析可以使用已有的 Hopper、Ghidra、IDA 或 Kuna；设置流程也可以在你批准后安装 Hopper。静态 JavaScript 分析不需要原生分析引擎。

 > **[访问 REA 网站](https://rea.tools/zh-CN/)**，查看设置说明、图解指南和真实案例。

@@ -149,7 +149,7 @@ REA 需要 Node.js 22.x（>=22.23.4）、24.x（>=24.22.1）或 26+ (>=26.12.1)

 | 目标                  | REA 返回的内容                                                               | 要求与指南                                                                                                         |
 | --------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
-| 原生二进制文件        | 伪代码、汇编、字符串、符号、调用和引用                                       | Hopper、Ghidra 或 IDA；[原生分析](../native-investigation.md)                                                      |
+| 原生二进制文件        | 伪代码、汇编、字符串、符号、调用和引用                                       | Hopper、Ghidra、IDA 或 Kuna；[原生分析](../native-investigation.md)                                                |
 | 离线 ELF 布局         | 节、段、原始符号/重定位信息及静态防护机制候选项                              | Linux x64 上由调用方提供的 pwntools；[二进制诊断](../binary-diagnostics.md)                                        |
 | Go 二进制文件         | 内嵌编译器版本、模块、替换项和构建设置                                       | 内置静态 ELF/PE/thin Mach-O 检查；无需安装 Go                                                                      |
 | WASM 工件             | 验证、节、精确的导入/导出 WAT 形式及解码后的 WAT                             | 调用方提供的 WABT 1.0.42；`inspect_wasm_artifact`                                                                  |
@@ -278,9 +278,9 @@ REA 导出可直接运行的环境，并附带基本测试，检查环境能否
 </details>

 <details>
-<summary><strong>需要 Hopper、Ghidra 或 IDA 吗？</strong></summary>
+<summary><strong>需要 Hopper、Ghidra、IDA 或 Kuna 吗？</strong></summary>

-深入的原生分析需要其中一个引擎。静态 JavaScript 和 .NET 检查不需要原生分析引擎。设置流程可以在你批准后安装 Hopper；Ghidra 和 IDA 则使用已有安装。见[提供方设置](../installation.md#hopper)。
+深入的原生分析需要其中一个引擎。静态 JavaScript 和 .NET 检查不需要原生分析引擎。设置流程可以在你批准后安装 Hopper；Ghidra、IDA 和 Kuna 则使用已有安装。见[提供方设置](../installation.md#hopper)。

 </details>

@@ -14,6 +14,9 @@ cannot. This increment adds the view kind only; serving from the state, loading
 another state through the AgentEnv data plane and modelling write effects are
 later increments.

+Safe `HEAD`, `OPTIONS` and `TRACE` tools have recorded views with reason
+`method-replay`; state rendering currently applies only to `GET` reads.
+
 ## Requirements

 - Accept `inspect_web_network_capture` HAR parents and
@@ -0,0 +1,11 @@
+# Implementation plan
+
+1. **Sorted creates.** Placed creates whose confirming read was a whole listing in collection order may be placed
+   again; narrowing keeps the sorts a later listing follows and adds those its items show, the type's id field last.
+2. **Listed references.** `referenceRule` reads a sent list of ids; `many` on the reference rule and its schema;
+   `referencedValue` maps each id; the create merge lets an empty reference agree and frees the members it fixed.
+3. **Hidden bodies.** Scenario records give a request with a body Playwright did not expose, and no `Content-Type`, a
+   `bodySize` of 0.
+4. **Toggles.** `toggledRules` turns a plan's `set` and a later call's opposite `set` into `toggle`; the rule's schema,
+   serving, later-call checks and the action verdict.
+5. **Skill, tests and docs.**
@@ -0,0 +1,41 @@
+# Serve sorted creates, listed references and toggles
+
+Issue: https://github.com/morluto/rea/issues/4933
+
+## Outcome
+
+Over 148 recorded captures (the 130 measured before and 18 from a fresh recording round), #7539 withholds 302 of 694
+write plans. A short diagnosis of the largest clusters found three gaps REA could close:
+
+- **A create's sort learned too late.** Grafana lists folders by title. A recording's first scratch folder sorted
+  after the one seeded folder, so the plan placed creates last; the second sorted before the first, the list after it
+  contradicted the plan, and the update and delete after that went unconfirmed.
+- **Lists of references.** Homebox creates an item from `parentId` and `tagIds` and answers with the parent and tag
+  objects. REA modelled a parent but not a list of tags, and a create that sent `null` and `[]` disagreed with one that
+  named both.
+- **Toggles.** Miniflux stars and unstars an entry with a body-less `PUT /v1/entries/{id}/bookmark`. Chromium exposes
+  no body for it, which REA read as unusable, and an action flipping a flag back was taken to contradict the call that
+  set it.
+
+## Behaviour
+
+- **Sorted creates.** A create a whole listing in collection order placed last is placed again by a field a later such
+  listing shows it sorted by, the type's id field last. A sort an earlier such listing did not follow stays ruled out,
+  though the entity that showed it is gone. A create another read placed keeps its place.
+- **Listed references.** A field holding one object per id a sent list names, in that order, is a `reference` with
+  `many`. A create that sent the member as `null` or `[]` and stored the field so agrees with one that named entities,
+  whichever create first showed the reference;
+  serving stores the entities a call names, or the empty value as that create did. A `null` id stays refused where
+  no recorded create sent one, and a call leaving the member out stores no field where the observed create showed
+  none.
+- **Hidden bodies.** A scenario request whose body Playwright did not expose and that names no `Content-Type` sent no
+  body.
+- **Toggles.** An item action a later call shows flipping back a boolean an earlier call set, when no call found it
+  already set, has a `toggle` rule: serving flips the field, refusing an entity that holds no boolean there.
+- **Skill.** Recordings run an action twice in a row on one object, reading it back after each (skill 55).
+
+Plans and views that need none of this are unchanged.
+
+## Acceptance
+
+- No write of the 148 captures goes from served to withheld, and no view changes.
@@ -0,0 +1,11 @@
+# Tasks
+
+- [x] Place a create again by the sort a later whole listing shows.
+- [x] Learn and serve references a sent list of ids names, and let an empty reference agree.
+- [x] Treat a hidden request body without a `Content-Type` as absent.
+- [x] Learn, check and serve toggles.
+- [x] Ask recordings to run an action twice on one object.
+- [x] Add view, serving, record and unit tests.
+- [x] Document the rules.
+- [x] Measure the recorded captures.
+- [x] Run static, formatting, documentation and test gates.
@@ -0,0 +1,88 @@
+# Verification
+
+Executed on macOS with Node v24.22.1 on this branch and on #7539 at `30e2a582`; the census and the base reproduction
+were repeated after merging #7539 at `2817665d`, `174a0ff2`, `5691f97f` (which merges main with #7332)
+and `3b800a10`.
+
+## Diagnosis
+
+Over 148 recorded captures, #7539 withholds 302 of 694 write plans. The largest clusters: Homebox item writes (36),
+unconfirmed deletes (23), Grafana's feature-flag evaluation calls (15, which change no state), Linkding renumbering
+bundles after a delete (7) and Miniflux's bookmark toggle (5).
+
+- **Grafana.** A fresh recording created "Scratch Pier 3", which the list after it showed after the one seeded folder,
+  then "Scratch Meadow Notes 4", which the list after it showed before the first, by title. The create plan had settled
+  on `last` when the first list confirmed it, so the second list contradicted it, and the folder update and delete
+  after it went unconfirmed.
+- **Homebox.** Item creates send `parentId` and `tagIds` and answer with `parent` and `tags` objects. The recording
+  that created one item with neither (`null` and `[]`) and one with both was withheld: `tags` had no rule, and the
+  first create fixed both members to their empty values.
+- **Miniflux.** `PUT /v1/entries/{id}/bookmark` sends no body and answers `204`. Chromium exposes no body for it and
+  the request names no `Content-Type`; REA read the body as unusable. Across the captures, every `POST`, `PUT` or
+  `PATCH` whose body was captured names `content-type` among its request header names (835 of 835).
+
+## Gates
+
+- `npm run -s check:fast`, `format:check`, `knip`, `scan:todos`, `docs:check`, `verify:test-discovery`,
+  `mcp-catalog:check` and `jscpd`: passed.
+- `npx vitest run --project domain --project services`: 11,886 passed, 6 skipped, merged with `3b800a10`. An earlier run of the suite failed a
+  `SetupRegistrationPrewarm` runner test whose child process outran its 5-second timeout; alone it passes on this
+  branch and on #7539 (3.0 to 4.7 seconds).
+- `npm run -s test:focused --` the environment build, export and serve CLI boundaries, the analysis-view CLI and MCP
+  boundaries and the environment serve MCP boundary: 7 files, 81 passed. `outputSchemaProfile`, `toolSchemaValidity`,
+  `mcpSchemaValidation`, `outputSchemaSemanticConstraints` and `analysisViewMcp`: 5 files, 54 passed; the compact
+  catalog stays under its frame.
+
+## Tests
+
+- View: a create placed last, then a create a later whole listing shows before it by title, learns `title` ascending
+  and its delete is served; an item create naming its parent and tags by id, after one naming none, learns
+  `reference` rules for `parent` and for `tags` (`many`) and is served; a body-less action two calls show starring
+  then unstarring an entry learns `toggle` and is served, and is not when its calls flip the flag one way only or a
+  later call leaves it unchanged.
+- Serving: a create stores the parent and the tags its ids name, in the order sent; a create leaving out both, or
+  sending them as `null` and `[]`, stores `null` and `[]`; a tag the environment does not hold is refused, and so is a
+  `null` shelf where every recorded create named one; an entry the recording never starred flips on each call.
+- Records: a hidden request body is absent when the request names no `Content-Type`, and stays unusable when it names
+  one.
+- The nine behaviour tests fail on #7539 at `30e2a582`, `2817665d`, `174a0ff2`, `5691f97f` and `3b800a10`; the three that guard toggles and `null` ids
+  pass there too.
+
+## Write plans and views over recorded captures
+
+The 148 captures, built by #7539 and by this branch: 694 plans, 392 served and 399, both at `30e2a582` and after
+merging `2817665d`, `174a0ff2`, `5691f97f` and
+`3b800a10`.
+
+- No write goes from served to withheld, and no served plan changes. Newly served: Grafana's folder create, update and
+  delete in a fresh recording; Homebox's item create in another; Miniflux's bookmark toggle in three recordings.
+- Five withheld plans explain more. Two Miniflux recordings learn the toggle but stay withheld: a list of starred
+  entries with no `order` parameter lists them by `published_at`, which REA answers in state order. Linkding's
+  unarchive learns its body-less call and stays `unconfirmed`, seen once. Two Homebox item writes learn their tag
+  references and stay withheld for other members.
+- Views are unchanged: 3,188 views across the captures.
+
+## Review round
+
+Greptile's review of `4e777d28` raised five findings. Two were in this branch's code and are fixed:
+
+- A sort an earlier whole listing ruled out could come back from a later listing once the entity that ruled it out was
+  deleted, and a create's retry could adopt it. Each create now keeps the sorts its whole listings did not follow.
+- A create sending a reference's member as `null` after a later create added the reference, the first having shown no
+  such field, was withheld: the empty-reference agreement now applies there too.
+
+Both tests fail on `4e777d28` and on #7539 at `174a0ff2`; the census is unchanged. The other three were in #7332's and
+#7539's code: `308aebf0` (#7332), already here, covers the made-object count, and #7539's `174a0ff2`, merged here,
+fixes the update default and the read clock spelling.
+
+Greptile's review of `f7c1bfe9` raised one more, fixed: once a later create sent a reference's member as `null`, a
+served create leaving the member out stored `null`, though the create the plan observes left it out and stored no such
+field. Serving now leaves the field out there, and still stores `null` for a call that sends it; the serving test fails
+on `f7c1bfe9`. The census is unchanged.
+
+## Not verified
+
+- No environment was rebuilt and run with agents for this branch, and no recording was made with skill 55.
+- The order an application gives a list read with no sort parameter (Miniflux's `published_at`) when it is not state
+  order.
+- The rest of the Homebox cluster: `assetId` numbering and item updates; Linkding renumbering bundles after a delete.
@@ -0,0 +1,9 @@
+# Implementation plan
+
+1. **Update members.** `refinedBody` keeps only the required members a later update also sent.
+2. **Numbered unless sent.** `sent` on sequence rules and their schema; the create merge adopts it for an echoed member
+   and a sequence from a call that left the member out; serving and replay take the sent value when there is one.
+3. **Cleared by a PUT.** `explainUpdate` records a `PUT`'s left-out member cleared to an empty value as a default;
+   update refinement keeps defaults from later calls; `updatedFields` applies them to members a call leaves out.
+4. **Update clocks.** `restampedFields` respells clocks from the first later read as it does nested clocks.
+5. **Skill, tests and docs.**
@@ -0,0 +1,56 @@
+# Serve writes whose calls send different members
+
+Issue: https://github.com/morluto/rea/issues/4933
+
+## Outcome
+
+A fresh recording round of seven applications, main against #7332, showed the recording skill now varies what the two
+creates and two updates of a type send, as it asks. Where the second call left out a member the first sent, REA
+withheld the write:
+
+- **Updates.** An update plan required every member its first call sent and never narrowed that, so EspoCRM's second
+  contact update, which changed only an email address, was refused in both recordings of the branch.
+- **Members numbered when left out.** Linkding stores a bundle's `order` as sent, or one past the others when a call
+  leaves it out. One create showed the first and another the second, which the create merge took as a disagreement.
+
+The same recordings and the 130 earlier captures showed two more update gaps:
+
+- **Whole-object PUTs.** Paperless clears a tag's, correspondent's or document type's `owner` when a `PUT` leaves it
+  out, and Homebox an item's `assetId`, so those updates were `unexplained-change`.
+- **Update clocks read at another precision.** Vikunja answers a task update with `done_at` to the nanosecond while its
+  reads spell it to the second, so the read after the update contradicted it.
+
+The round also found two creates of EspoCRM contacts in one second, which a list sorted newest first shows in an order
+the application breaks ties in. The skill now spaces creates.
+
+## Behaviour
+
+- **Update members.** A later update narrows the plan's required members to those every call sent.
+- **Numbered unless sent.** A member one create sent and stored as sent, and another left out and the application
+  numbered one past the others, is a `sequence` with `sent`, in either order: serving stores the value a call sends,
+  else the next number, and a later call that sends it must have stored what it sent. The next number follows the
+  largest value any call took, a deleted entity's included, in replay as in serving.
+- **Cleared by a PUT.** A field a `PUT` left out that the application cleared to an empty value (`""`, `null`, `false`,
+  `[]` or `{}`) is that member's default (`body.defaults`) when every call that left it out stored that value, as its
+  answer shows it or, where the answer leaves the member out, the read after it: serving stores it for an update that
+  leaves the member out. Calls that left it out and stored it otherwise withhold the plan.
+- **Update clocks.** The state holds an update's clock as the first read of the entity after it spells the same instant
+  at a coarser precision in the same zone and separator, as it already does for nested clocks: replay and serving store
+  every update's clocks in the spelling of the read the plan keeps as `observation.read`, so a later update whose read
+  spells them otherwise contradicts the plan, while answers keep the update's own. A create's clocks stay as answered,
+  as serving makes them.
+- **Skill.** Recordings leave more than a second between two creates, as between a create and its first edit.
+
+Plans and views that need none of this are unchanged.
+
+## Not covered
+
+- Vikunja numbers tasks per project. Creates into projects the recording did not list cannot be numbered, so its task
+  creates stay withheld.
+- Linkding renumbers bundles' `order` after a delete, which no rule models.
+- Homebox item creates expand sent tag ids into tag objects and pin `parentId`; they stay withheld.
+
+## Acceptance
+
+- No write tool of the recorded captures goes from served to withheld.
+- The writes the diagnosis named are served where their recordings show nothing else against them.
@@ -0,0 +1,11 @@
+# Tasks
+
+- [x] Narrow an update plan's required members to those every call sent.
+- [x] Serve a member the value a call sends, else the next number, when calls showed both.
+- [x] Learn and serve the value a `PUT` stores for a member it leaves out.
+- [x] Hold an update's clock as the read after it spells it.
+- [x] Ask recordings to space creates.
+- [x] Add view, serving and unit tests.
+- [x] Document the rules.
+- [x] Measure the recorded captures.
+- [x] Run static, formatting, documentation and test gates.
@@ -0,0 +1,95 @@
+# Verification
+
+Executed on macOS with Node v24.22.1 on this branch, on #7332 at `7d01a5d5` (main `5aa23c3d`), and on Ubuntu 24.04 VMs
+with snap Chromium for the recording round.
+
+## Diagnosis
+
+Claude Code (`claude-sonnet-5-5`) built an environment of each of seven applications from the same prompt, once with
+REA main `5aa23c3d` (skill 50) and once with #7332 at `7d01a5d5` (skill 53). Each bundle's write tasks ran with
+`fireworks_ai/gpt-oss-120b` and `fireworks_ai/glm-5p3-flash`, which scored alike:
+
+| Application | Write tasks | Main    | #7332   |
+| ----------- | ----------- | ------- | ------- |
+| Miniflux    | 3           | 3/3     | 3/3     |
+| Grafana     | 2           | 2/2     | 2/2     |
+| Vikunja     | 3 + 2       | 0/3 0/2 | 1/3 2/2 |
+| Paperless   | 3           | 1/3     | 2/3     |
+| Linkding    | 2           | 0/2     | 2/2     |
+| Homebox     | 2           | 2/2     | 0/2     |
+| EspoCRM     | 3           | 1/3     | 0/3     |
+| Total       | 20          | 9/20    | 12/20   |
+
+Served writes were 14 and 25. Recorded again, Homebox and EspoCRM gave main 2/2 and 1/3 and #7332 2/2 and 3/3: the
+first losses were the agents' runs, not REA. Built with both versions, none of the 18 recordings served fewer writes
+with #7332 (44 and 53 in all).
+
+Replaying #7332's recordings with failing checks and refusals logged gave the causes this branch takes: EspoCRM's
+second contact update left out `addressCity` and was refused for lacking a required member (both recordings); Linkding's
+second bundle create left `order` to the application, which the merge took as disagreeing with the first create's
+echo; Vikunja's task update stamped `done_at` to the nanosecond where the read after it showed seconds. Over the
+earlier captures, 14 withheld updates were `PUT`s whose application cleared a member they left out (Paperless `owner`,
+Homebox `assetId`).
+
+## Gates
+
+- `npm run -s check:fast`, `format:check`, `scan:todos`, `docs:check`, `verify:test-discovery`, `mcp-catalog:check` and
+  `jscpd`: passed. `npx knip` reports `staticFileUrlPath`, `ObjcClassImportBindingCoverage` and
+  `AndroidManifestComponentInventory`, as main `5aa23c3d` does.
+- `npx vitest run --project domain --project services`: 11,694 passed, 8 failed (`appleApplication.test.ts`), which fail
+  the same way on main `5aa23c3d`.
+- `npm run -s test:focused --` the environment build, export and serve CLI boundaries, the analysis-view CLI and MCP
+  boundaries and the environment serve MCP boundary: 80 passed. `outputSchemaProfile`, `toolSchemaValidity`,
+  `mcpSchemaValidation`, `outputSchemaSemanticConstraints` and `analysisViewMcp`: 54 passed; the compact catalog stays
+  under its frame.
+- The seven new view and serving tests fail on #7332 at `7d01a5d5` and pass here.
+
+## Write plans over recorded captures
+
+The 130 captures #7332 measured and the round's 18 recordings, built by #7332 at `7d01a5d5` and by this branch: 694
+plans, 386 served and 398. No write goes from served to withheld and every view is unchanged. Newly served:
+
+- Paperless correspondent, document type and tag updates in four recordings, whose `PUT` clears `owner`.
+- EspoCRM's contact update and Linkding's bundle create in #7332's recordings of the round.
+- Grafana's folder update and delete in a fresh recording whose second update sent fewer members.
+- Homebox's item update in the published capture, whose `PUT` clears `assetId`.
+
+Vikunja's task update reads back confirmed, but stays withheld: the task creates before it are not modelled (per-project
+numbers), so their entities carry the creates' answer spellings into later reads.
+
+## Review round
+
+- Greptile's first review: a `sequence` with `sent` now accepts a value a later create sent, whichever create came
+  first; a default must agree with every update that left its member out, else the plan is withheld; and serving
+  stores an update's clocks as the update plan's read-back spells them (`observation.read`). Their four tests fail on
+  `6300ec80`. #7332's made-object clock check, merged in, has its test there.
+- Gates as above: `domain` + `services` 11,699 passed, 8 failed (main's `appleApplication.test.ts`); focused boundaries
+  80 passed; the five MCP schema files 54 passed. The census stays at 694 plans and 398 served, with no plan or view
+  changing.
+
+Greptile's review after main `21b19270` was merged in (`467ac78f`) raised three more, fixed:
+
+- A member a call left out and the application stored a fixed value for (`body.defaults`) is no longer turned into a
+  `sequence` with `sent` by a later call that left it out and got the next number.
+- Serving stores an update's clock at a coarser read's precision from the answer's own digits, so an answer to the
+  nanosecond read back to the microsecond keeps its microseconds.
+- A `PUT` that names a `reference` field's entity by its member supplies that field: it is not checked against, or
+  given, the default a `PUT` that left the field out showed, whichever of the two calls came first.
+
+Their tests fail on `467ac78f`, and the reference case with the clearing call first on `7030ca4d`. Gates pass but
+`knip`, whose one finding main `21b19270` reports too; `domain` + `services` 12,046 passed; focused boundaries 82 passed; the five MCP schema files 55 passed. Over the 148 captures, main
+serves 380 writes and this branch 392, with no plan or view changing from `467ac78f`.
+
+Greptile's review of `b56f8924` raised two more on numbered members, fixed: a member a call sent empty (`""`) is no
+longer filled in for a call that leaves it out when a `sequence` with `sent` numbers it; and a later create the
+application numbered at or below a value an earlier create sent (9 sent and deleted, then 2) no longer turns the echo
+into a numbered `sequence`, since serving counts past every value a call sent. Their tests fail on `b56f8924`; gates
+pass but `knip` (main's finding), `domain` + `services` 12,048 passed, and the census is unchanged. Greptile's next
+review found that check counting values sent in other collections, which withheld a create numbered within its own
+collection; the check now counts them in the sequence's scope, and its test fails on `d4922b3d`.
+
+## Not verified
+
+- No recording round ran with this branch, so its write tasks are not measured.
+- The skill's spacing of creates.
+- Vikunja per-project task numbers, Linkding's renumbering after a delete and Homebox item creates, which stay withheld.
@@ -301,8 +301,9 @@ Turbo caches deterministic preparation and static checks, but `test:run` always
 executes. Repository files do not fully describe installed tool contents or host
 state. A previous test pass therefore cannot replace current validation, even
 when the source tree is unchanged. `check:pr` also runs the fast Python producer
-suite; CI runs it in the static job for code changes. These producer tests do not
-establish real LLDB engine coverage.
+suite. Fast CI runs it from the selected Python job after installing dependencies
+and preparing the compiled runtime; full qualification runs it from the deep
+static job. These producer tests do not establish real LLDB engine coverage.

 Vitest's persistent compile cache remains disabled. The `cliTest` fixture shares
 a temporary Node compile cache among its fresh CLI subprocesses. The worker
@@ -381,6 +382,38 @@ matching real-provider lane.
 | Client configuration or schema conversion | [Native client lane](client-verification.md)                  | Distinguish loopback models from live services              |
 | Agent investigation quality               | [Agent evaluation](#agent-evaluation-and-conformance-records) | Review transcript and scenario-specific evidence            |

+### Provider-backed workflow verification
+
+For a new or changed provider-backed tool, select tests from the analyst's
+question and the facts the contract claims, not from an upstream command list.
+Use the existing workflow as a baseline and identify what the proposed tool
+adds. Choose the relevant cases below; do not require every provider or a
+Cartesian matrix when it would not change the claim.
+
+When auditing existing tools, compare selected analyst workflows with the cases
+their existing tests and real-provider lanes actually exercise. Run relevant
+public workflows and focused checks; report untested scenarios rather than
+inferring that a green test proves them or that no prior testing occurred. A fix
+should add a regression for the demonstrated failure at its owning boundary and
+affected consumer.
+
+- Use a controlled target with independently known facts and a meaningful
+  counterexample. Compare native provider output with the target or a
+  format-aware oracle; a provider label, a mock, or another REA projection is
+  not independent proof of the underlying fact.
+- Exercise the affected public CLI/MCP workflow, including handoffs between
+  calls. Assert the requested result, caller-selected inputs, source identity,
+  evidence and coverage. Check that unavailable, partial and empty outcomes
+  retain their different meanings across the producing and consuming boundaries.
+- Where relevant, continue after a mixed success, failed request, cancellation
+  or close/reopen. Verify the next supported recovery and preservation of prior
+  results and resource ownership. Use the applicable lifecycle regressions below.
+- Record the provider version, host, fixture, actual entrypoint, controlled
+  faults and skipped or unavailable coverage. A simulated provider tests the
+  integration boundary; a scripted sequence tests that sequence, not an agent's
+  ability to discover it. Run the matching real-provider and agent lanes when
+  their respective claims require them.
+
 ## Test design and pruning

 Prefer real public CLI/MCP workflows, then production-boundary integration,
@@ -480,6 +513,18 @@ and retain representative compiled CLI parity checks. Every distinct source
 scenario still runs through the public workflow; session-lifecycle scenarios
 need their own sessions and cleanup assertions.

+Complete-inline-Evidence conformance uses
+`scripts/lib/mcp-verification-environment.mjs`: a finite 65,536-element
+allowance selected by the application harness, file-owned CLI/MCP session and
+artifact verifiers.
+Explicit harness environment selections take precedence. This keeps canonical
+workflow assertions reachable for large retained observations. Admission-policy
+tests launch the public server with the resource setting unset or explicitly
+selected, including the default structured-input boundary and continued-service
+checks. Downstream capacity fixtures select enough finite transport allowance
+to reach their original memory, depth, cycle or representation boundary; retain
+those stronger assertions.
+
 When a matrix already holds a named tool definition from live `tools/list`,
 pass that definition through the SDK's `toolDefinition` call option. This keeps
 the selected output-schema validation without eagerly compiling unrelated
@@ -839,8 +884,15 @@ Native, provider, fixture, SQLite compatibility, and website lanes wait for
 the fast static checks (typecheck, built lint, and format) to succeed before
 allocating their runners. Knip, duplication, architecture guards, test
 discovery, and the Python producer run in the separate full-tier deep static
-job and do not gate provider admission. Portable test shards and documentation
-checks remain independent of static results, so they can still provide
+job and do not gate provider admission. On the fast tier, changes to Python
+bridges, analysis-efficiency inputs, or the Python test runner select a separate
+required Python job. That job installs locked dependencies and prepares the
+compiled runtime before the suite, because analysis-efficiency checks import
+built process modules. Bridge tests are discovered from the source tree. The
+mitmproxy, native, and pwndbg families must each contain a test module and
+execute at least one non-skipped case or subtest. A parent case with only skipped
+subtests does not satisfy this requirement. A newly added failing test fails the job.
+Portable test shards and documentation checks remain independent of static results, so they can still provide
 diagnostic feedback. The required gate rejects skipped selected lanes when
 static checks fail; on the full tier it also requires the deep static job.
 Passing revisions retain all selected coverage. This ordering reduces peak
@@ -1009,7 +1061,7 @@ prove behavior on the verified Ghidra 12.1.4 and JDK 21 build.
 | `npm run verify:ghidra`                    | Linux x64/arm64 ELF or macOS x64/arm64 Mach-O                                                                    | Host C compiler, Ghidra 12.1.4, and full JDK 21                             |
 | `npm run verify:ghidra:seeds`              | POSIX; raw x86 fixture; seed ordering, BSS labels, analyzer readback, not-applicable and unknown analyzer names  | Ghidra 12.1.4 and full JDK 21                                               |
 | `npm run verify:ghidra:swift`              | macOS x64/arm64 Mach-O                                                                                           | Host Swift compiler, Ghidra 12.1.4, and full JDK 21                         |
-| `npm run verify:ghidra:riscv`              | Linux/macOS x64/arm64 host; source-owned RV32/RV64 ELF through CLI and MCP                                       | RISC-V Clang, LLD, LLVM readelf, Ghidra 12.1.4, and full JDK 21             |
+| `npm run verify:ghidra:riscv`              | Linux/macOS x64/arm64 host; source-owned RV32/RV64 double-float and RV32 ilp32 ELF through CLI and MCP           | RISC-V Clang, LLD, LLVM readelf and objdump, Ghidra 12.1.4, and full JDK 21 |
 | `npm run verify:ghidra:switch`             | Linux x64 ELF; GCC/Clang optimized and stripped switch fixtures                                                  | GCC, Clang, GNU nm/objdump/strip, Ghidra 12.1.4, and full JDK 21            |
 | `npm run verify:ghidra:aarch64-jump-table` | Any supported Ghidra host; AArch64 ELF; signed/unsigned byte/halfword tables; host ARM64 Mach-O                  | Clang with AArch64 target support, Ghidra 12.1.4, and full JDK 21           |
 | `npm run verify:ghidra:cross-format`       | Any supported Ghidra host; also analyzes AArch64 ELF, x86-64 PE, and x86-64 Mach-O                               | `clang`, LLD, and `lld-link` in addition to host-lane prerequisites         |
@@ -1418,6 +1470,11 @@ cached byte spans and a Ghidra comparison. See the [Linux report](https://github
 for measured scope and limitations. Windows, PE and universal Mach-O remain
 unverified by this lane.

+Kuna 1.986 passed the fixture and a separate small, source-owned Mach-O with
+symbols and stripped on macOS arm64, including the Ghidra comparison and owned
+cleanup. Linux and other hosts have not been verified with 1.986; this check is
+not a repeat of the larger 1.833 matrix.
+
 ## DOS Ghidra analysis

 `npm run verify:ghidra:dos` requires the supported Ghidra and JDK installation
@@ -1488,8 +1545,9 @@ real-provider coverage.
 For source-identity boundaries that a normal single-file import cannot create,
 `tests/conformance/ghidra/ReaFileOffsetSourceProbe.java` exercises the production
 bridge against real Ghidra `FileBytes`. It rejects auxiliary and partial sources,
-checks the original target's round trip, and retains ambiguity when duplicate
-target bytes have distinct loaded mappings. Injected decompiler failures and
+keeps distinct outcome codes for uninitialized and unmapped addresses, checks
+the original target's round trip, and retains ambiguity when duplicate target
+bytes have distinct loaded mappings. Injected decompiler failures and
 cancellation verify that completed source/function resolution facts and backend
 failure codes survive; these injections do not establish natural engine failures.
 On Windows, after creating the
@@ -1558,30 +1616,44 @@ initial proposal measures only leaf producer-test omissions; it does not promise
 the savings of a broader affected-test planner.

 `scripts/ci/plan.mjs` selects lanes using the ownership table in
-`scripts/ci/scopes.mjs`. Provider implementation changes run their real-provider
-verifiers and the Linux x64 installed-package/Inspector baseline. The `apple`
-scope owns the Apple artifact lane; the `package` scope owns the multi-host
+`scripts/ci/scopes.mjs`. Each lane record owns its path and test selection
+rules and required fast/full jobs; workflow contract tests verify the mapped jobs.
+Provider implementation changes run their real-provider verifiers and the Linux
+x64 installed-package/Inspector baseline. The `apple` scope owns the Apple artifact lane; the `package` scope owns the multi-host
 package matrix and the Windows curated lane, including Windows native controls,
 Inspector, setup, configuration and packaging entrypoints. Runtime sources under
 `src/` or `bridge/` without an owner, and the authored skill, run the Linux suite
 and the Linux x64 installed-package/Inspector baseline only. Test-only changes
 run the Linux suite without native package verification, except test files that
 the Apple or Windows curated lanes invoke explicitly, which also select that
-lane. Edits to verifier entrypoints run only by manual, licensed or self-hosted
+lane. Packet-capture and signal-recording tests and their producers select the
+corresponding real-tool lane; both also run in full qualification. The shared
+Linux resource-limit source and its tests select both. Each lane requires
+its Linux kernel resource-limit cases and all seven descriptor-cleanup cases to
+pass in the focused Vitest report. A missing report, missing case, skipped case,
+or duplicate identity fails the lane; unrelated host-specific skips remain
+allowed. These tests use synthetic producers. The separate real TShark or
+sigrok verifier establishes the actual-tool observation. Edits to verifier entrypoints run only by manual, licensed or self-hosted
 workflows run static checks and the Linux suite. Website changes run website
 checks. Provider workflow changes validate the workflow and run that provider's
 verifier. Changes under `bridge/ghidra/` also select the `ghidra_bridge` lane,
 which compiles the packaged bridge sources against the pinned Ghidra 12.1.4
-jars with `npm run verify:ghidra:bridge-sources`. It never launches Ghidra or
-imports a target, so a missing import fails the PR instead of every Ghidra
-session. The launcher, compiler and package checks share named required source
+jars with `npm run verify:ghidra:bridge-sources`. That compile step never
+launches Ghidra or imports a target, so a missing import fails the PR instead
+of every Ghidra session. The launcher, compiler and package checks share named required source
 roles. The manifest must match the complete Java cohort, so deleting a helper
 or adding an unregistered dependency cannot silently change the shipped set.
 The preflight reuses the provider's Java Properties parser with the pinned Node
 toolchain's native type stripping, without an npm install or runtime build.
 The shared release policy owns the verified version and JDK major. CI checks
 the archive pin before downloading and verifies the extracted SDK version;
-changes to these source owners also select the compile lane.
+changes to these source owners also select the compile lane. After compiling,
+the lane launches headless Ghidra on source-owned instruction bytes with
+`-noanalysis`. The ARM/Thumb probe sets each instruction's mode explicitly and
+checks the bridge's decoder-context readback. The decode probes check that
+`ARM:LE:32:Cortex`, `ARM:LE:32:v8-m` and `Xtensa:LE:32:default` decode their
+bytes from each language's default context. The bytes are never executed, and
+edits to those probe scripts also select the lane.
 Manual-provider/Android workflow changes run workflow validation only.
 The four-version SQLite compatibility matrix has its own `sqlite` scope for
 SQLite implementation, contracts, CLI/MCP registration, fixtures, and shared
@@ -1729,6 +1801,10 @@ The Apple artifact CLI/MCP lane uses one `macos-15` job to avoid adding demand
 for scarce macOS runner capacity. It runs the artifact-format and metadata
 verifiers, followed by one consolidated focused invocation containing all
 existing native and process-boundary regression paths.
+The real native provenance verifier checks CLI/MCP agreement on complete
+per-slice encryption absence. The encryption CLI regression builds a universal
+image, marks its owned arm64 command with `cryptid=1`, and compares the reported
+range with `otool`; this verifies declared metadata, not actual FairPlay data.

 The Linux source-test shards download a shared runtime and generated test
 metadata snapshot produced by the build job with `npm run test:prepare`. The
@@ -1831,8 +1907,8 @@ Portable owner-based test selection remains observational. Its reports compare
 proposed omissions with the full run; incomplete or skipped observations do not
 establish that fewer tests would preserve regression detection.

-The nine automatic browser, binary-layout, EVM, JavaScript-recovery,
-recorded-crash, web and environment-bundle provider lanes download
+The automatic browser, binary-layout, EVM, JavaScript-recovery, packet-capture,
+signal-recording, recorded-crash, web and environment-bundle provider lanes download
 `rea-build-cache` from their own run after the build and static jobs succeed. Their existing build commands still
 validate task hashes and rebuild mismatched inputs; provider observations always
 run. Provider-workflow-only edits also admit the build without enabling source
@@ -1950,6 +2026,33 @@ unknown chunks, depth limits and extracted child digests. The optional
 Neither optional toolchain is a base-lane prerequisite. See
 [firmware analysis](firmware-analysis.md) for limits and unverified formats.

+`npm run verify:esp-images` requires a Clang with the RISC-V target and
+`ld.lld` (`REA_RISCV_CLANG`, `REA_RISCV_LLD`) and a Python that runs esptool
+and espsecure (`REA_ESPTOOL_PYTHON`). It builds ESP32-C3 app and bootloader
+ELF files from `tests/conformance/esp/`, converts them with `esptool
+elf2image`, including `--secure-pad-v2`, `--ram-only-header` and
+`--pad-to-size`, signs one with RSA, ECDSA P-256 and P-384 keys, and compares
+REA's facts with `esptool image-info` and `espsecure signature-info-v2`. It
+compares extracted segments and signature blocks with the producer's bytes,
+and derives malformed images and ESP8266 v1 and v3 images. It checks each
+tool before building and warns when esptool is not the pinned v5.6.0.
+`REA_XTENSA_ESP32_GCC` adds an ESP32 Xtensa build. See
+[ESP images](esp-image.md).
+
+`npm run verify:uf2` needs only a Python that runs esptool, named by
+`REA_ESPTOOL_PYTHON` (default `python3`). It writes inputs at known addresses,
+builds UF2 files with esptool's `merge-bin --format uf2` (v4 `merge_bin`) with
+and without MD5 and with 256-byte payloads, and concatenates two chips'
+outputs. Inspection and extraction through the built CLI must return each input
+at its address under the familyID esptool itself reports. It is not part of CI.
+See [UF2 and DfuSe images](uf2-dfuse.md).
+`npm run verify:esp-flash` needs the same tools and an ESP-IDF checkout
+(`REA_ESP_IDF_PATH`) for `gen_esp32part.py` and `otatool.py`. It builds
+partition tables, assembles dumps with `esptool merge-bin`, writes OTA records
+with otatool through `tests/conformance/esp/flash_file_tool.py`, and compares
+REA's flash facts with `image-info`, the decoded table and
+`otatool read_otadata`. See [ESP flash images](esp-flash-image.md).
+
 ### JavaScript source recovery

 Build once with `npm run build:cached`, then run `npm run verify:javascript:recovery`.
@@ -48,6 +48,57 @@ fixture servers. Custom orchestration languages, replay engines, or separate
 prepare/execute plans need an observed requirement those primitives cannot
 satisfy. A plan without execution does not establish runtime behavior.

+## Exercise the analyst workflow
+
+Before defining a new provider-backed tool, state the analyst's question, what
+they already have, the intended result and authority, and what must remain
+unknown. Try the nearest existing REA workflow and the relevant native provider
+or ordinary script path when available. Identify the specific gap and what a
+new or extended contract would add; upstream capability alone does not require
+a new tool or equal support from every provider.
+
+Exercise the task through REA as a whole and compare relevant provider behavior
+with an independent artifact or format observation where possible. Use the
+caller's selected target and authority. Record the provider version, target and
+observed coverage, and distinguish an unsupported operation from an empty
+result or an untested path.
+
+Include the boundary cases that could change the answer: provider labels versus
+source facts, addresses versus file locations, partial results, and a useful
+recovery after failure or session close when those apply to the task. Check that
+composed results keep each observation's identity, limitations and source
+association. Existing real-provider lanes and focused tests establish their
+selected scenarios; they do not by themselves establish a different workflow or
+provider equivalence. If a provider cannot be exercised, report that limitation
+and continue with the available evidence. Measure agent tool selection only with
+an actual agent evaluation; a scripted tool sequence does not establish it. Use
+[testing guidance](testing.md#provider-backed-workflow-verification) to select
+the cases that establish the proposed contract.
+
+## Audit existing tools
+
+Scope an audit by analyst tasks and the caller's target, providers and authority.
+Record the source revision and, when used, the running server, catalog and
+provider versions; a connected server can differ from the current checkout.
+Inspect the live CLI help or MCP descriptions and schemas alongside the owning
+contracts and documentation. Choose representative tasks and their nearest REA
+and native alternatives rather than counting upstream commands.
+
+Exercise the selected public workflows, including the steps before and after a
+tool call. Check task selection, input choices, returned facts and their source,
+partial or unsupported outcomes, and applicable session and recovery behavior.
+Compare native provider output and an independent artifact observation where
+available. Inspect existing tests and real-provider lanes for the scenario they
+actually cover; a passing test does not establish a different task or host.
+Use [workflow verification](testing.md#provider-backed-workflow-verification)
+for counterexamples and lifecycle controls relevant to the audit.
+
+Report working routes as well as findings. Separate a reproduced contract bug,
+an intentional limitation, a design opportunity and an unverified hypothesis;
+include the smallest useful reproduction, impact and coverage limits. Do not
+claim autonomous-agent selection from a scripted trace. Check related reports
+before proposing another issue, and avoid treating lack of API parity as a bug.
+
 ## Define the contract

 - Use strict inputs with explicit target identity and required fields. Preserve
@@ -83,6 +134,51 @@ satisfy. A plan without execution does not establish runtime behavior.
  ceiling and its recovery as described in
  [admission limits and recovery](design/limits-and-recovery.md).

+### Compose declared Evidence inputs
+
+Declare each logical Evidence source with the shared `evidenceInputSchema`:
+complete inline Evidence or an exact
+`{kind: "retained-evidence", evidence_id}` reference. Use that declaration in
+single, optional, array and nested source fields across domains. Keep complete
+record schemas for stored Evidence, bundle records and pure semantic inputs;
+request alternatives do not change those representations. Ordinary IDs in
+parameters or result data are not implicitly source selectors.
+
+Derive borrowing request validation and source resolution from the canonical
+request schema with `getEvidenceInputContract` and `resolveEvidenceRequest`.
+The shared application entrypoint selects references for CLI and MCP before the
+format owner admits, authenticates and interprets their records. Preserve
+admission before copying large source payloads. Do not maintain a second list
+of source paths or resolve references only in an adapter. A resolved reference
+has the same identity, caller-selected observations, provenance, coverage and
+partial or unknown facts as its complete inline record; it never reruns a
+producer or upgrades incomplete evidence.
+Keep Evidence-bearing request unions outside skipping `default` wrappers;
+use `prefault` when a default must pass through branch selection. Catalog
+conformance rejects unsupported source containers rather than silently losing
+their references.
+
+Return authenticated source records alongside derived workflow Evidence when
+the adapter must retain them. Keep links to those exact sources and require the
+source closure when the workflow follows their links. Missing references and
+incompatible workflow roles are explicit failures; do not infer a substitute
+from ledger order, display names or the active target. A summary or inspection
+page has its own identity: consumers needing complete source facts use its
+`normalized_result.parent_evidence_id`, unless their contract explicitly accepts
+that view.
+
+New provider-owned source observations require a retention owner. Existing
+caller-owned inputs can also compose on a fixed port without a recorder;
+when a recorder is available, preserve its acceptance or rejection and retain
+completed sources through cancellation.
+
+MCP supplies the current ledger lookup. CLI commands that advertise
+`--evidence-bundle` use one explicitly selected, authenticated bundle for the
+command's lifetime. Keep cleanup with that owner. A retained reference does not
+grant filesystem access: file selectors remain separate, explicit contracts
+where supported. See [retained Evidence inputs](mcp-contracts.md#retained-application-evidence-inputs)
+and [CLI reuse](cli.md#import-export-and-compare-evidence).
+
 ### Interpret boundary facts once

 The format or protocol reader owns interpretation. Pass its parsed facts and
@@ -0,0 +1,224 @@
+# UF2 and DfuSe images
+
+REA inventories UF2 (Microsoft's USB Flashing Format) and DfuSe (ST's DFU
+update container, `.dfu`) files through `inspect-artifact` /
+`inspect_artifact`, and materializes their decoded bytes through
+`extract-artifact` / `extract_artifact`. UF2 is the drag-and-drop format of the
+RP2040 and RP2350 bootloaders, of TinyUF2 on ESP32-S2 and ESP32-S3, and of
+`esptool merge-bin --format uf2`. Decoding is static and needs no external tool.
+
+```sh
+rea inspect-artifact ./firmware.uf2 --json
+rea inspect-artifact ./firmware.dfu --detail summary --evidence_output evidence.json --json
+rea extract-artifact ./firmware.uf2 --json
+```
+
+For MCP, open the file with `open_binary`, then call `inspect_artifact`. Summary
+delivery retains the complete Evidence; use `parent_evidence_id` with
+`inspect_analysis_view` to read selected regions and fields. `extract_artifact`
+returns a fresh `output_root` containing one raw file per region.
+
+## Recognition
+
+A file is UF2 only when its first 512 bytes are a complete block with all three
+magic numbers: `0x0A324655` and `0x9E5D5157` at the start and `0x0AB16F30` at
+the end. A file is DfuSe only when it begins with `DfuSe` and format version 1
+and ends with a 16-byte DFU 1.1a suffix: `bcdDFU` `0x011A`, the `UFD` signature
+and `bLength` 16. The suffix CRC is not part of recognition. The file name does
+not matter, and a file with only one of the DfuSe markers stays unrecognized.
+The container formats are `uf2` and `dfuse`.
+
+## UF2 regions and metadata
+
+Each entry is one address-contiguous region of one family's main-flash
+payloads, named `family-0x<familyID>/0x<start>-0x<end>.bin` with an inclusive
+end address, for example `family-0xe48bff56/0x10000000-0x1000ffff.bin`. Blocks
+without the familyID flag (`0x2000`) go under `no-family/`. Families are
+separate address spaces: a multi-family file, such as a Pico SDK image for both
+RP2040 and RP2350, has a region per family even at the same addresses. Gaps are
+never filled.
+
+Region `format_metadata` (`uf2-region`) records `family_id` (or `null`),
+`family_name`, `start_address`, `end_address`, `length`, `block_count`, and
+`first_file_block`/`last_file_block`: the zero-based positions in the file of
+the contributing blocks, not their UF2 block numbers. `family_name` is REA's
+label, not file content. It comes from a small table copied from Microsoft's
+`uf2families.json` at commit
+[`cf3bd7f9`](https://github.com/microsoft/uf2/blob/cf3bd7f9c274b949528f8cd6a19eef2502a687d2/utils/uf2families.json),
+which the root's `family_name_registry` names. The table covers the ESP32
+family, ESP8266, RP2040, the RP2350 and RP2XXX download families, STM32F4,
+nRF52840, SAMD21 and SAMD51. It also covers the families that LibreTiny builds
+for and the registry lists: RTL8710A, RTL8710B, RTL8720C, RTL8720D, BK7231U,
+BK7231N, BK7251 and BL602. Other IDs, LibreTiny's LN882H among them, keep their
+value with `family_name: null`. A familyID names a target family; it does not
+establish the CPU state, memory map or entry point.
+
+Root `format_metadata` (`uf2`) records:
+
+| Field                                                      | Meaning                                                                                                                |
+| ---------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- |
+| `block_count`, `trailing_bytes`                            | Complete 512-byte blocks, and bytes after the last complete block                                                      |
+| `invalid_block_count`                                      | Blocks with a wrong magic number, a payload over 476 bytes, or a payload that wraps past 4 GiB                         |
+| `flash_block_count`                                        | Valid main-flash blocks, the only source of region bytes                                                               |
+| `not_main_flash_block_count`, `file_container_block_count` | Blocks with flag `0x1`, and blocks with flag `0x1000`                                                                  |
+| `md5_block_count`, `extension_tag_block_count`             | Blocks that declare an MD5 flash region (`0x4000`) or extension tags (`0x8000`)                                        |
+| `family_count`, `family_name_registry`                     | Distinct familyIDs among main-flash blocks, and the registry revision of `family_name`                                 |
+| `numbering_group_count`                                    | Groups of valid blocks that share a familyID (or none) and a declared block count                                      |
+| `missing_block_count`                                      | Block numbers below a group's block count that no valid block carries                                                  |
+| `ambiguous_numbering_group_count`                          | Groups whose numbers appear at unequal counts of target addresses                                                      |
+| `repeated_block_count`, `out_of_order_block_count`         | Blocks whose number already appeared in their group, and blocks numbered at or below the previous block of their group |
+| `block_number_out_of_range_count`                          | Blocks numbered at or above their block count, or with a block count of 0                                              |
+| `region_count`, `data_bytes`, `duplicate_bytes`            | Regions, unique decoded bytes, and bytes rewritten with identical values                                               |
+
+Numbering is grouped by familyID because a bootloader ignores every field of
+another family's block, including its numbering. Within a group, a block number
+seen at several target addresses belongs to several copies of a sequence:
+esptool numbers each merged input file from 0, so inputs with equal block
+counts share a group, and each number then appears once per input. A block sent
+twice to the same address is one block. A group is complete when every number
+below its block count is present at the same count of addresses. If some numbers
+appear at more addresses than others, a copy may have lost a block, so coverage
+is unknown and a limitation names the group.
+
+## UF2 facts, limitations and failures
+
+| Situation                                                     | Outcome                                                                                        |
+| ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
+| Blocks out of address order                                   | Sorted into regions                                                                            |
+| Blocks numbered at or below the previous block of their group | Counted in `out_of_order_block_count`; the spec lets blocks arrive in any order                |
+| An address written twice with the same value in one family    | Accepted and counted in `duplicate_bytes`                                                      |
+| An address written twice with different values in one family  | Fails, naming the family, the address and the block spans of both writes                       |
+| The same addresses in different families                      | Separate regions; never a conflict                                                             |
+| Numbered blocks absent from a group                           | Regions are returned; coverage is unknown and a limitation names the groups                    |
+| Reused numbers at unequal address counts                      | Regions are returned; coverage is unknown and a limitation names the groups                    |
+| An invalid block                                              | Excluded; coverage is unknown and a limitation names the first one and its offset              |
+| A partial final block                                         | Excluded; coverage is unknown and the file may be truncated                                    |
+| Block numbers at or above the block count                     | Payloads are kept; coverage is unknown                                                         |
+| Not-main-flash blocks (`0x1`)                                 | Excluded from regions; their count and payload byte count are reported; coverage is unaffected |
+| File-container blocks (`0x1000`)                              | Excluded from regions; their files are not reconstructed, so coverage is unknown               |
+| MD5 (`0x4000`) and extension-tag (`0x8000`) blocks            | Counted and reported as a limitation; neither is decoded or verified                           |
+
+Unlike a malformed Intel HEX record, which fails the whole file, an invalid UF2
+block is excluded and reported: each block carries its own framing and address,
+so its neighbours stay readable.
+
+The MD5 structure is not checked because it is not a checksum of the block's
+bytes in the file. It names a region of device flash, usually aligned to erase
+pages, whose MD5 a flashing tool compares to skip writing. Producers also
+disagree on its place: the specification puts it in the last 24 bytes of the
+data area, while esptool v4.12.0 and v5.6.0 write it right after a shorter final
+payload, so those 24 bytes hold zeros or part of that structure.
+
+## DfuSe regions and metadata
+
+Each element is one entry at its own file range, named
+`target-<t>/element-<e>-0x<start>-0x<end>.bin` with zero-based target and
+element indexes, for example `target-0/element-0-0x08000000-0x0800ffff.bin`.
+Elements are never merged. Each occurrence's `source_location` is the byte range
+of the element data in the file.
+
+Element `format_metadata` (`dfuse-element`) records `target_index`,
+`alternate_setting`, `target_name`, `element_index`, `start_address`,
+`end_address` and `length`. `target_name` is `null` when `bTargetNamed` is 0;
+otherwise it is `szTargetName` up to its first NUL, one character per byte.
+`compare_artifacts` treats an element's alternate setting and target name as
+its declaration, so the same bytes moved to another device memory are
+`changed` in `metadata`.
+
+Root `format_metadata` (`dfuse`) records:
+
+| Field                                                | Meaning                                                                         |
+| ---------------------------------------------------- | ------------------------------------------------------------------------------- |
+| `image_size`, `target_count`                         | `DFUImageSize` and `bTargets` from the prefix                                   |
+| `element_count`, `empty_element_count`, `data_bytes` | All elements, elements of 0 bytes (which have no entry), and element data bytes |
+| `overlapping_element_count`                          | Elements that overlap an earlier element of the same alternate setting          |
+| `device_version`, `product_id`, `vendor_id`          | `bcdDevice`, `idProduct` and `idVendor` from the suffix                         |
+| `suffix_crc`, `computed_crc`                         | The stored `dwCRC`, and the same CRC computed over every byte before it         |
+
+Recognition already requires `bVersion` 1 and `bcdDFU` `0x011A`, so they are
+not repeated. The DFU suffix CRC is CRC-32 without the final inversion, as
+dfu-util stores and checks it.
+
+Producers disagree on `DFUImageSize`. UM0391 calls it the file length, and
+dfu-util's `dfuse-pack.py` writes that value since commit `ee6b393d`
+(2020-10-08). Earlier `dfuse-pack.py` and MicroPython's `tools/dfu.py`
+(checked at `cb99ca98`) write the length before the suffix, and an ST community
+report describes ST's DfuFileMgr the same way; REA has not run DfuFileMgr.
+dfu-util's own parser ignores the field. REA accepts either value and keeps the
+declared one in `image_size`.
+
+## DfuSe facts, limitations and failures
+
+| Situation                                                                          | Outcome                                                                                             |
+| ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- |
+| `dwCRC` differs from the computed CRC                                              | Follows `integrity_policy`, below                                                                   |
+| A target without the `Target` signature                                            | Fails with its byte offset                                                                          |
+| `DFUImageSize` that equals neither the file length nor the bytes before the suffix | Fails with the declared size, the suffix offset, the file length and whether the suffix CRC matches |
+| A target size or an element size that disagrees with the bytes that hold it        | Fails with the byte offset and the declared and available sizes                                     |
+| An element whose address range wraps past `0xFFFFFFFF`                             | Fails with its byte offset                                                                          |
+| Overlapping elements of one alternate setting                                      | Kept as separate entries; a limitation names the first four; coverage is unaffected                 |
+| The same addresses in different alternate settings                                 | Separate entries; an alternate setting selects a device memory                                      |
+| Elements of 0 bytes, and targets with no elements                                  | No entry; counted; a limitation names the first four, with address and alternate setting            |
+
+A CRC mismatch is an integrity contradiction, never proof of a cause. With the
+default `integrity_policy` `fail`, inspection and extraction fail with
+`artifact_integrity_mismatch`, whose details carry `algorithm: "dfu-crc32"`,
+`declared_crc32` and `calculated_crc32`. With `record-and-continue`
+(CLI `--integrity-policy record-and-continue`), the root occurrence becomes
+`mismatched`, `integrity_contradictions` records the pair for logical path `.`,
+and extraction carries that contradiction, because every element came from the
+contradicted container. The root occurrence has no `declared_integrity`: that
+field holds entry digests, so the declared CRC appears in the contradiction and,
+as a number, in `suffix_crc`. Under `fail`, the elements are hashed before the
+mismatch is raised.
+
+## Limits
+
+Each file must be at most 128 MiB. The UF2 decoder reserves at most 476 bytes
+per complete block before reading, merges payloads into regions of at most the
+same total size, and keeps one numbering entry per valid block, so its peak is
+about twice the decoded bytes. It retains at most 65,536 regions as entries; the
+order of blocks does not count against that bound. The DfuSe decoder holds the
+file once, serves elements as views of it, and retains at most 65,536 elements
+with bytes as entries; empty elements are only counted. These are fixed
+resource bounds, not format limits, and fail as limits (`file-size` and
+`capacity`) with no runtime override. Configurable ceilings are tracked in
+[#6176](https://github.com/morluto/rea/issues/6176).
+
+Decoded regions are cached only for the reader's lifetime, and each open checks
+the admitted carrier identity again. These readers share the Intel HEX
+reader's region streams, cancellation and close behavior.
+
+## Analyzing a region
+
+Inventory does not establish the CPU, byte order or memory map, or an entry
+point. To disassemble a region, extract it and open the region file with
+`open_binary` using format `raw-binary`, an architecture you choose, and
+`entry_point` set to the region start address; raw-binary maps file offset 0 at
+`entry_point`. Each region is opened separately, so references between regions
+are not resolved.
+
+## Verification
+
+Fixtures written from the UF2 specification and from ST UM0391 cover block and
+element layouts, numbering groups and reused numbers, families, rewrites and
+conflicts, invalid and partial blocks, not-main-flash and file-container blocks,
+structural faults, overlaps, both integrity policies, accepted boundaries beside
+each refusal, resource refusals, inventory, extraction, comparison and reader
+identity checks. The reader lifecycle (cancellation, close and stream
+ownership) is covered by the Intel HEX reader tests, which exercise the shared
+reader. Two DfuSe fixtures are byte-identical, CRC included, to what the
+`build()` functions of dfu-util's `dfuse-pack.py` (at `f9a537c9`) and
+MicroPython's `tools/dfu.py` (at `cb99ca98`) produce for the same image, one for
+each `DFUImageSize` convention. Those functions were transcribed and run under
+Python 3; the scripts themselves were not run. CLI and stdio MCP tests exercise
+the same artifact provider and advertised schemas.
+
+`npm run verify:uf2` runs esptool's `merge-bin --format uf2` on generated
+inputs at known addresses, with and without MD5, with 256-byte payloads, with
+two inputs of equal block count, and on a concatenation of two chips' outputs.
+Inspection and extraction must return every input at its address under
+esptool's own familyID. It passed with esptool v4.12.0 and v5.6.0 on macOS. Set
+`REA_ESPTOOL_PYTHON` to a Python that runs `-m esptool`. Pico SDK, picotool,
+`uf2conv.py`, TinyUF2 and real DfuSe producers remain unverified, and no device
+accepted these files in REA's tests.